Grace Blackwell 需要新的排程器：同一機架可提升 27% GPU 可用率

並非所有高速互連都是相同的，使用錯誤的互連可能會相當昂貴：將同一個分散式訓練工作跑在 InfiniBand 而非 NVLink 上，可能會降低 43% 的效能。

歷史上，NVLink 僅限於單個節點內的通訊，這意味著多節點 AI 工作負載被迫透過 InfiniBand 或雲端等效方案（AWS 的 EFA、GCP 的 GPUDirect-TCPX）進行通訊。NVIDIA 的 NVL72 系統透過在機架內將所有 72 個 GPU 連線至統一的 NVLink 網路，消除了此限制，使不同節點的 GPU 能以十倍以上的頻寬交換資料。

然而，最大化 NVL72 系統的效益高度依賴工作負載的佈局：跨機架分佈的多節點工作仍然受 InfiniBand 的瓶頸限制。隨著硬體故障使節點下線，以及工作在不同時間結束而將空閒容量散佈於各機架，維持機架本地性變得更困難。

本部落格將討論大型訓練與推論中的通訊瓶頸、NVL72 機架級網路，以及為 GPU 故障提供彈性的切片尺寸，並說明 SkyPilot Platform 如何透過拓樸感知佈局、硬體失效即時復原以及共享叢集的自動除碎片化，保持多節點工作本地於機架。

Frontier 訓練工作跨越數千個 GPU 執行。為此需要回答兩個問題：

如何將模型切分到多個 GPU 上，以確保它能實際執行？
在已知運算預算的前提下，你可以執行多少份切分後的模型副本，以最大化訓練吞吐量？

第一個問題通常以以下組合來回答：

Tensor Parallelism（TP）：將層的權重矩陣分散到多個 GPU 上
Expert Parallelism（EP）：將混合專家（MoE）層的專家放置於不同 GPU 上
Pipeline Parallelism（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 測得在將其移至 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 在一臺 vs. 兩臺 H100 上的 GPU 記憶體分解。 (資料來源：vLLM。)

Expert parallelism follows the same logic. With a low degree of expert parallelism, each GPU holds many experts, leaving less room for the KV cache. WideEP, which refers to expert-parallel configurations spanning multiple nodes, significantly reduces the number of experts per GPU. The trade-off is network traffic: every all-to-all now spans more GPUs. On standard 8-GPU servers, an expert-parallel group can span at most eight GPUs before it has to communicate over InfiniBand, where per-GPU bandwidth drops 18x. NVL72 removes this limit by keeping all 72 GPUs in a rack on NVLink. When serving DeepSeek-R1 at interactive speeds, GB200 NVL72 with 32-way expert parallelism delivers up to 4.4x higher throughput per GPU than 8-GPU B200 servers, which are capped at 8-way.

NVL72 extends NVLink from a single node to the entire rack, so the whole rack acts like a gigantic accelerator with shared memory.

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 vs. 1,602 節點）。它們也以 4% 的優勢擊敗 9 節點切片，儘管兩個 9 節點切片恰好填滿一棟：使用 9 節點切片時，每一次失效都消耗半棟，而使用 16 節點切片時，第一兩次失效在棟內完全吸收。與 8 節點切片相比，16 節點切片為每個工作提供雙倍 GPU 數量於 NVLink 域，同時在節點不可用率低於 3.3% 時，放棄的可用容量不足 1%。

十六節點也是分散式 AI 工作負載的自然尺寸：64 顆 GPU 為二的冪，符合平行群組通常的尺寸規範。

目前為止，我們已闡述為何最需要大量通訊的平行技術適用於 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 團隊比較了兩種不同排程策略的效果，在 512 GB300 GPU 的 128 節點上對 GR00T N1.7（為人形機器人設計的多模態基礎模型）進行預訓練。第一次執行使用了將節點隨機分佈於任意數量機架的簡單排程器。第二次執行則採用像圖10所示的機架感知、基於切片的策略，將其放置於恰好 8 個機架。機架感知排程使吞吐量提升 14.4%，將每次迭代時間從 1.59 秒縮短至 1.39 秒。

在 10,000 GPU 的叢集上，同樣的加速可每小時節省約 16.7K 美元。只靠更好的排程決策，每天可節省約 400K 美元。

碎片化阻礙機架規模工作負載

迄今為止，我們已探討了拓撲感知排程在隔離環境中的運作方式。實際上，大型叢集通常是共用的：如預訓練、RL 迭代、批次推理等異質工作負載都競爭相同資源。TAS 在排程時將同一機架內的工作負載進行 bin packing，但工作負載結束時間不同，導致空閒節點分散於各機架。這就是碎片化：叢集雖有足夠的空閒 GPU 可執行機架規模工作，但因分散於多個機架，工作無法排程。

Animated diagram: free nodes are split across two racks, so the 16-node hero-run waits in the queue — **Figure 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 — **Figure 12.** Auto Defrag 先中斷 sft-d 並將其重新排程至 rack-a，從檢查點恢復。這釋放了 rack-b，讓 hero-run 能以單一 16 節點切片排程。

Auto Defrag 只會中斷能安全重啟的工作負載，例如從檢查點恢復的受管理工作。除非管理員明確啟用，否則互動式開發環境不會被中斷。

大型 AI 工作負載預設已分散式執行，其最耗網路的通訊模式位於關鍵路徑。像 NVL72 這類機架規模系統旨在於硬體層面解決此瓶頸，但硬體本身並不能保證加速。這些系統需要機架感知排程、對硬體失效的韌性，以及隨著工作進出動態重新平衡。SkyPilot 平臺專為彌合此差距而設：拓撲感知排程讓多節點工作保持在 NVLink 上，Frontier Trainer 在 GPU Manager 檢測到硬體失效時替換健康備援，Auto Defrag 讓共用機架保持可供大型工作使用。如果你正在管理 NVL72 叢集，我們很樂意聊聊。