DeepSeek-V4-Pro H20优化：一张路由表适配四种流量场景

当千亿甚至万亿参数的大模型需要部署在现有普及的通用硬件集群上时，如何在不更换显卡的前提下最大化服务性能，是行业内普遍关注的落地问题。近期有研究团队针对DeepSeek-V4-Pro这一1.6万亿参数的MoE模型，展开了基于H20集群的服务优化探索，最终形成了一套可落地的多路径调度方案。

DeepSeek-V4-Pro本身针对新一代硬件做了优化，同时支持FP8和FP4权重格式，更适配如B300这类搭载原生FP4 Tensor Core、拥有更强FP8算力与更大HBM显存的新型显卡。但现实中的数据中心不会因为新模型的推出就立刻完成硬件升级，因此如何让这款大模型在已部署的H20集群上稳定运行，成为了本次优化的核心目标。

研究团队首先对现有H20集群的不同显存规格进行了差异化调度。对于prefill阶段而言，其不需要长期保留每个请求的状态信息，因此可以使用H20-96GB规格的节点；而decode阶段需要在整个文本生成过程中持续留存KV缓存，显存容量直接决定了长上下文支持能力与并发请求数量，因此这部分工作负载被分配到H20-141GB的节点上。

一张配置表管不了全场景流量

在prefill阶段内部，团队还进一步做了流量拆分。PP2和PP4两套方案采用了相同的Attention-CP8 → MoE-TP8执行路径，核心差异仅在于流水线深度。测试数据显示，当上下文长度为4K和32K时，PP2的首令牌延迟（TTFT）分别比PP4低16.7%和19.5%；而当上下文长度达到128K以上时，情况发生反转，PP4的性能领先幅度从26.2%逐步扩大到44.8%。这是因为短上下文的请求无法生成足够多的chunk来填满PP4的四个执行stage，反而会因为跨stage的填充与调度开销拉低整体性能；而当上下文长度拉长后，更深的流水线能够被充分利用，整体效率反而更高。

这套基于上下文长度的分流规则，并非通用的启动参数模板，而是基于实测的工作负载总结出的调度逻辑，将“按场景优化”从抽象概念落地为具体的调度动作。

decode阶段则被拆分为两条独立的路径。单节点TP8配置用于追求极致低延迟的场景，能够最大化单节点的性能上限；PP2-TP8则通过额外的流水线开销，换取了更多的KV缓存空间，更适合实际的低延迟服务场景。而高吞吐场景下的配置，则需要在DP16-EP16和DP32-EP32之间权衡单卡计算效率与并发请求容量，根据实际的业务需求选择最优的组合。

适度增加通信换取稳定低延迟

在prefill阶段的通信架构选择上，团队做出了一个反常识的决策：放弃通信量更少的MoE-EP方案，转而使用MoE-TP。这一选择的核心症结在于真实流量中的专家偏斜问题——实际业务中的token会更多地被路由到少数热门的专家节点，导致负责这些热门专家的计算rank率先完成任务，其他rank即使提前完成自身计算，也需要在combine阶段等待最慢的节点，最终导致即便通信量减少，首令牌延迟也没有得到有效降低。

而MoE-TP架构会通过AllGather和ReduceScatter操作增加通信量，但这些通信流量都在高带宽的NVLink内部完成，同时所有TP rank能够分摊同一批路由token的计算任务。团队在这组负载中的取舍非常明确：通过增加少量稳定的通信成本，替换掉不可预测的专家长尾延迟。

此外，团队在kernel调优环节并没有使用理想化的合成形状数据，而是从真实的路由直方图中提取高频计算形状，针对性地优化W13和W2算子，这一做法让调优结果更贴合实际的服务场景，比孤立的峰值性能测试数据更具实用价值。

271 token/s的极致性能边界

本次优化取得了亮眼的实测性能：单节点由8张NVLink互连的H20-141GB显卡，在batch size为1的情况下，输出token速度达到271 tokens/s；prefill阶段的单节点输入处理速度达到8.45k tokens/s，能够在43.7秒内完成1M-token的prompt处理。研究团队同时对比了B300显卡上的公开测试结果，两者的性能差距约为1.42倍。

当性能拉满后，显存空间会成为新的瓶颈：单节点TP8配置在1M上下文的场景下仅能支持batch size为1；而PP2-TP8虽然增加了流水线开销，但能够将模型权重分摊到两个执行stage，在1M、512K和256K的上下文长度下，分别支持batch size为4、8和16。这也说明，“最快的单节点性能”与“最适合实际服务的配置”并非同一概念。

在高吞吐的配置方案中，DP16-EP16的单节点输出吞吐达到4.67k tokens/s，平均每令牌处理时间（TPOT）为27.4ms；当上下文长度为4K、每个DP rank支持32并发请求时，系统通过持续优化将每GPU吞吐从319.92 tokens/s提升至703.15 tokens/s，累计提升幅度达到2.20倍。

从权重和KV缓存双维度优化显存

为了提升显存的有效利用率，团队从模型权重与KV缓存两个维度同时入手进行优化。首先通过Humming MXFP4AFP8方案，使用MXFP4格式存储专家权重，并采用在线FP8格式处理激活值，有效降低了权重占用与内存流量；随后通过Online C128压缩技术缩小压缩页的辅助状态，将更多的HBM显存释放给KV缓存使用。

两项优化组合后，相对于FP8 + Offline C128的基线配置，DP32-EP32配置下的full-token capacity提升至3.88倍，PP2-TP8配置下则提升至10.14倍。需要注意的是，这里的full-token capacity是扣除模型权重与运行时缓冲区后的内存上限，并不等同于线上可以直接接纳的实际并发batch size。同一套优化方案，在不同的服务配置下，能够带来差异巨大的性能提升幅度。

最终落地的路由调度方案

研究团队最终并未找到一套能够适配所有请求场景的通用配置参数，而是通过拆解延迟、吞吐、上下文长度与显存容量等核心指标，针对不同的业务流量制定了多套执行路径。

这套调度方案的核心逻辑非常清晰：首先梳理业务请求的上下文长度与并发分布，再结合首令牌延迟、每令牌处理时间与显存容量目标，最终将不同的请求分配到PP2、PP4、低延迟decode或高吞吐decode的执行路径中。单一的配置参数已经无法适配DeepSeek-V4-Pro的全场景服务需求，但基于上下文的路由表方案则可以灵活覆盖不同的业务场景。