华为昇腾 910B×8 部署 DeepSeek-V4-Flash 实战记录
·
前言
DeepSeek-V4 系列发布后，官方给出了 DeepSeek-V4-Flash（284B，MoE 架构，推理时仅激活小部分参数）和 DeepSeek-V4-Pro（1.6T）两种规格。借助 vLLM-Ascend 对 DeepSeek-V4 的适配，这类超大规模 MoE 模型已经可以跑在国产昇腾算力上。本文记录一次在单机 8 卡 910B4 服务器上，通过 vllm-ascend 官方镜像 + Docker Compose 部署 DeepSeek-V4-Flash-w8a8-mtp（W8A8 量化 + MTP 投机解码版本）的完整过程，包含硬件确认、Compose 编排、关键参数解读三部分，方便日后回顾和给同事参考。
一、硬件环境确认
部署前先用 npu-smi info 确认板卡状态：
[root@bms-10124111 deepseek_v4_flash]# npu-smi info
+------------------------------------------------------------------------------------------------+
| npu-smi 25.2.1 Version: 25.2.1 |
+---------------------------+---------------+----------------------------------------------------+
| NPU Name | Health | Power(W) Temp(C) Hugepages-Usage(page)|
| Chip | Bus-Id | AICore(%) Memory-Usage(MB) HBM-Usage(MB) |
+===========================+===============+====================================================+
| 0 910B4-1 | OK | 96.5 37 0 / 0 |
| 0 | 0000:C1:00.0 | 0 0 / 0 62702/ 65536 |
+===========================+===============+====================================================+
| 1 910B4-1 | OK | 97.5 36 0 / 0 |
| 0 | 0000:C2:00.0 | 0 0 / 0 62701/ 65536 |
+===========================+===============+====================================================+
| 2 910B4-1 | OK | 91.5 34 0 / 0 |
| 0 | 0000:81:00.0 | 0 0 / 0 62701/ 65536 |
+===========================+===============+====================================================+
| 3 910B4-1 | OK | 98.5 38 0 / 0 |
| 0 | 0000:82:00.0 | 0 0 / 0 62701/ 65536 |
+===========================+===============+====================================================+
| 4 910B4-1 | OK | 98.9 41 0 / 0 |
| 0 | 0000:01:00.0 | 0 0 / 0 62701/ 65536 |
+===========================+===============+====================================================+
| 5 910B4-1 | OK | 92.9 41 0 / 0 |
| 0 | 0000:02:00.0 | 0 0 / 0 62702/ 65536 |
+===========================+===============+====================================================+
| 6 910B4-1 | OK | 95.6 42 0 / 0 |
| 0 | 0000:41:00.0 | 0 0 / 0 62701/ 65536 |
+===========================+===============+====================================================+
| 7 910B4-1 | OK | 95.2 43 0 / 0 |
| 0 | 0000:42:00.0 | 0 0 / 0 62701/ 65536 |
+===========================+===============+====================================================+
| NPU Chip | Process id | Process name | Process memory(MB) |
+===========================+===============+====================================================+
| 0 0 | 1277790 | VLLMWorker_TP | 59349 |
| 1 0 | 1277990 | VLLMWorker_TP | 59349 |
| 2 0 | 1278321 | VLLMWorker_TP | 59349 |
| 3 0 | 1278567 | VLLMWorker_TP | 59349 |
| 4 0 | 1278658 | VLLMWorker_TP | 59349 |
| 5 0 | 1278790 | VLLMWorker_TP | 59349 |
| 6 0 | 1279178 | VLLMWorker_TP | 59349 |
| 7 0 | 1279351 | VLLMWorker_TP | 59349 |
几个关键信息：
- 8 张 910B4-1，
Health均为OK，功耗在 91~99W 之间，温度 34~43°C，属于正常运行区间。 - 每张卡 HBM 总量 65536 MB（64GB），当前
HBM-Usage约 62701~62702 MB，说明模型 + KV Cache 几乎把显存吃满了（对应 Compose 里--gpu-memory-utilization 0.95）。 - 底部进程表显示 8 张卡上各自跑着一个
VLLMWorker_TP进程，进程内存约 59349 MB，这正是--tensor-parallel-size 8张量并行下，每张卡各自持有一份切分后的模型权重 + 激活值的体现——8 进程一一对应 8 张卡，没有出现漏卡或进程堆积的情况，说明 TP 拉起正常。
二、Docker Compose 编排
version: "3.3"
services:
deepseek-v4-flash:
image: quay.io/ascend/vllm-ascend:v0.22.1rc1
container_name: deepseek-v4-flash
restart: always
network_mode: host
shm_size: "1g"
stdin_open: true
tty: true
devices:
- /dev/davinci0:/dev/davinci0
- /dev/davinci1:/dev/davinci1
- /dev/davinci2:/dev/davinci2
- /dev/davinci3:/dev/davinci3
- /dev/davinci4:/dev/davinci4
- /dev/davinci5:/dev/davinci5
- /dev/davinci6:/dev/davinci6
- /dev/davinci7:/dev/davinci7
- /dev/davinci_manager:/dev/davinci_manager
- /dev/devmm_svm:/dev/devmm_svm
- /dev/hisi_hdc:/dev/hisi_hdc
environment:
OMP_PROC_BIND: "false"
OMP_NUM_THREADS: "10"
PYTORCH_NPU_ALLOC_CONF: "expandable_segments:True"
HCCL_BUFFSIZE: "1024"
HCCL_OP_EXPANSION_MODE: "AIV"
TASK_QUEUE_ENABLE: "1"
ASCEND_MAX_OP_CACHE_SIZE: "-1"
VLLM_ASCEND_ENABLE_MLAPO: "1"
TE_PARALLEL_COMPILER: "32"
VLLM_ASCEND_BALANCE_SCHEDULING: "1"
PYTHONHASHSEED: "0"
volumes:
- /models:/workspace
- /usr/local/Ascend/driver:/usr/local/Ascend/driver
- /usr/local/dcmi:/usr/local/dcmi
- /usr/local/bin/npu-smi:/usr/local/bin/npu-smi
- /root/.cache:/root/.cache
command: >
vllm serve /workspace/DeepSeek-V4-Flash-w8a8-mtp
--max_model_len 1048576
--max-num-batched-tokens 8192
--served-model-name deepseek-v4-flash
--gpu-memory-utilization 0.95
--max-num-seqs 16
--data-parallel-size 1
--tensor-parallel-size 8
--enable-expert-parallel
--tokenizer-mode deepseek_v4
--tool-call-parser deepseek_v4
--enable-auto-tool-choice
--reasoning-parser deepseek_v4
--safetensors-load-strategy prefetch
--model-loader-extra-config '{"enable_multithread_load":"true","num_threads":128}'
--quantization ascend
--enable-prefix-caching
--port 8077
--block-size 128
--speculative-config '{"num_speculative_tokens":1,"method":"mtp","enforce_eager":true}'
--compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY","cudagraph_capture_sizes":[1,2,4,8,16,24,32,40,48,56,64,128,256,512,1024,2048,4096,8192]}'
--async-scheduling
--additional-config '{"ascend_compilation_config":{"enable_npugraph_ex":true,"enable_static_kernel":true},"enable_cpu_binding":true,"enable_dsa_cp":false,"multistream_overlap_shared_expert":true}'
2.1 设备直通
devices 里把 8 张 davinciN 卡加上 davinci_manager、devmm_svm、hisi_hdc 一起挂进容器，这几个是昇腾驱动栈访问 NPU 硬件、管理设备状态和内存映射必需的字符设备，缺一个都可能导致容器内 npu-smi 或 CANN 运行时初始化失败。network_mode: host 则是为了让容器内 vLLM 的 HTTP 服务端口（8077）和卡间通信（HCCL）直接使用宿主机网络栈，避免走 NAT 增加延迟。
2.2 环境变量
| 变量 | 作用 |
|---|---|
OMP_PROC_BIND=false / OMP_NUM_THREADS=10 |
控制 CPU 侧 OpenMP 线程绑核策略与线程数，多进程/多卡场景下关闭强制绑核可以减少 CPU 抢占冲突 |
PYTORCH_NPU_ALLOC_CONF=expandable_segments:True |
让 NPU 显存分配器按需扩展显存段，缓解长时间运行后的显存碎片化问题 |
HCCL_BUFFSIZE=1024 |
HCCL（华为集合通信库）通信缓冲区大小（MB），TP=8 时卡间 all-reduce/all-to-all 流量较大，适当调大可以提升吞吐 |
HCCL_OP_EXPANSION_MODE=AIV |
指定 HCCL 算子展开方式为 AIV（AI Vector core）路径，是官方在 DeepSeek 系列部署教程中推荐的通信优化开关 |
TASK_QUEUE_ENABLE=1 |
开启异步任务队列，让算子下发与执行更好地重叠 |
ASCEND_MAX_OP_CACHE_SIZE=-1 |
不限制算子缓存大小，避免频繁编译/缓存淘汰带来的额外开销 |
VLLM_ASCEND_ENABLE_MLAPO=1 |
开启 MLA（Multi-head Latent Attention）相关融合算子，能明显提升 DeepSeek 系列模型的性能，但会额外占用显存 |
TE_PARALLEL_COMPILER=32 |
图编译阶段的并行编译线程数，加速启动时的算子编译过程 |
VLLM_ASCEND_BALANCE_SCHEDULING=1 |
启用 vLLM-Ascend 的均衡调度，帮助在多卡/多请求场景下更均匀地分配计算负载 |
PYTHONHASHSEED=0 |
固定哈希种子，保证多进程/多次运行之间某些依赖哈希顺序的行为一致，便于复现 |
2.3 挂载卷
/models:/workspace：宿主机模型目录映射进容器，避免把几百 GB 的权重打进镜像。/usr/local/Ascend/driver、/usr/local/dcmi、/usr/local/bin/npu-smi：把宿主机的昇腾驱动、DCMI 管理接口和npu-smi工具挂进容器，让容器内的 CANN 运行时能匹配宿主机驱动版本，同时容器内也能直接执行npu-smi info排障。/root/.cache:/root/.cache：持久化模型下载/编译缓存（比如算子编译产物），避免容器重启后重新编译浪费时间。
2.4 启动参数解读
vllm serve 后面这一长串参数是本次部署的核心，按功能分组来看：
并行策略
--tensor-parallel-size 8：8 卡张量并行，权重按层内切分到 8 张卡，这也是为什么npu-smi里每张卡都有一个VLLMWorker_TP进程、单进程显存占用约 59GB。--data-parallel-size 1：单机单份数据并行副本，8 卡全部用于 TP。--enable-expert-parallel：MoE 模型的专家层按专家并行切分到各卡，是 MoE 大模型在多卡上高效运行的关键。
显存与序列
--max_model_len 1048576：支持百万级（1M token）超长上下文，对应 DeepSeek-V4 主打的长文本能力。--gpu-memory-utilization 0.95：预留 5% 显存给系统和通信 buffer，其余全部用于权重和 KV Cache，这也解释了 npu-smi 里 HBM 占用接近满载。--max-num-seqs 16/--max-num-batched-tokens 8192：限制并发序列数和单批 token 数，在超长上下文场景下这是控制显存峰值的关键旋钮。--block-size 128：PagedAttention 的 KV Cache 分块粒度。
量化与加载
--quantization ascend：使用昇腾侧的量化实现来加载 W8A8 权重。--safetensors-load-strategy prefetch+--model-loader-extra-config '{"enable_multithread_load":"true","num_threads":128}'：128 线程预取式并行加载权重，对于 284B 参数规模的模型，这能显著缩短启动时的权重加载时间。
推测解码（MTP）
--speculative-config '{"num_speculative_tokens":1,"method":"mtp","enforce_eager":true}'：启用 Multi-Token Prediction 投机解码，每步预测 1 个额外 token 再校验，用于提升 decode 阶段吞吐；enforce_eager让 MTP 部分不进入图模式，以保证兼容性/稳定性。
图编译与算子优化
--compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY", "cudagraph_capture_sizes":[...]}'：仅在 decode 阶段启用全量图捕获（ACLGraph 的等价配置项沿用了 vLLM 的命名），并预先捕获从 1 到 8192 一系列 batch size 的图，减少运行时重复编译开销。--async-scheduling：异步调度，让请求调度与算子下发不互相阻塞，MTP 场景下官方也推荐搭配开启。--additional-config中的ascend_compilation_config.enable_npugraph_ex、enable_static_kernel：启用昇腾扩展图模式与静态 kernel，进一步压缩算子调度开销；enable_cpu_binding：开启 CPU 绑核以降低调度抖动；multistream_overlap_shared_expert：为共享专家计算开启额外流，与其它专家计算/通信重叠，提高 MoE 层效率；enable_dsa_cp: false：本次部署未开启 DSA（DeepSeek Sparse Attention）相关的上下文并行，单机 8 卡场景下上下文并行通常用于跨机场景，这里保持关闭。
工具调用 / 推理解析
--tokenizer-mode deepseek_v4/--tool-call-parser deepseek_v4/--reasoning-parser deepseek_v4/--enable-auto-tool-choice：适配 DeepSeek-V4 专属的分词器格式、function calling 输出格式和思维链（reasoning）输出解析，保证对外暴露的 OpenAI 兼容接口能正确解析出tool_calls和reasoning_content字段。
其它
--enable-prefix-caching：开启前缀缓存，重复 prompt 前缀可以复用 KV Cache，对多轮对话/共享 system prompt 场景收益明显。--port 8077：对外服务端口。
三、小结
这次部署本质上是"单机 8 卡 910B4 + TP8 + EP + W8A8 量化 + MTP 投机解码"的组合拳，核心思路是：
- 用
--tensor-parallel-size 8把 284B 参数的权重切满 8 卡，配合--enable-expert-parallel让 MoE 专家层也分布式承载； - 用 W8A8 量化（
--quantization ascend）把显存压力降下来，换取在 64GB HBM 单卡上跑起百万级上下文； - 用 MTP 投机解码 + ACLGraph 全量图捕获 + 多项 Ascend 专属融合算子/多流重叠开关，尽量把 decode 吞吐往上提。
从 npu-smi 的输出看，8 张卡负载均衡、显存占用符合预期（约 95% 利用率），进程数与 TP 卡数一一对应，说明这套 Compose 编排已经成功把服务拉起来了。
后续可以补充的内容：实际压测的 TTFT / TPOT 数据、不同
max-num-seqs下的吞吐对比、以及长上下文（比如 128K/512K/1M token）场景下的显存曲线，这些留到下一篇性能篇里详细记录。
环境：Atlas 800 系列（910B4-1 ×8），vllm-ascend 镜像 v0.22.1rc1，模型 DeepSeek-V4-Flash-w8a8-mtp
作为“人工智能6S店”的官方数字引擎，为AI开发者与企业提供一个覆盖软硬件全栈、一站式门户。
更多推荐
1
0- 0
已为社区贡献1条内容
所有评论(0)