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

前言

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

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

💡 为什么选择DeepSeek R1？

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

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

一、环境准备 1.1 硬件配置

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

服务器型号：H20GPU：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 jiangsu-10.zos.ctyun /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 jiangsu-10.zos.ctyun /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 gitee /yangxianpku/llmperf.git # 设置环境变量 export HF_ENDPOINT= hf-mirror 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 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, 张量并行