个人主页：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-W8A8Docker镜像
直接拉华为官方的，别自己费劲打镜像了，推荐用这个,省去环境配置:
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案例库对本文写作亦有帮助。
