SkyPilot 解析 Grace Blackwell NVL72 调度：16 节点切片多出 27% 可用 GPU

并非所有高速互连都是生而平等的，使用错误的一种可能代价高昂：在 InfiniBand 而非 NVLink 上运行相同的分布式训练任务，可能导致性能下降 43%。

历史上，NVLink 仅限于单节点内的通信，这意味着多节点 AI 工作负载被迫通过 InfiniBand 或云上等效方案（AWS 上的 EFA、GCP 上的 GPUDirect-TCPX）进行通信。NVIDIA 的 NVL72 系统通过统一的 NVLink 网络结构连接一个机架内的全部 72 块 GPU，消除了这一限制，因此不同节点上的 GPU 能够以高出一个数量级的带宽交换数据。

然而，要最大化 NVL72 系统的收益，高度依赖于工作负载的放置：跨机架分布的多节点任务仍会受限于 InfiniBand。随着硬件故障导致节点离线、以及不同时间完成的任务将空闲容量分散到各个机架，保持机架局部性变得更加困难。

本博客涵盖大规模训练与推理中的通信瓶颈、NVL72 机架级网络结构、为抵御 GPU 故障而进行的切片规模设定，以及 SkyPilot 平台如何通过拓扑感知放置、硬件故障原地恢复和共享集群自动碎片整理，使多节点任务保持机架局部性。

前沿训练任务运行在数千块 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 通过将机架内全部 72 个 GPU 保持在 NVLink 上，消除了这一限制。在以交互速度服务 DeepSeek-R1 时，采用 32 路专家并行的 GB200 NVL72 相比最高仅支持 8 路的 8-GPU B200 服务器，每 GPU 吞吐量最高提升 4.4 倍。

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 端口映射到为该机架网络背板提供支持的 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。）

这种网络拓扑确保网络结构完全无阻塞，意味着机架内任意 GPU 都能以一致的延迟向任意其他 GPU 传输数据，使其成为大规模分布式 AI 工作负载的理想选择。

An NVL72 rack next to its non-blocking NVSwitch fabric, which connects every GPU in the rack — **图 6.** NVSwitch 网络结构完全无阻塞。任意 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 对 1,602 个节点）。它们也比 9 节点切片高出 4%，尽管两个 9 节点切片恰好填满一个机架：使用 9 节点切片时，每次故障都会损失半个机架，而使用 16 节点切片时，一个机架内的前两次故障会被完全吸收。与 8 节点切片相比，16 节点切片让每个作业在每个 NVLink 域内获得两倍的 GPU 数量，同时在节点不可用率超过约 3.3% 之前，仅损失不到 1% 的可用容量。

16 节点也是分布式 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 的拓扑感知调度器（TAS）确保工作节点位于同一机架：

Animated diagram: SkyPilot's Topology-Aware Scheduler places all of hero-run's nodes on a single rack — **图 9.** SkyPilot 的拓扑感知调度器将作业的工作节点保持在单个机架上。

对于多机架工作负载，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 秒缩短至 1.39 秒。

在 10,000 块 GPU 的集群上，同样的加速每训练小时可节省约 1.67 万美元。也就是说，仅仅通过做出更好的调度决策，每个训练日就能节省约 40 万美元。

碎片化阻碍机架级作业

到目前为止，我们探讨的是拓扑感知调度在孤立场景下的工作方式。在实践中，大型集群通常是共享的：预训练运行、RL rollout 和批量推理等异构工作负载都在竞争同一批资源。TAS 在调度时将工作负载装箱打包到同一机架内，但作业在不同时间完成，导致空闲节点分散在各个机架中。这就是碎片化：集群有足够的空闲 GPU 来运行机架级作业，但由于它们分散在不同机架，该作业无法被调度。

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

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 平台正是为弥合这一差距而专门构建的：拓扑感知调度将多节点作业保持在 NVLink 上，Frontier Trainer 在 GPU Manager 检测到硬件故障时换入健康的备用节点，自动碎片整理则为大型作业保持共享机架的开放。如果你正在管理 NVL72 集群，我们很乐意聊聊。