引言

在此前的工作中，我们使用 Wide-EP 在 H200 上实现了 2.2K tok/s/H200 的解码吞吐量。vLLM 团队随后继续围绕 NVIDIA GB200 平台推进性能优化。本文重点介绍使 vLLM 在 GB200 上实现 26.2K prefill TPGS（每 GPU 每秒 token 数）和 10.1K decode TPGS 的关键优化，测试工作负载为 2K 输入 token 和 2K 输出 token，目标模型为 DeepSeek R1/V3/V3.1 这一类 DeepSeek 风格的 MoE 模型。上述数据来自一种由 4 个 prefill 实例（每个实例 2 张 GB200）和 1 个 decode 实例（8 张 GB200）组成的部署，全部采用数据并行（DP）与专家并行（EP）的组合。

这些提升来自多项新优化的叠加：

新优化：

  • 低精度运算（NVFP4 GEMM、FP8 GEMM、NVFP4 MoE Dispatch）
  • 内核融合（RoPE+Quant+Q Write、RoPE+Quant、Concat K）
  • 通过权重卸载缩减 prefill 规模
  • 最小化分块开销

此前已经介绍过的特性：

  • 异步调度
  • Prefill/Decode 分离式推理

GB200 更强的计算能力，与这些针对性优化结合之后，使 vLLM 相比 H200 部署获得了显著的吞吐提升。

结果

下面的基准测试比较了 vLLM 在 GB200 与 H200 上运行 DeepSeek-V3/R1 工作负载时的性能，固定负载为 2K 输入 token 与 2K 输出 token。详细部署配置见下表。

部署配置 H200 GB200
Prefill 16 GPUs 8 GPUs（4 个实例 x 2 GPUs）
Decode 32 GPUs 8 GPUs（1 个实例 x 8 GPUs）

GB200 更高的显存带宽（8 TB/s 对 4.8 TB/s）、通过 FP4 带来的更高计算吞吐，以及 CPU 与 GPU 之间的 NVLink-C2C 互连，都共同贡献了这些提升。我们再通过下文详述的优化，进一步把这些硬件优势充分释放出来。

我们还在保持相同并行配置的前提下，针对一组标准工作负载，评估了 DeepSeek-V3/R1 在 GB200 上的解码吞吐量，同时调整 decode batch size，以尽可能吃满 GPU 显存。

复现全部基准测试结果的说明可以在这里找到。

关键优化

低精度运算

与 H200 相比，GB200 在 FP4 和 FP8 运算上的吞吐能力大幅提升。vLLM 通过多项精度优化来利用这些能力。

NVFP4 GEMM（MoE GEMM、O-proj）

DeepSeek-V3/R1 模型可以把 MoE 专家权重和输出投影层量化到 FP4 精度。vLLM 集成了 FlashInfer 的 TRTLLM-Gen GEMM 内核，这套内核专门针对 GB200 的 FP4 tensor core 做了优化。

FP4 checkpoint 格式会以打包后的 4-bit 表示存储权重，并为每个 group 保存缩放因子。运行时，TRTLLM-Gen 内核会在 tensor core 内部即时完成反量化，在尽量维持模型质量的同时，拿到接近原生 FP4 的吞吐表现。

关键实现细节包括：

  • FP4 权重配合 FP8 或 FP16 scale，以打包格式存储
  • FlashInfer TRTLLM-Gen 内核针对 GB200 tensor core 调度做了优化
  • 应用于 MoE 专家 GEMM 以及注意力输出投影（O-proj）

用于 MLA 的 FP8 GEMM

对于 DeepSeek 的多头潜在注意力（MLA），query 上投影，也就是从潜在空间映射回完整 query 维度的那一步，可以从 FP8 量化中显著受益。与 MoE 层不同，MoE 层里 FP4 往往能给出最好的吞吐/精度平衡；而注意力投影对量化更敏感，因此 FP8 更高的数值精度对保持注意力质量更有帮助。

vLLM 在这些投影上使用了优化的 FP8 GEMM 内核，在保持注意力质量的同时，相比 FP16 获得了可观的提速。

NVFP4 MoE Dispatch

除了专家 GEMM 本身，MoE dispatch，也就是把 token 路由到对应专家的操作，也可以从低精度中获益。vLLM 实现了 NVFP4 dispatch，会在 all-to-all 通信前先把 token 激活量化为 FP4。

这样一来，相比 FP16 dispatch，all-to-all 的通信量减少了 4 倍，显著降低了 EP 部署中的 GPU 间通信延迟。量化本身的额外开销会被通信节省所摊销，因此最终会带来净吞吐增益。

内核融合

vLLM 采用了多种内核融合策略，把原本分散的多个操作合并进单个 GPU 内核，从而减少显存带宽消耗和 kernel launch 开销。

RoPE + Quant + Q Write（Decode）

在 decode 过程中，query 投影通常需要依次完成：

  1. 应用 RoPE（旋转位置编码）
  2. 为后续 GEMM 做量化
  3. 写入 query buffer

vLLM 把这三步融合到一个内核中，省掉了两次中间显存往返。


Decode 路径中的 RoPE+Quant+Q Write 融合

RoPE + Quant（Prefill）

类似地，在 prefill 路径里，RoPE 应用与量化也被融合在一起。由于 prefill 会处理更大的 token batch，因此融合带来的显存带宽节省会更加显著。

Concat K 优化

在 MLA 的 key 投影部分，vLLM 使用了 FlashInfer 的 concat_mla_k 内核来实现优化版拼接操作。在 DeepSeek 的 MLA 架构里，key tensor 由两部分组成：一部分是非位置编码的 k_nope，按 head 独立；另一部分是旋转位置编码的 k_rope，由所有 head 共享。最终这两部分需要拼接成完整的 key tensor。

如果采用朴素实现，就需要复制 k_nope，同时把 k_rope 广播到全部 128 个 head 上，这会带来明显的显存带宽消耗。FlashInfer 的 concat_mla_k 内核做了多项优化：

  • 基于 warp 的处理：每个 warp 处理一个 (token, head_chunk) 对，一次处理 16 个 head
  • 向量化内存访问：对 nope 数据使用 8 字节向量加载，对 rope 数据使用 4 字节加载，以最大化内存吞吐
  • 带 L2 预取的软件流水线：处理当前行时提前预取下一行，隐藏内存延迟
  • rope 值的寄存器复用：由于 rope 在全部 head 之间共享，因此只需加载一次到寄存器，再写入 chunk 内全部 16 个 head，避免冗余内存读取

缩减 Prefill 规模

为什么缩减规模是合理的

在面向吞吐量的推理服务里，讨论 GPU 数量时，我们通常会通过横向扩展来容纳模型，或者通过切分专家和上下文来扩大 batch size。然而，对于已经是计算受限的 prefill 工作负载来说，减少 GPU 数量反而可能通过降低通信开销来提升整体吞吐。

我们的微基准测试表明，当 batch size 从 16K token 增长到 64K token 时，MLA 后端的吞吐开始趋于平台期。超过 64K token 之后，MoE 吞吐继续提升的收益也很有限。这意味着，只要使用适合 2 GPU 服务配置的 batch size，就已经可以把计算利用率吃满。


MLA 与 MoE 吞吐在约 64K batch size 开始趋于平稳

当 GPU 数量从 4 减少到 2 时，EP 通信里对应的 NCCL collectives，也就是 all_gather 与 reduce_scatter，会减半，从而显著降低通信开销。


降低 EP 度数可将通信开销减半

权重卸载 v2

为了在保持性能的同时降低 GPU 显存占用，vLLM 实现了带异步预取的权重卸载 v2。这一 v2 方案借鉴了 SGLang prefill 中的卸载方法，并进一步适配，使其能够在 vLLM 中兼容 torch.compile 与 CUDA graph。

在 vLLM 权重卸载 v1 中，被卸载的权重会保留在 CPU 上，并通过统一虚拟寻址（UVA）访问，这会带来较慢的 PCIe 传输延迟。它原本是为 GPU 资源有限时“勉强跑起来模型”而设计的最后手段。

而权重卸载 v2 则采取了不同策略：它会显式地提前把权重复制，也就是 onload，到 GPU 上。关键创新在于，下一层的权重会通过独立 CUDA stream 做异步 onload。只要 carefully overlap 好权重 onload 与内核执行，onload 的延迟就可以被完全隐藏。

用户通过按组选择的方式来配置卸载：

  • group_size：每 N 层划成一个组
  • num_in_group：每组中卸载多少层，通常是每组最后 N 层
  • prefetch_step：提前预取多少层

在 DeepSeek-R1 的 prefill 服务中，我们对每两个 MoE GEMM 权重卸载一个，在保持完整吞吐的同时获得了可观的显存节省。


权重 onload 与层执行重叠的 trace

GB200 上 CPU 与 GPU 之间的 NVLink-C2C 连接，使权重卸载 v2 特别有效，因为相比基于 PCIe 的系统，加载延迟被大幅压低。

最小化分块开销

MoE 模型中的大批量处理通常需要分块，才能放进 GPU 显存。但块太小会因为重复的 kernel launch 和同步而带来额外开销，形成 GPU bubbles。vLLM 提供了多种块大小配置选项，以便在显存约束内尽可能逼近最大吞吐。

MoE DP Chunk

当使用数据并行与专家并行（DP+EP）时，token 会从每个 DP rank 按协同块进行 dispatch。VLLM_ENABLE_MOE_DP_CHUNK 开关默认开启，用于启用这种分块行为。

较大的 chunk size 可以把 dispatch / combine 的开销摊薄到更多 token 上，从而减少 GPU bubbles。块大小由 VLLM_MOE_DP_CHUNK_SIZE 控制，默认是 256 token。提高这个值通常可以通过减少同步频率来提升吞吐。

对于 GB200，我们在 prefill 阶段关闭 MoE DP chunking（VLLM_ENABLE_MOE_DP_CHUNK=0），并在 decode 阶段把 VLLM_MOE_DP_CHUNK_SIZE 设置为与 batch size 匹配。

MoE Activation Chunk

对大型 prefill batch，vLLM 会对激活张量分块，让每次只处理部分 token 经过 MoE 层。VLLM_ENABLE_FUSED_MOE_ACTIVATION_CHUNKING 开关默认开启，用于控制这一行为。

更大的 chunk size 可以降低 launch 开销，同时提供足够的工作量去吃满 GPU 计算，从而提升吞吐。块大小由 VLLM_FUSED_MOE_CHUNK_SIZE 控制，默认是 16K token。最优设置通常是在可用显存范围内尽量把块做大。

在 GB200 上，由于显存更大，可以直接容纳完整 batch 而无需分块，因此我们关闭了 activation chunking（VLLM_ENABLE_FUSED_MOE_ACTIVATION_CHUNKING=0），以最大化吞吐。

Output Processing Chunk

在 V1 引擎的异步服务路径里，输出处理，包括 logit 计算、采样和响应生成，也会以分块方式执行。VLLM_V1_OUTPUT_PROC_CHUNK_SIZE 控制每次迭代处理多少输出，默认值为 128。

更大的 chunk size 可以通过减少每块开销来提升整体吞吐。但对于流式负载而言，块太大可能会增加消息间延迟抖动。对于面向吞吐优化的 GB200 decode，我们将该值设为 2048。

后续工作

vLLM 团队正在围绕 GB200 部署推进以下工作：

  1. 改进负载均衡并继续扩大 EP 规模：扩展专家负载均衡机制，使其能够处理更高的 EP 度数和更动态的工作负载，并改进重平衡算法
  2. 优化 MoE dispatch 延迟：通过内核优化与通信调度，进一步降低 all-to-all dispatch 的延迟
  3. 通过计算-通信重叠隐藏通信延迟：在通信受限场景中使用更激进的 overlap 策略，以实现更高 GPU 利用率
  4. 在 GB300 上扩展 WideEP 与大规模推理：利用 GB300 更强的 HBM 与计算能力，在更小的主机占用下实现更高 TPGS

最新路线图请参考 roadmap.vllm.ai。

总结

  • vLLM 针对 DeepSeek 风格 MoE 模型，实现了 26.2K prefill TPGS 和 10.1K decode TPGS，相比 H200 提升 3 到 5 倍
  • 低精度运算（NVFP4 GEMM、FP8 GEMM、NVFP4 dispatch）充分利用了 GB200 更强的 tensor core 能力
  • 内核融合减少了显存带宽压力和 kernel launch 开销
  • 通过权重卸载 v2 缩减 prefill 规模，在保持计算饱和的同时降低了 EP 通信开销
  • 通过环境变量可控的分块优化，进一步压低了大批量处理下的额外开销

团队

  • Meta：Ming Yang、Xiaozhu Meng、Pengchao Wang、Lucia (Lu) Fang、Bangsheng Tang、Yan Cui、Hongyi Jia、Jinghui Zhang、Zebing Lin、Jason Park、Yejin Lee、Jaewon Lee、Bradley Davis、Jingyi Yang、Adi Gangidi、Ayush Goel、Charlotte (Ye) Qi、Stephen Chen、Raj Ganapathy、Akshay Hegde、Lu Fang
  • NVIDIA：Duncan Moss、Cyrus Chang、Andrew Briand、Siyuan Fu、Hanjie Qiu、Jason Li、Pavani Majety、Xin Li、Chirayu Garg、Abhinav Singh、Minseok Lee

参考链接