# 突破 DeepSeek-V4-Pro 服务极限：H20 上的多场景优化方法 - 来源：LMSYS：Blog（Chatbot Arena 团队） - 作者：Tianyu Zhang, Yusong Gao, Yun Zhang - 发布时间：2026-08-20 01:56 - AIHOT 分数：73 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.virxact.com/items/cmt0e7sxo01eiro2o4l4y9jmh - 原文链接：https://www.lmsys.org/blog/2026-08-19-deepseek-v4-pro-engine-optimization-h20 ## 精选理由 文章提出按上下文长度与并发需求分场景选择 prefill/decode 配置，并用 Humming 压缩和 Online C128 释放 HBM，使 H20 也能服务 1M 上下文，为受限硬件上的大规模推理提供了可复用的工程思路。 ## AI 摘要 LMSYS 团队针对 1.6 万亿参数的 MoE 模型 DeepSeek-V4-Pro，在 H20 GPU 上通过场景化服务配置逼近 B300 性能。单节点 H20-141GB 参考实现达 271 output tokens/s，与 B300 的 383.7 tokens/s 性能差距缩小至 1.42×。 ## 正文 突破 DeepSeek-V4-Pro 服务能力的极限 张天宇、高雨松、张云 1. 引言 DeepSeek-V4-Pro 是一个 1.6 万亿参数的混合专家（MoE）模型，同时发布了 FP8 和 FP4 两种权重的版本。这种规模的模型天然受益于 NVIDIA Blackwell GPU 等加速器，后者提供更大的 HBM 容量、更高的计算吞吐量以及原生的 FP4 Tensor Core 支持。然而，H20 GPU 尽管缺乏这些优势，仍被广泛部署。 硬件限制并不会降低服务要求。长上下文预填充仍须控制首 token 时间（TTFT）。交互式解码必须满足每个服务层级的时间每输出 token（TPOT）目标。持续流量必须在聚合吞吐量与 KV 缓存容量之间取得平衡。短输入、长上下文、延迟敏感型请求以及高并发会以不同方式给系统施加压力；没有任何一种通用配置能够同时很好地应对所有这些情况。 一个模型需要多种服务配置。工作负载特征、服务级别目标（SLO）以及实测的硬件行为共同决定部署拓扑和执行路径： 将服务配置与工作负载相匹配。在本文评估的配置中，预填充根据实测的上下文长度范围在 PP2 和 PP4 之间进行选择，而解码则使用针对不同延迟、吞吐量和 KV 容量目标优化的配置。 优化预填充路径。我们优化了 Attention-CP8 → MoE-TP8 以及上下文并行通信，然后针对长上下文和短上下文工作负载产生的真实路由形态进行调优。 优化解码路径。我们优化了 DSpark 投机解码路径，针对不同的解码 SLO 细化执行、专家路由以及通信与计算的重叠。 突破延迟极限。在批大小为 1 时，单节点 H20-141GB 参考配置达到 271 输出 token/秒，而 B300 上报告的数值为 383.7 token/秒。尽管硬件差距巨大，针对特定工作负载的系统优化将实测解码性能比缩小至 1.42 倍。详细的基准测试设置以及基于日志的吞吐量提取方法见附录 B.3。 覆盖服务（serving）的完整性能包络。延迟结果只代表系统的一个侧面。在更广泛的配置（profile）族中，优化后的预填充（prefill）达到每节点每秒 8.45k 输入 token，并在 43.7 秒内处理完一个 1M token 的提示词。在面向吞吐量的解码（decode）方面，DP16-EP16 效率参考配置达到每节点每秒 4.67k 输出 token，对应平均 TPOT 为 27.4 毫秒。这些结果有意取自不同的配置，每个配置都针对上下文长度、延迟、吞吐量和容量约束的不同组合进行了选择和优化。 这里的贡献是一套方法论，而非单一基准。场景化服务（scenario-specific serving）允许每个工作负载在现有硬件上评估的各配置中，向更优的实测运行点移动。我们希望这里呈现的部署选择、优化方法和实测结果，能为在算力、内存、带宽或互联约束下服务前沿模型的团队提供实用参考。 2. 从硬件约束到服务配置（Serving Profiles） 2.1 硬件约束与服务角色 图 1. 硬件差距：H20 对比 B300。 Blackwell 提供原始性能；H20 提供可规模化的部署能力。B300 具备原生 FP4 Tensor Core、高得多的 FP8 吞吐量，以及显著更大的 HBM。H20 无法匹敌其计算能力，但它仍可大规模获取，并提供高内存带宽和 900 GB/s 的 NVLink。本研究中的每个节点包含八块通过 NVLink 连接的 GPU。预填充不保留跨请求的长期状态，因此其硬件选择主要受 TTFT、计算和通信效率的制约。解码必须在整个生成过程中保留每个活跃请求的 KV cache，这使得 HBM 容量直接限制上下文长度和并发度。在本研究所涉及的部署中，这促使我们使用 H20-141GB 用于解码，使用 H20-96GB——其容量足以满足我们的预填充工作负载——用于预填充。 图 2. 按服务角色的硬件分配。 2.2 容量选择 服务容量最终来源于共享的 HBM 预算：模型权重和每请求的 KV 状态会竞争同一块内存。我们将“全 token 容量”定义为：在模型权重和运行时缓冲区分配完毕后，每个 rank 所能容纳的全注意力 KV token 的最大数量。它是一个内存上限，而非可接受批处理规模的直接保证。 使用 Humming MXFP4AFP8 缩减权重占用 首先缩减权重占用。Humming MXFP4AFP8 使用 MXFP4 专家权重配合在线 FP8 激活，以减少 H20 GPU（缺乏原生 FP4 Tensor Core）上的权重占用和内存流量。SGLang 集成已可在 sglang#23754 中获取。我们将在后续专门文章中介绍 Humming/SGLang 集成。模型级精度结果和公开参考测量数据见附录 D.2。 通过 Online C128 扩展 KV 容量 为 KV 缓存留出增长空间。Offline C128 基线为每个压缩页保留逐索引状态。Online C128 则维护一个紧凑的聚合状态，将更多 HBM 释放给 KV 缓存池。它会引入额外的状态维护和推测验证工作，但我们在测试中未观察到 TPOT 回退。 综合容量提升 图 3. 使用 Humming MXFP4AFP8 和 Online C128 的容量扩展。 容量提升在权重和 KV 状态两个维度上叠加生效。通过缩减权重占用，Humming MXFP4AFP8 将全 token 容量扩展到 Baseline FP8 + Offline C128 配置的 1.71 倍（DP32-EP32）和 4.47 倍（PP2-TP8）。Online C128 随后缩减 C128 辅助状态占用，在 Humming 基础上再提供 2.268 倍的提升。两项技术结合后，容量分别提升至基线的 3.88 倍（DP32-EP32）和 10.14 倍（PP2-TP8）。附录 D.1 提供了完整数据。 2.3 场景特定的服务配置 Prefill 配置 图 4. Prefill 配置：相同执行路径，不同流水线深度。 正确的流水线深度取决于需要流水化的工作量大小。PP2-CP8-TP8 和 PP4-CP8-TP8 共享相同的 Attention-CP8 → MoE-TP8 执行路径。在拓扑层面，它们的主要区别在于流水线深度：PP2 将模型分布在两个阶段，而 PP4 使用四个阶段。 短上下文更倾向于较低的流水线开销；长上下文则能暴露更多的并行度。短输入产生的块（chunk）较少，会使更深的流水线填充不足，从而让填充（fill）、排空（drain）和跨阶段传输的成本更加突出。长上下文能提供足够的块，使四个阶段保持忙碌；由于每个阶段的层数更少，额外的节点便转化为更多的预填充并行度。在我们的部署中，这些特性促使我们对较短上下文采用 PP2-CP8-TP8，而对长上下文工作负载采用 PP4-CP8-TP8。 低延迟解码配置 图 5. 低延迟解码：TP8 参考配置与 PP2-TP8 服务配置。 低延迟始于最短的执行路径。单节点 TP8 与 PP2-TP8 共享相同的 Attention-TP8 → MoE-TP8 执行路径；区别在于模型是否跨节点划分。单节点 TP8 将所有层放置在单个 H20-141GB 节点上，避免了跨阶段通信和同步。PP2-TP8 则将模型划分到两个流水线阶段上。 最快的拓扑并不总是最实用的。单节点 TP8 执行路径更短，但模型权重和服务状态共享单个节点的 HBM，留给 KV 缓存的空间有限。它无法同时支持长上下文和更大的批处理规模。PP2-TP8 虽然增加了额外的流水线开销，但将模型权重分布到两个节点上，为 KV 状态释放了更多 HBM。针对我们的延迟和容量目标，我们采用单节点 TP8 作为批大小为 1 的延迟参考，并采用 PP2-TP8 作为低延迟服务配置。 高吞吐解码配置 图 6. 高吞吐解码：DP16-EP16 参考配置与 DP32-EP32 容量配置。 高吞吐解码同时扩展数据并行和专家并行。两种配置都使用 Attention-DP → MoE-EP 执行路径。DP16-EP16 是最小的部署单元；DP32-EP32 在相同拓扑内同时扩展 DP 和 EP。 扩展（Scale-out）优先考虑请求容量而非单 GPU 吞吐量。更大的 EP 组将专家权重分布到更多 GPU 上，释放 HBM 给 KV cache，从而容纳更多并发请求。与此同时，MoE 流量中留在节点内的比例变小，跨节点传输的比例变大，这可能会降低单 GPU 效率。在本文评估的配置中，我们以 DP16-EP16 作为最小部署单元和效率基准，以 DP32-EP32 来扩展请求容量。 3. 预填充（Prefill）：平衡计算与通信 预填充性能是一个系统性问题。专家负载不均衡、上下文并行通信以及生产环境的路由形态共同决定了 TTFT；仅仅优化单个内核是不够的。 3.1 为什么选择 MoE-TP 而非 MoE-EP 图 7. 用 MoE-TP 替代 MoE-EP。 流量更少也可能耗时更长。MoE-EP 只交换被路由的 token，但真实预填充流量表现出显著的专家倾斜。拥有热门专家的 rank 需要执行更多计算，成为掉队者（straggler）；所有其他 rank 在合并（combine）步骤都要等待最慢的路径。更低的通信量并不等于更低的 TTFT。 在最小化流量之前先平衡计算。对于本文评估的 H20 预填充工作负载，PP2 和 PP4 均使用 MoE-TP。全序列的 all-gather 和 reduce-scatter 会引入更多通信，但这些流量走的是高带宽 NVLink，成本稳定且可预测。所有 TP rank 对相同的被路由 token 执行张量并行计算，从而避免专家倾斜演变为 rank 级别的长尾问题。对于该工作负载，可预测的通信比不可预测的不均衡更划算。该实现可在 sglang#24947 中获取。 3.2 加速与融合预填充集合通信 图 8. 对称内存集合通信与预填充融合。 构建可复用的集合通信快速路径。MoE-TP 用可预测的集合通信流量取代了不可预测的专家负载不均衡，使通信效率成为下一个瓶颈。我们让对称内存在 TP 和 CP 之间可复用，使 AllReduce、AllGather 和 ReduceScatter 能够共享已注册缓冲区的快速路径，并适用相应的 Hopper 加速。上游配套工作涵盖内存池所有权、通信器注册、MoE-TP 集合通信缓冲区，以及 CP Attention 和 KV 缓存缓冲区路径。 然后缩短 Prefill 关键路径。仅靠更快的集合通信并不能消除通信与计算之间的边界。针对 32K 单块场景，我们构建了一条融合路径，将基于拷贝引擎驱动的 AllGather 与融合 FP8 量化和共享专家 GEMM 重叠执行，然后在第二个 Triton kernel 中合并 TopK 归约、共享专家加法和 ReduceScatter。这七个算子被重组为三个执行组，在匹配的 PP4 A/B 测试中，TTFT 降低了约 3.5%。 3.3 针对真实路由形态调优 Humming 图 9. 针对真实路由形态调优 Humming。 通用调优无法覆盖真正重要的形态。Prefill 路由将 token 不均匀地分布到 384 个专家上，因此有效的 M 维度聚集在一小组离散值上。W13 和 W2 也作用于不同的形态，因此单一的通用启发式策略无法同时优化两条路径。 基于生产路由进行调优。我们从真实路由直方图中提取高频形态，为 W13 和 W2 分别构建精确形态配置，并在 kernel、流水线阶段和匹配 A/B 层面进行验证。优化目标不是合成范围的 M，而是我们实际服务的路由分布。在 32K 的匹配 PP4 A/B 测试中，选定的 MoE kernel 延迟降低约 21%，转化为端到端 TTFT 降低 11.35%。 4. Decode：优化投机采样与 MoE 执行 在我们的实现中，解码优化是特定于配置文件的。PP2-TP8 需要跨推测流水线阶段进行协调，而 DP32-EP32 则专注于在高并发下优化精炼步骤和专家路由。Humming 融合与重叠优化了这些服务拓扑之下的共享 MoE 热路径。 4.1 低延迟 PP2-TP8：跨流水线阶段扩展 DSpark 图 10. 跨 PP2 阶段协调 DSpark。 流水线并行分割了推测循环。在 PP2-TP8 中，目标执行跨越两个流水线阶段，而 DSpark 草稿模型仅驻留在最后一个阶段。阶段 0 将目标隐藏状态发送到阶段 1，阶段 1 执行验证、接受 token，并为下一轮生成候选。 让两个阶段如同一个整体般推进。每一轮推测都跨越流水线边界。我们在一个统一的执行协议下协调两个阶段及所需的中间传输，防止阶段进入不同的轮次，同时避免冗余同步。PP 特定的 DSpark 集成正在被合入 sglang#32281。 4.2 高吞吐 DP32-EP32：消除高并发瓶颈 图 11. DP32-EP32 瓶颈消除。 本小节中匹配的 A/B 结果使用 DP32-EP32，在 4K 上下文下每个 DP rank 有 32 个并发请求。 为精炼步骤选择正确的执行形态。精炼步骤应用全词表投影来对 DSpark 的候选集重新评分。在高并发下，逐行的点积归约会为每个活动行反复读取词表权重，在每个解码步骤中造成持续的尾部延迟。我们将活动行合并为一次转置 GEMM，减少了冗余的内存流量并缩短了精炼路径。每 GPU 吞吐量提升了 22.8%。 根据实测路由放置专家。DSpark 流量也表现出显著的专家倾斜。我们从代表性请求中记录路由亲和性，并使用它来配置专家并行负载均衡（EPLB）和冗余专家，防止少量热门专家反复延长关键路径。每 GPU 吞吐量提升了 13.5%。 4.3 Humming 解码热路径：融合与重叠 图 12. Humming 解码热路径优化。 这些优化位于服务拓扑层之下，可被基于 Humming 的解码配置复用。下方匹配结果采用 DP32-EP32 配置，4K 上下文，每个 DP rank 并发 32 个请求。 移除额外的量化过程。我们将 SwiGLU 激活与量化融合，使融合后的内核直接生成 W2 所需的数据和缩放因子。这消除了对中间缓冲区的重复访问，并移除了独立的量化过程，使 W2 能够更早启动。在匹配的 DSpark A/B 测试中，单卡吞吐量提升了 44.0%。 将通信与 W2 重叠。我们将此前工作（sglang#9660）中的单批次重叠（SBO）机制适配为 Humming-Aware SBO。基于逐 tile 的信号，DeepEP 可以在某个 W2 输出 tile 完成时立即启动对应的 combine 发送，无需等待整个 GEMM 完成。在相同运行点下，此前的非投机匹配 A/B 测试中，SBO 相比 FP8 传输层级恢复了 4.12% 的吞吐量。 5. 评估：系统收益与配置权衡 5.1 预填充：累积收益与上下文长度权衡 图 13. 预填充吞吐量累积增益。 PP2 强化了短上下文配置。PP2 在全部九个输入长度上均有提升，几何平均吞吐量增益为 36.5%，峰值总输入吞吐量达 16,900 tokens/s。其更浅的流水线减少了短请求的填充与排空开销，使 PP2 能够以更少的资源维持更低的 TTFT。 PP4 将增益延续至长上下文。PP4 在同样的九个测试点上实现了 31.8% 的几何平均吞吐量增益。随着上下文长度增长，更深的流水线有足够的工作量来摊薄其固定成本：总输入吞吐量在 512K 时达到 25,860 tokens/s，在 1M 时仍保持 23,970 tokens/s。 图 14. PP2 与 PP4 之间的 TTFT 权衡。 上下文长度会改变 PP2/PP4 之间的权衡关系。相对于 PP4，PP2 在 4K 上下文下将 TTFT 降低了 16.7%，在 32K 下降低了 19.5%。在 8K、16K 和 64K 下，两种配置的差异保持在 2% 以内。从 128K 开始，PP4 建立起决定性优势，在 128K、256K、512K 和 1M 下，相对于 PP2 的 TTFT 分别降低了 26.2%、33.3%、42.1% 和 44.8%。因此，我们将路由边界视为一种基于实测上下文长度范围得出的运行策略，而非一个通用的交叉点。 附录 A.1–A.2 提供了完整的 TTFT 和总输入吞吐量结果。 5.2 低延迟解码：性能与容量权衡 图 15. 优化后 DSpark 的峰值 TPOT 提升。 优化后的 DSpark 重新设定了延迟基线。在图 15 所示的四种输入长度下，优化后的 DSpark 在批大小为 1 时将峰值 TPOT 降低了 74.8%–78.0%。在每对测量所共有的最大批大小下，降幅仍保持在 52.2%–60.0%。这一提升在 8K 到 1M 的范围内均能保持，而非仅限于短上下文或单请求执行场景。 图 16. 批大小为 1 时的解码吞吐量：H20-141GB 与 B300 参考对比。 实测服务性能远高于仅凭峰值算力比值所预期的水平。在图 16 所示的四种输入长度下，采用 PP2-TP8 配置的优化 DSpark 在批大小为 1 时达到 150–174 tokens/s。单节点 TP8 参考配置达到 183–271 tokens/s。就实际执行路径所使用的精度而言，B300 的峰值 Tensor Core 算力约为 H20-141GB 的 45.6 倍（B300 FP4 对比 H20 FP8），内存带宽为其 1.67 倍。然而，实测的最高生成速率分别为 B300 上的 383.7 tokens/s 和 H20-141GB 上的 271 tokens/s——比值为 1.42 倍。即便面对如此强大的硬件参考，针对工作负载的优化仍使 H20-141GB 参考配置在实测服务性能上大幅接近对手。 就我们的生产目标而言，容量更倾向于 PP2-TP8。单节点 TP8 速度更快，但在 1M 上下文下，其 KV-cache 容量仅够 batch size 为 1 时使用，无法容纳更大的 batch 或更多并发请求。通过将模型权重分布到两个流水线阶段，PP2-TP8 在 1M、512K 和 256K 上下文下分别支持 batch size 4、8 和 16。配合 Online C128，其全 token 容量可达 11.04M tokens/rank。对于与我们类似的上下文长度和并发目标，我们建议保留单节点 TP8 作为延迟基准，并使用 PP2-TP8 作为低延迟服务配置。附录 B 和附录 D.1 提供了完整的性能和容量数据。 5.3 高吞吐解码：前沿增益与配置权衡 图 17. 吞吐量–交互性帕累托前沿。 图 17 展示了吞吐量–交互性前沿如何随系统演进。横轴是交互性，单位为 tokens/s/user；纵轴是吞吐量，单位为 tokens/s/GPU。在这些 DP/EP 配置中，每个 DP rank 对应一个 GPU；交互性等于每 GPU 吞吐量除以每个 DP rank 的并发请求数。越靠近右上方的点，代表用户可见生成速度与 GPU 效率的组合越优。四条曲线代表系统的累积演进，而非第 4 节中任何单一优化的孤立收益。 MTP 指多 token 预测；(3, 1, 4) 配置使用三步投机采样、top-k 为 1、四个草稿 token。 系统优化推动了整个前沿的移动。在 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 只能处理一个请求；最终系统支持四个请求，并达到 177.48 tokens/s/GPU。扩展后的运行范围既来自更快的执行速度，也来自更大的容量。 图 18. 每 GPU 吞吐量：DP16-EP16 与 DP32-EP32 对比。 较小的部署单元可在选定的高并发运行点上保持效率。在我们此前基于 H20 服务 DeepSeek-V3/R1 的工作中，我们发现较小的 EP 部署单元可以在每个节点内保留更大比例的 MoE 流量。DeepSeek-V4-Pro 在图 18 绘制的运行点上表现出同样的优势：当每个 DP rank 的并发请求数为 16 和 32 时，DP16-EP16 的每 GPU 吞吐量比 DP32-EP32 高出约 3.6%–20%。完整扫描结果并非在每个并发级别上都呈单调变化，因此我们将 DP16-EP16 作为效率参考，而非 DP32-EP32 的通用替代方案。 图 19. 每个 DP rank 的长上下文请求容量。 容量改变了首选的高吞吐量配置。DP16-EP16 在每 GPU 上更高效，但 DP32-EP32 将专家权重分布到更多 rank 上，为 KV cache 释放了更多 HBM。在 256K、512K 和 1M 上下文长度下，每个 DP rank 的最大并发请求数分别从 8、4、2 增加到 16、8、4——一致地实现了 2 倍扩展。对于与我们类似的长上下文并发目标的部署，这种额外容量使 DP32-EP32 成为面向容量的高吞吐量配置，而 DP16-EP16 仍可作为效率参考。附录 C 和附录 D.1 提供了完整数据。 6. 结论 一个模型并不需要一种折中的配置。我们为 H20 上的 DeepSeek-V4-Pro 构建了面向场景的服务栈。Prefill 根据上下文长度在 PP2 和 PP4 之间切换。Decode 使用 PP2-TP8 实现低延迟，使用 DP32-EP32 实现高吞吐量。通过协同设计容量、部署拓扑和执行路径，H20 在计算资源有限且缺乏原生 FP4 Tensor Cores 的情况下，仍能支撑 1M token 上下文并满足多种服务 SLO。 可迁移的成果是一套以场景驱动的方法论。服务配置不应仅从硬件规格或孤立的基准测试中选取。我们建议从工作负载、SLO、上下文长度和并发度出发，然后通过性能剖析来识别瓶颈资源，并将其转化为具体的拓扑和执行路径决策。我们希望这套方法论能帮助 AI 基础设施团队在多样化的资源约束下——无论瓶颈是算力、内存容量、内存带宽还是互联——构建实用的前沿模型服务系统，并将这些经验分享给更广泛的开源生态。 致谢 我们感谢 SGLang 团队和社区在 SGLang 框架上的杰出工作。我们也感谢以下团队和合作者的支持与贡献： 蚂蚁集团 SCT 团队：徐永飞、张倩瑜、顾泽凯、黄志林、王法康、傅建豪、杜卓轩、詹霞、黄纯、刘琦、陈曦、毛宇涵、程培成、高翰林、姚静华 蚂蚁集团 Venus 团队：林金镇 SGLang 社区：张鹏 附录 A. 预填充结果 A.1 Humming PP2 预填充：基线 vs. 最终配置 输入长度基线 TTFT（毫秒）基线总输入吞吐量（tokens/秒）最终 TTFT（毫秒）最终总输入吞吐量（tokens/秒） 4K775.85,280573.37,140 8K1202.16,810907.69,030 16K2059.87,9501649.59,930 32K4137.57,9202470.313,260 64K6195.710,5804063.816,130 128K10744.412,2007975.916,430 256K20542.212,76015507.216,900 512K44544.611,77034982.614,990 1M100304.210,45079214.213,240 A.2 Humming PP4 预填充：基线 vs. 最终配置 输入长度基线 TTFT（毫秒）基线总输入吞吐量（tokens/秒）最终 TTFT（毫秒）最终总输入吞吐量（tokens/秒） 4K924.64,430687.95,950 8K1174.56,970890.39,200 16K2202.07,4401635.410,020 32K4185.67,8303068.410,680 64K5252.412,4803982.616,460 128K7793.416,8205882.522,280 256K13210.719,84010348.925,330 512K26350.119,90020273.125,860 1M55532.318,88043742.523,970 附录 B. 低延迟解码结果 B.1 不同输入长度和批处理大小下的峰值 TPOT B.1.1 无投机解码 PP2-TP8 输入长度 / 批处理大小（峰值 TPOT，毫秒）124816 8K26.3930.8631.3131.7931.74 32K25.7226.5827.8131.0637.97 64K25.7526.6228.1329.1938.75 128K25.9426.9428.3829.7538.51 256K26.0827.2128.8432.4338.83 512K26.2527.5129.1633.70- 1M26.4227.8129.52-- B.1.2 优化版 DSpark PP2-TP8 输入长度 / 批大小（峰值 TPOT，毫秒）12481632 4K5.916.767.9710.0014.5519.23 8K5.806.878.8510.4815.1819.60 32K6.147.048.3910.8314.8620.46 64K6.157.138.7310.3915.4921.65 128K6.777.028.9111.5916.1724.78 256K5.766.988.6111.9817.72- 512K6.357.959.8714.30-- 1M6.658.9212.43--- B.2 批大小为 1 时的输出吞吐量 输入长度无投机解码 PP2-TP8（tokens/s）优化版 DSpark PP2-TP8（tokens/s）单节点 TP8（tokens/s） 4K-169213 8K38172260 16K--244 32K39163269 64K39163246 128K39148267 256K38174271 512K38157254 1M38150183 B.3 基准测试设置 硬件：一个 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 \ --dataset-name random \ --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 解码批处理日志行；我们丢弃最高和最低 20% 的样本，对剩余部分取平均值。B300 的数据遵循所链接来源中报告的设置。 附录 C. 高吞吐量解码结果 C.1 DP32-EP32 搭配 FP8 + MTP（3, 1, 4） 输入长度 / 每个 DP 秩的并发请求数（tokens/s/GPU）12481632 4K30.4958.58102.89174.75253.15319.92 8K30.3458.29102.38174.67251.62318.32 16K29.7056.5599.47170.01242.22302.43 32K29.5856.3598.28164.26234.13- 64K29.0755.7396.43161.60-- 128K28.3954.0692.89153.55-- 256K28.3553.0290.89--- 512K27.5151.49---- 1M27.05----- C.2 DP32-EP32 搭配 FP8 + 优化版 MTP（3, 1, 4） 输入长度 / 每个 DP 秩的并发请求数（tokens/s/GPU）12481632 4K36.8469.86131.96232.94389.94514.77 8K32.5869.51131.53222.06348.80416.82 16K31.8967.44127.79216.14341.85395.99 32K31.4967.21124.49208.83337.97- 64K30.9566.47123.68205.44-- 128K30.2264.47119.14--- 256K30.1863.23---- 512K29.2861.40---- 1M28.79----- C.3 DP32-EP32 搭配 FP8 + DSpark 输入长度 / 每个 DP 秩的并发请求数（tokens/s/GPU）12481632 4K53.194.8181.2338.1495.8591.8 8K44.588.4170.1317.3495.5- 16K43.688.3165.3308.8455.5- 32K43.087.3161.0298.4-- 64K42.386.3158.0--- 128K41.383.8---- 256K41.2----- 512K40.0----- 1M39.3----- C.4 DP32-EP32 搭配 Humming MXFP4AFP8 + 在线 C128 + DSpark 输入长度 / 每个 DP 秩的并发请求数（tokens/s/GPU）12481632 4K75.32127.10235.85417.53564.08703.15 8K75.60128.29238.01417.34560.68709.64 16K74.00124.47231.25406.21539.72674.19 32K73.07122.27225.28392.47521.70601.67 64K71.81120.92221.05386.11516.54599.63 128K70.12117.29212.93366.88487.69- 256K70.03115.03208.35345.21457.62- 512K67.95111.71191.99302.80-- 1M66.82105.82177.48--- C.5 DP16-EP16 搭配 Humming MXFP4AFP8 + 在线 C128 + DSpark 输入长度 / 每个 DP 秩的并发请求数（tokens/s/GPU）12481632 4K76.80129.62236.83397.42584.37759.73 8K76.69130.55237.53398.60582.03762.09 16K76.16127.88233.10388.54571.22745.23 32K74.07124.77226.24378.79559.05722.51 64K74.57124.69223.84373.13541.46695.35 128K72.36120.34219.66365.13518.98- 256K71.38119.19211.64340.72-- 512K69.54115.14198.81--- 1M67.39106.50---- 附录 D. 容量结果 D.1 解码容量扩展 解码配置配置全 token 容量（tokens/秩）与上一阶段对比与 FP8 基线对比 DP32-EP32基线 FP8 + 离线 C1281,475,328-1.00× Humming MXFP4AFP8 + 离线 C1282,526,7201.71×1.71× Humming MXFP4AFP8 + 在线 C1285,731,3282.268×3.88× PP2-TP8基线 FP8 + 离线 C1281,089,024-1.00× Humming MXFP4AFP8 + 离线 C1284,869,8884.47×4.47× Humming MXFP4AFP8 + 在线 C12811,044,9062.268×10.14× D.2 Humming 精度验证 我们在 GSM8K1000 上评估了 DP16-EP16 Humming MXFP4AFP8 + 在线 C128 + DSpark 配置。该配置实现了 95.5% 的精确匹配准确率，有一个无效响应和零系统错误，通过了我们 95.0% 的验收阈值。 作为公开参考，上游 SGLang Humming 集成在 DeepSeek-V4-Flash 的 200 示例 GSM8K 评估中报告了以下结果： 后端GSM8K 准确率 Marlin MXFP4A1696.5%–97.0% FlashInfer MXFP496.5%–97.0% Humming MXFP4A1696.5%–97.5% Humming MXFP4AFP897.0% 在这项公开对比中，Humming MXFP4AFP8 没有出现明显的精度下降。由于它使用的是 DeepSeek-V4-Flash 而非 DeepSeek-V4-Pro，我们将其视为外部参考，而不是对我们服务配置的匹配精度损失测量。