Grace Blackwell NVL72 需要机架感知调度，同等机架规模下可用 GPU 增加 27%

并非所有高速互连都生而平等，选错可能会代价高昂：同一个分布式训练作业若使用 InfiniBand 而非 NVLink 运行，可能使性能下降 43%。

过去，NVLink 的通信范围仅限于单个节点内部，这意味着多节点 AI 工作负载只能通过 InfiniBand 或其云端对应方案（AWS 上的 EFA、GCP 上的 GPUDirect-TCPX）进行通信。NVIDIA 的 NVL72 系统通过统一的 NVLink 网络将机架中的全部 72 块 GPU 互联，消除了这一限制，因此不同节点上的 GPU 可以以高一个数量级的带宽交换数据。

然而，充分发挥 NVL72 系统的优势在很大程度上取决于工作负载放置：跨机架分布的多节点作业仍会受到 InfiniBand 瓶颈限制。随着硬件故障导致节点离线，以及作业在不同时刻完成、将可用容量分散到各机架，保持机架局部性变得更加困难。

本文介绍大规模训练和推理中的通信瓶颈、NVL72 机架级网络、针对 GPU 故障韧性的切片规模设定，以及 SkyPilot Platform 如何通过拓扑感知放置、硬件故障后的原地恢复以及共享集群的自动碎片整理，让多节点作业保持机架局部性。

前沿训练作业会跨数千块 GPU 运行。要实现这一点，需要回答两个问题：

如何在多块 GPU 之间对模型进行分片，以确保它确实能够运行？
在给定计算预算的情况下，最多可以运行多少份分片后的模型，以最大化训练吞吐量？

第一个问题通常通过组合以下几种方式解决：

张量并行（TP）：将一层的权重矩阵拆分到多块 GPU 上
专家并行（EP）：将混合专家（MoE）层中的各专家放置在不同 GPU 上
流水线并行（PP）：按层将模型拆分到多块 GPU 上

第二个问题的答案决定数据并行度（DP）：即并行训练的分片模型副本数量，每个副本对应训练数据的一个不同切片。

在这些并行策略中，张量并行的 all-reduce 和专家并行的 all-to-all 通信模式位于训练关键路径上，因此将它们保持在 NVLink 上最为重要（§9.1.2）。

张量并行

张量并行将每一层内部的权重矩阵拆分到多块 GPU 上，因此每块 GPU 只存储并计算每一层的一部分。

Transformer 层由两个块组成：自注意力块和多层感知机（MLP）块。每个块的核心都是连续两次矩阵乘法（GEMM）。Megatron-LM（§3）表明，如果按列切分一个块的第一次 GEMM、按行切分第二次 GEMM，那么 GPU 每个块只需在第二次 GEMM 之后通过 all-reduce 同步一次，而不必在每次 GEMM 后都同步。

Animated diagram: tensor parallelism splits A column-wise and B row-wise across two GPUs, and one all-reduce sums the partial z results — **图 1.** 两块 GPU 上的张量并行。A 按列切分，因此每块 GPU 无需通信即可计算自己的 y 切片。B 按行切分以与之匹配，因此每块 GPU 生成部分 z 结果，再通过一次 all-reduce 对部分结果求和。

即使有了这一优化，张量并行在前向传播期间仍需要每个 Transformer 层执行两次 all-reduce。这些 all-reduce 步骤位于训练的关键路径上，因为它们无法与计算完全重叠。因此，张量并行通常保持在 NVLink 上：Hugging Face 测得，从 NVLink 迁移到 InfiniBand 后，训练吞吐量下降了 43%。

专家并行

在混合专家（MoE）层中，MLP 块被许多更小的 MLP（称为专家）和一个路由器所替代；路由器会将每个 token 发送到少数几个专家。专家并行通过切分 MoE 层，将这些彼此独立的小型专家放在不同 GPU 上。

在专家并行下，每个 MoE 层在前向传播期间需要两个 all-to-all 通信步骤，即分发和合并。路由器为每个 token 选择前 k 个专家，并将 token 发送至显存中拥有这些专家的 GPU。随后，每块 GPU 通过一次分组矩阵乘法，对收到的 token 计算本地专家。最后，专家输出被发送回每个 token 最初所在的 GPU 并进行合并。

Expert parallelism diagram: an all-to-all dispatches tokens to experts on different GPUs, and a second all-to-all combines the results — **图 2。** 专家并行将专家分布到多块 GPU 上。all-to-all 通信将 token 分发至为其分配的专家，并合并结果。（来源：NVIDIA，图 4。）

随着模型增加更多 MoE 层，并将每个 token 路由到更多专家，all-to-all 流量不断增长，带来通信瓶颈。

使用 64 路专家并行训练 MoE 模型时，每个 MoE 层的专家会分布到 64 块 GPU 上。在标准的 8-GPU 服务器上，这会使 all-to-all 流量不再经过高带宽 NVLink，而改由带宽窄得多的 InfiniBand 互连传输，未经优化的通信最多可占用60% 的训练时间（§1.2）。在 NVL72 系统上，全部 64 块 GPU 都位于单一 NVLink 域内，从而有效消除通信瓶颈（§9.2.2）。

上述并行技术并非训练所独有。除了让推理引擎能够运行大到单块 GPU 无法容纳的模型之外，模型并行还可以提高吞吐量。将模型权重拆分到更多 GPU 上，可以为 KV 缓存腾出内存，因此引擎能够处理更多并发请求或支持更大的上下文窗口。在某些情况下，释放出的内存增长速度快于 GPU 数量：在一次vLLM 基准测试中，将模型按张量并行拆分到两块 GPU 上，使 KV 缓存块数量增至 13.9 倍，并使吞吐量达到 3.9 倍。

Animated diagram: Llama-3.1-70B weights fill most of one H100, and sharding them across two H100s frees memory for 13.9x more KV cache blocks — **图 3。** Llama-3.1-70B 在一块与两块 H100 上的 GPU 内存构成。（数据：vLLM。）

专家并行遵循相同的逻辑。在专家并行度较低时，每块 GPU 承载许多专家，为 KV 缓存留下的空间更少。WideEP 指跨越多个节点的专家并行配置，可显著减少每块 GPU 上的专家数量。其权衡之处在于网络流量：每次 all-to-all 现在都会跨越更多 GPU。在标准 8-GPU 服务器上，专家并行组最多可跨越八块 GPU，之后就必须通过 InfiniBand 通信，而此时每 GPU 带宽会下降 18 倍。NVL72 通过使用 NVLink 将机架中的全部 72 块 GPU 保留在机架内，消除了这一限制。在以交互速度为 DeepSeek-R1 提供服务时，采用 32 路专家并行的 GB200 NVL72 相比 8-GPU B200 服务器可实现每块 GPU 的吞吐量最高提升 4.4 倍，而后者的专家并行度上限为 8 路。

NVL72 将 NVLink 从单个节点扩展到整个机架，因此整个机架就像一个拥有共享内存的巨型加速器。

The NVLink hierarchy in an NVL72 rack: the NVLink domain, NVLink partitions, and IMEX domains — **图 4。** NVL72 机架内的 NVLink 层级结构。（来源：NVIDIA，图 1。）

NVL72 机架中的每块 GPU 都有 18 个 NVLink 端口，每个端口提供 100 GB/s 的双向带宽，总计每块 GPU 可达到1.8 TB/s。给定 GPU 上的每个 NVLink 端口都映射到为机架 fabric 背板提供支撑的 18 块 NVSwitch 芯片之一。由于每块 NVSwitch 芯片可接收 72 条 NVLink 链路，每块 GPU 各提供一条，因此机架内部的聚合带宽为 130 TB/s。

NVL72 topology: every GPU connects one NVLink port to each of the rack's 18 NVSwitch chips — **图 5。** 每块 GPU 分别将一个 NVLink 端口连接到机架中的 18 块 NVSwitch 芯片。（来源：NADDOD。）

这种网络拓扑确保 fabric 完全无阻塞，这意味着机架中的任意 GPU 都能以统一的延迟将数据传输到任意其他 GPU，非常适合大规模分布式 AI 工作负载。

An NVL72 rack next to its non-blocking NVSwitch fabric, which connects every GPU in the rack — **图 6。** NVSwitch fabric 完全无阻塞。机架中的任意 GPU 都能以相同的延迟和全带宽与任意其他 GPU 通信。（来源：NVIDIA，图 1）

使用 NVL72 系统时，人们很容易将整个 18 节点机架分配给工作负载，以最大化集群利用率。实际上，团队通过在每个机架中留出两个备用节点，反而能从集群中获得更多可用容量。

GPU 并不可靠。在其吉瓦级超级集群上，Meta 在投入大量工程精力提升可靠性后，测得每个 4-GPU 节点的中断平均间隔时间（MTBI）约为 490 天。NVL72 集群以 72-GPU 机架作为计算的原子单位，与构成该机架的 4-GPU 节点相比，故障波及范围扩大了 18 倍。该机架的 MTBI 计算公式如下：

根据上述公式，机架大约每 490 / 18 ≈ 27 天就会发生一次中断。如果将整个 18 节点机架分配给作业，那么每次此类中断都会使整个机架在故障节点修复前无法被调度。在一个 128 机架的集群中，这意味着大约每 5 小时就会有一个机架无法用于整机架作业。

每个机架预留两个节点作为备用会改变这一情况。当某个节点发生故障时，同一机架中的备用节点会替代它，因此单个节点故障不再会导致整个机架停摆。代价是在系统一切正常时，每个机架都有两个节点处于闲置状态。

为了量化这一权衡，NVIDIA 建模分析了不同切片大小如何影响 128 机架（2,304 节点）集群的可用容量，以及不可用节点比例增长时的变化。

Chart of usable capacity of a 128-rack cluster versus node unavailability for 8, 9, 16 and 18-node slices — **图 7。** 节点不可用率上升时，不同切片大小下 128 机架集群的可用容量。每个切片必须容纳于单个机架内。（改编自 NVIDIA，图 6。）

在 SkyPilot，我们管理着客户数万块 GPU；在生产环境的 NVL72 集群上，我们测得节点不可用率约为 2%。在这一比例下，NVIDIA 的模型显示，16 节点切片比 18 节点切片提供 27% 更多的可用容量（2,037 个节点 vs. 1,602 个节点）。即使两个 9 节点切片恰好填满一个机架，16 节点切片的可用容量也高出 9 节点切片 4%：使用 9 节点切片时，每次故障都会损失半个机架；而使用 16 节点切片时，机架中的前两次故障都会被完全吸收。与 8 节点切片相比，16 节点切片让每个作业在每个 NVLink 域中获得两倍数量的 GPU，同时在节点不可用率超过约 3.3% 之前，损失的可用容量不到 1%。

十六节点对于分布式 AI 工作负载来说也是一个自然的规模：64 块 GPU 是 2 的幂，这与并行组通常的规模确定方式相匹配。

到目前为止，我们已经讨论了为何通信量最大的并行技术应运行在 NVLink 上、NVL72 如何将 NVLink 从单个节点扩展到整个机架，以及为什么每个机架配备两个备用节点的 16 节点切片能从生产集群中获得最多的可用容量。SkyPilot 将这一理念付诸实践：每个切片都放置在单个机架内，在原地恢复硬件故障，并在作业不断启动和结束的过程中保持整个机架空闲。

调度器需要了解硬件

选择合适的切片大小只是第一步。研究人员如何确保多节点训练运行中的每个切片都实际落在单个机架内？

朴素的调度器会将多节点作业拆分到不同机架中，迫使工作节点通过 InfiniBand（每个方向 400 Gb/s）而不是 NVLink（双向 1.8 TB/s）进行通信：

Animated diagram: a naive scheduler places hero-run on free nodes in two racks, so its traffic crosses InfiniBand — **图 8。** 朴素放置策略将多节点作业拆分到不同机架。

SkyPilot 的 Topology-Aware Scheduler（TAS）确保工作节点位于同一机架：

Animated diagram: SkyPilot's Topology-Aware Scheduler places all of hero-run's nodes on a single rack — **图 9。** SkyPilot 的 Topology-Aware Scheduler 将该作业的工作节点保持在单个机架内。

对于多机架工作负载，TAS 会将作业拆分为 16 节点（可配置）切片，并将每个切片分别放置在各自配备两个备用节点的机架上。随后，当 SkyPilot 的 GPU Manager 检测到 GPU 故障时，SkyPilot Frontier Trainer 可以在其余节点继续无中断运行的同时，将故障节点热替换为预留健康节点之一。如果同一机架中没有剩余备用节点，Frontier Trainer 会将故障机架上的切片重新调度到健康机架：

Animated diagram: hero-run runs as two 16-node slices with two spare nodes per rack; failed nodes are swapped for spares, then the slice moves to an idle rack — **图 10。** 基于切片的调度会在每个机架中保留两个健康的备用节点。当 GPU Manager 检测到故障节点时，Frontier Trainer 会用同一机架中的备用节点替换故障节点。

为了量化基于切片的调度所产生的影响，NVIDIA 的 GR00T 团队在横跨 128 个节点的 512 块 GB300 GPU 上，对 GR00T N1.7（一种面向人形机器人的多模态基础模型）进行预训练期间，比较了两种不同调度策略的效果。第一次运行使用朴素调度器，将节点分布在数量任意的多个机架中。第二次运行采用类似图 10 的机架感知、基于切片的策略，恰好分布在 8 个机架上。采用机架感知放置后，吞吐量提高了 14.4%，每次迭代时间从 1.59 s 缩短至 1.39 s。

在包含 10,000 块 GPU 的集群上，同样的加速效果每个训练小时可节省约 $16.7K。这意味着每个训练日可节省约 $400K，仅需作出更好的调度决策。

碎片化阻碍机架级作业

到目前为止，我们单独探讨了拓扑感知调度的运作方式。在实际应用中，大型集群通常是共享的：预训练运行、RL rollout 和批量推理等异构工作负载都会争用相同的资源。TAS 会在调度时将工作负载按装箱方式分配到同一机架内，但作业完成时间不同，导致空闲节点分散在各机架中。这就是碎片化：集群拥有足够的空闲 GPU 来运行机架级作业，但由于这些 GPU 分散在不同机架中，因此无法调度该作业。

Animated diagram: free nodes are split across two racks, so the 16-node hero-run waits in the queue — **图 11。**作业完成时间各不相同，导致空闲节点分散在各个机架中。当有 16 个节点空闲，但分散在两个机架之间时，这个 16 节点的大型运行任务无法被放置，只能等待。

SkyPilot 的自动碎片整理（Auto Defrag）正是为解决这一问题而构建的。当作业受到拓扑限制而非容量不足阻塞时，Auto Defrag 会找出干扰最小的一组工作负载，将其抢占以腾出整个机架。这些工作负载会被重新调度到其他机架，从而让受阻作业得以调度。

Animated diagram: Auto Defrag moves sft-d to rack-a, freeing rack-b for the 16-node hero-run — **图 12。** Auto Defrag 抢占 sft-d 并将其重新调度到 rack-a，在那里从检查点恢复运行。这腾出了 rack-b，因此 hero-run 可以作为单个 16 节点切片进行调度。

Auto Defrag 只会抢占能够安全重启的工作负载，例如可从检查点恢复的托管作业。除非管理员明确选择将其纳入处理范围，否则交互式开发环境会保持不受影响。

大规模 AI 工作负载默认采用分布式方式运行，其中最耗网络的通信模式位于关键路径上。诸如 NVL72 这样的机架级系统旨在通过硬件解决这一瓶颈，但仅有硬件并不能保证提速。这些系统需要具备机架感知的放置能力、针对硬件故障的韧性，以及随着作业进出而进行的动态再平衡。SkyPilot Platform 专为弥补这一差距而打造：拓扑感知调度让多节点作业保持在 NVLink 上，当 GPU Manager 检测到硬件故障时，Frontier Trainer 会换入一个健康的备用设备，而自动碎片整理则确保共享机架可为大型作业所用。如果你正在管理 NVL72 集群，我们很乐意聊聊。