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-size 8 \
  --pipeline-parallel-size 1 \
  --enable-expert-parallel \
  --quantization awq \          # 或 w8a8
  --max-model-len 65536 \
  --gpu-memory-utilization 0.95 \
  --dtype bfloat16

关键参数解释：

• --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（控制面）
sudo docker run -d --name gpustack \
  --restart unless-stopped \
  -p 80:80 \
  --volume gpustack-data:/var/lib/gpustack \
  swr.cn-south-1.myhuaweicloud.com/gpustack/gpustack:v2.1.2 \
  --debug --bootstrap-password GPUStack@123

3.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-utilization 0.9
--max-model-len 65536
--max-num-batched-tokens 8192
--max-num-seqs 16
--data-parallel-size 1
--tensor-parallel-size 8
--enable-expert-parallel
--quantization ascend
--block-size 128
--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=1
OMP_PROC_BIND=false
OMP_NUM_THREADS=10
PYTORCH_NPU_ALLOC_CONF=expandable_segments:True
ACL_OP_INIT_MODE=1
TRITON_ALL_BLOCKS_PARALLEL=1

3.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的部署目前有两个成熟路线：

1. H800 + vLLM：生态成熟，性能稳定，但硬件成本高，且受供应链限制
2. 昇腾910B + GPUStack：硬件成本低，国产化，但软件栈还在快速迭代中

如果现在就要上线，H800方案更稳妥。如果有国产化要求或者预算紧张，昇腾方案已经可以跑通，31 tokens/s的单请求速度也够用。

下一篇是本系列收官：DeepSeek vs Qwen3 vs GLM-5，2026年年中选型指南。

---

参考资料：DeepSeek-V4-Flash部署指南（知乎）、GPUStack昇腾910B部署实测（cnblogs）、vLLM-Ascend官方文档，2026年4-5月