从零开始：H20服务器上DeepSeek R1 671B大模型部署与压力测试全攻略

前言

最近，我有幸在工作中接触到了DeepSeek R1 671B模型，这是目前中文开源领域参数量最大的高质量模型之一。DeepSeek团队在2024年推出的这款模型，以其惊人的6710亿参数量和出色的推理性能，引起了业界广泛关注。

作为一名AI基础设施工程师，我有机会在H20服务器上部署这个庞然大物，并对其进行了全面的压力测试。这篇文章将详细记录我的部署过程和性能测试方法，希望能为大家提供一些参考。

💡 为什么选择DeepSeek R1？

超大规模参数量（671B）
优秀的中英文理解能力
开源可商用的许可证
在多项基准测试中表现优异

那么，如何在自己的服务器上部署这个"巨无霸"模型呢？接下来，我将分享我的完整操作流程。

一、环境准备

1.1 硬件配置

在开始部署之前，先来看看我使用的硬件配置：

服务器型号：H20
GPU：8×NVIDIA H20 (141GB)
CPU：双路Intel至强处理器
内存：2TB
存储：高速NVMe SSD

这套配置对于部署671B参数的模型来说是刚好够用的。根据我的经验，至少需要8张高端GPU才能满足推理需求。

1.2 环境检查

首先，确认系统资源是否满足需求：

# 检查CPU信息
lscpu

# 检查GPU信息
nvidia-smi

# 检查内存信息
dmidecode -t memory

# 检查磁盘空间
df -h

这次试用的H20是141G显存的PCIE版本。8张GPU之间都是通过NV18(18条NVLink)互联,形成了全互联(fully connected)的网络拓扑,GPU0-3属于NUMA节点0 (CPU核心0-55,112-167),GPU4-7属于NUMA节点1 (CPU核心56-111,168-223),单卡总带宽：26.562 × 18 ≈ 478 GB/s

特别注意：部署DeepSeek R1 671B至少需要700GB的磁盘空间用于存储模型文件，请确保有足够空间。

1.3 软件环境配置

我选择使用Apptainer（原Singularity）作为容器运行环境，它比Docker更适合HPC场景，在多GPU协作方面表现更好。

# 安装Apptainer
sudo add-apt-repository -y ppa:apptainer/ppa
sudo apt update
sudo apt install -y apptainer

# 检查安装版本
apptainer --version

二、模型获取与存储

2.1 模型下载

DeepSeek R1 671B模型可以从官方渠道下载，但文件非常大。在我的案例中，模型已预先下载并存储在 /data0/DeepSeek-R1/ 目录下。

2.2 模型完整性验证

下载完成后，务必验证模型文件的完整性：

cd /data0/DeepSeek-R1
# 验证模型文件的MD5值
md5sum model-00001-of-00163.safetensors

⚠️ 注意：模型文件可能分为多个部分，一定要验证所有文件的完整性，避免因文件损坏导致的启动失败。

三、服务部署

对于超大规模模型，我测试了两种主流的部署方式：基于vLLM和基于SGLang的部署。

3.1 基于vLLM的部署

vLLM是一个高性能的大语言模型推理引擎，专为LLM优化，支持PagedAttention等技术，内存使用效率高。

3.1.1 获取vLLM容器镜像

mkdir -p /data0/ctyun/vllm
cd /data0/ctyun/vllm
wget https://jiangsu-10.zos.ctyun.cn/galaxy/apptainer/vllm/vllm-openai_v0.7.3.sif

3.1.2 创建启动脚本

vi run.sh

在脚本中添加以下内容：

#!/bin/bash
apptainer run --nv vllm-openai_v0.7.3.sif \
  python3 -m vllm.entrypoints.openai.api_server \
  --model /data0/DeepSeek-R1 \
  --tensor-parallel-size 8 \
  --host 0.0.0.0 \
  --port 8000

这里的关键参数是--tensor-parallel-size 8，表示使用8卡张量并行，这对于671B规模的模型是必须的。

3.1.3 启动服务

sh run.sh

vllm服务启动成功后，每块显卡的显存已经占用了122G。

成功启动后，vLLM会提供一个兼容OpenAI API格式的接口，默认端口为8000。

3.2 基于SGLang的部署

SGLang是另一个优秀的LLM推理框架，特别在批处理方面有一些独特优势。

3.2.1 下载SGLang容器镜像

mkdir -p /data0/ctyun/sglang
cd /data0/ctyun/sglang
wget https://jiangsu-10.zos.ctyun.cn/galaxy/apptainer/sglang/sglang_v0.4.3-cu125.sif

3.2.2 创建启动脚本并运行

vi run.sh
# 配置SGLang启动参数
#!/bin/bash

# SGLang Server Startup Script
# Environment configuration
export OMP_NUM_THREADS=14
export NCCL_IB_DISABLE=1
export CUDA_VISIBLE_DEVICES="0,1,2,3,4,5,6,7"

# Model configuration
CONTAINER_PATH="/data0/ctyun/sglang/sglang_v0.4.3-cu125.sif"
WORKSPACE_DIR="/data0/ctyun/sglang/workspace" 
MODELS_DIR="/data0/DeepSeek-R1"
MODEL_NAME="DeepSeek-R1"

# Create workspace directory if it doesn't exist
mkdir -p "$WORKSPACE_DIR"

# Server Configuration
SGLANG_HOST="0.0.0.0"
SGLANG_PORT=8000

# Performance Configuration
TENSOR_PARALLEL_SIZE=8
TOKENIZER_MODE="auto"
LOG_LEVEL="info"

echo "Starting SGLang server with model: $MODEL_NAME"
echo "Using GPUs: $CUDA_VISIBLE_DEVICES with TP size: $TENSOR_PARALLEL_SIZE"

# Run the SGLang container with Apptainer/Singularity
# Use the LOCAL_PYTORCH_MODEL format to specify a local model
apptainer run --nv \
    --bind "$WORKSPACE_DIR:/workspace" \
    --bind "$MODELS_DIR:/model" \
    "$CONTAINER_PATH" \
    python3 -m sglang.launch_server \
    --model-path "/model" \
    --tokenizer-path "/model" \
    --host "$SGLANG_HOST" \
    --port "$SGLANG_PORT" \
    --tensor-parallel-size "$TENSOR_PARALLEL_SIZE" \
    --context-length 32768 \
    --mem-fraction-static 0.9 \
    --tokenizer-mode "$TOKENIZER_MODE" \
    --trust-remote-code \
    --log-level "$LOG_LEVEL"

# 启动服务
sh run.sh

🔔 小贴士：我发现vLLM在通用场景下表现更稳定，而SGLang在批处理场景下吞吐量略高。

SGLang明显占用显存一些，模型加载完成显存已经吃得差不多了。

四、压力测试工具准备

为了全面评估DeepSeek R1 671B的性能，我使用了三种不同的测试工具：LLMPerf、EvalScope和SGLang内置的benchmark工具。

4.1 LLMPerf测试工具安装

LLMPerf是一个专门针对大模型设计的性能测试工具：

mkdir -p /data0/ctyun/yangxian
cd /data0/ctyun/yangxian
git clone https://gitee.com/yangxianpku/llmperf.git

# 设置环境变量
export HF_ENDPOINT=https://hf-mirror.com
export OPENAI_API_KEY=secret_abcdefg
export OPENAI_API_BASE="http://localhost:8000/v1/"

4.2 EvalScope测试工具安装

EvalScope是另一个功能强大的评估工具，尤其适合模拟真实用户请求：

# 创建虚拟环境
python3 -m venv evalscope
cd evalscope/
source bin/activate

# 安装evalscope
pip install evalscope
pip install evalscope[perf]

4.3 SGLang测试工具安装

SGLang自带了性能基准测试工具，可以精确测量批处理性能：

python3 -m venv sglang
cd sglang/
source bin/activate
pip install "sglang[all]>=0.4.3" --find-links https://flashinfer.ai/whl/cu124/torch2.5/flashinfer-python

五、压力测试方案与结果

接下来是最激动人心的部分 - 压力测试！我设计了一系列测试场景，从单并发到高并发，从短文本到长文本生成，全方位评估模型性能。

5.1 使用LLMPerf进行吞吐量测试

首先，测试不同输入长度下的单并发性能：

# 输入8K tokens，输出1K tokens
python3 token_benchmark_ray.py --model "DeepSeek-R1" \
  --mean-input-tokens 8192 --stddev-input-tokens 0 \
  --mean-output-tokens 1024 --stddev-output-tokens 0 \
  --max-num-completed-requests 6 --timeout 600 \
  --num-concurrent-requests 1 --results-dir "result_outputs" \
  --llm-api openai --additional-sampling-params '{}'

然后，测试不同并发数下的性能表现：

# 64并发，输入4K tokens，输出1K tokens
python3 token_benchmark_ray.py --model "DeepSeek-R1" \
  --mean-input-tokens 4096 --stddev-input-tokens 0 \
  --mean-output-tokens 1024 --stddev-output-tokens 0 \
  --max-num-completed-requests 192 --timeout 600 \
  --num-concurrent-requests 64 --results-dir "result_outputs" \
  --llm-api openai --additional-sampling-params '{}'

测试结果分析：

单并发下，8K输入+1K输出的场景，平均吞吐量约为750 tokens/s
并发数增加到64时，总吞吐量可达2万 tokens/s左右
超过128并发后，性能提升不明显，甚至可能因资源竞争而下降

5.2 使用EvalScope模拟真实用户请求

EvalScope能模拟更接近真实场景的测试，我从低并发逐步提高到高并发：

# 单并发测试
evalscope perf --parallel 1 --url http://127.0.0.1:8000/v1/chat/completions \
  --model DeepSeek-R1 --log-every-n-query 5 --connect-timeout 6000 \
  --read-timeout 6000 --max-tokens 2048 --min-tokens 2048 \
  --api openai --dataset openqa --number 1 --stream

# 逐步提高并发
evalscope perf --parallel 192 --url http://127.0.0.1:8000/v1/chat/completions \
  --model DeepSeek-R1 --log-every-n-query 5 --connect-timeout 6000 \
  --read-timeout 6000 --max-tokens 2048 --min-tokens 2048 \
  --api openai --dataset openqa --number 192 --stream

测试发现：

对话模式下，流式输出(stream)的用户体验更好
并发提升到192时，延迟开始明显增加
输出token长度对吞吐量影响显著：
- 2048 tokens输出：约10K tokens/s总吞吐量
- 200 tokens输出：约25K tokens/s总吞吐量
- 50 tokens输出：约35K tokens/s总吞吐量

5.3 使用SGLang测试批处理性能

SGLang特别适合测试批处理能力：

# 测试不同批处理大小
python3 -m sglang.bench_one_batch_server --model DeepSeek-R1 \
  --base-url http://127.0.0.1:30000 --batch-size 1 \
  --input-len 128 --output-len 128

python3 -m sglang.bench_one_batch_server --model DeepSeek-R1 \
  --base-url http://127.0.0.1:30000 --batch-size 192 \
  --input-len 128 --output-len 128

批处理测试结果：

批处理大小=1：约800 tokens/s
批处理大小=32：约12K tokens/s
批处理大小=192：约28K tokens/s
批处理大小=512：约32K tokens/s（但延迟增加显著）

六、性能监控与调优

在测试过程中，持续监控系统资源使用情况非常重要：

# GPU监控
nvidia-smi

# 系统资源监控
htop
nvtop

# 进程监控
top

基于监控结果，我发现了一些性能优化的关键点：

GPU利用率：在高并发场景下，GPU利用率稳定在85%-95%之间最佳
CPU资源：预处理和后处理阶段会消耗大量CPU资源，建议使用高频CPU
内存使用：671B模型在8卡配置下，每卡大约需要64-70GB显存
网络带宽：高并发场景下网络可能成为瓶颈，建议使用高速网络接口

七、常见问题与解决方案

在部署过程中，我遇到了一些常见问题，分享解决方案：

7.1 资源冲突问题

如果系统中运行着其他Docker容器或进程，可能会与模型部署冲突：

# 停止Docker服务
systemctl stop docker.service
systemctl stop docker.socket

# 终止占用资源的Python进程
pkill python3
kill -9 [PID]

7.2 GPU不可见问题

有时容器内无法正确识别GPU：

# 检查NVIDIA驱动与CUDA版本兼容性
nvidia-smi

# 确保使用--nv参数启动Apptainer
apptainer run --nv ...

7.3 模型加载缓慢

DeepSeek R1 671B模型非常大，首次加载可能需要3-5分钟，请耐心等待。

7.4 内存溢出错误

如果出现OOM错误，可以尝试：

减小batch size
减小tensor_parallel_size（但可能需要更多显存）
使用模型量化版本（如FP8或INT8）

八、总结与建议

经过一系列测试，我对DeepSeek R1 671B模型有了更深入的了解：

硬件需求：8张高端GPU(如H20-141G)是基本配置，内存建议1TB以上
部署方式：vLLM在通用场景更稳定，SGLang在批处理场景优势明显
并发能力：最佳并发数在128-192之间，超过这个范围性能提升不明显
响应延迟：首token延迟约1-2秒，生成速度在单请求下750-800 tokens/s
吞吐量：在最佳配置下，整体吞吐量可达30K tokens/s左右

如果你计划在生产环境部署DeepSeek R1 671B，我的建议是：

使用张量并行（TP）而非流水线并行（PP）
针对真实业务场景进行针对性测试和优化
考虑使用模型量化技术降低资源需求
实现动态批处理以提高整体吞吐量

写在最后

通过这次DeepSeek R1 671B的部署之旅，我深刻体会到大模型服务化的挑战和乐趣。希望本文能帮助更多开发者了解如何部署和测试超大规模语言模型，也欢迎在评论区分享你的经验和问题。

你是否有部署超大模型的经历？遇到了哪些挑战？欢迎在评论区讨论！

关键词： DeepSeek R1, 671B, 大模型部署, vLLM, SGLang, 压力测试, GPU, 张量并行