DeepSeek V4 部署实战:从H800到昇腾910B
1.6T参数、49B激活,V4的模型尺寸比V3大了一倍多。怎么把这张"怪兽"跑起来,而且推理成本压到最低?本文拆解H800和昇腾910B两种部署方案,给出实测数据和成本对比。
一、先算账:跑V4到底要多少钱
在聊技术细节之前,先算一笔账——这是大多数团队最关心的问题。
1.1 H800部署(英伟达路线)
| 配置项 | 数值 | 说明 |
|---|---|---|
| 模型尺寸 | 1.6T总参数,49B激活 | MoE架构,每次只激活部分专家 |
| 显存需求(FP16) | 约320GB(全精度) | 单卡放不下,必须多卡并行 |
| 推荐配置 | 8×H800 80GB | TP=8,专家并行 |
| 量化后显存(W8A8) | 约160GB | 8卡可放下,有余量 |
| 单卡成本(市价) | 2.5-3万美元 | 禁运前价格,现在更高 |
| 8卡服务器成本 | 约25-30万美元 | 不含IDC |
1.2 昇腾910B部署(华为路线)
| 配置项 | 数值 | 说明 |
|---|---|---|
| 推荐配置 | 8×昇腾910B2 64GB | 参考GPUStack实测方案 |
| 显存需求(W8A8) | 约160GB | 同上 |
| 单卡算力(BF16) | 约320 TFLOPS | H800约1979 TFLOPS,差距仍在 |
| 8卡服务器成本 | 约150-200万人民币 | 比H800方案便宜约30-40% |
| 软件栈 | MindSpore + CANN | 需适配,生态不如PyTorch成熟 |
1.3 推理成本对比(每1M tokens)
| 方案 | 硬件摊销(3年) | 电费 | 合计/1M tokens |
|---|---|---|---|
| H800×8(自建) | 约0.8元 | 约0.15元 | ~0.95元 |
| 昇腾910B×8(自建) | 约0.5元 | 约0.12元 | ~0.62元 |
| API调用(官方) | — | — | 约2-5元(参考DeepSeek官方API定价) |
注:以上为粗略估算,实际成本受吞吐量、并发数、IDC租金等影响。
二、H800部署方案:vLLM + TP=8
2.1 基础环境
# 验证GPU状态nvidia-smi# 推荐配置# 8×H800 80GB# CUDA 12.4+# vLLM 0.6.8+(支持V4的MoE并行)2.2 部署命令(vLLM)
vllm serve DeepSeek-V4\--tensor-parallel-size8\--pipeline-parallel-size1\--enable-expert-parallel\--quantizationawq\# 或 w8a8--max-model-len65536\--gpu-memory-utilization0.95\--dtypebfloat16关键参数解释:
--enable-expert-parallel:MoE专家并行,8卡各自持有不同专家--quantization awq:4bit量化,显存占用减少约70%--max-model-len 65536:V4支持256K,但推理时设64K已够绝大多数场景
2.3 预期性能(H800×8,W8A8量化)
| 指标 | 数值 | 说明 |
|---|---|---|
| 单请求吞吐量 | 约25-35 tokens/s | 取决于序列长度 |
| 并发(10请求) | 约150-200 tokens/s total | 受益于MoE稀疏激活 |
| 首token延迟(TTFT) | 约200-400ms | 长上下文会更高 |
| 每请求显存占用 | 约6-10GB | 取决于KVCache大小 |
三、昇腾910B部署方案:GPUStack + vLLM-Ascend
这是2026年4月刚出的实测方案,有人踩过坑了。
3.1 环境准备
# 验证NPU状态(类似nvidia-smi)npu-smi info# 要求:驱动版本 ≥ 25.5# Ascend Docker Runtime v7.3.1# 启动GPUStack(控制面)sudodockerrun-d--namegpustack\--restartunless-stopped\-p80:80\--volumegpustack-data:/var/lib/gpustack\swr.cn-south-1.myhuaweicloud.com/gpustack/gpustack:v2.1.2\--debug--bootstrap-password GPUStack@1233.2 添加vLLM-Ascend推理后端
GPUStack支持自定义推理引擎,需要手动添加vLLM-Ascend 0.13.0rc3版本:
| 配置项 | 值 |
|---|---|
| 版本号 | 0.13.0rc3 |
| 镜像 | quay.io/ascend/vllm-ascend:v0.13.0rc3 |
| 框架 | CANN |
| 入口命令 | vllm serve |
| 执行命令模板 | {{model_path}} --host {{worker_ip}} --port {{port}} --served-model-name {{model_name}} |
3.3 模型文件准备
方案A(联网):GPUStack控制台 → 部署 → ModelScope,搜索Eco-Tech/DeepSeek-V4-Flash-w8a8-mtp,直接拉取。
方案B(离线):提前下载权重到所有Worker节点,控制台 → 模型文件 → 添加本地路径。
3.4 部署配置(实测可用)
# 后端参数(填写到GPUStack控制台)--gpu-memory-utilization0.9--max-model-len65536--max-num-batched-tokens8192--max-num-seqs16--data-parallel-size1--tensor-parallel-size8--enable-expert-parallel--quantizationascend --block-size128--async-scheduling --chat-template /var/lib/gpustack/cache/.../chat_template.jinja --additional-config'{"enable_cpu_binding": "true", "multistream_overlap_shared_expert": true}'--speculative-config'{"num_speculative_tokens": 1, "method": "deepseek_mtp"}'环境变量(必须配置):
USE_MULTI_BLOCK_POOL=1OMP_PROC_BIND=falseOMP_NUM_THREADS=10PYTORCH_NPU_ALLOC_CONF=expandable_segments:TrueACL_OP_INIT_MODE=1TRITON_ALL_BLOCKS_PARALLEL=13.5 实测性能(昇腾910B2×8)
| 指标 | 数值 | 说明 |
|---|---|---|
| 单请求吞吐量 | 31 tokens/s | GPUStack初始适配结果,后续有优化空间 |
| 量化方案 | W8A8 | 显存占用约160GB(8卡分摊) |
| 并行策略 | TP=8 + 专家并行 | 与H800方案类似 |
注意:31 tokens/s是初始结果,vLLM-Ascend还在快速迭代,后续版本可能有显著提升。
四、两种方案的选择建议
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 已有H800集群 | H800 + vLLM | 生态成熟,问题好排查 |
| 新建集群,预算敏感 | 昇腾910B + GPUStack | 硬件成本低30-40% |
| 需要256K长上下文 | H800(目前) | 昇腾方案的长上下文适配还在完善 |
| 对稳定性要求极高 | H800 + vLLM | 软件生态更成熟 |
| 信创/国产化要求 | 昇腾910B | 唯一选择 |
五、DeepSeek-V4-Flash:轻量版的选择
如果49B激活仍然太大,可以考虑DeepSeek-V4-Flash(MIT开源,2026年4月24日发布):
- 参数规模大幅缩减(官方未披露具体数值,实测显存占用约Flash版为V4-Pro的约1/3)
- 单机8卡910B即可完整运行(W8A8量化)
- 效果比V4-Pro弱,但推理成本低很多
- 适合对效果要求不那么极致的业务场景
六、总结
V4的部署目前有两个成熟路线:
- H800 + vLLM:生态成熟,性能稳定,但硬件成本高,且受供应链限制
- 昇腾910B + GPUStack:硬件成本低,国产化,但软件栈还在快速迭代中
如果现在就要上线,H800方案更稳妥。如果有国产化要求或者预算紧张,昇腾方案已经可以跑通,31 tokens/s的单请求速度也够用。
下一篇是本系列收官:DeepSeek vs Qwen3 vs GLM-5,2026年年中选型指南。
参考资料:DeepSeek-V4-Flash部署指南(知乎)、GPUStack昇腾910B部署实测(cnblogs)、vLLM-Ascend官方文档,2026年4-5月