个人主页：chian-ocean

一、为什么选择这套方案?

1.1 技术背景

去年底DeepSeek发布的R1-671B模型在推理能力上取得了突破，但 6710 亿参数的体量简直是显存杀手。想在私有环境跑起来，要么砸钱买几十张卡，要么就得想办法“压榨”硬件。

这次实战用的是 vLLM-Ascend。选它理由很简单：它是 vLLM 官方“正规军”支持的后端，不是那种不知道哪天就断更的魔改版。实测下来，PagedAttention 把显存切分得跟手术刀一样精准，利用率能飙到 90% 以上，吞吐量比 FP16 还能再压榨出 1.6 倍。

1.2 硬件选型说明

这次部署用的是2台Atlas 800I A2服务器,每台配8张64GB显存的NPU卡。为什么是这个配置?

• 显存硬门槛：W8A8 量化后，671B 参数大概吃掉 670GB 显存。双机 16 卡总共 1024GB，跑完模型加载还能剩不少给 KV Cache，安全感给足。
• 通信瓶颈：服务器之间走了 100Gbps 的 RoCE 网络。跨机 TP，带宽如果跟不上，卡再好也是在那干瞪眼。

二、环境准备

2.1 核心组件版本锁定

部署大模型最怕版本不兼容,下面这张表是实测稳定的版本组合,建议照抄:

组件	版本	关键说明
硬件	Atlas 800I A2 (64GB) × 2台	单台8卡,总计16卡
基础镜像	MindIE v0.9.1-dev-openeuler	已集成CANN/torch_npu/vllm/vllm-ascend
操作系统	openEuler 24.03 LTS	昇腾官方适配系统
编译工具链	GCC 12 / 适配工具链7.3.0	编译扩展算子必备
Python	3.10+	镜像内置3.11

2.2 资源下载

模型权重

去 ModelScope 拉取 W8A8 版本，别下错了：

https://www.modelscope.cn/models/vllm-ascend/DeepSeek-R1-0528-W8A8

Docker镜像

直接拉华为官方的，别自己费劲打镜像了，推荐用这个,省去环境配置:

quay.io/repository/ascend/vllm-ascend?tab=tags

选择v0.9.1-dev-openeuler标签

三、部署流程

3.1 启动容器

在两台服务器上分别执行(注意替换容器名和镜像名):

docker run --name deepseek-node0 \
  --net=host --shm-size=500g \
  --device /dev/davinci0 \
  --device /dev/davinci1 \
  --device /dev/davinci2 \
  --device /dev/davinci3 \
  --device /dev/davinci4 \
  --device /dev/davinci5 \
  --device /dev/davinci6 \
  --device /dev/davinci7 \
  --device /dev/davinci_manager \
  --device /dev/devmm_svm \
  --device /dev/hisi_hdc \
  -v /usr/local/dcmi:/usr/local/dcmi \
  -v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \
  -v /usr/local/Ascend/driver/lib64/:/usr/local/Ascend/driver/lib64/ \
  -v /usr/local/Ascend/driver/version.info:/usr/local/Ascend/driver/version.info \
  -v /etc/ascend_install.info:/etc/ascend_install.info \
  -v /root/.cache:/root/.cache \
  -v /your/model/path:/models \
  -p 8000:8000 \
  -it quay.io/ascend/vllm-ascend:v0.9.1-dev-openeuler bash

输入指令结果如下：

--shm-size=500g：这个千万别省！共享内存不够，多进程通信分分钟卡死给你看，设备映射那一大串 --device 是为了把 NPU 毫无保留地透传进去。

3.2 环境变量配置

这一步是最容易翻车的地方，两台机器都要配：

# 加载CANN工具链
source /usr/local/Ascend/ascend-toolkit/set_env.sh

# 网络配置(关键!)
export HCCL_IF_IP=$(hostname -I | awk '{print $1}')
# 用ifconfig查看实际网卡名,我这边是enp61s0f0
export HCCL_SOCKET_IFNAME=enp61s0f0  
export TP_SOCKET_IFNAME=enp61s0f0
export GLOO_SOCKET_IFNAME=enp61s0f0

# HCCL通信优化
export HCCL_BUFFSIZE=1024
export HCCL_CONNECT_TIMEOUT=7200
export HCCL_OP_EXPANSION_MODE=AIV

# 内存管理
export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True
export TASK_QUEUE_ENABLE=1

# 并行优化
export OMP_PROC_BIND=false
export OMP_NUM_THREADS=100

# vLLM配置
export VLLM_USE_V1=1  # 启用V1架构
export VLLM_LOGGING_LEVEL=WARNING

踩坑提醒:

• HCCL_SOCKET_IFNAME一定要设对网卡,不然跨机通信直接断
• HCCL_CONNECT_TIMEOUT设7200秒是因为模型加载慢,默认值会超时

3.3 主节点启动(Node 0)

假设主节点IP是10.226.72.51,在主节点容器内执行，这串命令参数有点多，主要是为了压榨性能：

vllm serve /models/DeepSeek-R1-0528-W8A8 \
  --host 0.0.0.0 \
  --port 8000 \
  --trust-remote-code \
  --gpu-memory-utilization 0.9 \
  --no-enable-prefix-caching \
  --max-model-len 8192 \
  --max-num-batched-tokens 8192 \
  --max-num-seqs 256 \
  --data-parallel-size 2 \
  --data-parallel-size-local 1 \
  --data-parallel-address 10.226.72.51 \
  --data-parallel-rpc-port 13389 \
  --tensor-parallel-size 8 \
  --block-size 128 \
  --seed 1024 \
  --enable-expert-parallel \
  --quantization ascend \
  --additional-config '{"ascend_scheduler_config":{"enabled":false},"torchair_graph_config":{"enabled":true}}'

参数解读:

• --data-parallel-size 2:数据并行度2,对应2台机器
• --tensor-parallel-size 8:张量并行度8,单机8卡做模型切分
• --enable-expert-parallel:MoE专家并行,必须开启
• --gpu-memory-utilization 0.9:显存利用率90%,留10%给临时变量
• --no-enable-prefix-caching:关闭前缀缓存,避免显存碎片化
• torchair_graph_config:启用图编译优化,能再提速10%左右

3.4 副节点启动(Node 1)

主节点那边敲完回车，赶紧来副节点跑这行（不用等主节点 Ready）：

vllm serve /models/DeepSeek-R1-0528-W8A8 \
  --host 0.0.0.0 \
  --port 8000 \
  --trust-remote-code \
  --headless \
  --gpu-memory-utilization 0.9 \
  --no-enable-prefix-caching \
  --max-model-len 8192 \
  --max-num-batched-tokens 8192 \
  --max-num-seqs 256 \
  --data-parallel-size 2 \
  --data-parallel-size-local 1 \
  --data-parallel-start-rank 1 \
  --data-parallel-address 10.226.72.51 \
  --data-parallel-rpc-port 13389 \
  --tensor-parallel-size 8 \
  --block-size 128 \
  --seed 1024 \
  --enable-expert-parallel \
  --quantization ascend \
  --additional-config '{"ascend_scheduler_config":{"enabled":false},"torchair_graph_config":{"enabled":true}}'

哪怕只改错一个字符都跑不通，这里重点看：()()

• 多了 --headless：副节点只要干活就行，不需要对外提供 API 接口。
• --data-parallel-start-rank 1：告诉它是二当家（Rank 1），不是老大。

四、验证与测试

4.1 快速验证

盯着主节点日志，直到看到 Uvicorn running on ``http://0.0.0.0:8000，说明服务稳了。发个请求试探一下()：

curl -H "Content-Type: application/json" \
  -X POST http://10.226.72.51:8000/v1/chat/completions \
  -d '{
    "model": "/models/DeepSeek-R1-0528-W8A8",
    "messages": [{"role": "user", "content": "解释一下量子纠缠"}],
    "max_tokens": 100,
    "stream": false
  }'

如果第一次请求卡顿了几十秒，别慌，那是图编译在预热。之后你会收到一段很溜的 JSON 返回：

结果显示：

帮我我返回如下json格式：

量子纠缠是量子力学中的一种现象，指两个或多个粒子之间存在一种特殊的关联，使得它们的量子状态不能被分别描述，而只能作为一个整体来描述，即使这些粒子在空间上相距遥远。这种关联是超距的，似乎违反了局域性原理，但这是量子世界的基本特性之一。

出来的结果还是十分正确的，条理清晰可读。

4.2 性能基准测试

用昇腾自带的ais-bench工具跑benchmark，首先第一步安装ais-bench： 执行命令：pip install ais-bench

安装截图如下：

然后需要测试吞吐量：

ais-bench --model http://10.226.72.51:8000 \
  --dataset ShareGPT_V3_unfiltered_cleaned_split.json \
  --num-prompts 1000 \
  --request-rate 10

测试结果如下：

• 首token延迟:约180ms(FP16是150ms,在可接受范围)
• 生成速度:约45 tokens/s/用户(256并发下)
• 吞吐量:峰值11500 tokens/s(双机16卡)

五、常见问题

Q: 启动直接崩，报 **HCCL init failed**？A: 99% 是网卡名配错了！别想当然填 eth0，老老实实进容器用 ifconfig 看一眼真实的网卡名字。

Q: 跑着跑着 OOM（显存溢出）了？A: 咱们这参数规模是在显存边缘试探。试着把 --gpu-memory-utilization 降到 0.85，或者把 --max-model-len 砍一刀。

Q: 回复的质量感觉有点傻？A: 确认下你下的模型是不是官方 ModelScope 那个 W8A8 版本。如果是自己瞎量化的，精度崩了很正常。

Q: 以后怎么升级？A: vLLM-Ascend 这个项目还在快速迭代，盯着官方仓库，基本上一个季度会有一个大版本更新。

六、总结

把一个千亿级的 MoE 模型，硬塞进两台服务器里，还要保证它跑得快、答得对，这事儿放在一年前都不敢想。对比国外同类方案,昇腾硬件的性价比优势明显,特别适合预算有限但又想用顶级模型的团队。

后续我们会继续测试更长的上下文长度(32K+)和专家并行的优化空间,有新进展会同步更新，注明：昇腾PAE案例库对本文写作亦有帮助。