Grace Blackwellは新しいスケジューラを必要とする：同じラックから27%多くのGPUを利用可能に

Grace Blackwellは新しいスケジューラを必要とする：同じラックから27%多くのGPUを利用可能に

すべての高速インターコネクトが同等ではなく、間違ったものを使用すると非常にコストがかかる可能性があります。InfiniBandではなくNVLink上で同じ分散トレーニングジョブを実行すると、パフォーマンスが43%低下する可能性があります。

歴史的に、NVLinkは単一ノード内の通信に限定されていました。これは、マルチノードAIワークロードがInfiniBandまたはクラウド相当のもの（AWSのEFA、GCPのGPUDirect-TCPX）を介して通信することを余儀なくされていたことを意味します。NVIDIAのNVL72システムは、ラック内の72個のGPUすべてを統一されたNVLinkファブリックで接続することにより、この制限を解消します。これにより、異なるノード上のGPUは、オーダー・オブ・マグニチュード大きい帯域幅でデータを交換できます。

［画像: InfiniBand］

しかし、NVL72システムのメリットを最大化するには、ワークロードの配置が非常に重要です。ラックをまたいで分散されたマルチノードジョブは、依然としてInfiniBandによってボトルネックになります。ハードウェア障害によってノードがオフラインになったり、ジョブが異なる時間に終了してラック間で空き容量が分散したりすると、ラック局所性を維持することはますます困難になります。

この記事では、大規模トレーニングおよび推論における通信ボトルネック、NVL72ラック規模ファブリック、GPU障害に対する耐性を高めるためのスライスサイジング、そしてSkyPilot Platformがトポロジー認識配置、ハードウェア障害からのインプレース復旧、共有クラスタの自動デフラグメンテーションを通じて、マルチノードジョブをラックローカルに保つ方法について解説します。

大規模トレーニングは通信の問題である #

Frontierのトレーニングジョブは数千のGPUにまたがって実行されます。これを行うには、2つの質問に答える必要があります。

1. モデルを実行できるように、GPU間でどのようにモデルをシャーディングしますか？
2. コンピューティング予算が与えられた場合、トレーニングスループットを最大化するために、シャーディングされたモデルのコピーをいくつ実行できますか？

最初の質問は、通常、以下の組み合わせで回答されます。

• テンソル並列（TP）：レイヤーの重み行列をGPU間で分割する
• エキスパート並列（EP）：混合エキスパート（MoE）レイヤーのエキスパートを異なるGPUに配置する
• パイプライン並列（PP）：モデルをレイヤーごとにGPU間で分割する

2番目の質問への回答は、データ並列（DP）の度合いを設定します。これは、トレーニングデータの異なるスライスでそれぞれ並列にトレーニングされる、シャーディングされたモデルのコピーの数です。

これらの並列化戦略の中で、テンソル並列のall-reduceとエキスパート並列のall-to-all通信パターンは、トレーニング中のクリティカルパス上にあり、NVLink上に維持することが最も重要です（§9.1.2）。

テンソル並列

テンソル並列は、各レイヤー内の重み行列をGPU間で分割するため、各GPUは各レイヤーのスライスのみを格納し、計算します。

Transformerレイヤーは、自己注意（self-attention）と多層パーセプトロン（MLP）の2つのブロックで構成されます。そのコアでは、各ブロックは行方向に2つの行列乗算（GEMM）です。Megatron-LM（§3）は、ブロックの最初のGEMMを列ごとに、2番目のGEMMを行ごとに分割することで、GPUは各GEMMの後に同期するのではなく、ブロックごとに1回のall-reduceで同期するだけでよいことを示しました。

［画像: アニメーション図：テンソル並列はAを列ごとに、Bを行ごとに2つのGPUに分割し、1回のall-reduceで部分的なz結果を合計します］

図1。 2つのGPU間でのテンソル並列。Aは列ごとに分割されるため、各GPUは通信なしでyのスライスを計算します。Bはそれに合わせて行ごとに分割されるため、各GPUは部分的なzを生成し、1回のall-reduceで部分的な結果を合計します。

この最適化があっても、テンソル並列はフォワードパス中にTransformerレイヤーごとに2回のall-reduceを必要とします。これらのall-reduceステップは、計算と完全にオーバーラップできないため、トレーニング中のクリティカルパス上にあります。その結果、テンソル並列は通常NVLink上に維持されます。Hugging Faceは、NVLinkからInfiniBandに移行した際にトレーニングスループットが43%低下したと測定しました。

エキスパート並列

混合エキスパート（MoE）レイヤーでは、MLPブロックはエキスパートと呼ばれる多数の小さなMLPと、各トークンをエキスパートの小さなサブセットにルーティングするルーターに置き換えられます。エキスパート並列は、これらの小さく独立したエキスパートが異なるGPUに配置されるようにMoEレイヤーを分割します。

エキスパート並列下では、各MoEレイヤーはフォワードパス中に2つのall-to-all通信ステップ、ディスパッチと結合を必要とします。ルーターは各トークンの上位k個のエキスパートを選択し、それらのエキスパートをメモリに持つGPUにトークンをディスパッチします。各GPUは、単一のグループ化された行列乗算を介して受信したトークン上でローカルエキスパートを計算します。最後に、エキスパートの出力は各トークンの元のGPUに送り返され、結合されます。

［画像: エキスパート並列図：all-to-allがトークンを異なるGPUのエキスパートにディスパッチし、結果を結合します］

図2。 エキスパート並列はGPU全体にエキスパートを分散させます。all-to-all通信は、割り当てられたエキスパートにトークンをディスパッチし、結果を結合します。（出典：NVIDIA、図4。）

モデルがMoEレイヤーを増やし、各トークンをより多くエキスパートにルーティングするにつれて、all-to-allトラフィックの量が増加し、通信ボトルネックが発生します。

64ウェイエキスパート並列のMoEモデルをトレーニングすると、各MoEレイヤーのエキスパートが64個のGPUに分散されます。標準的な8GPUサーバーでは、all-to-allトラフィックがハイバンド幅のNVLinkから離れ、はるかに狭いInfiniBandインターコネクトを通過します。最適化されていない通信は、トレーニング時間の最大60%を消費する可能性があります（§1.2）。NVL72システムでは、64個すべてのGPUが単一のNVLinkドメイン内に留まり、通信ボトルネックを効果的に排除します（§9.2.2）。

推論にも高速なノード間ネットワーキングが必要 #

前述の並列化手法は、トレーニングに固有のものではありません。推論エンジンが単一GPUには大きすぎるモデルを提供できるようにするだけでなく、モデル並列化はスループットを向上させることもできます。モデルの重みをより多くのGPUに分割すると、KVキャッシュ用のメモリが解放されるため、エンジンはより多くの同時リクエストを処理したり、より大きなコンテキストウィンドウをサポートしたりできます。場合によっては、解放されたメモリはGPUの数よりも速く増加します。あるvLLMベンチマークでは、モデルを2つのGPUにテンソル並列で分割したところ、KVキャッシュブロックの量が13.9倍に増加し、スループットが3.9倍向上しました。

［画像: アニメーション図：Llama-3.1-70Bの重みは1つのH100の大部分を占め、2つのH100に分割すると13.9倍のKVキャッシュブロック用のメモリが解放されます］

図3。 1つ対2つのH100でのLlama-3.1-70BのGPUメモリ内訳。（データ：vLLM。）

エキスパート並列も同様のロジックに従います。エキスパート並列の度合いが低い場合、各GPUは多くのエキスパートを保持し、KVキャッシュ用のスペースが少なくなります。複数のノードにまたがるエキスパート並列構成を指すWideEPは、GPUあたりのエキスパート数を大幅に削減します。トレードオフはネットワークトラフィックです。すべてのall-to-allは、より多くのGPUにまたがるようになります。標準的な8GPUサーバーでは、エキスパート並列グループは、InfiniBandを介して通信しなければならなくなる前に最大8GPUにまたがることができます。そこでは、GPUあたりの帯域幅が18倍低下します。NVL72は、ラック内のすべての72個のGPUをNVLink上に維持することで、この制限を解除します。DeepSeek-R1をインタラクティブな速度で提供する場合、32ウェイエキスパート並列のGB200 NVL72は、8ウェイに制限されている8GPU B200サーバーと比較して、GPUあたり最大4.4倍高いスループットを提供します。

ラックが新しいサーバーになる #

NVL72はNVLinkを単一ノードからラック全体に拡張するため、ラック全体が共有メモリを持つ巨大なアクセラレータのように機能します。

［画像: NVL72ラック内のNVLink階層：NVLinkドメイン、NVLinkパーティション、IMEXドメイン］

図4。 NVL72ラック内のNVLink階層。（出典：NVIDIA、図1。）

NVL72ラック上の各GPUは、それぞれ100 GB/sの双方向帯域幅を持つ18個のNVLinkポートを備えており、これは各GPUあたり合計1.8 TB/sに達します。各GPUのNVLinkポートは、ラックのファブリックバックプレーンを駆動する18個のNVSwitchチップのいずれかにマッピングされます。各NVSwitchチップは72個のNVLinkライン（各GPUから1つ）を受け入れるため、ラック内の集約帯域幅は130 TB/sです。

［画像: NVL72トポロジー：各GPUはラックの18個のNVSwitchチップのそれぞれに1つのNVLinkポートを接続します］

図5。 各GPUは、ラックの18個のNVSwitchチップのそれぞれに1つのNVLinkポートを接続します。（出典：NADDOD。）

このネットワークトポロジーは、ファブリックが完全にノンブロッキングであることを保証します。これは、ラック内のどのGPUも他のどのGPUにも均一なレイテンシでデータを送信できることを意味し、大規模な分散AIワークロードに最適です。

［画像: ノンブロッキングNVSwitchファブリックの隣にあるNVL72ラック。これはラック内のすべてのGPUを接続します］

図6。 NVSwitchファブリックは完全にノンブロッキングです。どのGPUも、同じレイテンシでフル帯域幅でラック内の他のどのGPUとも通信できます。（出典：NVIDIA、図1）

時には少ない方が多い：各ラックのノード数を減らすことで信頼性が大幅に向上する #

NVL72システムでは、クラスタの利用率を最大化するために、18ノードのラック全体をワークロードに割り当てたくなる誘惑があります。実際には、各ラックにいくつかの予備ノードを残すことで、チームはクラスタからより多くの利用可能な容量を得ています。

GPUは信頼性が低い。Metaは、そのギガワット規模のスーパークラスタで、信頼性向上に多大なエンジニアリング努力を注いだ後、4GPUノードあたり約490日の中断間平均時間（MTBI）を測定しました。NVL72クラスタは、72GPUラックをコンピューティングの原子単位とします。これは、ラックを構成する4GPUノードと比較して、障害の影響範囲を18倍に増加させます。ラックのMTBIは、次のように与えられます。

上記の式に基づくと、ラックは約27日ごとに中断されることになります（490 / 18）。ジョブが18ノードのラック全体に割り当てられている場合、それらの各中断により、障害のあるノードが修理されるまでラック全体がスケジュール不能になります。128ラックのクラスタでは、これはラックがフルラックジョブで約5時間ごとに使用不能になることを意味します。

ラックあたり2つのノードを予備として予約すると、この状況が変わります。ノードが故障した場合、同じラック内の予備がそれを置き換えるため、単一ノードの障害がラック全体を使用不能にするわけではありません。コストは、すべてが正常な場合にラックあたり2つのノードがアイドル状態になることです。

このトレードオフを定量化するために、NVIDIAは、ノードの利用不可率が増加するにつれて、128ラック（2,304ノード）クラスタでの利用可能な容量に異なるスライスサイズがどのように影響するかをモデル化しました。

［画像: 8、9、16、18ノードのスライスに対するノード利用不可率と128ラッククラスタの利用可能容量のグラフ］

図7。 ノード利用不可率の増加に伴う、さまざまなスライスサイズの128ラッククラスタの利用可能容量。各スライスは単一ラック内に収まる必要があります。（NVIDIA、図6より改変。）

SkyPilotでは、顧客の数万個のGPUを管理しており、本番のNVL72クラスタでは約2%の利用不可率を測定しています。そのレートでは、NVIDIAのモデルは、16ノードスライスが18ノードスライスよりも27%多くの利用可能容量（2,037ノード対1,602ノード）を提供することを示しています。また、2つの9ノードスライスがラックをちょうど満たすにもかかわらず、9ノードスライスよりも4%優れています。9ノードスライスでは、各障害が半ラックを失いますが、16ノードスライスでは、ラック内の最初の2回の障害は完全に吸収されます。8ノードスライスと比較して、16ノードスライスは各ジョブにNVLinkドメインあたり2倍のGPUを提供し、ノード利用不可率が約3.3%を超えるまで利用可能容量の1%未満しか失いません。

16ノードは、分散AIワークロードにとっても自然なサイズです。64GPUは2の累乗であり、並列化グループのサイズ設定方法と一致します。

最新のスケジューラはジョブをNVLink上に維持する方法 #

これまでは、最も通信負荷の高い並列化手法がNVLink上に配置されるべき理由、NVL72がNVLinkを単一ノードからラック全体に拡張する方法、そしてラックあたり2つの予備ノードを持つ16ノードスライスが本番クラスタから最も多くの利用可能容量を引き出す理由について説明しました。SkyPilotはこれを実践するために、各スライスを単一ラックに配置し、ハードウェア障害からインプレースで復旧し、ジョブの出入りに合わせてラック全体を解放します。

スケジューラはハードウェアを理解する必要がある

適切なスライスサイズを選択することは最初のステップにすぎません。研究者は、マルチノードトレーニング実行のスライスが実際に単一ラックに配置されることをどのように保証するのでしょうか？

ナイーブなスケジューラはマルチノードジョブをラック間で分割し、ワーカーにInfiniBand（双方向400 Gb/s）ではなくNVLink（双方向1.8 TB/s）を介して通信させます。

［画像: アニメーション図：ナイーブなスケジューラは、hero-runを2つのラックの空きノードに配置するため、トラフィックはInfiniBandを横断します］

図8。 ナイーブな配置は、マルチノードジョブをラック間で分割します。

SkyPilotのトポロジー認識スケジューラ（TAS）は、ワーカーが同じラック上にコロケートされることを保証します。

［画像: アニメーション図：SkyPilotのトポロジー認識スケジューラは、hero-runのすべてのノードを単一ラック上に配置します］

図9。 SkyPilotのトポロジー認識スケジューラは、ジョブのワーカーを単一ラック上に維持します。

マルチラックワークロードの場合、TASはジョブを16ノード（設定可能）スライスに分割し、それぞれを2つの予備ノードを持つ独自のラックに配置します。次に、SkyPilotのGPUマネージャーがGPU障害を検出すると、SkyPilot Frontier Trainerは、残りのノードが中断なく実行を続ける間に、障害のあるノードを予約済みの正常なノードのいずれかにホットスワップできます。同じラックに残りの予備がない場合、Frontier Trainerは障害のあるラックのスライスを正常なラックに再スケジュールします。

［画像: アニメーション図：hero-runは、ラックあたり2つの予備ノードを持つ2つの16ノードスライスとして実行されます。障害のあるノードは予備と交換され、その後スライスはアイドルラックに移動します］

図10。 スライスベースのスケジューリングは、各ラックに2つの正常な予備ノードを保持します。GPUマネージャーが障害のあるノードを検出すると、Frontier Trainerは同じラック内の予備と障害のあるノードを交換します。

スライスベースのスケジューリングの影響を定量化するために、NVIDIAのGR00Tチームは、GR00T N1.7（人型ロボット向けのマルチモーダル基盤モデル）の事前トレーニング中に、2つの異なるスケジューリングポリシーの影響を比較しました。最初の実行では、任意の数のラックにノードを配置するナイーブなスケジューラを使用しました。2番目の実行は、図10のようなラック認識のスライスベースポリシーでスケジュールされ、正確に8ラックに配置されました。ラック認識配置はスループットを14.4%向上させ、各イテレーションを1.59秒から1.39秒に短縮しました。

10,000GPUクラスタでは、同じ高速化により、トレーニング時間あたり約16.7Kドルが節約されます。これは、単に優れたスケジューリング決定を行うだけで、トレーニング1日あたり約400Kドルの節約になります。

断片化はラック規模のジョブをブロックする

これまでは、トポロジー認識スケジューリングが単独でどのように機能するかを検討してきました。実際には、大規模クラスタは通常共有されます。事前トレーニング実行、RLロールアウト、バッチ推論などの異種ワークロードが、同じリソースを競合します。TASはスケジューリング時に同じラック内でワークロードをビンパッキングしますが、ジョブは異なる時間に終了し、ラック全体に空きノードが分散します。これが断片化です。クラスタには、ラック規模のジョブを実行するのに十分な空きGPUがありますが、ラック全体に分散しているため、ジョブはスケジュールできません。

［画像: アニメーション図：空きノードが2つのラックに分割されているため、16ノードのhero-runはキューで待機します］

図11。 ジョブは異なる時間に終了し、空きノードがラック全体に分散します。16個の空きノードがありますが、2つのラックに分割されているため、16ノードのhero-runは配置できず待機します。

SkyPilotの自動デフラグメンテーション（Auto Defrag）は、これを解決するために構築されています。ジョブが容量ではなくトポロジーによってブロックされた場合、Auto Defragは、ラック全体を解放するためにプリエンプトする最も影響の少ないワークロードセットを見つけます。これらのワークロードは他のラックで再スケジュールされ、ブロックされたジョブがスケジュールできるようになります。

［画像: アニメーション図：Auto Defragはsft-dをrack-aに移動し、rack-bを16ノードのhero-runのために解放します］

図12。 Auto Defragはsft-dをプリエンプトしてrack-aで再スケジュールし、そこでチェックポイントから再開します。これによりrack-bが解放され、hero-runを単一の16ノードスライスとしてスケジュールできるようになります。

Auto Defragは、チェックポイントから安全に再開できる管理対象ジョブなど、安全に再開できるワークロードのみをプリエンプトします。インタラクティブ開発環境は、管理者が明示的にオプトインしない限り、そのままにされます。

結論 #

大規模AIワークロードはデフォルトで分散されており、最もネットワーク集約的な通信パターンはクリティカルパス上にあります。NVL72のようなラック規模システムは、ハードウェアでこのボトルネックに対処することを目指していますが、ハードウェアだけでは高速化は保証されません。これらのシステムには、ラック認識配置、ハードウェア障害への耐性、ジョブの出入りに伴う動的な再バランシングが必要です。SkyPilot Platformは、このギャップを埋めるために特別に構築されています。トポロジー認識スケジューリングはマルチノードジョブをNVLink上に維持し、Frontier TrainerはGPUマネージャーがハードウェア障害を検出したときに正常な予備と交換し、自動デフラグメンテーションは大規模ジョブのために共有ラックを開いたままにします。NVL72クラスタを管理している場合は、チャットさせていただければ幸いです。