# Orchestrate Next-Generation AI Workloads With Open-Source Slurm ## 概要 NVIDIA GTC 2026 のセッション S82420 において、SchedMD のリーダーシップ(Tim Wickberg, Danny Auble)により発表されたスライド資料である。SchedMD の NVIDIA 傘下入りとオープンソース継続のコミットメントを表明した上で、次世代 AI ワークロード向けの大規模トポロジ最適化(`topology/block`)、障害復帰高速化(Expedited Requeue)、および Kubernetes との双方向連携ツールキット `Slinky`(Slurm Operator と Slurm Bridge)のアーキテクチャと最新機能を網羅的に解説している。 ## 主要メッセージ - **SchedMD の NVIDIA 参入と OSS コミットメント (p.3-5)**: SchedMD は NVIDIA の一部となったが、Slurm と Slinky は完全なオープンソースとして開発が継続される。従来の Bugzilla ベースのパッチ提出から GitHub(`https://github.com/SchedMD/slurm`)での PR・Issue ボード受付へ移行し、コミュニティ開発の透明性を高めた。 - **多層インターコネクト向けの高度なトポロジ計画 (p.7-12)**: NVL72(ラック内 NVLink 72 GPU ドメイン、ラック間 NDR InfiniBand)のような多層ネットワークにおいて、通信局所性を保つ `topology/block` プラグインが提供される。`--segment`(最適ノード群の指定)、`--spread-segments`、`--consolidate-segments`、`--exclusive=block`(ブロック単位の占有)により通信帯域を保証する。また、パーティションごとに異なるトポロジを定義できる `topology.yaml` 形式への移行や、`topology/ring`・`topology/torus3d` プラグイン(Slurm 26.11 予定)が予告されている。 - **トポロジ自動検出ツール NVIDIA Topograph (p.13)**: クラウドやベアメタル InfiniBand のトポロジを自動検出し、Slurm の `topology.conf` / `topology.yaml` や Kubernetes のノードラベルとして出力するオープンソースツール(`https://github.com/NVIDIA/topograph`)が公開されている。 - **大規模訓練向け Expedited Requeue (p.14-16)**: コンピュートノード障害が発生しやすい大規模 AI 訓練(Hero jobs)において、従来の 120 秒再キュー遅延を撤廃。`SlurmctldParameters=enable_expedited_requeue` と `--requeue=expedite` により、ノード障害またはジョブスクリプト+Epilog 失敗時に最上位の `EXPEDITING` 状態へ遷移し、代替ノードが揃い次第即座に再起動される。 - **階層型リソース管理 (p.17)**: 従来のフラットなライセンス管理から、インターコネクトオフロードや PDU・ラック・列・DC 単位の電力キャッピング(Mode 3: 階層集約)を表現可能な階層型リソースモデルへ拡張。 - **可観測性の強化と SLUID (p.18)**: `slurmctld` からの OpenMetrics (Prometheus) 直接出力、Kafka 連携のジョブ開始時通知拡張、および再キュー時にも重複しない辞書順ソート可能な一意 ID である `SLUID`(Slurm Lexicographically-sortable Unique ID)が導入された(Slurm 25.11)。 - **Slinky による Kubernetes 統合 (p.20-29)**: Slinky ツールキットは、Kubernetes 上で Slurm クラスタを Pod として運用・自動スケールさせる **Slurm Operator** と、Kubernetes の Scheduling Framework(PreEnqueue, PreFilter, Filter, PostFilter, PreBind)および DRA(Dynamic Resource Allocation)と統合して Slurm を Kubernetes の第 1 級スケジューラとして動作させる **Slurm Bridge** から構成される。 ## 視覚的に重要な図表 **p.7 NVLink ドメインとジョブ配置のトポロジ計画** ![[_attachments/Slurm_GTC_2026/page-007.png]] Slurm Login Node に投入された User 1(10ノード)と User 2(8ノード)のマルチノードジョブが、同一 NVLink 72 ドメイン内の個別の IMEX Domain(IMEX Service 境界)へ整合して割り当てられる配置構造を示す。 **p.9 NVIDIA Vera Rubin NVL72 単一ラックレイアウト** ![[_attachments/Slurm_GTC_2026/page-009.png]] 1 ラックあたり 18 基のコンピュートトレイ(上部10、下部8。1トレイ4 GPU = 計72 GPU)と、中央の 9 基の NVLink Switch トレイ(各トレイ 72 ポートの NVLink Switch 2基)が 1,296 本のインターコネクトで全結合される物理構成を示す。 **p.10 topology.conf のブロック定義と階層ネットワーク木** ![[_attachments/Slurm_GTC_2026/page-010.png]] `BlockName=block1 Nodes=node[01-04]` などのブロック定義と、Spine 1 から ibleaf 1・2 を経由して各 4 ノードのブロックおよび下位 NVLink(NVL)レイヤへと至る木構造の対応関係を示す。 **p.20 Slinky ツールキットのコンセプト** ![[_attachments/Slurm_GTC_2026/page-020.png]] Slurm と Kubernetes を融合した Slinky の構成要素(Slurm Operator、Slurm Bridge、Go 製 REST API クライアント、コンテナイメージ)を示す。 **p.27 Slurm Bridge の技術アーキテクチャ** ![[_attachments/Slurm_GTC_2026/page-027.png]] Kubernetes Scheduling Framework の拡張ポイントと DRA ResourceClaims の生成、および Pod 要件をバッチスクリプト不要の Slurm「外部ジョブ(external job)」として変換・スケジューリングする機構を示す。 ## 概念・実体への接続 - [[Slurm]]: SchedMD の NVIDIA 傘下入りに伴う OSS 体制の刷新、25.11 / 26.05 / 26.11 ロードマップ。 - [[SchedMD]]: 開発元組織のステータス変化とエンタープライズサポート提供体制。 - [[NVIDIA]]: GB300 NVL72 / Vera Rubin NVL72 アーキテクチャおよび Topograph。 - [[Slinky]]: Kubernetes と Slurm の統合ツールキット(Slurm Operator, Slurm Bridge)。 - [[トポロジ考慮型スケジューリング]]: Slurm の `topology/block` プラグイン、`topology.yaml`、および Slinky における Pod トポロジ連携。 - [[GPUクラスタスケジューリング]]: 大規模 AI 訓練ジョブ(Hero jobs)の耐障害性向上(Expedited Requeue)およびバックフィル・フェアシェアの K8s 拡張。 - [[Dynamic Resource Allocation (DRA)]]: Slurm Bridge が Kubernetes の DRA GPU/CPU ドライバに対して ResourceClaims を発行する連携機構。 ## 限界・不確実点 - 提供された動画 URL (`https://www.nvidia.com/en-us/on-demand/session/gtc26-s82420/`) は認証・ポータル保護のため自動文字起こし(yt-dlp/whisper)を実行できず、本ノートはスライド画像および PDF 抽出テキストに基づいている。 - p.28 の「Bridge Demo」はスライド上プレースホルダーのみであり、デモの具象画面は動画本体でのみ確認可能である。