从零开始：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, 张量并行
