Slurm のトポロジー対応ジョブスケジューリングにより NVIDIA GB200 NVL72 でエクサスケール性能を発揮

AI モデルの規模と複雑性が増大する中、現代の加速インフラの性能を最大限に引き出すには、ハードウェアそのものと同様にワークロードの配置方法が重要となります。[NVIDIA GB200 NVL72](https://www.nvidia.com/en-us/data-center/gb200-nvl72/) は単一のラックでエクサスケール計算を実現し、リアルタイムでのトリリオンパラメータモデルの実行を可能にします。しかし、共有クラスタにおいてその性能を引き出すには、システムアーキテクチャを理解し、ジョブをネットワークトポロジと整合させるスケジューラーが必要です。 本記事では、[Slurm](https://slurm.schedmd.com/overview.html) のトポロジ認識型ジョブスケジューリングが NVIDIA GB200 NVL72 でどのように機能するかを解説し、最適な GPU 稼働率を得るためのスケジューリング推奨事項を提供します。 ## NVIDIA GB200 NVL72 はエクサスケール計算をどのように実現するのか？ [NVIDIA GB200 NVL72](https://www.nvidia.com/en-us/data-center/gb200-nvl72/) は、単一のラックに収まるエクサスケールコンピューターです。72 個の [NVIDIA Blackwell](https://www.nvidia.com/en-us/data-center/technologies/blackwell-architecture/) GPU が、生産規模で最大級のアップグレード計算ファブリックによって相互接続されており、[NVIDIA NVLink](https://www.nvidia.com/en-us/products/workstations/nvlink-bridges/) は AI およびハイパフォーマンスコンピューティング (HPC) ワークロード向けに、1 秒あたり 130 テラバイト (TB/s) の低遅延 GPU 通信帯域幅を提供します。複数の GB200 NVL72 システムをクラスタで結合することで、非常に高いネットワーク帯域域を持つ大規模ドメインを含む階層型ネットワークトポロジが構築されます。 AI 学習ジョブは、NVLLink ファブリックの活用を最大化するようにスケジューリングされる場合、GB200 NVL72 が提供する豊富なネットワーク帯域幅から大きな恩恵を受けることができます。最近の結果では、GB200 NVL72 は、トレーニング（[最新の MLPerf トレーニングで 2.6 倍以上の性能向上](https://developer.nvidia.com/blog/nvidia-blackwell-delivers-up-to-2-6x-higher-performance-in-mlperf-training-v5-0/)）、さまざまな推論ユースケース（[トリリオンパラメータモデルのリアルタイム推論](https://developer.nvidia.com/blog/nvidia-gb200-nvl72-delivers-trillion-parameter-llm-training-and-real-time-inference/)、[OAI gpt-oss モデルで 150 万トークン/秒以上](https://developer.nvidia.com/blog/delivering-1-5-m-tps-inference-on-nvidia-gb200-nvl72-nvidia-accelerates-openai-gpt-oss-models-from-cloud-to-edge/)、[最先端の分散型サービス](https://developer.nvidia.com/blog/how-nvidia-gb200-nvl72-and-nvidia-dynamo-boost-inference-performance-for-moe-models/)）、そして [推論能力](https://developer.nvidia.com/blog/nvidia-blackwell-ultra-for-the-era-of-ai-reasoning/) を含む、すべての AI ワークロードにおいて顕著な性能向上をもたらすことが示されています。 複数のトレーニングジョブを実行する共有クラスタでは、リソース効率的なスケジューラは、異なるネットワーク帯域幅要件を考慮する必要があります。 ## トポロジ対応型ジョブスケジューリングとは何ですか？ トポロジ対応ジョブスケジューリングは、[Slurm](https://slurm.schedmd.com/overview.html) などのジョブスケジューラが、スイッチやラックの階層構造などクラスターの物理ネットワークレイアウトに基づいてリソース割り当ての判断を行えるようにするものです。スケジューラは可能な限りワークロードを同じ NVLink ドメイン内に保持し、局所性を維持すべきです。さらに、複数のトレーニングまたは推論ジョブが NVL72 ラックのグループに収容できるため、スケジューラはリソースの断片化を防ぐために効率的なビンパッキングを提供する必要があります。 長年使われてきた Slurm のトポロジ/ツリープラグインは大規模クラスターに対してトポロジ対応スケジューリングを提供しますが、そのベストエフォート型のアプローチはキュー時間を短縮するためにジョブをリーフスイッチ間で断片化させる傾向があります。この開始時間とパフォーマンスの間の妥協は従来の InfiniBand ファブリックでは許容されていましたが、GB200 NVL72 や GB300 NVL72 などのラックスケールシステムの登場により変更が必要となりました。これに対応し、NVIDIA と SchedMD は Slurm 23.11 でこれらの現代アーキテクチャに特化した新しいトポロジ/ブロックプラグインの導入を共同で発表しました。 このトポロジプラグイン設定は、同じ NVL72 ドメインに属するノードのグループに関する情報を提供し、Slurm ジョブを NVL72 ドメイン境界と整合させるアルゴリズムを可能にします。ブロックトポロジプラグインの詳細やセグメントサイズのスケジューリング方法については、[Slurm ブロックスケジューリングによる NVIDIA GB200 NVL72 でのシステムおよびワークロード効率の最大化](https://developer.nvidia.com/blog/achieving-peak-system-and-workload-efficiency-on-nvidia-gb200-nvl72-with-slurm-block-scheduling/) をご覧ください。 ## GB200 NVL72 におけるクラスター分割とジョブスケジューリングはどのように機能するか？ クラスターの規模と複雑性が増大するにつれ、高い利用率と予測可能なパフォーマンスを達成するために GPU リソースの管理が極めて重要になります。GB200 NVL72 システムでは、より大きな AI ジョブのセグメントサイズと微細なスケジューリング制御を導入し、オペレーターがワークロードのニーズに合わせてセグメント構成を調整できるようにしています。Slurm ワークロードマネージャーにおける GB200 NVL72 対応のスケジューリング拡張機能とともに、このアプローチはハードウェア障害が存在する場合でも、大規模ジョブと小規模ジョブのバランスを取りながら効率を最大化します。 ## GB200 NVL72 はどのようにしてより大きなセグメントサイズを実現するのか？ マルチ GPU ワークロードにおいて、ジョブセグメントサイズは、NVLLink 上で完全に相互通信可能なノードで構成されるサブユニットを定義します。図 1 は、特定のジョブに割り当てられる GPU を定義するために、セグメント番号 (Y) とセグメントサイズ (S) がどのように使用されるかを示しています。GB200 および GB300 におけるノードあたりの GPU 数 (G) は常に 4 です。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/gpu-job-allocation-nvidia-gb200-nvl72-1.webp)*図 1. GB200 NVL72 のジョブサイズは、NVLink を介したより大規模でスケーラブルな GPU グループ化を可能にします* 以前のシステム（NVIDIA HGX H100 など）では、ジョブは 1 ノード分のセグメントサイズに制限されていました。一方、GB200 NVL72 システムは、より大きなセグメントサイズ（最大 18 ノードまで）をサポートするだけでなく、セグメントを単一ノードとして効率的に扱うことも可能です。 特定のアプリケーションにおける最適なセグメントサイズは、モデルの種類やトレーニングに使用される並列処理タイプの組み合わせなどの要因によって決定されます。一般的に、より大規模なジョブ（より多くの GPU を利用するもの）や、高い I/O バンド幅を必要とするジョブ（例えば、Mixture-of-Experts (MoE) トレーニングなど）は、大きなセグメントサイズから恩恵を受けます。逆に、小規模なジョブは通常、I/O バンド幅の要件が低いため、クラスタースケジューラーを過度に制約しないよう、小さなセグメントサイズを使用すべきです。不確実な場合は、パフォーマンスへの影響がワークロード固有となる可能性があるため、ユーザーは自らの特定のワークロードに対してこのガイダンスを検証する必要があります。 ## GB200 NVL72 のセグメントサイズ設定におけるベストプラクティスとは？ モデリングにおいて、当チームは GB200 NVL72 クラスターの利用率を最大化するためのいくつかの一般的なガイドラインを見出しました。一つの目安として、クラスター内の GPU 使用時間の割合が 90% を超えないように、「大規模」なセグメントサイズ（16 ノード）を使用するクリティカルジョブサイズの選択が挙げられます。これにより、スケジューラーはさまざまなセグメントサイズを適切に組み合わせながら、クラスターをフル活用するための柔軟性を得ることができます。表 1 は、推奨される最適な構成のいくつかを要約したものです。 **ジョブサイズ****セグメントサイズ****例示ワークロード** 12816MoE モデルトレーニング 32 – 644大規模密モデルトレーニング 32 未満1小規模モデルトレーニング *表 1. ジョブサイズとワークロードタイプ別 GB200 NVL72 の推奨セグメントサイズ* なお、本記事の目的上、ユーザージョブは 2 のべき乗数の GPU セグメントサイズ（例：4 ノード = 16 GPU）での実行を好むものと仮定しています。他のセグメントサイズ（例：セグメントあたり 12、36、または 72 GPU など）を選択することも可能です。代替アプローチが妥当かどうかを判断するには、非 2 のべき乗数のセグメントサイズにジョブをマッピングした際の効率性と、異なるサイズのジョブがクラスター全体の利用率に与える影響を検討する必要があります。 ## GB200 NVL72 システム上でのジョブスケジューリング方法 NVIDIA と SchedMD は、高利用率を実現するための GB200 NVL72 対応ジョブ配置を可能にする Slurm ベースのブロックスケジューリング拡張機能を開発しました。 2 の累乗サイズのセグメントを使用することで、GB200 NVL72 クラスターは大規模ジョブと小規模ジョブを並行して実行できます。例えば、16 ノードのセグメントを使用した 512 GPU を要するジョブ 1 つと、単一ノードのセグメントを使用した 16 GPU のジョブを複数同時に走らせることが可能です。これらのスケジューリングポリシーは、クラスター全体で高い効率性を維持しつつ、フラグメンテーション（断片化）を最小限に抑えます。 ## GB200 NVL72 のスケジューリングシミュレーションフレームワークとは何か？ 大規模なスケジューリング戦略を評価するために、私たちは仮想マシン上で動作し、時間圧縮されたワークロードシミュレーションを可能にするスタンドアロンの Slurm シミュレータを開発しました。図 2 に示す通り、このシミュレータは以下の機能により、正確で再現性のある結果を提供します。 - Slurm コードの実行 - 本番環境のワークロードの再生または合成ワークロードの生成 - ノード障害や復旧など現実世界の条件のシミュレーション - メトリクスシステムとの統合による結果の直接比較 この構成により、本番環境への展開前に新しいスケジューリングポリシーをテストし、比較し、自信を持って導入するための大きな利点を得ることができます。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/slurm-simulator-flow-625x375.png)*図 2. Slurm シミュレータフローにおいて、本番環境とテスト環境間で実測値とシミュレーション値が比較される* ## シミュレーションパラメータ チームがモデル化したシミュレーション環境のパラメータは以下の通りです。 - クラスター容量：5,000 台の GB200 NVL72 ノード（GPU 計 20,000 基） - ワークロード：7 日間にわたる 15,000 ジョブ - 信頼性：任意の時点で平均 2.5% のノードがダウンしている状態 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/simulation-job-distribution.webp) 各カテゴリには 2 つの棒グラフが表示されています。灰色の棒はジョブ数の割合を、緑色の棒はノード使用時間の割合を示しています。「Large」カテゴリでは両方の値が最も高く、緑色の棒（ノード使用時間）がわずかに灰色の棒を上回っています。「XLarge」も高いノード使用時間の割合を持ちますが、ジョブ数は低くなっています。「Small」と「Medium」カテゴリは高いジョブ数ですが、ノード使用時間は低い傾向にあります。縦軸は 0 から 50 のパーセンテージを表しています。*Figure 3. ノード数別バケットにおけるジョブの分布状況を示す図。総ジョブ数の割合と総ノード使用時間の割合を比較* チームは、利用効率と大規模ジョブのパフォーマンスのバランスを取るために設計された Large_Perf_Custom ポリシーを使用してパフォーマンスを評価しました: - 32 ノード以上のジョブは、セグメントサイズ 16 で実行されました - より小さなジョブは、セグメントサイズ 2 で実行されました ## シミュレーション結果は何を示しているか？ 新しいスケジューリング戦略のパフォーマンスを評価するために、私たちは 2 つの主要なクラスター指標に焦点を当てました: ブロックの断片化と全体の GPU 稼働率です。 ## 断片化分析 GB200 NVL72 のスケジューリングにおける重要な指標は、小規模ジョブが大規模ジョブに対する NVLink ドメインの利用可能性にどのような影響を与えるかという点です。シミュレータは、各 NVLink ドメイン内で小規模ジョブ（1〜18 ノード）がどのように配置されたかを追跡しました。 主な発見は、トポロジープラグインが小規模ジョブを各ドメインの最後の 2 つのノードに効果的に配置し、断片化を最小限に抑えつつ、大規模ジョブのための容量を確保していることです。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/heat-map-large-perf-job-distribution-625x508.png)*図 4. 断片化を最小限に抑えるために、各ドメインの最後の 2 つのノードに小規模ジョブが集中して配置されている様子を示すヒートマップ* ## 稼働率指標 トポロジー認識型スケジューリングは制約を導入しますが、私たちの結果では、最適なトポロジー認識型スケジューリングの実装を通じて、全体の稼働率への影響をほぼ完全に排除できることが示されました。図 5 では、Large_Perf_Custom と NoTopo の間の差が約 1% であることが示されています。このギャップは、さらに多くの小規模ジョブを追加することで埋めることができます。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/occupancy-simulation-results-large-perf-notopo-625x216.png)*図 5. シミュレーション結果は、柔軟なセグメントサイズにより占有率が向上することを示しています* 私たちは、開発した Large_Perf_Custom アルゴリズムにおける占有率と、noTopo ポリシー（noTopo 設定）を比較しました。ここでいう noTopo 設定とは、ジョブサイズの分布を考慮して理論的に可能な最高の占有率を表すものであり、noTopo アルゴリズムにおいて配置が不適切な場合に生じる大きなランタイムのペナルティは無視したものです。実用的な目標は、トポロジーに無知なスケジューリングによるパフォーマンスの低下を回避しつつ、可能な限り noTopo の占有率に近づけることです。 結果として、私たちのシミュレーションでは noTopo とほぼ 1% の差で占有率を達成し、トポロジー認識型スケジューリングが性能を犠牲にすることなく高い利用率を実現できることが示されました。 ## GB200 NVL72 における最適なジョブスケジューリング手法とは何か？ シミュレーション結果およびパフォーマンステストに基づき、大規模ジョブのパフォーマンスを優先しつつ高い利用率を維持する NVIDIA GB200 NVL72 クラスター向けのスケジューリングアプローチを推奨します。64 GPU 以上の大規模ジョブは、NVLink ドメインの最大数へのアクセス権限を与え、セグメントサイズ調整によりドメイン間で GPU が比例配分されるようにする必要があります。リソースとワークロードパターンを整合させるためには、セグメントベースのスケジューリングが不可欠です。32 ノード以上のジョブについては、アプリケーションがその恩恵を受けられる場合、セグメントサイズ 16 を推奨します。一方、小規模なジョブはワークロード特性に応じて、セグメントサイズ 2 から 8 がより適しています。 時間経過に伴う効率を維持するためには、継続的な監視と最適化が重要です。フラグメンテーション指標の追跡、ワークロードパターンの進化に応じたセグメントサイズの調整、本番環境への展開前のシミュレーションツールによる変更検証を行うことで、パフォーマンスを犠牲にすることなく高い利用率を維持できます。ブロックトポロジーは占有率を低下させる制約をもたらす可能性がありますが、戦略的なスケジューリングポリシーを適用することでこの影響を緩和し、パフォーマンス上のメリットを保持することが可能です。 ## NVIDIA GB200 NVL72 の活用開始 NVIDIA GB200 NVL72 システムは、AI および HPC（High Performance Computing）コンピューティングにおける主要な進展を表しており、その潜在能力を最大限に引き出すにはトポロジ対応型スケジューリングが必要です。当社のモデル化により、単純な設定とセグメントベースのスケジューリングを用いることで、高いクラスター利用率を維持しながら最適なパフォーマンスを実現できることが示されています。異なるスケジューリングシナリオをシミュレーションする能力は、本番環境のワークロードにリスクを負うことなく、新しいポリシーを確信を持って導入することを可能にします。[NVIDIA GB200 NVL72 について詳しくはこちら](https://www.nvidia.com/en-us/data-center/gb200-nvl72/)。

Slurm のトポロジー対応ジョブスケジューリングにより NVIDIA GB200 NVL72 でエクサスケール性能を発揮

背景や根拠まで確認しますか？

調べる

選ぶ

サイト