在 Blackwell 上托管 Qwen

我们在 NVIDIA GB200 NVL72 机架上运行 Qwen3 235B,在保持模型准确性的同时降低推理成本。

作者Perplexity Research

NVIDIA GB200 NVL72 机架配备了通过 72 路 NVLink 互连的 NVIDIA Blackwell GPU,非常适合部署混合专家(MoE)模型。在本篇博客中,我们介绍了用于处理部分 Perplexity 流量的经过训练的 Qwen3 235B 模型的推理设置。我们展示了如何改造内部推理引擎,以利用 NVIDIA Blackwell GPU 的高级张量核心和高速互连技术。借助此硬件,我们能够在不牺牲基础模型准确性的前提下,以更低的成本处理更多流量。

在 GB200 NVL72 上进行部署

GB200 NVL72 机架由 18 个节点组成,每个节点配备 2 个基于 ARM 的 NVIDIA Grace CPU 和 4 个基于 Blackwell 的 GPU,每块 GPU 配备 180GB HBM。72 个 GPU 通过 NVLink 和 18 个 NVLink Switch ASIC 互连,在任意两个对等节点之间提供 1800 GB/s 的带宽,并共享足够的内存来承载万亿参数模型。此外,ConnectX-7 InfiniBand 适配器可在机架内各节点之间以及相邻机架之间额外提供 400 Gb/s 的带宽。

为了处理流量,我们选择训练并服务 Qwen 模型。在本篇博客中,我们重点介绍 Qwen3 235B,但所讨论的许多服务技术和性能特征与我们正在迁移至的较新的 Qwen3.5 397B 和 122B 模型相似。在并行化方面,线性注意力与完全自注意力相似,且现有的 MoE 层实现可以轻松调整以适应新的门控项。为了在保持一致解码率的同时最大化吞吐量,我们选择了将预填充与解码解耦,并针对这两种节点采用了不同的并行策略。预填充器到解码器的通信通过 InfiniBand 处理,而 NVLink 带宽则保留用于预填充器和解码器内部的通信。本博客中探讨的 Blackwell 设备在进行矩阵乘法和设备间通信时的性能特征,决定了所使用的分片策略。与 NVIDIA Hopper GPU 相比,由于流式多处理器数量增加、内存带宽提升以及点对点延迟降低,我们看到了逐内核的改进。

在 prefill 和 decode 之间解耦,prefillers 和 decoders 之间采用 InfiniBand,每个部署内部采用 NVLink。

我们的 TransferEngine 实现了预填充的解耦,并处理了预填充器和解码器之间任意且可能不匹配的分片。KV 缓存以 HND 顺序布局在内存中,头位于前导维度,标记保持连续,从而允许预填充器上的分片 KV 缓存能够在传输到解码器节点的过程中被进一步拆分或连接。

预填充器

预填充器节点接收请求的输入标记,填充 KV 缓存并将它们传输到解码器以继续文本生成。由于序列中的数千个标记是同时处理的,因此预填充过程计算密集。

因此,我们发现张量并行部署是合适的,模型在单个 GB200 节点内的 4 个 GPU 上进行分片,并且投影和专家进行了分片(TP=4,EP=4)。由于注意力机制和 MLP 均受计算限制,两者均受益于并行化,将专家和注意力头分布在不同的等级上。进一步的并行化产生的边际收益会递减,因为在每个等级上托管较少数量的专家(16 个对比 32 个)所带来的吞吐量提升,无法抵消 8 路 all-reduce 的额外成本,以及跨两个节点拆分主机端代码(需要通过以太网进行通信)带来的开销。

Qwen3 235B 只有 4 个键值头,如果使用 8 个设备,则需要将 k 和 v 投影在成对的等级上复制。我们本可以考虑更激进的分片以减少在每个等级上存储权重所需的内存量,从而为 KV 缓存中的更多标记释放空间。然而,我们发现更广泛的部署并不划算。

假设输入长度约为 6000 个标记,128 个专家中的每一个都有大约 6000 * 8 / 128 = 375 个标记被路由至该专家,确保了 MoE GEMM 的密集问题。由于这已经使设备的计算吞吐量饱和,因此预填充不需要数据并行。

尽管注意力成本呈二次方增加,但预填充器仍能提供一致的吞吐量,从而可以粗略估算节点在一秒钟内可以处理的输入标记数量。依靠跟踪请求输入标记总数的指标,可以扩展预填充器节点的数量,以确保整体预填充吞吐量得到相应的调整。为了避免排队,预填充器副本的数量与接收到的输入标记总数相匹配。

解码器

解码器节点从预填充器接收 KV 缓存并逐个生成标记。解码通常受内存限制:当输入标记很少时,矩阵乘法完全受限于将权重从 HBM 加载到 Tensor Core 的成本。除了采用不同的分片策略外,还必须调整多个内核以更好地并行化计算和内存访问。

与预填充不同,分片注意力不再有益:跨多个设备拆分注意力头意味着在单个设备内并行化的机会更少。因此,仅使用了数据并行和专家并行:专家跨多个设备分片,但每个设备管理自己的 KV 缓存和请求。如果没有张量并行,设备上的每个标记 KV 缓存大小会更大。然而,通过在单个节点上定位较少的专家,可以释放内存空间。与我们在 8-GPU 节点的单个 NVLink 域内限制张量并行的 Hopper 不同,在 Blackwell 上,我们发现使用多达 16 个设备跨域内的多个节点进行扩展是有益的。

为了最大化吞吐量,解码器会并发处理更多的请求。即使额外的请求在 MoE 层和其他投影中产生的开销极小,它们确实不成比例地增加了注意力成本。为了保持合理的最低解码速度,会对解码器节点的数量进行缩放,以保持每个解码器的批处理大小低于特定阈值。

与之前的 Hopper 部署类似,我们使用内部训练的 MTP 层的推测性解码来提高解码率。幸运的是,底层硬件和编程框架足够相似,可以在两种架构之间完全共享实现。

节点内和节点间通信

GB200 NVL72 与之前 Hopper 节点的主要区别在于巨大的 NVLink 域,它实现了超越先前 8 个设备限制的点对点通信。即使 Blackwell 设备已部署在 8-GPU 节点中,与较慢的 InfiniBand 网络相比,跨 NVLink 在多个节点上进行扩展也具有很高的价值。

在预填充器节点上,我们依赖于注意力层内的 all-reduce 通信以及与 all-reduce 非常相似的专家并行归约。在 4 个 GPU 上,我们同时利用 NVLink 和 NVIDIA SHARP(可扩展分层聚合和归约协议):除了点对点带宽外,我们还利用 NVLink Switch 中的归约操作来进一步降低延迟并实现快速广播。在解码器节点上,使用了通过 NVLink 的定制 all-to-all 分发和合并实现。内核是使用 CuTeDSL 和 cuMem 映射或多播映射在内部实现的。

All-Reduce

预填充器在注意力层的输出投影中执行 all-reduce 操作,汇总跨参与等级分片的头的贡献。只有当 all-reduce 开销的成本被较小矩阵乘法问题的延迟降低所抵消时,张量并行才是有效的。此假设通常适用于预填充。

在数据中心级的 NVIDIA HGX H200 和 GB200 NVL72 系统上,GPU 通常通过 NVLink Switch 连接。除了路由之外,交换机还可以通过 SHARP 对连接的设备执行归约操作。在创建内存映射并使用 CUDA API 将其注册到多播组后,内核可以使用 multicast.ld_reduce 和 multicast.st 通过交换机聚合和广播值。为了建立可以融合到其他内核中的基础和可重用组件,我们在内部维护了一个使用这些原语的 CuTeDSL all-reduce 内核。

在一个拥有 N 个 GPU 归约 B 字节的系统中,简单的实现会让一个对等点从所有其他对等点加载值,总共产生 N * (N - 1) * B 字节的读取流量。更高效的实现会将要归约的数据拆分到各对等点之间,每个对等点归约输入的一部分,然后将其广播给其余对等点。这导致每个对等点读取并广播给其余对等点 (N - 1) * (B / N) 字节,总共进行 (N - 1) * B * 2 次读写,从而减少了交换机上的流量。

带有 GPU 侧累加和交换机辅助归约的 NVSwitch 全归约流量。

利用 SHARP,归约和广播可以更高效地执行:无需将 (N - 1) * (B / N) 字节读入设备进行本地累加,只需从交换机移动 B / N 字节,因为它使用来自对等点的数据自行执行归约。对于广播,也有类似的改进,因为 GPU 和交换机之间通过 NVLink 通道的事务数量大大减少。没有 SHARP 时,累加设备将通过 NVLink 与交换机执行 (N - 1) * (B / N) 次事务,交换机从对等点读取相同量的数据,总共 2 * (N - 1) * (B / N) 次事务。利用 SHARP,GPU 和交换机之间执行 B / N 次事务,与对等点之间进一步执行 (N - 1) * (B / N) 次事务,总共 B 次事务。

由于其简单性,SHARP 是一个很有价值的工具,因为它为算法提供了直接的硬件实现。尽管传输量在理论上减少了 N / (2 * (N - 1)) 的分数(在 4 个对等点时计算为 33%),但在实践中,我们观察到 H200 和 GB200 NVL72 系统上的预填充和解码延迟均有 10% 的改善。

在 H200 和 GB200 上,TP=4 且 16K tokens 时的 NVLink 和 NVLS 调度延迟。

MoE 分发 - 合并

对于 MoE 模型,分发和合并内核会移动并分组标记,以处理对等点之间后续的 MoE GEMM 问题,并在合并后执行加权累加。我们通过将现有的分发和合并内核移植到 CuTeDSL,调整块分配并积极地在预填充和解码之间进行专业化,使它们适应了 Blackwell。

专家并行

专家并行(EP)内核用于预填充器中。由于其输入在所有等级上被复制,分发内核只需要简单地选择路由到当前等级专家的标记。它聚合路由信息并将标记准备到用作 MoE GEMM 输入的缓冲区中。合并内核首先在路由到当前等级专家的标记的贡献之间执行本地累加,然后跨所有等级执行 all-reduce。

对于解码,整个内核融合为一个。预填充内核被拆分为多个内核,因为路由和 all-reduce 比本地合并步骤需要更少的块。通过 CuTeDSL,我们可以构建一个通用的库,用于 SHARP 和 NVLink all-reduce 以及点对点同步,并将其组合到 all-reduce 和专家并行内核中。

在不同 expert-parallel 配置下,H200 和 GB200 上的专家并行 prefill 调度和合并延迟。

在性能方面,我们观察到由于改进的传输速度、更高的内存带宽和更好的计算吞吐量,Blackwell 明显快于 Hopper。跨 GB200s 上的 8 个设备和多个节点进行分片(EP=8)时,内核变得更快,因为本地累加在每个设备上运行的标记要少得多,并且借助 SHARP,跨更多等级进行归约的成本扩展得更好。然而,在实践中,我们将并行性限制为 4 个设备,因为这些加速并不普遍适用于所有内核。

数据并行和专家并行

数据并行和专家并行(DP-EP)内核用于数据并行解码器。它将来自所有等级的不同标记广播给专家,将结果传输到源等级并进行累加。由于它实现了一个稀疏的 all-to-all 问题,它完全依赖于 NVLink。

在 Hopper 上,此内核仅限于单个节点 NVLink 域内的 8 个设备。然而,在 GB200 系统上,我们可以将其扩展到整个机架。大部分代码都被重用。唯一的区别是使用 fabric 句柄通过 IMEX 交换对等点信息以进行初始设置。

在 data-parallel 和 expert-parallel 配置下,GB200 的调度和合并延迟。

由于解码期间产生的传输规模很小,它们远未达到 NVLink 带宽的饱和,而是受到延迟限制。延迟在几十微秒数量级,并且随着对等点数量的增加保持相对稳定,使我们能够将部署扩展到更多的设备,而不会产生重大的额外延迟。

MoE GEMM

MoE 模型受益于专家并行,因为所有标记与所有专家相乘的成本可以轻松地跨多个设备并行化。在预填充器上进行张量并行时,在密集问题上收益非常直接,因为每个等级现在必须执行的计算更少。在解码情况下,数据并行在专家并行之上提供了额外的好处,因为更多的并行请求将更多的标记路由到每个专家,从而使问题密度更高。

在我们的实现中,目前依赖于 CUTLASS CUDA/C++ 内核进行矩阵乘法。我们针对具有各种量化方案和并行级别的稀疏解码输入对它们进行了基准测试,以决定解码器的最佳分片策略。在下面的基准测试中,所有专家均由单个标记激活。

H200 和 GB200 上,不同 expert-parallel 配置和量化方案下的分组 MoE GEMM 延迟。

我们发现,随着 CUTLASS 将 128 个专家扩展到超过 16 个等级,边际收益递减,因为乘以 2 个专家的成本并不比乘以 4 个专家低多少。即使在次优的块缩放策略下,Blackwell 较 Hopper 也有明显的改进。由于 EP=8 和 EP=16 分发/合并之间的延迟增加约 5 us,而 GEMM 成本降低了超过 10 us,因此在 GB200 系统上,跨 16 个等级分片解码器是合理的,这一点也得到了端到端基准测试的证实。

量化

Blackwell 为新的 8 位和 4 位量化方案引入了硬件支持。与依赖于每张量或每块缩放因子的 Hopper 不同,Blackwell 需要微缩放(microscaling)来实现最佳的预填充和解码吞吐量。虽然 DeepSeek 或 Kimi 等模型所使用的块缩放方案可用,但微缩放更为高效。

我们使用 MXFP8 量化方案部署了 Qwen3 235B,在对模型进行微调后静态转换了权重。精度影响与使用随机量化的块缩放影响相似,但性能提升巨大,如 MoE GEMM 微基准测试所示。我们还考虑了 MXFP4 和 NVFP4 量化方案,尽管在没有量化感知训练的情况下精度影响对于从 Hopper 到 Blackwell 的初始过渡来说太大了。我们计划在未来的工作中更深入地探索这些格式。

端到端性能

我们对 Blackwell Qwen3 235B 部署的解码器进行了基准测试,并将其与之前的 Hopper 部署进行了比较。在此设置中,我们考虑了两种部署中的块缩放,以便专注于并行化的影响。两种架构都分开了 TP=4 预填充器,以便隔离解码性能。下图说明了假设我们 MTP 层提供的实际草稿接受率下的解码吞吐量。

在假设 draft acceptance length 为 0.8 的情况下,H200 和 GB200 expert-parallel 配置下的 Qwen3 235B FP8 解码速度和每 GPU 吞吐量。

在 Hopper 上,跨超过 8 个 GPU 进行部署分片是不可行的,因为通过 InfiniBand(特别是在 EFA 适配器上)的延迟要慢得多。然而,在 Blackwell 上,由于更大的 NVLink 域,我们实现了显著更高的吞吐量。

我们通过概括现有的 Hopper 内核并提升基于 NVLink 内核的性能,实现了初步的 Blackwell 实现。我们将通过改进量化并微调管线中其他内核的解码性能和预填充吞吐量,进一步降低服务 Qwen 的成本。

参考资料

Transfer Engine 博客文章

CuTeDSL 博客文章

Prefill-Disagg 博客文章

推测性解码博客文章

CUTLASS

NVLink

引用

BibTeX
@online{perplexity2026HostingQwenOnBlackwell,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Bex Brooker and Erin McKnight},
  title = {{Hosting Qwen on Blackwell}},
  date = {2026-05-12},
  url = {https://www.perplexity.ai/hub/blog/hosting-qwen-on-blackwell}
}