Slurm ブロックスケジューリングによる NVIDIA GB200 NVL72 のシステム・ワークロード効率最大化

[NVIDIA GB200 NVL72](https://www.nvidia.com/en-us/data-center/gb200-nvl72/) は、[NVIDIA NVLink](https://www.nvidia.com/en-us/data-center/nvlink/) の整合性をラック全体に拡張することで、GPU クラスターを構築する根本的に新しい方法を導入しました。この設計はエクサスケール性能を実現しますが、多くのスケジューリングシステムが前提としていた仮定も変化させます。 その結果、「ラックスケールの局所性」が強制的な制約となります。ワークロードがドメイン境界を越えるとパフォーマンスが急激に低下し、ネットワークファブリックをベストエフォート型のツリートポロジと見なすスケジューラーは、キュー待ち時間を増加させアプリケーションのパフォーマンスを劣化させるような割り当ての断片化を引き起こします。 これに対処するため、[Slurm ワークロードマネージャー](https://slurm.schedmd.com/overview.html) はトポロジ/ブロックプラグインを導入し、セグメントスケジューリングによる機能拡張を続けています。このプラグインにより、管理者やユーザーはアプリケーション固有の NVLink 要件を、緩やかに最適化された割り当てではなく、原子的なブロックとして表現できるようになります。 本記事では、[NVIDIA GB200 NVL72](https://www.nvidia.com/en-us/data-center/gb200-nvl72/) アーキテクチャがどのように独自性を有するか、Slurm のブロックスケジューリングが配置とパフォーマンスの最適化にどう役立つか、そしてプロトタイプクラスターから本番グレードのラックスケールオーケストレーションへ移行するために、topology.yaml、--segment および関連機能の設定をどのように行うかを解説します。 ## NVIDIA GB200 NVL72 アーキテクチャはどのように独自なのか？ [NVIDIA GB200 NVL72](https://www.nvidia.com/en-us/data-center/gb200-nvl72/) は、GPU クラスター設計における新たなパラダイムを代表する、ラック単体のエクサスケールコンピューターです。以前のサーバー世代では [NVIDIA NVLink](https://www.nvidia.com/en-us/data-center/nvlink/) がシャーシ内で使用されていましたが、GB200 NVL72 はこのコヒーレントメモリドメインをラック全体に拡張します：18 個の計算トレイにまたがる 72 個の [NVIDIA Blackwell](https://www.nvidia.com/en-us/data-center/technologies/blackwell-architecture/) GPU が、第 5 世代 NVLink によって統合されています。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/nvidia-gb200-nvl72-rack.webp)*図 1. GB200 NVL72 ラックと NVLink トポロジーにおける日益複雑化する相互接続には、より高度なワークロードインテリジェンスが必要* ラック内のすべての通信は NVLink の速度で動作します：NVIDIA GB200 NVL72 は GPU あたり 1.8 TB/s の双方向スループットを提供し、合計帯域幅は 130 TB/s に達します。ドメイン境界を越える通信では性能が著しく低下し、通常は InfiniBand または Ethernet を介して 50 GB/s（400 Gb/s）程度となります。 大規模な GB200 NVL72 クラスターを運用するには、NVLink ドメインをジョブのハード境界として扱う新しいワークロードスケジューリングアルゴリズムが必要です。これらの新アルゴリズムは効率的なワークロードに不可欠ですが、同時にシステム断片化に関する管理側の認識も必要とします。トポロジー/ブロック Slurm プラグインは、ユーザーと管理者の両方にとってこの 2 つの課題を解決する手助けとなります。 ## Slurm におけるブロックスケジューリングはどのように機能するのか？ Slurm は長年、トポロジ認識型ジョブスケジューリングをサポートしてきました。トポロジ/ツリープラグインは、大規模クラスターにおける標準的な手法です。これは、ネットワーク計算ファブリックをスイッチとノードの階層ツリーとしてモデル化します。トポロジ/ツリーの主な目的は、ジョブが跨ぐスイッチ数を最小限に抑えることですが、これはベストエフォート型の試みに過ぎません。ジョブはより早く開始するために、リーフスイッチ間で重度に断片化される可能性があります。 すべての計算ノードをインフィニバンドファブリックで接続するクラスターにおいては、このトレードオフは理にかなっています。複数のリーフスイッチにまたがるジョブは、単一のリーフスイッチ下で実行する場合よりもわずかに低速になるかもしれませんが、開始時間とパフォーマンスの間のトレードオフは一般的に許容範囲と見なされています。 GB200 NVL72 および GB300 NVL72 の登場により、新たなアプローチが必要となりました。NVIDIA と SchedMD による共同開発の結果、Slurm 23.11 リリースにおいて新しいトポロジ/ブロックプラグインが導入され、GB200 NVL72 などのラックスケールアーキテクチャをサポートするようになりました。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/block-scheduling-nvlink-slurm-625x315.png)*図 2. クラスター内の各マルチノード NVLink ドメインはブロックとしてモデル化され、これは剛性のあるスケジューリング単位です* ジョブが単一のブロック（18 ノード以下）に収まる割り当てリクエストを提出した場合、ノードは常に 1 つのブロックから割り当てられ、ジョブは断片化されることはありません。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/job-allocation-examples-slurm-nvlink-596x1024.png)*図 3. デフォルトのスケジューリング下でブロック全体にノードがどのように割り当てられるかを示すジョブ割り当て例（-N12, -N8, -N32）* トポロジー/ブロックのデフォルト動作では、16 ノードを要求するジョブは、アイドル状態の 16 ノードを持つ単一のマルチノード NVLink ドメインが利用可能になるまでスケジューラが待機することになります。これにより、ジョブキューでの待ち時間が長くなる可能性があります。実際には、アプリケーションの NVLink 接続要件が、NVL72 ドメイン全体よりも小さい場合があります。 ユーザーがアプリケーションのトポロジー要件をジョブスケジューラに伝えることを可能にするため、Slurm はトポロジー/ブロックジョブに対して --segment 引数を導入しました。これは、同じブロック内に配置しなければならないノードの原子グループを定義する調整可能なパラメータとして機能し、スケジューラの効率性とアプリケーションの実際のハードウェア局所性要件とのバランスを取るのに役立ちます。 このパラメータを変更することで、スケジューリングの制約を大幅に緩和できます。例えば、12 ノードを要求しつつ --segment=4 を指定するジョブは、3 つの別々のブロックに分割して実行可能です。単一のブロックに 12 ノードが利用可能でないため、--segment=4 を指定しなければこの新しいジョブを実行することはできません。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/segmented-job-allocation-example-split-across-multiple-blocks-625x347.png)*図 4. セグメント化された割り当ての例 (-N12 --segment=4) は、ジョブが複数のブロックにどのように分割されるかを示しています* ## Slurm ブロックスケジューリングはパフォーマンスをどのように最適化するのか？ ユーザーをしばしば驚かせる重要な微妙な点は、Slurm が同じジョブの複数のセグメントを同じブロックに割り当てられる可能性があるという事実です。 セグメントの使用は、ワークロードの特定の局所性要件に基づいてパフォーマンスを最適化するために不可欠です。[テンソル並列処理 (TP)](https://docs.nvidia.com/nemo/megatron-bridge/latest/parallelisms.html#tensor-parallelism) は、遅延感受性の通信を高速な NVLink ファブリック内に維持するために小さく密なセグメントを必要とする場合があります。一方、[エキスパート並列処理 (EP)](https://docs.nvidia.com/nemo/megatron-bridge/latest/parallelisms.html#expert-parallelism-and-mixture-of-experts-moe) は、すべてのオールツーオール集合演算が常に単一の NVLink ドメイン内で行われるようにするために、より大きなセグメントサイズを必要とする場合があります。 --segment=16** **のような大きなセグメント値を使用することは、ノードをブロック間でバランスよく割り当てるための方法でもあります。図 4 は、32 ノードがブロック 3 に 18 ノード、ブロック 4 に 14 ノードとして分割される様子を示しています。代わりに --segment=16 を使用すれば、図 5 に示すように各ブロックに正確に 16 ノードを割り当てることを保証できます。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/balanced-job-allocation-example-even-distribution-across-blocks-625x346.png)*図 5. ブロック間でのノードの均等な分散を示すバランス型割り当て例 (-N32 --segment=16)* Slurm 25.11 で導入されたコマンドライン引数 [--consolidate-segments](https://slurm.schedmd.com/srun.html#OPT_consolidate-segments) と [--spread-segments](https://slurm.schedmd.com/srun.html#OPT_spread-segments) を使用すると、セグメントの配置をユーザーが制御できるようになります。 ## Slurm ブロックスケジューリングの設定方法 トポロジー/ブロック設定については、Slurm 管理者に対しては、クラスター内の各 GB200 NVL72 ドメイン（18 ノード）ごとに 1 つのブロックを定義することを推奨します。18 ノード未満のジョブで --segment オプションを指定しない場合、Slurm はアロケーションをブロック境界間で断片化しません。代わりに、クラスター内で十分なリソースが利用可能になるまでジョブをキューに残置します。 これにより、このジョブに割り当てられたすべてのノードが NVLink を介して通信できるようになり、クラスターの現在の状態に関わらず一貫したパフォーマンスが保証されます。18 ノードを超えるジョブで --segment オプションを指定しない場合、Slurm は必要な最小限のブロック数にアロケーションを収めます。 topology/block の設定には、Slurm 25.05 で導入された機能であるファイル [topology.yaml](https://slurm.schedmd.com/topology.yaml.html) を利用することを推奨します。例えば、2 つの GB200 NVL72 ドメインを定義するには、以下のスクリプトを使用します： - topology: gb200-nvl72 cluster_default: true block: block_sizes: - 18 blocks: - block: block01 nodes: node[0001-0018] - block: block02 nodes: node[0019-0036] Slurm のトポロジ/ブロックプラグインは、複数の階層レベルでのグループ化をサポートしており、最初のレベルは NVL72 ドメインとなり、より上位のレベルのブロックは、データセンター行やデータセンターホールをまたぐ際の性能への影響など、計算ファブリック設計の物理的な現実を反映することができます。 GB200 NVL72 クラスターにおいて、計算ファブリックに対して完全な [fat-tree（脂肪樹状トポロジ）](https://docs.nvidia.com/networking/display/infinibandclusterbringupprocedure/setting+the+infiniband+cluster+topology) が構成されている場合、マルチノード NVLink ドメインに対しては Slurm ブロックを単一のレベルのみ使用することが推奨されます。これは、リーフスイッチをまたぐ際の性能低下が、NVL ドメインをまたぐ際の性能低下ほど急峻ではないためです。スケジューリング可能な最小単位は 1 ノード（4 つの GPU）となります。 Slurm によって作成されたブロックトポロジは、以下のコマンドで確認できます: $ scontrol show topology BlockName=block01 BlockIndex=0 Nodes=node[0001-0018] BlockSize=18 BlockName=block02 BlockIndex=1 Nodes=node[0019-0036] BlockSize=18 新しい機能を十分に活用し、アプリケーションがトポロジ要件の追加によって恩恵を受けられるジョブを提出するためには、クラスターユーザーはクラスター管理レベルで有効化された --segment 引数付きでジョブを提出する必要があります。NVLINK が 4 つの GPU（1 ノード）間のみで必要である場合は、スケジューラーに対する配置柔軟性を最大化できるため、--segment=1 を使用すべきです。 --segment=18 の使用は推奨されず、代わりに --segment=16 の使用が勧められる可能性があります。これにより、Slurm が排水済みまたはダウンしたノードを含むブロックを使用する機会が増えます。クラスター管理者はまた、ガイドラインから強制へ切り替えることもでき、クラスターのガイドラインを満たさないジョブを拒否することで実現できます。これは、シンプルな [cli_filter/lua](https://slurm.schedmd.com/cli_filter_plugins.html) スクリプトを使用して達成できます： function slurm_cli_pre_submit(options, pack_offset) if options["segment"] == "18" then slurm.log_error("error: using --segment=18 is currently not allowed.") return slurm.ERROR end return slurm.SUCCESS end function slurm_cli_setup_defaults(options, early_pass) return slurm.SUCCESS end function slurm_cli_post_submit(offset, job_id, step_id) return slurm.SUCCESS end $ srun -N18 --segment=18 hostname srun: error: lua: error: using --segment=18 is currently not allowed. srun: error: cli_filter plugin terminated with error ## NVIDIA IMEX の設定方法 ブロックスケジューリングの設定に加えて、同じマルチノード NVLink ドメイン上で実行されるジョブ間のドライバレベルでの分離を確保するために、Slurm 内で [NVIDIA IMEX](https://docs.nvidia.com/multi-node-nvlink-systems/imex-guide/overview.html) サービスが NVLink ネットワークに対して適切に設定されていることを確認することも有益です。 NVLink ドメイン内のノード間で GPU メモリのインポートおよびエクスポートを有効にするには、クラスター内のすべての計算ノードで NVIDIA IMEX サービスを開始する必要があります。IMEX 設定ファイルが静的な場合、推奨されるアプローチは、ブート時に nvidia-imex systemd サービスを単純に開始し、Slurm ジョブ全体を通じて同じサービスインスタンスを維持することです。 各ジョブに対して [IMEX チャネル](https://docs.nvidia.com/multi-node-nvlink-systems/imex-guide/imexchannels.html) の割り当てを Slurm が管理できるようにするためには、Switch/nvidia_imex プラグイン（Slurm 24.05 で導入）を有効にすることが推奨されます。これにより、ジョブ間のドライバレベルでの分離が提供され、誤った干渉を防ぐことができます。プラグインを有効にするには、slurm.conf に以下の単一行を使用します。 SwitchType=switch/nvidia_imex このアプローチでは、IMEX サービスとチャネルの管理に、Slurm のプロローグおよびエピログスクリプト内でカスタムロジックを実装する必要はありません。 ## トポロジー/ブロックアドバンスド機能とは何ですか？ トポロジー/ブロックプラグインの初期リリース後、NVIDIA は Slurm コミュニティと緊密に協力し、トポロジー/ブロックプラグインの動作に対するより多くの制御を提供する新機能を導入してきました。 Slurm 25.05 から、Slurm トポロジファイルに不完全なブロック（定義されたブロックサイズよりノード数が少ないブロック）を宣言できるようになりました。また、プレースホルダーとしてノードが全くないブロックも宣言可能です。これはドメイン内のすべてのノードがまだオンラインになっていないクラスタの初期段階で有用です。Slurm 24.05 以降では、定義されたブロックサイズよりも多くのノードをリストするだけで、ドメイン内に予備ノードを宣言することも可能になりました。 topology.yaml ファイルの導入により、従来のアプローチにおける主要な制約の一つが解消されました：現在では、Slurm クラスタ上で複数のトポロジプラグインを同時に使用でき、各 Slurm パーティションに対して異なるトポロジプラグインを関連付けることが可能になりました。この機能は、トラブルシューティングのためにクラスタ管理者がトポロジ/ブロックプラグインをバイパスする方法を定義するために活用されます。これは、topology.yaml 内で「フラット」なトポロジを定義することで実現されます： - topology: gb200-flat cluster_default: false flat: true 次に、このトポロジを slurm.conf の管理者専用パーティションに関連付けます： PartitionName=admin-flat AllowAccounts=admin Default=NO Nodes=nodes[0001-0036] Hidden=YES Topology=gb200-flat ## セグメントサイズがノードの可用性に与える影響は？ --segment オプションを適切に設定することの重要性を検討するためには、特定のジョブに対する有効なクラスタ容量へのセグメントサイズのインパクトを示す簡易的な数学モデルを使用できます。管理者は、セグメントサイズがノードの可用性にどのように影響するかを理解しておく必要があります。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/usable-cluster-node-capacity-versus-node-unavailability-rate-segment-size.webp)*図 6.** **単一の非常に大きなジョブが --segment を使用している場合の、利用可能なクラスター容量への影響（ノード未利用率λが増加するにつれて）* --segment=9 の影響も観察できます。ノードが 1 つでも未利用になると、ドメインは --segment=9 を使用するジョブに対して 9 ノードしか提供できないため、ノード未利用率λが増加すると期待される利用可能容量は急速に低下します。**一方、--segment=16 の場合**、未利用ノードが 3 つ未満であれば、ドメインは 16 ノードを提供し続けます。 ## ラックスケールアーキテクチャの最適化を始めるには ラックスケールアーキテクチャは AI コンピューティングの未来であり、NVIDIA Blackwell GB200 NVL72 は、技術がより大きなドメインサイズへと向かう中で設計されたこのアプローチの最初の試作です。この新しいパラダイムをサポートするために、ソフトウェアインフラストラクチャも進化させる必要があります。Slurm のトポロジ/ブロックプラグインは基盤を提供し、Slurm コミュニティと協力して、大規模な展開・理解・最適化・運用を容易にするための継続的な取り組みにコミットしています。 ラックスケールオーケストレーションの最適化をお考えですか？Blackwell クラスターでブロックスケジューリングの実装を開始するには、[Slurm topology.yaml ドキュメント](https://slurm.schedmd.com/)および [NVIDIA MNNVL ユーザーガイド](https://docs.nvidia.com/)をご覧ください。

Slurm ブロックスケジューリングによる NVIDIA GB200 NVL72 のシステム・ワークロード効率最大化

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

関連記事

調べる

選ぶ

サイト