從零開始：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 128python3 -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, 張量并行