突破 DeepSeek-V4-Pro 服务极限（28分钟阅读时间）

# 突破 DeepSeek-V4-Pro 服务极限 来源：https://www.lmsys.org/blog/2026-08-19-deepseek-v4-pro-engine-optimization-h20 ## 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/s**，而 B300 (https://www.lmsys.org/blog/2026-07-06-dspark-sglang/) 报告的速度为 **383.7 token/s**。尽管硬件差距显著，但针对特定工作负载的系统优化将观察到的解码性能差距缩小至 **1.42×**。详细的基准测试设置和基于日志的吞吐量提取方法见附录 B.3 (https://www.lmsys.org/blog/2026-08-19-deepseek-v4-pro-engine-optimization-h20#b3-benchmark-settings)。 **覆盖服务包络。**延迟结果仅代表系统的一个边缘。在更广泛的配置家族中，优化后的预填充每节点达到 **8.45k 输入 token/s**，并在 **43.7 秒**内处理 **100 万 token** 的提示。对于面向吞吐量的解码，DP16-EP16 效率参考配置每节点达到 **4.67k 输出 token/s**，对应的平均 TPOT 为 **27.4 ms**。这些结果有意来自不同的配置，每个配置都针对上下文长度、延迟、吞吐量和容量约束的不同组合进行了选择和优化。 **贡献在于方法论，而非单一基准。**特定场景的服务使每个工作负载能在可用硬件评估的配置中朝着更好的测量工作点前进。我们希望这里呈现的部署选择、优化方法和测量结果，能为在计算、内存、带宽或互连约束下服务前沿模型的团队提供实用参考。 ## 2. 从硬件约束到服务配置 ### 2.1 硬件约束与服务角色 H20-96GB、H20-141GB 和 B300 的硬件规格比较，涵盖 FP4 和 FP8 计算、HBM 容量、内存带宽、NVLink 和 RDMA *图 1. 硬件差距：H20 与 B300。* **Blackwell 提供原始性能；H20 提供可部署的规模。**B300 提供原生 FP4 Tensor Core、高得多的 FP8 吞吐量和显著更大的 HBM。H20 无法匹敌其计算能力，但它仍能大规模获得，并提供高内存带宽和 900 GB/s NVLink。本研究中的每个节点包含八个通过 NVLink 连接的 GPU。预填充不保留长期的每请求状态，因此其硬件选择主要受 TTFT、计算和通信效率支配。解码必须在生成期间保留每个活跃请求的 KV 缓存，使得 HBM 容量成为上下文长度和并发的直接限制。对于本研究的部署，这引导我们使用 H20-141GB 进行解码，使用 H20-96GB（其容量足以满足我们的预填充工作负载）进行预填充。 按服务角色分配的硬件：H20-96GB 服务于 TTFT 敏感、状态短暂的预填充，而 H20-141GB 服务于 KV 容量受限、状态持久的解码 *图 2. 按服务角色分配硬件。* ### 2.2 容量选择 服务容量最终来自共享的 HBM 预算：模型权重与每请求的 KV 状态竞争相同的内存。我们将 **full-token capacity** 定义为在分配模型权重和运行时缓冲区后，每个 rank 能容纳的全注意力 KV token 的最大数量。它是一个内存上限，而非对可接受批大小的直接保证。 #### 使用 Humming MXFP4AFP8 减小权重占用 **首先减小权重占用。**Humming MXFP4AFP8 (https://github.com/inclusionAI/humming) 使用 MXFP4 专家权重与在线 FP8 激活，以减少 H20 GPU（缺乏原生 FP4 Tensor Core）上的权重占用和内存流量。SGLang 集成可在 sglang#23754 (https://github.com/sgl-project/sglang/pull/23754) 中获得。我们将在专门的后续文章中介绍 Humming/SGLang 集成。模型级精度结果和公开参考测量见附录 D.2 (https://www.lmsys.org/blog/2026-08-19-deepseek-v4-pro-engine-optimization-h20#d2-humming-accuracy-validation)。 #### 使用 Online C128 扩展 KV 容量 **为 KV 缓存留出增长空间。**离线 C128 基线为每个压缩页面保留每索引状态。在线 C128 则维护紧凑的聚合状态，释放更多 HBM 给 KV 缓存池。它引入了额外的状态维护和投机验证工作，但我们在测试中未观察到 TPOT 退化。 #### 组合容量增益 两幅水平条形图面板展示了从基线 FP8 到 Humming MXFP4AFP8 再到 Online C128，DP32-EP32 和 PP2-TP8 的 full-token capacity 缩放情况 *图 3. 使用 Humming MXFP4AFP8 和 Online C128 的容量扩展。* **容量增益在权重和 KV 状态上复合。**通过减小权重占用，Humming MXFP4AFP8 将 full-token capacity 扩展到基线 FP8 + 离线 C128 配置的 **1.71×**（对于 DP32-EP32）和 **4.47×**（对于 PP2-TP8）。然后，在线 C128 减少了 C128 辅助状态的占用，在 Humming 基础上又提供了 **2.268×** 的增长。结合这两种技术，DP32-EP32 的容量提升至基线的 **3.88×**，PP2-TP8 提升至 **10.14×**。完整数据见附录 D.1。 ### 2.3 特定场景的服务配置 #### 预填充配置 两种独立的预填充部署策略：PP2 和 PP4 使用不同的层划分，而每个阶段遵循相同的 Attention-CP8 和 MoE-TP8 执行路径 *图 4. 预填充配置：相同执行路径，不同流水线深度。* **合适的流水线深度取决于有多少工作可流水线化。**PP2-CP8-TP8 和 PP4-CP8-TP8 共享相同的 `Attention-CP8 → MoE-TP8` 执行路径。在拓扑层面，它们的主要区别是流水线深度：PP2 将模型分布在两个阶段，而 PP4 使用四个。 **短上下文有利于较低的流水线开销；长上下文暴露出更多并行度。**短输入产生更少的块，导致更深的流水线填充不足，使得填充、排空和跨阶段传输成本更加突出。长上下文提供足够的块以保持四个阶段忙碌；由于每个阶段的层数更少，额外的节点转化为更多的预填充并行度。在我们的部署中，这些特性导致我们使用 **PP2-CP8-TP8 用于较短上下文**，**PP4-CP8-TP8 用于长上下文工作负载**。 #### 低延迟解码配置 单节点 TP8 是虚线参考，PP2-TP8 是我们部署中使用的双节点低延迟服务配置；两者都执行 Attention-TP8 和 MoE-TP8，每个后跟其自身的 AllReduce *图 5. 低延迟解码：TP8 参考与 PP2-TP8 服务配置。* **低延迟始于最短的执行路径。**单节点 TP8 和 PP2-TP8 共享相同的 `Attention-TP8 → MoE-TP8` 执行路径；区别在于模型是否跨节点划分。单节点 TP8 将所有层放在一个 H20-141GB 节点上，避免了跨阶段通信和同步。PP2-TP8 将模型划分为两个流水线阶段。 **最快的拓扑并不总是最容易服务的。**单节点 TP8 的执行路径更短，但模型权重和服务状态共享一个节点的 HBM，为 KV 缓存留下的空间有限。它无法同时支持长上下文和更大的批大小。PP2-TP8 支付额外的流水线开销，但将模型权重分布在两个节点上，释放更多 HBM 给 KV 状态。对于我们的延迟和容量目标，我们使用 **单节点 TP8 作为批大小为 1 的延迟参考**，**PP2-TP8 作为低延迟服务配置**。 #### 高吞吐量解码配置 高吞吐量解码将 DP 和 EP rank 从双节点 DP16-EP16 参考扩展到我们部署中使用的四节点 DP32-EP32 服务配置；每个节点参与所有层，而路由的专家保持跨 EP rank 分片 *图 6. 高吞吐量解码：DP16-EP16 参考与 DP32-EP32 容量配置。* **高吞吐量解码同时扩展数据和专家并行。**两个配置都使用 `Attention-DP → MoE-EP` 执行路径。DP16-EP16 是最小的部署单元；DP32-EP32 在同一拓扑内扩展了 DP 和 EP。 **扩展优先考虑请求容量而非每 GPU 吞吐量。**更大的 EP 组将专家权重分布在更多 GPU 上，释放 HBM 给 KV 缓存，从而允许更多并发请求。同时，更小比例的 MoE 流量留在每个节点内，而更大比例跨节点，这可能会降低每 GPU 效率。在评估的配置中，我们使用 DP16-EP16 作为最小部署单元和效率参考，DP32-EP32 用于扩展请求容量。 ## 3. 预填充：平衡计算与通信 **预填充性能是一个系统问题。**专家不平衡、上下文并行通信以及生产环境路由形状共同决定 TTFT；优化孤立的内核是不够的。 ### 3.1 为什么使用 MoE-TP 而非 MoE-EP 在预填充路径中用 MoE-TP 替换 MoE-EP *图 7. 用 MoE-TP 替换 MoE-EP。* **更少的流量仍可能耗时更长。**MoE-EP 只交换路由的 token，但实际预填充流量显示出显著的专家偏差。拥有热专家的 rank 执行更多计算并成为落后的者；所有其他 rank 在组合步骤等待最慢路径。更低的通信量并不意味着更低的 TTFT。 **在最小化流量之前平衡计算。**对于评估的 H20 预填充工作负载，PP2 和 PP4 都使用 MoE-TP。全序列 all-gather 和 reduce-scatter 引入更多通信，但流量保持在高带宽 NVLink 上，并且具有稳定、可预测的成本。所有 TP rank 对相同路由的 token 执行张量并行计算，防止专家偏差成为 rank 级别的长尾。对于此工作负载，**可预测的通信比不可预测的不平衡更廉价**。实现可在 sglang#24947 (https://github.com/sgl-project/sglang/pull/24947) 中获得。 ### 3.2 加速与融合预填充集合操作 对称内存集合操作为 TP 和 CP 提供可重用的基础，而融合的预填充内核则压缩了通信密集型关键路径 *图 8. 对称内存集合操作与预填充融合。* **构建可重用的集合操作快速路径。**MoE-TP 用可预测的集合操作流量取代了不可预测的专家不平衡，使通信效率成为下一个瓶颈。我们使对称内存在 TP 和 CP 之间可重用，允许 AllReduce、AllGather 和 ReduceScatter 共享注册缓冲区快速路径和适用的 Hopper 加速。相关的上游工作包括 memory-pool ownership (https://github.com/sgl-project/sglang/pull/21392)、communicator registration (https://github.com/sgl-project/sglang/pull/19329)、MoE-TP collective buffers (https://github.com/sgl-project/sglang/pull/29007) 以及 CP Attention (https://github.com/sgl-project/sglang/pull/17756) 和 KV-cache (https://github.com/sgl-project/sglang/pull/24040) 缓冲区路径。 **然后缩短预填充关键路径。**更快的集合操作本身并不能消除通信与计算之间的界限。对于 32K 单块情况，我们构建了一条融合路径，将复制引擎驱动的 AllGather 与融合的 FP8 量化和共享专家 GEMM 重叠，然后在第二个 Triton 内核中组合 TopK 归约、共享专家加法和 ReduceScatter。这将七个算子重组为三个执行组，在匹配的 PP4 A/B 测试中将 TTFT 降低了约 **3.5%**。 ### 3.3 针对真实路由形状调优 Humming Humming 预填充工作流：从路由捕获到 W13 和 W2 的单独调优，再到分阶段验证 *图 9. 针对真实路由形状调优 Humming。* **通用调优会遗漏重要的形状。**预填充路由将 token 不均匀地分配给 384 个专家，因此有效的 `M` 维度聚集在少量离散值中。W13 和 W2 也运行在不同的形状上，因此单一的通用启发式方法无法同时优化两个路径。 **从生产路由中调优。**我们从真实的路由直方图中提取高频形状，为 W13 和 W2 构建单独的精确形状配置，并在内核、流水线阶段和匹配的 A/B 测试级别进行验证。优化目标不是合成的 `M` 范围，而是**我们实际服务的路由分布**。在 32K 的匹配 PP4 A/B 测试中，选定的 MoE 内核延迟下降了约 **21%**，转化为 **11.35%** 的端到端 TTFT 降低。 ## 4. 解码：优化推测与 MoE 执行 **解码优化在我们的实现中是特定于配置的。**PP2-TP8 需要跨推测流水线阶段进行协调，而 DP32-EP32 则专注于优化细化步骤和高并发下的专家路由。Humming 融合与重叠改进了这些服务拓扑下的共享 MoE 热路径。 ### 4.1 低延迟 PP2-TP8：跨流水线阶段扩展 DSpark PP2-TP8 DSpark 跨两个流水线阶段协调执行，目标隐藏状态发送到阶段 1，接受的 token 和下一个候选在共享的阶段滴答协议下返回 *图 10. 跨 PP2 阶段协调 DSpark。* **流水线并行拆分了推测循环。**在 PP2-TP8 中，目标执行跨越两个流水线阶段，而 DSpark (https://github.com/sgl-project/sglang/pull/30261) 草稿模型仅位于最终阶段。阶段 0 将目标隐藏状态发送到阶段 1，阶段 1 执行验证、接受 token 并生成下一轮的候选。 **使两个阶段作为一个整体推进。**每一轮推测都跨越流水线边界。我们在一个执行协议下协调两个阶段和所需的中间传输，防止阶段进入不同轮次，同时避免冗余同步。特定于 PP 的 DSpark 集成正在上游提交至 sglang#32281 (https://github.com/sgl-project/sglang/pull/32281)。 ### 4.2 高吞吐量 DP32-EP32：消除高并发瓶颈 DP32-EP3