让 H20 撑起 1.6 万亿参数模型：DeepSeek-V4-Pro 多场景推理服务优化实录
背景：一个「算力不够」的现实问题
DeepSeek-V4-Pro 是一个 1.6 万亿参数的 MoE 模型，官方同时发布了 FP8 与 FP4 两套权重。这类规模的模型天然需要 Blackwell 级别的加速卡——更高的 HBM 容量、更强的 FP8 吞吐、原生的 FP4 Tensor Core。
但现实是：H20 仍然大量部署在生产环境里，它没有原生 FP4 Tensor Core，FP8 算力与 HBM 容量都远低于 B300。硬件约束并不会让服务要求变低：长上下文 prefill 必须压住首 token 时延（TTFT），交互式 decode 必须满足各服务等级的每 token 时延（TPOT），持续流量要在吞吐与 KV cache 容量之间找平衡。
短输入、长上下文、低延迟请求、高并发——它们对系统的压力各不相同，不存在一个通用配置能同时服务好所有场景。LMSYS 团队在官方博客中给出的答案是：一个模型，多套 serving profile。
思路：把「部署拓扑 × 执行路径」拆成场景档位
这篇实践的核心方法论可以概括为三句话：
- 按工作负载匹配 serving profile：prefill 按实测上下文长度在 PP2 / PP4 之间切换；decode 按延迟、吞吐、容量目标分别使用不同 profile。
- 优化 prefill 路径：把
Attention-CP8 → MoE-TP8以及上下文并行通信做透，再按长/短上下文工作负载的真实路由形状调优。 - 优化 decode 路径：针对不同 SLO 优化 DSpark 投机解码路径、专家路由和通信-计算重叠。
最终在 batch size 1 下，单节点 H20-141GB 参考实现达到 271 tokens/s，对比 B300 的 383.7 tokens/s（来源）。考虑到 B300 在本次执行路径所用精度下的峰值 Tensor Core 算力约为 H20-141GB 的 45.6×、内存带宽约为 1.67×，系统级优化把实际观测到的解码性能差距压到了 1.42×——这就是「系统优化 > 裸算力差距」的直观证据。
第一层：容量设计——先给 KV cache 腾出空间
服务容量归根结底来自同一份 HBM 预算：模型权重和每请求 KV 状态争抢同一块显存。文章定义了「full-token capacity」——每个 rank 在分配完权重与运行时缓冲后，最多能容纳的全注意力 KV token 数。
用 Humming MXFP4AFP8 压缩权重占用
H20 没有原生 FP4 Tensor Core，直接跑 FP4 权重没有硬件加速。Humming MXFP4AFP8 的思路是：专家权重用 MXFP4 存储、激活在线转成 FP8 计算，在 H20 上既减小权重足迹与访存流量，又不牺牲算子效率。SGLang 集成见 sglang#23754。
用 Online C128 释放 KV 辅助状态
KV cache 的 C128 压缩页会保留每索引状态（Offline C128）；Online C128 改为维护一份紧凑的聚合状态，把省下的 HBM 还给 KV cache 池。代价是多了一些状态维护与投机验证工作，但实测没有 TPOT 回退。
容量收益是叠加的
- Humming MXFP4AFP8：DP32-EP32 容量提升至 1.71×，PP2-TP8 提升至 4.47×；
- Online C128 在 Humming 之上再提升 2.268×；
- 两者合计：DP32-EP32 达 3.88×，PP2-TP8 达 10.14×（相对 Baseline FP8 + Offline C128）。
第二层：prefill——算力不足，就用通信与调度补
prefill 的硬件选择主要看 TTFT、算力与通信效率。该部署用 H20-96GB 承担 prefill（短生命周期状态，容量够用），H20-141GB 承担 decode（KV cache 容量敏感）。
为什么用 MoE-TP 而不是 MoE-EP
直觉上 MoE-EP 只交换路由 token，通信量更小，看起来更适合算力紧张的 H20。但真实 prefill 流量有显著的专家倾斜：热专家所在的 rank 计算量更大、成为 straggler，所有其他 rank 都要在 combine 步等最慢的那条路径。通信量低 ≠ 时延低。
于是 prefill 改用 MoE-TP：全序列 AllGather / Reduce-Scatter 确实带来更多通信，但这些流量走 900 GB/s NVLink、成本稳定可预测；所有 TP rank 对相同的路由 token 做张量并行计算，专家倾斜不再变成 rank 级长尾。一句话总结这个取舍：可预测的通信，比不可预测的失衡更便宜。实现见 sglang#24947。
两个具体优化
融合 prefill 关键路径：针对 32K 单 chunk 场景，构建一条融合路径——先用拷贝引擎驱动的 AllGather 重叠 FP8 量化与共享专家 GEMM，再在一个 Triton kernel 里合并 TopK 归约、共享专家加法和 Reduce-Scatter。七个算子重组为三个执行组，匹配 A/B 下 TTFT 下降约 3.5%。
按真实路由形状调优 Humming：prefill 路由把 token 不均匀地分到 384 个专家，有效 M 维度聚成少量离散值，且 W13 与 W2 的形状不同。团队从真实路由直方图提取高频形状，为 W13 / W2 分别建精确形状配置，再在 kernel、pipeline stage、匹配 A/B 三级验证。匹配 PP4 A/B（32K）下，MoE kernel 时延降约 21%，端到端 TTFT 降 11.35%。
成果数据：PP2 在全部九个输入长度点都优于基线，几何平均吞吐增益 36.5%，峰值总输入吞吐 16,900 tokens/s；PP4 几何平均增益 31.8%，512K 下达到 25,860 tokens/s、1M 下仍保持 23,970 tokens/s。PP2 与 PP4 的取舍随上下文长度迁移：4K 与 32K 下 PP2 的 TTFT 分别低 16.7% 与 19.5%，8K/16K/64K 下两者差距在 2% 以内，而从 128K 起 PP4 建立决定性优势（TTFT 低 26.2% / 33.3% / 42.1% / 44.8%，对应 128K/256K/512K/1M）。路由边界因此被当作运营策略而非固定阈值。
第三层：decode——低延迟与高吞吐分兵作战
decode 必须为每个活跃请求长期持有 KV cache，HBM 容量直接决定上下文长度与并发度，所以本部署的 decode 全用 H20-141GB。
低延迟档：PP2-TP8 + 跨流水线的 DSpark
单节点 TP8 执行路径最短（Attention-TP8 → MoE-TP8，无跨节点通信），batch size 1 时最快——但权重与服务状态挤在同一节点 HBM 里，1M 上下文下只能容纳 batch size 1，无法支撑更大批次。最快的拓扑不一定是最可服务的拓扑。
服务档位选择 PP2-TP8：模型分到两个流水线 stage，权重分散后释放 HBM 给 KV cache，支持 1M/512K/256K 下 batch 4/8/16。难点在于投机解码跨了流水线边界：DSpark drafter 只存在于末 stage，每轮投机都要跨 stage 协调。团队用统一执行协议让两个 stage 按同一节奏推进，避免进入不同轮次。PP 专用 DSpark 集成正在上游推进（sglang#32281）。
效果：优化的 DSpark 在 batch size 1 下把峰值 TPOT 压降 74.8%–78.0%，且在 8K 到 1M 全范围成立，不是只对短上下文有效；batch size 1 输出吞吐达 150–174 tokens/s（PP2-TP8），单节点 TP8 参考达 183–271 tokens/s。
高吞吐档：DP32-EP32 + 瓶颈移除
高吞吐档用 Attention-DP → MoE-EP 路径。DP16-EP16 是最小部署单元与效率参考；DP32-EP32 把 DP 和 EP 一起扩大，专家权重分布到更多 GPU，释放 HBM 承接更多并发请求。
重构 refinement 执行形状：refinement 步要对 DSpark 候选集做全词表投影，高并发下逐行 dot-reduce 反复读词表权重形成每步长尾。把活跃行合成一个转置 GEMM，每 GPU 吞吐提升 22.8%。
按实测路由放置专家：DSpark 流量同样有专家倾斜。记录代表性请求的路由亲和性，用它配置 EPLB（专家并行负载均衡）与冗余专家，避免少数热专家反复拖长关键路径，每 GPU 吞吐提升 13.5%。
Humming 解码热路径：把 SwiGLU 激活与量化融合（直接产出 W2 所需的数据与 scale），消除中间缓冲与独立量化 pass，匹配 DSpark A/B 下每 GPU 吞吐提升 44.0%；再把 Single-Batch Overlap 适配为 Humming-Aware SBO——W2 每个 tile 一完成就让 DeepEP 发起对应 combine 发送，吞吐额外恢复 4.12%。
最终成绩：4K 输入、每 DP rank 32 并发下，每 GPU 吞吐从 319.92 提升到 703.15 tokens/s/GPU（2.20×）；1M 输入下从 27.05 提升到 66.82 tokens/s/GPU，最终系统在 1M 上下文还能同时服务 4 个请求（177.48 tokens/s/GPU）。DP16-EP16 效率参考达到 4.67k output tokens/s per node、平均 TPOT 27.4ms。
容量 vs 效率：高吞吐档位怎么选
DP16-EP16 每 GPU 效率更高（16/32 并发下比 DP32-EP32 高约 3.6%–20%），但 DP32-EP32 释放更多 HBM 给 KV cache：256K/512K/1M 下每 DP rank 最大并发请求从 8/4/2 翻倍到 16/8/4，容量一致地 ×2。文章的处理方式很务实：DP16-EP16 作效率参考，DP32-EP32 作容量档，按自己的上下文与并发目标选。
给 AI 基础设施团队的三个启示
- 别用硬件规格或孤立 benchmark 选 serving profile。从工作负载、SLO、上下文长度、并发度出发，用 profiling 找到瓶颈资源，再把它翻译成拓扑与执行路径决策。
- 算力差距可以用系统优化大幅弥合。45.6× 的峰值算力差距被压到 1.42× 的实测差距，靠的是容量释放、通信重叠、执行形状重构与投机解码的组合拳。
- 「一台机器跑一个配置」的时代过去了。同一模型按场景拆成 prefill 档、低延迟 decode 档、高吞吐 decode 档，各自优化，才是受限硬件上服务前沿模型的可行姿势。
对于正在做企业 AI 落地与算力规划的技术团队，这篇实践的价值在当前国内算力环境下尤为直接。一个现实是：H20 是目前国内合法可售、且已大量部署的主流合规 GPU，存量设备规模可观；而 B300 等更高性能的算力产品受出口管制影响，采购路径受限、价格畸高，短期内难以成为规模化选项。这意味着，现有存量 GPU 集群的潜力远没有被榨干——与其被动等待算力供给松动，不如先用 serving profile 方法论把已有资源盘活：通过容量释放、通信重叠、执行形状重构与投机解码的组合优化，H20 同样能撑起 1.6 万亿参数级别的模型服务。对多数企业而言，这往往是比采购新卡性价比更高的第一步，也是算力租赁与推理部署服务商帮客户降本增效的核心抓手。
关于天泰伟业
北京天泰伟业信息技术有限公司（2016 年成立）深耕云计算、企业 AI 与算力租赁领域，为企业提供 GPU 算力资源、大模型推理部署与 AI 应用落地的全链路服务。无论是存量 GPU 集群的推理优化咨询，还是面向 DeepSeek 等前沿开源模型的算力规划与部署实施，天泰伟业均可提供贴近业务场景的工程化方案。