Driving vLLM WideEP and Large-Scale Serving Toward Maturity on Blackwell (Part I)

发表时间: 2026-02 · Blog post by Meta and NVIDIA Team (blog.vllm.ai)

原文: https://blog.vllm.ai/blog/2026-02-03-dsr1-gb200-part1

作者/机构：Meta and NVIDIA Team

速读

一句话结论
本文针对 DeepSeek-V3/R1 这类混合专家模型，通过在 NVIDIA GB200 硬件上结合低精度计算、算子融合与异步权重卸载技术，在 vLLM 框架中实现了 26.2K 的 Prefill TPGS 和 10.1K 的 Decode TPGS，吞吐量相比 H200 提升了 3 到 5 倍。

要解决什么问题
在大规模部署 DeepSeek 风格的混合专家模型（MoE）和多头潜在注意力（MLA）架构时，原有的推理系统在显存带宽、通信开销和计算调度上存在严重卡点。首先，MoE 架构在专家并行（EP）模式下，分发 token 到不同专家时需要进行全局的 All-to-All 通信，在 FP16 精度下庞大的激活值传输量会导致严重的跨 GPU 通信延迟。其次，在 Prefill（预填充）阶段，传统的横向扩展（增加 GPU 数量）策略存在反作用：当批处理大小达到 64K tokens 时，计算单元的吞吐量已经饱和，此时继续增加 GPU 数量不仅无法提升算力利用率，反而会成倍增加 NCCL 集合通信（如 all_gather 和 reduce_scatter）的开销，导致整体吞吐量下降。此外，MLA 架构中的键值拼接操作以及常规的旋转位置编码（RoPE）、量化和显存写入等步骤，如果采用独立的算子执行，会产生大量冗余的显存读写往返，极大地消耗显存带宽。最后，在处理大批量数据时，为了适配显存上限而引入的分块（Chunking）机制会频繁触发内核启动和同步，从而产生大量 GPU 空闲气泡，拉低整体执行效率。

怎么做的
核心思路是充分压榨 GB200 的底层硬件特性（如 FP4 张量核心和 NVLink-C2C 互联），通过极致的降精度、算子融合以及反直觉的“缩减规模”策略来绕开带宽与通信瓶颈。关键设计由四个部件构成。第一是混合低精度计算与分发。对于 MoE 专家权重和注意力输出投影，采用 NVFP4 格式，将权重以打包的 4-bit 形式存储并附带 FP8 或 FP16 的缩放因子，在张量核心内实时反量化；对于精度敏感的 MLA 查询上投影，则保留 FP8 精度。更关键的是实现了 NVFP4 MoE 分发，在 All-to-All 通信前将 token 激活值量化为 FP4，这使得通信数据量 $V_{FP4} = \frac{1}{4} V_{FP16}$，用极小的量化开销换取了 4 倍的通信延迟缩减。第二是激进的算子融合。在 Decode 阶段，将 RoPE 计算、量化和查询缓冲区写入合并为一个内核，消除了两次中间显存往返；针对 MLA 的键张量拼接，引入了 FlashInfer 的优化内核，利用线程束每次处理 16 个注意力头，通过 8 字节和 4 字节的向量化内存访问分别加载非位置向量和位置向量，并利用寄存器复用共享的 RoPE 值，避免重复加载。第三是基于异步权重卸载的 Prefill 降维。既然 64K tokens 已让计算饱和，系统反其道而行之，将 Prefill 实例的 GPU 数量从 4 张减半到 2 张以砍掉一半的 EP 通信开销。为了在减少 GPU 的同时装下模型，设计了第二代权重卸载机制，利用独立的 CUDA 流异步将下一层的权重从 CPU 预取到 GPU，其核心不变量为 $T_{compute\_layer\_i} \ge T_{onload\_layer\_i+1}$，通过完美掩盖传输延迟，实现了对 MoE GEMM 权重“每两层卸载一层”的策略。第四是消除分块开销。得益于 GB200 更大的显存，系统直接禁用了 Prefill 阶段的 MoE 数据并行分块和激活值分块，让大批次数据直通计算单元，从而彻底消除了内核频繁启动带来的同步气泡。

效果如何
实验基于 DeepSeek-V3/R1 模型，在固定 2K 输入 tokens 和 2K 输出 tokens 的负载下进行。硬件平台对比了 H200 集群与 GB200 集群。对比基线为 vLLM 在 H200 上的大规模部署方案，该基线代表了上一代硬件结合常规宽专家并行（Wide-EP）的优化路线。在 Prefill 阶段，H200 使用 16 张 GPU，而 GB200 仅使用 8 张 GPU（划分为 4 个实例，每个实例 2 张），GB200 实现了 26.2K 的 TPGS（每 GPU 秒处理 token 数），大幅超越基线；在 Decode 阶段，H200 使用 32 张 GPU，GB200 使用 8 张 GPU（单实例 8 张），GB200 实现了 10.1K 的 TPGS。整体吞吐量相比 H200 基线提升了 3 到 5 倍。作者也坦诚了该方案当前面临的局限与代价：对于流式输出任务，为了追求极致吞吐而设置的超大输出处理分块（如设置为 2048）可能会导致消息间的延迟方差增大；此外，当前系统在应对更大规模的专家并行度和更动态的负载时，负载均衡机制仍显不足，且 All-to-All 分发延迟和通信计算重叠策略仍有进一步优化的空间，这些都被列入了未来的改进计划中。

一、 主要贡献

本文致力于在NVIDIA的GB200平台上对vLLM进行大规模服务和性能优化，这是基于团队此前在H200平台上实现宽专家并行（Wide-EP）达到2.2k tok/s吞吐量工作的进一步延伸【1，vLLM Large Scale Serving: DeepSeek @ 2.2k tok/s/H200 with Wide-EP + 2025 + https://blog.vllm.ai/2025/12/17/large-scale-serving.html】 。

本研究的核心目标是针对DeepSeek风格的混合专家（MoE）模型（包括DeepSeek R1/V3/V3.1），在GB200硬件架构上实现极致的推理吞吐量。通过一系列针对性的创新优化，vLLM在2K输入token和2K输出token的固定工作负载下，成功在GB200上实现了26.2K的预填充TPGS（每GPU秒处理的Token数，Tokens Per GPU Second）以及10.1K的解码TPGS。

这些显著的性能提升得益于以下核心创新点与现有特性的结合：

  1. 引入低精度计算操作：全面利用GB200的张量核心（Tensor Core）能力，实现了NVFP4 GEMM、FP8 GEMM以及NVFP4 MoE分发（Dispatch）机制。
  2. 深度的内核融合（Kernel Fusion）：将多个独立操作合并，包括RoPE+量化+Q写入（解码阶段）、RoPE+量化（预填充阶段）以及针对MLA的Concat K优化。
  3. 预填充规模缩减（Scaling Down Prefill）：通过引入第二代权重卸载（Weight Offloading v2）技术，在保持计算饱和度的同时减少GPU通信开销。
  4. 最小化分块开销（Chunking Overheads）：针对大规模批处理，精细化配置MoE数据并行分块、MoE激活分块以及输出处理分块。
  5. 结合现有高级特性：继续利用异步调度（Async scheduling）和预填充/解码分离服务（Disaggregated serving）架构。

上述数据是在一个包含4个预填充实例（每个实例2张GB200）和1个解码实例（8张GB200）的部署架构下测得的，所有实例均采用了数据并行（DP）与专家并行（EP）的组合策略。

二、 方法细节

低精度计算操作（Lower-Precision Operations）
相较于H200，GB200为FP4和FP8操作引入了显著更高的吞吐量【3，NVIDIA GB200 NVL72 Architecture + https://www.nvidia.com/en-us/data-center/gb200-nvl72/】。vLLM通过多种精度优化策略充分利用了这些硬件能力 。

NVFP4 GEMM应用于MoE与O-proj
对于DeepSeek-V3/R1模型，其MoE专家权重和输出投影层（Output Projection）可以被量化为FP4精度。vLLM在这一环节集成了FlashInfer【2，FlashInfer: Kernel Library for LLM Serving + https://github.com/flashinfer-ai/flashinfer】 的TRTLLM-Gen GEMM内核，这些内核是专门为GB200的FP4张量核心优化的。在具体实现细节上，FP4的检查点（Checkpoint）格式将权重存储为一种打包的4位表示形式，并附带每组（per-group）的缩放因子（采用FP8或FP16格式存储）。在运行时阶段，TRTLLM-Gen内核会在张量核心内部进行即时的（on-the-fly）反量化操作。这种设计使得系统能够在保持模型生成质量的同时，实现接近原生FP4的极高吞吐量。

MLA的FP8 GEMM优化
在DeepSeek的多头潜在注意力（Multi-head Latent Attention, MLA）架构中，查询的上投影（Query up-projection，即从潜在空间映射到完整的查询维度）从FP8量化中获得了显著收益。由于注意力投影层对量化误差比MoE层更为敏感，FP8的较高精度能够提供最佳的吞吐量与准确率平衡。vLLM针对这些投影操作使用了高度优化的FP8 GEMM内核，在保持注意力机制质量的前提下，实现了相较于FP16的巨大加速。

NVFP4 MoE分发（Dispatch）
除了专家层的GEMM计算本身，负责将Token路由到指定专家的MoE分发操作同样可以从低精度计算中获益。vLLM实现了NVFP4分发机制，在执行All-to-All通信之前，将Token的激活值（Activations）量化为FP4格式。这一操作使得All-to-All的通信数据量相比FP16分发大幅减少了4倍，从而极大地降低了专家并行（EP）部署中GPU之间的通信延迟。尽管量化过程本身会带来一定的计算开销，但这些开销被通信时间的大幅节省所抵消，最终带来了净吞吐量的显著提升。

内核融合技术（Kernel Fusion）
系统采用了多种内核融合策略，通过将多个独立的操作合并到单个GPU内核中，有效降低了显存带宽的消耗以及内核启动（Kernel launch）的开销。

解码阶段的RoPE+Quant+Q Write融合
在解码（Decode）阶段，查询投影（Query projection）原本需要经历三个连续步骤：首先应用旋转位置编码（RoPE）；其次为后续的GEMM操作进行量化；最后将结果写入查询缓冲区（Query buffer）。vLLM将这三个操作完美融合为一个单一的内核。这种融合设计彻底消除了两次中间显存读写的往返开销，极大地提升了执行效率。
解码阶段的RoPE+Quant+Q Write融合

预填充阶段的RoPE+Quant融合
与解码阶段类似，在预填充（Prefill）阶段，RoPE的应用与量化操作也被融合在一起。由于预填充路径需要处理规模更大的Token批次，这种融合所带来的显存带宽节省效果变得尤为显著和关键。

Concat K优化
针对MLA的键投影（Key projections），vLLM利用FlashInfer的concat_mla_k内核实现了一种优化的拼接操作。在DeepSeek的MLA架构中，键张量（Key tensor）由两部分组成：非位置嵌入部分（$k_{nope}$，每个注意力头独立）和旋转位置嵌入部分（$k_{rope}$，所有注意力头共享）。这两部分必须被拼接以形成完整的键张量。如果采用朴素的实现方法，需要复制$k_{nope}$并将$k_{rope}$广播到所有128个头，这将导致极其严重的显存带宽浪费。FlashInfer的concat_mla_k内核实施了以下四项关键优化：

  • 基于Warp的处理机制：每个Warp负责处理一个（Token, head_chunk）对，一次性并行处理16个注意力头。
  • 向量化显存访问：对于$k_{nope}$数据使用8字节的向量加载指令，对于$k_{rope}$数据使用4字节的加载指令，从而最大化显存吞吐量。
  • 带有L2预取的软件流水线：在处理当前数据行的同时，提前预取下一行的数据，有效隐藏了显存访问延迟。
  • $k_{rope}$值的寄存器复用：由于$k_{rope}$在所有头之间是共享的，内核将其一次性加载到寄存器中，随后直接写入该分块中的所有16个头，彻底避免了多余的显存加载操作。

缩减预填充规模（Scaling Down Prefill）
缩减规模的合理性分析
在面向吞吐量的推理服务中，通常会增加GPU数量以容纳更大的模型，或者通过分片显存（用于专家或上下文）来提升批处理大小。然而，对于本身已经是计算密集型（Compute-bounded）的预填充工作负载而言，减少GPU数量反而可以通过降低通信开销来提升吞吐量。团队的微基准测试表明，当批处理大小从16K增加到64K Tokens时，MLA后端的吞吐量性能开始趋于平缓；而当批处理大小超过64K Tokens后，MoE吞吐量的增长也变得微乎其微。这意味着系统完全可以在一个仅需2张GPU的部署配置下，通过合适的批处理大小达到计算利用率的饱和状态。
MLA和MoE吞吐量在约64K批处理大小处达到平缓
MLA和MoE吞吐量在约64K批处理大小处达到平缓
通过将GPU数量从4张减少到2张，系统将专家并行（EP）通信所需的NCCL集合通信操作（all_gather和reduce_scatter）直接减半，从而极其显著地降低了通信开销。
降低EP程度可使通信开销减半
降低EP程度可使通信开销减半

权重卸载v2（Weight Offloading v2）
为了在保持极致性能的同时降低GPU显存占用，vLLM实现并引入了带有异步预取功能的权重卸载v2机制。该机制的灵感来源于SGLang预填充的卸载方案，并经过专门适配，以兼容vLLM内部的torch.compile和CUDA图（CUDA graph）。在vLLM早期的权重卸载v1中，被卸载的权重保留在CPU内存中，通过统一虚拟寻址（UVA）进行访问，这会引入极其缓慢的PCIe传输延迟，因此v1仅作为GPU资源受限时的最后退路。
权重卸载v2则采取了截然不同的策略：它会提前将权重显式地复制（Onload）到GPU显存中。其核心创新点在于，利用一个独立的CUDA流（CUDA stream）异步地加载下一层的权重。通过精心设计权重加载与内核执行的时间重叠，系统能够完全隐藏加载延迟。用户可以通过基于组的选择策略来配置卸载行为：

  • group_size：将每N层分为一组。
  • num_in_group：在每个组中卸载指定数量的层（即每组的最后N层）。
  • prefetch_step：提前预取的层数。
    在DeepSeek-R1的预填充服务中，系统每隔一个MoE GEMM权重就卸载一个，在保持全额计算吞吐量的同时实现了显著的显存节省。此外，GB200的CPU与GPU之间配备了NVLink-C2C互连技术，这使得权重卸载v2的效果尤为出色，因为其加载延迟相比传统的基于PCIe的系统被降到了最低。
    显示权重加载与层执行重叠的追踪图

最小化分块开销（Minimize Chunking Overheads）
在MoE模型中处理大规模批次时，必须进行分块（Chunking）以适应GPU显存的硬性限制。然而，过小的分块会导致频繁的内核启动和同步开销，从而产生GPU气泡（GPU bubbles）。vLLM提供了一系列分块大小配置选项，以在显存限制内最大化吞吐量。

MoE DP分块（MoE DP Chunk）
当结合使用数据并行与专家并行（DP+EP）时，系统会协调各个DP Rank，将Token分块进行分发。该行为由VLLM_ENABLE_MOE_DP_CHUNK环境变量控制（默认开启）。较大的分块大小能够将分发与合并的开销分摊到更多的Token上，从而减少GPU气泡。分块大小的具体数值由VLLM_MOE_DP_CHUNK_SIZE控制（默认值为256个Token）。增加此值可通过降低同步频率来提升吞吐量。在GB200平台上，团队在预填充阶段禁用了MoE DP分块（设置VLLM_ENABLE_MOE_DP_CHUNK=0），而在解码阶段，则将VLLM_MOE_DP_CHUNK_SIZE设置为与批处理大小相匹配的值。

MoE激活分块（MoE Activation Chunk）
对于超大的预填充批次，vLLM会对激活张量进行分块，使得Token的子集依次通过MoE层。此行为由VLLM_ENABLE_FUSED_MOE_ACTIVATION_CHUNKING环境变量控制（默认开启）。较大的分块可以减少内核启动开销，并提供充足的工作量以完全打满GPU计算单元。分块大小由VLLM_FUSED_MOE_CHUNK_SIZE控制（默认值为16K个Token）。最佳设置应在可用显存允许的范围内尽可能最大化该值。在GB200平台上，由于其庞大的显存容量足以容纳完整的批次而无需分块，团队直接禁用了激活分块（设置VLLM_ENABLE_FUSED_MOE_ACTIVATION_CHUNKING=0）以获取极致吞吐量。

输出处理分块（Output Processing Chunk）
在V1引擎的异步服务路径中，输出处理环节（包括Logit计算、采样、响应生成）同样被分块执行。VLLM_V1_OUTPUT_PROC_CHUNK_SIZE控制每次迭代处理的输出数量（默认值为128）。较大的分块大小通过降低每个分块的固定开销来提升整体吞吐量。然而，对于流式（Streaming）工作负载，过大的分块可能会增加消息间延迟的波动方差。为了在GB200上实现吞吐量最优的解码性能，团队将该分块大小激进地调整为2048。

三、 实验环境与实验结果

实验环境配置

  • 测试负载：固定为2K输入Tokens和2K输出Tokens，测试模型为DeepSeek-V3/R1。

  • 硬件平台对比配置：

    • H200集群：预填充节点使用16张GPU；解码节点使用32张GPU。
    • GB200集群：预填充节点使用8张GPU（划分为4个实例，每个实例2张GPU）；解码节点使用8张GPU（划分为1个实例，共8张GPU）。

  • 硬件核心优势：GB200提供了高达8 TB/s的显存带宽（而H200为4.8 TB/s），通过FP4提供了更高的计算吞吐量，并且配备了CPU与GPU之间的NVLink-C2C高速互连总线。

实验结果与分析
在上述配置下，vLLM在GB200上实现了26.2K预填充TPGS和10.1K解码TPGS的绝对性能。相较于H200部署方案，GB200在资源更少的情况下实现了3到5倍的整体性能提升。

此外，团队还在GB200上针对DeepSeek-V3/R1进行了一系列标准工作负载下的解码吞吐量基准测试。在保持相同并行设置的前提下，通过改变解码批处理大小以完全打满GPU显存，验证了系统在不同负载压力下的扩展能力与极值吞吐表现。

四、 结论与未来工作展望

结论总结
本文展示了vLLM在NVIDIA GB200架构上的深度优化成果。通过充分利用GB200增强的张量核心能力（NVFP4 GEMM、FP8 GEMM、NVFP4分发），结合精细的内核融合技术（有效缓解显存带宽压力及内核启动开销），以及创新的预填充规模缩减架构（通过权重卸载v2在保持计算饱和的同时降低EP通信开销），系统在DeepSeek风格的MoE模型上实现了26.2K的预填充TPGS和10.1K的解码TPGS，代表了相较于H200平台3-5倍的跨代际性能飞跃。同时，通过环境变量控制的细粒度分块优化，彻底最小化了大规模批处理的系统开销。

未来工作（Future Work）
vLLM团队正在积极推进以下针对GB200部署的后续改进方案：

  1. 优化负载均衡并扩展EP规模：扩展专家负载均衡机制以应对更大的专家并行（EP）度以及更动态的工作负载，并引入改进的重平衡算法。
  2. 优化MoE分发延迟：通过更底层的内核优化和通信调度策略，进一步降低All-to-All分发操作的绝对延迟。
  3. 通过计算-通信重叠隐藏通信延迟：在受限于通信带宽的场景中，采用更激进的重叠执行策略以实现更高的GPU利用率。
  4. 在GB300上扩展WideEP与大规模服务：计划利用下一代GB300更卓越的HBM和计算能力，进一步深化WideEP和大规模服务工作，旨在以更小的主机资源占用实现更高的TPGS指标。

五、 参考文献汇总

本文在方法与背景描述中引用的核心文献及项目如下：

  • 【1】vLLM Large Scale Serving: DeepSeek @ 2.2k tok/s/H200 with Wide-EP (2025). URL: https://blog.vllm.ai/2025/12/17/large-scale-serving.html

    • 引用位置：主要贡献章节。
    • 描述内容：本文工作是建立在该团队此前在H200平台上利用Wide-EP实现大规模服务基础之上的延续。

  • 【2】FlashInfer: Kernel Library for LLM Serving. URL: https://github.com/flashinfer-ai/flashinfer

    • 引用位置：方法细节（NVFP4 GEMM应用于MoE与O-proj / Concat K优化）。
    • 描述内容：vLLM集成了该库提供的TRTLLM-Gen GEMM内核用于FP4计算，并使用了其提供的concat_mla_k内核来实现高效的键张量拼接优化。

  • 【3】NVIDIA GB200 NVL72 Architecture. URL: https://www.nvidia.com/en-us/data-center/gb200-nvl72/

    • 引用位置：方法细节（低精度计算操作）。
    • 描述内容：支撑本文所有优化的底层硬件架构基础，提供了显著高于前代架构的FP4/FP8吞吐量及NVLink-C2C互连能力。