Pushing the Limits of Serving DeepSeek-V4-Pro

发表时间: 2026-08 · Blog post by Tianyu Zhang, Yusong Gao, Yun Zhang (lmsys.org)

原文: https://lmsys.org/blog/2026-08-19-deepseek-v4-pro-engine-optimization-h20

作者/机构： Tianyu Zhang, Yusong Gao, Yun Zhang
发表日期： 2026年8月19日

速读

一句话结论 通过针对不同负载场景定制部署拓扑与执行路径，本文在算力和显存受限的 H20 GPU 集群上成功部署了 1.6T 参数的 DeepSeek-V4-Pro 模型，在单批次生成上达到了 271 tokens/s 的速度，并将 1M tokens 长文本的预填充时间控制在 43.7 秒。

要解决什么问题 DeepSeek-V4-Pro 是 1.6T 参数的 MoE 模型，理想硬件是具备原生 FP4 和超大显存的 Blackwell GPU。但现实中大量部署的 H20 GPU 在算力和显存上存在显著劣势。在硬件受限时，传统的通用部署配置会遭遇严重的机制卡点：预填充阶段若采用常规的专家并行（MoE-EP），真实的 token 路由会产生严重的专家负载倾斜，导致部分 GPU 算力过载成为长尾节点，直接拖慢首字延迟；解码阶段需要将所有活跃请求的 KV Cache 保存在显存中，庞大的模型权重与 KV Cache 争抢有限的 HBM 空间，导致并发度上不去、长上下文请求直接因显存溢出而失效。此外，短文本看重流水线开销，长文本吃重并行度，低延迟要求极短的执行路径，而高吞吐需要极致的显存释放，这些相互冲突的系统压力使得单一的并行策略无法同时满足不同服务分级的目标。

怎么做的 核心思路是放弃通用配置，采用场景定制化的服务配置，协同设计容量压缩、部署拓扑与执行路径。首先，为绕开显存容量卡点，方法引入了 Humming MXFP4AFP8（一种使用 MXFP4 专家权重和在线 FP8 激活的量化方案）大幅压缩权重体积，并配合 Online C128（一种只保留紧凑聚合状态的 KV Cache 压缩技术）释放显存，为并发请求腾出空间。其次，针对预填充的专家倾斜问题，将 MoE-EP 替换为张量并行（MoE-TP）。其核心逻辑是：全序列的 AllGather 和 ReduceScatter 虽增加通信量，但在 NVLink 上成本稳定，本质是用可预测的通信开销取代不可预测的算力失衡。在此基础上，预填充路径根据上下文长度动态切换流水线并行度：短文本使用 PP2 减少气泡开销，长文本使用 PP4 增加并行度；同时开发融合算子，将 AllGather、FP8 量化与 GEMM 融合，并直接针对生产环境的真实路由分布直方图微调 Humming 算子。最后，针对解码阶段，低延迟场景采用 PP2-TP8 拓扑，将 DSpark（一种投机解码方案）的执行协议跨流水线阶段同步；高吞吐场景采用 DP32-EP32 拓扑，将细化重打分步骤中的逐行点积替换为单块转置 GEMM 以消除高并发瓶颈，并通过 Humming-Aware SBO 机制，在 W2 矩阵乘法的单个分块计算完成后立即触发 DeepEP 的通信发送，实现计算与通信的极致掩盖。

效果如何 实验在 H20 GPU 集群上进行（96GB 版本用于预填充，141GB 版本用于解码），对比基线包括代表算力上限的 B300 硬件基线、单节点 TP8 极速基线、以及代表高吞吐效率的 DP16-EP16 基线。在 Batch Size 1 的低延迟解码测试中，优化后的 PP2-TP8 配合 DSpark 在 H20-141GB 上达到 271 tokens/s；相比算力高出 45.6 倍的 B300 硬件基线（383.7 tokens/s），本方法将实际性能差距缩小至 1.42 倍。在预填充测试中，PP4 策略在 1M 上下文长度下实现了 23,970 tokens/s 的吞吐量，耗时仅 43.7 秒。在容量与高吞吐测试中，Humming 联合 Online C128 将单卡全 token 容量最高提升了 10.14 倍；在 4K 输入、单 DP 组 32 并发的设置下，系统将单卡吞吐量从纯 FP8 多 token 预测基线的 319.92 tokens/s 提升至 703.15 tokens/s。作者也指出了方法的局限与代价：例如 DP32-EP32 虽能通过分散专家权重换取更大的 KV Cache 容量（支持 1M 上下文并发），但跨节点通信增加导致其单卡绝对效率比 DP16-EP16 基线低 3.6% 到 20%，且 Online C128 引入了额外的状态维护与验证计算开销。

主要贡献

DeepSeek-V4-Pro 作为一个拥有1.6万亿参数的混合专家（MoE）模型，发布了FP8和FP4两种权重的版本。尽管NVIDIA Blackwell GPU（如B300）原生支持FP4 Tensor Core并提供更高的HBM和计算吞吐量，但在实际部署中，受限于硬件可用性，H20 GPU仍然被广泛使用。然而，硬件的限制并不能放宽模型服务的严格要求：长上下文的预填充（Prefill）必须控制首字延迟（TTFT）；交互式解码（Decode）必须满足各个服务层级的每个输出Token时间（TPOT）目标；持续的流量必须在总吞吐量和KV缓存容量之间取得平衡。短输入、长上下文、延迟敏感型请求以及高并发等场景以不同的方式对系统施加压力，没有任何一种单一的通用配置能够完美应对所有情况。

本文的核心问题在于如何在受限的H20硬件集群上，通过系统性优化来满足DeepSeek-V4-Pro在不同场景下的服务等级目标（SLOs）。本文的研究目标与创新点主要包括：

1. 提出“单一模型，多种服务配置文件”的共设计方法：工作负载特征、服务等级目标（SLOs）和实际测量的硬件行为共同决定了部署拓扑和执行路径。预填充阶段根据测量的上下文长度范围在PP2和PP4之间动态选择；解码阶段则针对不同的延迟、吞吐量和KV容量目标使用不同的优化配置文件。
2. 深度优化预填充（Prefill）路径：优化了 Attention-CP8 → MoE-TP8 路径以及上下文并行（Context-Parallel）通信，并针对长短上下文工作负载产生的真实路由形状进行了深度微调。
3. 深度优化解码（Decode）路径：优化了DSpark投机解码（Speculative-Decoding）路径，针对不同的解码SLO完善了执行流程、专家路由以及通信与计算的重叠机制。
4. 突破延迟与吞吐量的边界：在Batch Size为1的情况下，单节点H20-141GB参考配置达到了 271 output tokens/s 的生成速度，与更强算力的B300（报告值为383.7 tokens/s）相比，通过针对工作负载的系统优化，将实际解码性能差距缩小至仅 1.42倍。在更广泛的配置中，优化后的预填充达到 每节点8.45k input tokens/s，并在43.7秒内处理完1M Token的提示词。面向吞吐量的解码配置（DP16-EP16）达到 每节点4.67k output tokens/s，平均TPOT为27.4毫秒。
5. 提供场景驱动的方法论：本文的贡献不仅限于单一基准测试，而是提供了一套场景特定的服务方法论，为在计算、内存、带宽或互连受限的情况下服务前沿模型的团队提供了极具实用价值的参考。

---

背景与设计原则

2.1 硬件约束与服务角色

Blackwell提供原始性能，而H20提供可部署的规模。 B300提供了原生的FP4 Tensor Core、高得多的FP8吞吐量以及显著更大的HBM容量。尽管H20无法在计算能力上与之匹敌，但它在规模部署上仍然具备可用性，并提供高内存带宽和900 GB/s的NVLink互连。在本研究的部署中，每个节点包含八个通过NVLink连接的GPU。预填充（Prefill）阶段不需要保留长生命周期的请求级状态，因此其硬件选择主要受首字延迟（TTFT）、计算能力和通信效率的制约。相反，解码（Decode）阶段必须在整个生成过程中保留每个活跃请求的KV缓存，这使得HBM容量成为上下文长度和并发量的直接瓶颈。基于这些特征，本研究将H20-141GB分配给解码任务，而将H20-96GB（其容量足以满足预填充工作负载）分配给预填充任务。

Figure 1. Hardware Gap: H20 vs. B300.

Figure 2. Hardware Assignment by Serving Role.

2.2 容量选择

共享HBM预算下的容量分配。 服务容量最终来源于共享的HBM预算：模型权重和每个请求的KV状态在同一内存空间中竞争。作者定义全Token容量（full-token capacity）为在分配了模型权重和运行时缓冲区之后，每个Rank所能容纳的最大全注意力KV Token数量。这是一个内存上限，而不是对允许的批处理大小（Batch Size）的直接保证。

首先减少权重内存占用。 本文采用了Humming MXFP4AFP8【1，Humming MXFP4AFP8 GitHub仓库，https://github.com/inclusionAI/humming】技术，在缺乏原 生FP4 Tensor Core的H20 GPU上，使用MXFP4格式的专家权重并结合在线FP8激活，以此来减少权重内存占用和内存通信流量。相关的SGLang集成方案见【2，SGLang Pull Request #23754，https://github.com/sgl-project/sglang/pull/23754】 。

为KV缓存腾出增长空间。 离线（Offline）C128基线方案为每个压缩页面保留基于索引的状态。相比之下，在线（Online）C128方案维护一个紧凑的聚合状态，从而将更多的HBM释放给KV缓存池。虽然这引入了额外的状态维护和投机验证工作，但在测试中并未观察到TPOT（每个输出Token时间）的退化。

权重与KV状态的复合容量增益。 通过减少权重占用，Humming MXFP4AFP8将DP32-EP32配置的全Token容量扩展至基线（FP8 + Offline C128）的 1.71倍，将PP2-TP8配置的容量扩展至 4.47倍。随后，Online C128进一步减少了C128辅助状态的内存占用，在Humming的基础上又提供了 2.268倍 的增长。综合这两项技术，DP32-EP32的容量提升至基线的 3.88倍，而PP2-TP8的容量提升至基线的 10.14倍。

Figure 3. Capacity Scaling with Humming MXFP4AFP8 and Online C128.

2.3 面向特定场景的服务配置文件

预填充配置文件

合适的流水线深度取决于有多少工作需要被流水线化。 PP2-CP8-TP8和PP4-CP8-TP8共享相同的 Attention-CP8 → MoE-TP8 执行路径。在拓扑层面上，它们的主要区别在于流水线深度：PP2将模型分布在两个阶段，而PP4使用四个阶段。

短上下文倾向于低流水线开销，而长上下文暴露更多并行性。 短输入产生的块（chunks）较少，这会导致较深的流水线无法被填满，从而使得填充（fill）、排空（drain）以及跨阶段传输的成本变得更加突出。相反，长上下文提供了足够的块来保持四个阶段处于繁忙状态；由于每个阶段的层数更少，增加的节点转化为更多的预填充并行性。基于这些特性，部署中采用 PP2-CP8-TP8处理较短的上下文，采用 PP4-CP8-TP8处理长上下文工作负载。

Figure 4. Prefill Profiles: Same Execution Path, Different Pipeline Depth.

低延迟解码配置文件

低延迟始于最短的执行路径。 单节点TP8和PP2-TP8共享相同的 Attention-TP8 → MoE-TP8 执行路径；区别在于模型是否跨节点划分。单节点TP8将所有层放置在一个H20-141GB节点上，避免了跨阶段的通信和同步。而PP2-TP8将模型划分到两个流水线阶段。

最快的拓扑并非总是最可服务的。 单节点TP8拥有更短的执行路径，但模型权重和服务状态共享一个节点的HBM，留给KV缓存的空间非常有限。它无法同时支持长上下文和更大的批处理大小。PP2-TP8虽然付出了额外的流水线开销，但将模型权重分布在两个节点上，释放了更多HBM用于KV状态。因此，对于延迟和容量目标，系统将 单节点TP8作为Batch Size 1的延迟参考，并将 PP2-TP8作为低延迟服务配置文件。

Figure 5. Low-Latency Decode: TP8 Reference and PP2-TP8 Serving Profile.

高吞吐量解码配置文件

高吞吐量解码同时扩展数据与专家并行。 DP16-EP16和DP32-EP32配置文件均使用 Attention-DP → MoE-EP 执行路径。DP16-EP16是最小的部署单元；DP32-EP32在同一拓扑内同时扩展了DP（数据并行）和EP（专家并行）。

横向扩展优先考虑请求容量而非单GPU吞吐量。 更大的EP组将专家权重分布在更多的GPU上，从而为KV缓存释放HBM并允许接入更多并发请求。同时，留在每个节点内的MoE流量比例变小，跨节点的流量比例变大，这可能会降低单GPU效率。在评估的配置中，系统将DP16-EP16作为最小部署单元和效率参考，而使用DP32-EP32来扩展请求容量。

Figure 6. High-Throughput Decode: DP16-EP16 Reference and DP32-EP32 Capacity Profile.

---

方法细节：预填充阶段

预填充性能是一个系统性问题。 专家不平衡、上下文并行通信以及生产环境中的路由形状共同决定了首字延迟（TTFT）；仅仅优化孤立的内核是远远不够的。

3.1 为什么选择MoE-TP而不是MoE-EP

较少的流量仍然可能耗费更长时间。 MoE-EP（专家并行）仅交换被路由的Token，但实际的预填充流量表现出显著的专家倾斜（expert skew）。拥有热点专家（hot experts）的Rank执行了更多的计算，从而成为拖后腿的节点（stragglers）；所有其他Rank在合并步骤时都必须等待最慢的路径。因此，较低的通信量并未转化为较低的TTFT。

在最小化流量之前先平衡计算。 对于这里评估的H20预填充工作负载，PP2和PP4均使用了MoE-TP（张量并行）。全序列的All-Gather和Reduce-Scatter引入了更多的通信，但这些流量保留在高带宽的NVLink上，具有稳定且可预测的成本。所有的TP Rank对相同的路由Token执行张量并行计算，从而防止了专家倾斜演变为Rank级别的长尾延迟。对于这种工作负载，可预测的通信比不可预测的不平衡代价更低。相关实现见【3，SGLang Pull Request #24947，https://github.com/sgl-project/sglang/pull/24947】 。

Figure 7. Replacing MoE-EP with MoE-TP.

3.2 加速并融合预填充集合通信

构建可复用的集合通信快速路径。 MoE-TP用可预测的集合通信流量取代了不可预测的专家不平衡，使得通信效率成为下一个瓶颈。作者使对称内存（symmetric memory）在TP和CP之间可复用，允许AllReduce、AllGather和ReduceScatter共享已注册缓冲区的快速路径以及适用的Hopper架构加速。支持此功能的上游工作涵盖了内存池所有权、通信器注册、MoE-TP集合通信缓冲区，以及CP Attention和KV缓存缓冲区路径。

缩短预填充关键路径。 更快的集合通信本身并不能消除通信与计算之间的边界。对于32K单块（single-chunk）的情况，作者构建了一个融合路径：首先，将由复制引擎（copy-engine）驱动的AllGather与融合的FP8量化以及共享专家GEMM进行重叠执行；接着，在第二个Triton内核中，将TopK归约、共享专家加法以及ReduceScatter结合起来。这种重组将七个算子折叠为三个执行组，并在匹配的PP4 A/B测试中将首字延迟（TTFT）降低了约 3.5%。

Figure 8. Symmetric-Memory Collectives and Prefill Fusion.

3.3 针对真实路由形状微调Humming

通用调优会遗漏关键的形状。 预填充路由将Token不均匀地分布在384个专家中，因此有效的 M 维度会聚类成一小组离散值。此外，W13和W2操作的形状也不同，单一的通用启发式方法无法同时优化这两条路径。

基于生产环境路由进行调优。 作者从真实的路由直方图中提取高频形状，为W13和W2构建了独立的精确形状配置，并在内核、流水线阶段以及匹配的A/B测试级别对其进行验证。优化的目标不是合成的 M 范围，而是 实际服务中真实的路由分布。在32K上下文的PP4匹配A/B测试中，选定的MoE内核延迟下降了约 21%，这转化为端到端TTFT降低了 11.35%。

Figure 9. Tuning Humming for Real Routing Shapes.

---

方法细节：解码阶段

在作者的实现中，解码优化是特定于配置文件的。 PP2-TP8需要跨投机流水线阶段进行协调，而DP32-EP32则侧重于在高并发下优化细化（refinement）步骤和专家路由。Humming的融合与重叠技术改善了这些服务拓扑底层的共享MoE热路径。

4.1 低延迟PP2-TP8：跨流水线阶段扩展DSpark

流水线并行分割了投机循环。 在PP2-TP8中，目标模型的执行跨越了两个流水线阶段，而DSpark【4，SGLang Pull Request #30261，https://github.com/sgl-project/sglang/pull/30261】草稿模型（drafter）仅驻留在最终阶段。阶段0将目标隐藏状态发送给阶段1，阶段1执行验证、接受Token，并为下一轮生成候选Token 。

使两个阶段同步推进。 每一轮投机解码都跨越了流水线边界。作者在一个统一的执行协议下协调两个阶段以及所需的中间传输，防止阶段进入不同的轮次，同时避免了冗余的同步。特定于流水线并行的DSpark集成正在被合并到上游【5，SGLang Pull Request #32281，https://github.com/sgl-project/sglang/pull/32281】中 。

Figure 10. Coordinating DSpark Across PP2 Stages.

4.2 高吞吐量DP32-EP32：消除高并发瓶颈

（本小节中的匹配A/B测试结果使用DP32-EP32配置，在4K上下文下，每个DP Rank有32个并发请求。）

为细化步骤选择正确的执行形状。 细化（refinement）步骤应用全词表投影来重新评分DSpark的候选集。在高并发情况下，逐行（row-wise）的点积归约（dot-reduce）会为每个活跃行重复读取词表权重，从而在每个解码步骤中造成持久的长尾延迟。作者将活跃行合并为一个转置GEMM，减少了冗余的内存流量并缩短了细化路径。此优化使单GPU吞吐量提升了 22.8%。

根据测量的路由放置专家。 DSpark流量同样表现出显著的专家倾斜。作者记录了代表性请求的路由亲和性，并利用它来配置专家并行负载均衡（EPLB）和冗余专家，从而防止少数热点专家反复延长关键路径。此优化使单GPU吞吐量提升了 13.5%。

Figure 11. DP32-EP32 Bottleneck Removal.

4.3 Humming解码热路径：融合与重叠

（这些优化位于服务拓扑底层，可被基于Humming的解码配置文件复用。匹配结果使用DP32-EP32配置，4K上下文，每个DP Rank 32个并发请求。）

移除额外的量化过程。 作者将SwiGLU激活函数与量化过程融合，使得融合后的内核直接产生W2所需的数据和缩放因子（scale）。这消除了对中间缓冲区的重复访问，并移除了独立的量化过程，允许W2更早开始执行。在匹配的DSpark A/B测试中，单GPU吞吐量提升了 44.0%。

将通信与W2重叠。 作者将前期工作中的单批次重叠（Single-Batch Overlap, SBO）【6，SGLang Pull Request #9660，https://github.com/sgl-project/sglang/pull/9660】机制适配 为 Humming-Aware SBO。每Tile（per-tile）的信号允许DeepEP在W2输出Tile完成时立即开始相应的合并发送（combine send），而无需等待整个GEMM完成。在相同操作点下早期的无投机解码A/B测试中，相对于FP8传输层，SBO恢复了 4.12% 的吞吐量。

Figure 12. Humming Decode Hot-Path Optimizations.

---

实验环境

• 硬件配置：

  • 解码节点：1台包含8张 H20-141GB GPU的服务器，使用900 GB/s NVLink互连。
  • 预填充节点：H20-96GB GPU服务器（由于预填充不需要长期维持状态，HBM容量需求较低）。
  • 对比参考硬件：NVIDIA B300（用于峰值算力与实际吞吐量的对比）。

• 软件配置：

  • 服务框架：SGLang（使用 sglang-oai-chat 后端）。
  • MoE后端：Humming (--moe-runner-backend humming)。
  • 投机解码：DSpark算法 (--speculative-algorithm DSPARK)，配置7个草稿Token (--speculative-num-draft-tokens 7)，块大小为7 (--speculative-dspark-block-size 7)。

• 模型配置：DeepSeek-V4-Pro（1.6万亿参数，MoE架构，FP8/FP4权重）。

• 数据集配置：采用随机生成数据集（dataset-name: random），随机输入长度设为262144，随机输出长度设为4096，并发数根据实验动态调整。

---

实验结果

5.1 预填充：累积增益与上下文长度权衡

PP2增强了短上下文配置文件。 PP2在测试的9个输入长度上均表现出改进，几何平均吞吐量增益为 36.5%，峰值总输入吞吐量达到 16,900 tokens/s。其较浅的流水线减少了短请求的填充和排空开销，使PP2能够以更少的资源保持较低的TTFT。

PP4将增益延续到长上下文。 在相同的9个数据点上，PP4实现了 31.8% 的几何平均吞吐量增益。随着上下文长度的增长，较深的流水线有足够的工作量来摊销其固定成本：在512K时，总输入吞吐量达到 25,860 tokens/s，在1M时保持在 23,970 tokens/s。

Figure 13. Cumulative Prefill Throughput Gains.

上下文长度改变了PP2/PP4的权衡。 相对于PP4，PP2在4K时将TTFT降低了 16.7%，在32K时降低了 19.5%。在8K、16K和64K时，两者的差异保持在 2% 以内。从128K开始，PP4确立了决定性的优势，相对于PP2，其在128K、256K、512K和1M时的TTFT分别降低了 26.2%、33.3%、42.1% 和 44.8%。因此，系统将路由边界视为从测量的上下文长度范围推导出的操作策略，而不是一个固定的交叉点。

Figure 14. TTFT Trade-off Between PP2 and PP4.

5.2 低延迟解码：性能与容量权衡

优化的DSpark重置了延迟基线。 在图15所示的四个输入长度（8K、64K、256K、1M）下，优化的DSpark在Batch Size 1时将峰值TPOT降低了 74.8%–78.0%。在每对测量共享的最大Batch Size下，降低幅度依然保持在 52.2%–60.0%。这种增益从8K一直延伸到1M，而不仅仅局限于短上下文或单请求执行。

Figure 15. Peak TPOT Gains from Optimized DSpark.

观察到的服务性能远比峰值计算比例所暗示的更接近。 在图16所示的四个输入长度下，优化的DSpark在PP2-TP8上于Batch Size 1时达到了 150–174 tokens/s。单节点TP8参考配置达到了 183–271 tokens/s。以实际执行路径使用的精度计算，B300的峰值Tensor Core算力约为H20-141GB的 45.6倍（B300 FP4 vs H20 FP8），内存带宽是其 1.67倍。然而，观察到的最高生成速率分别为B300上的 383.7 tokens/s 和H20-141GB上的 271 tokens/s——比例仅为 1.42倍。即使面对算力强得多的硬件参考，针对工作负载的系统优化也使H20-141GB在实际服务性能上大幅拉近了差距。

容量优势使得PP2-TP8成为生产目标的首选。 单节点TP8速度更快，但在1M上下文下，其KV缓存容量仅够容纳Batch Size 1，无法接入更大的Batch或更多并发请求。通过将模型权重分布在两个流水线阶段，PP2-TP8在1M、512K和256K上下文下分别支持Batch Size 4、8和16。结合Online C128，其全Token容量达到 11.04M tokens/rank。

Figure 16. Batch-Size-1 Decode Throughput: H20-141GB and B300 Reference.

5.3 高吞吐量解码：前沿增益与配置权衡

图17展示了吞吐量-交互性边界（Pareto frontier）随系统的演变。横轴是交互性（tokens/s/user），纵轴是吞吐量（tokens/s/GPU）。越靠近右上角的点，表明对用户可见的生成速度和GPU效率的组合越好。

系统优化推动了整个边界。 在4K上下文、每个DP Rank 32个并发请求的条件下，单GPU吞吐量从 319.92 tokens/s/GPU 上升到 703.15 tokens/s/GPU，提升了 2.20倍。在1M上下文、每个DP Rank 1个请求的情况下，吞吐量从 27.05 tokens/s/GPU 上升到 66.82 tokens/s/GPU。前三个系统里程碑在1M时每个DP Rank只能处理1个请求；而最终系统支持4个并发，并达到 177.48 tokens/s/GPU。

Figure 17. Throughput–Interactivity Pareto Frontiers.

较小的部署单元在特定的高并发操作点保留了效率。 在16和32个并发请求/DP Rank下，DP16-EP16提供的单GPU吞吐量比DP32-EP32高出约 3.6%–20%。因此系统将DP16-EP16作为效率参考。

Figure 18. Per-GPU Throughput: DP16-EP16 vs. DP32-EP32.

容量改变了首选的高吞吐量配置。 尽管DP16-EP16在单GPU上更高效，但DP32-EP32将专家权重分布在更多的Rank上，为KV缓存释放了额外的HBM。在256K、512K和1M上下文下，每个DP Rank的最大并发请求数从 8、4和2 增加到了 16、8和4——实现了稳定的 2倍 扩展。这使得 DP32-EP32成为面向容量的高吞吐量配置文件。

Figure 19. Long-Context Request Capacity per DP Rank.

---

结论

单一模型不需要单一的妥协配置文件。 作者为H20上的DeepSeek-V4-Pro构建了一个面向特定场景的服务栈。预填充根据上下文长度在PP2和PP4之间切换；解码阶段使用PP2-TP8实现低延迟，使用DP32-EP32实现高吞吐量。通过协同设计容量、部署拓扑和执行路径，尽管计算资源有限且缺乏原生的FP4 Tensor Core，H20依然能够维持1M Token的上下文并满足多种服务SLO。

可迁移的成果是一种场景驱动的方法论。 服务配置文件不应仅从硬件规格或孤立的基准测试中选择。作者建议从工作负载、SLO、上下文长度和并发度出发，然后利用Profiling（性能分析）来识别瓶颈资源，并将其转化为具体的拓扑和执行路径决策。这一方法论旨在帮助AI基础设施团队在计算、内存容量、内存带宽或互连受限的各种条件下，构建实用的前沿模型服务系统。

---

补充细节：致谢

作者感谢 SGLang团队和社区 在SGLang框架上的出色工作。同时感谢以下团队和合作者的支持与贡献：

• 蚂蚁集团SCT团队：Yongfei Xu, Qianyu Zhang, Zekai Gu, ZhiLin Huang, Fakang Wang, Jianhao Fu, Zhuoxuan Du, Xia Zhan, Chun Huang, Qi Liu, Xi Chen, Yuhan Mao, Peipeng Cheng, Hanlin Gao, Jinghua Yao
• 蚂蚁集团Venus团队：Jinzhen Lin
• SGLang社区：Peng Zhang

---

附录

A. 预填充结果

A.1 Humming PP2 预填充：基线对比最终配置

输入长度	基线 TTFT (ms)	基线总输入吞吐量 (tokens/s)	最终 TTFT (ms)	最终总输入吞吐量 (tokens/s)
4K	775.8	5,280	573.3	7,140
8K	1202.1	6,810	907.6	9,030
16K	2059.8	7,950	1649.5	9,930
32K	4137.5	7,920	2470.3	13,260
64K	6195.7	10,580	4063.8	16,130
128K	10744.4	12,200	7975.9	16,430
256K	20542.2	12,760	15507.2	16,900
512K	44544.6	11,770	34982.6	14,990
1M	100304.2	10,450	79214.2	13,240

A.2 Humming PP4 预填充：基线对比最终配置

输入长度	基线 TTFT (ms)	基线总输入吞吐量 (tokens/s)	最终 TTFT (ms)	最终总输入吞吐量 (tokens/s)
4K	924.6	4,430	687.9	5,950
8K	1174.5	6,970	890.3	9,200
16K	2202.0	7,440	1635.4	10,020
32K	4185.6	7,830	3068.4	10,680
64K	5252.4	12,480	3982.6	16,460
128K	7793.4	16,820	5882.5	22,280
256K	13210.7	19,840	10348.9	25,330
512K	26350.1	19,900	20273.1	25,860
1M	55532.3	18,880	43742.5	23,970

B. 低延迟解码结果

B.1 跨输入长度和Batch Size的峰值TPOT

B.1.1 无投机解码 (No-Spec) PP2-TP8

输入长度 / Batch Size (峰值 TPOT, ms)	1	2	4	8	16
8K	26.39	30.86	31.31	31.79	31.74
32K	25.72	26.58	27.81	31.06	37.97
64K	25.75	26.62	28.13	29.19	38.75
128K	25.94	26.94	28.38	29.75	38.51
256K	26.08	27.21	28.84	32.43	38.83
512K	26.25	27.51	29.16	33.70	-
1M	26.42	27.81	29.52	-	-

B.1.2 优化的DSpark PP2-TP8

输入长度 / Batch Size (峰值 TPOT, ms)	1	2	4	8	16	32
4K	5.91	6.76	7.97	10.00	14.55	19.23
8K	5.80	6.87	8.85	10.48	15.18	19.60
32K	6.14	7.04	8.39	10.83	14.86	20.46
64K	6.15	7.13	8.73	10.39	15.49	21.65
128K	6.77	7.02	8.91	11.59	16.17	24.78
256K	5.76	6.98	8.61	11.98	17.72	-
512K	6.35	7.95	9.87	14.30	-	-
1M	6.65	8.92	12.43	-	-	-

B.2 Batch-Size-1 输出吞吐量

输入长度	No-Spec PP2-TP8 (tokens/s)	优化的DSpark PP2-TP8 (tokens/s)	单节点TP8 (tokens/s)
4K	-	169	213
8K	38	172	260
16K	-	-	244
32K	39	163	269
64K	39	163	246
128K	39	148	267
256K	38	174	271
512K	38	157	254
1M	38	150	183

B.3 基准测试设置代码

硬件配置：1个 8× H20-141GB 解码节点。

解码服务器启动命令：

--tp-size 8 \
--mem-fraction-static 0.91 \
--max-running-requests 1 \
--cuda-graph-max-bs 1 \
--cuda-graph-bs 1 \
--moe-runner-backend humming \
--moe-a2a-backend none \
--speculative-algorithm DSPARK \
--speculative-num-draft-tokens 7 \
--speculative-dspark-block-size 7 \
--speculative-moe-runner-backend triton \
--speculative-moe-a2a-backend none

客户端基准测试命令：

python3 -m sglang.bench_serving \
  --backend sglang-oai-chat \
  --host 127.0.0.1 \
  --port 8000 \
  --model <MODEL_PATH> \
  --dataset-name random \
  --dataset-path <DATASET_PATH> \
  --random-input-len 262144 \
  --random-output-len 4096 \
  --random-range-ratio 1.0 \
  --num-prompts 10 \
  --max-concurrency 1 \
  --warmup-requests 0 \
  --seed 1

输出吞吐量提取自服务器的TP0 Decode batch 日志行；作者丢弃了最高和最低的20%样本，并对剩余部分取平均值。

C. 高吞吐量解码结果

C.1 DP32-EP32 结合 FP8 + MTP (3, 1, 4)

输入长度 / 每DP Rank并发请求数 (tokens/s/GPU)	1	2	4	8	16	32
4K	30.49	58.58	102.89	174.75	253.15	319.92
8K	30.34	58.29	102.38	174.67	251.62	318.32
16K	29.70	56.55	99.47	170.01	242.22	302.43
32K	29.58	56.35	98.28	164.26	234.13	-
64K	29.07	55.73	96.43	161.60	-	-
128K	28.39	54.06	92.89	153.55	-	-
256K	28.35	53.02	90.89	-	-	-
512K	27.51	51.49	-	-	-	-
1M	27.05	-	-	-	-	-

C.2 DP32-EP32 结合 FP8 + 优化的 MTP (3, 1, 4)

输入长度 / 每DP Rank并发请求数 (tokens/s/GPU)	1	2	4	8	16	32
4K	36.84	69.86	131.96	232.94	389.94	514.77
8K	32.58	69.51	131.53	222.06	348.80	416.82
16K	31.89	67.44	127.79	216.14	341.85	395.99
32K	31.49	67.21	124.49	208.83	337.97	-
64K	30.95	66.47	123.68	205.44	-	-
128K	30.22	64.47	119.14	-	-	-
256K	30.18	63.23	-	-	-	-
512K	29.28	61.40	-	-	-	-
1M	28.79	-	-	-	-	-

C.3 DP32-EP32 结合 FP8 + DSpark

输入长度 / 每DP Rank并发请求数 (tokens/s/GPU)	1	2	4	8	16	32
4K	53.1	94.8	181.2	338.1	495.8	591.8
8K	44.5	88.4	170.1	317.3	495.5	-
16K	43.6	88.3	165.3	308.8	455.5	-
32K	43.0	87.3	161.0	298.4	-	-
64K	42.3	86.3	158.0	-	-	-
128K	41.3	83.8	-	-	-	-
256K	41.2	-	-	-	-	-
512K	40.0	-	-	-	-	-
1M	39.3	-	-	-	-	-

C.4 DP32-EP32 结合 Humming MXFP4AFP8 + Online C128 + DSpark

输入长度 / 每DP Rank并发请求数 (tokens/s/GPU)	1	2	4	8	16	32
4K	75.32	127.10	235.85	417.53	564.08	703.15
8K	75.60	128.29	238.01	417.34	560.68	709.64
16K	74.00	124.47	231.25	406.21	539.72	674.19
32K	73.07	122.27	225.28	392.47	521.70	601.67
64K	71.81	120.92	221.05	386.11	516.54	599.63
128K	70.12	117.29	212.93	366.88	487.69	-
256K	70.03	115.03	208.35	345.21	457.62	-
512K	67.95	111.71	191.99	302.80	-	-
1M	66.82	105.82	177.48	-	-	-

C.5 DP16-EP16 结合 Humming MXFP4AFP8 + Online C128 + DSpark

输入长度 / 每DP Rank并发请求数 (tokens/s/GPU)	1	2	4	8	16	32
4K	76.80	129.62	236.83	397.42	584.37	759.73
8K	76.69	130.55	237.53	398.60	582.03	762.09
16K	76.16	127.88	233.10	388.54	571.22	745.23
32K	74.07	124.77	226.24	378.79	559.05	722.51
64K	74.57	124.69	223.84	373.13	541.46	695.35
128K	72.36	120.34	219.66	365.13	518.98	-
256K	71.38	119.19	211.64	340.72	-	-
512K	69.54	115.14	198.81	-	-	-
1M	67.39	106.50	-	-	-	-

D. 容量验证结果

D.1 解码容量扩展

解码配置文件	配置	全Token容量 (tokens/rank)	对比前一阶段	对比 FP8 基线
DP32-EP32	基线 FP8 + Offline C128	1,475,328	-	1.00×
	Humming MXFP4AFP8 + Offline C128	2,526,720	1.71×	1.71×
	Humming MXFP4AFP8 + Online C128	5,731,328	2.268×	3.88×
PP2-TP8	基线 FP8 + Offline C128	1,089,024	-	1.00×
	Humming MXFP4AFP8 + Offline C128	4,869,888	4.47×	4.47×
	Humming MXFP4AFP8 + Online C128	11,044,906	2.268×	10.14×

D.2 Humming 准确率验证

作者在 GSM8K1000 数据集上评估了 DP16-EP16 Humming MXFP4AFP8 + Online C128 + DSpark 配置文件。该配置文件达到了 95.5% 的精确匹配（exact-match）准确率，仅有1个无效响应且系统错误为零，成功通过了作者设定的 95.0% 的接受阈值。

作为公开参考，上游的 SGLang Humming 集成在DeepSeek-V4-Flash的200个样本GSM8K评估中报告了以下结果：

后端	GSM8K 准确率
Marlin MXFP4A16	96.5%–97.0%
FlashInfer MXFP4	96.5%–97.0%
Humming MXFP4A16	96.5%–97.5%
Humming MXFP4AFP8	97.0%

在这一公开比较中，Humming MXFP4AFP8 并没有表现出明显的准确率下降。由于该参考使用的是 DeepSeek-V4-Flash 而不是 DeepSeek-V4-Pro，作者将其视为外部参考，而不是本服务配置文件的直接准确率损失测量值。