ML Cluster Orchestration（ML クラスタオーケストレーション）

ML クラスタオーケストレーションは分散学習 (tech-48) や推論を GPU クラスタ (tech-71) 上で「いつ・どこに・どのトポロジで」起動するかを決める層で、汎用 K8s の fit→score→bind では扱えない。本稿は Gang Scheduling・トポロジ認識・MIG/MPS・弾性学習・Slurm/K8s 収斂・ML プラットフォーム・観測性・10 アンチパターン・フロンティアを整理。バージョン/GA は訓練データ (~2025-08) 依存で [VERIFY] や「確認時点 2026-05 未確認」で分離、confidence: medium 固定。コンテナ層 tech-66、マネージド tech-74。

なぜ ML スケジューラは汎用 K8s と違うのか

汎用 K8s は Pod を独立に逐次 bind するが ML は不適合: (1) Gang = AllReduce は全 Pod 同時 Running でないと partial-pod deadlock。(2) トポロジ依存 = NVLink ≫ PCIe ≫ IB ≫ Ethernet、island 内で MFU 変動 ([VERIFY])。(3) 粒度 = MIG/MPS/Time-slicing が独立トレードオフ。(4) フェアネス = FIFO は不公平、DRF/階層キュー必要。(5) 学習+推論混在 = PriorityClass + preemption + checkpoint。代表論文: Gandiva (OSDI 2018)・Tiresias (NSDI 2019)・Themis (NSDI 2020)・Pollux (OSDI 2021、arXiv:2008.12260 [VERIFY])。

Gang Scheduling とキュー公平性

Volcano (CNCF Incubating、Huawei) は K8s 拡張スケジューラ + CRD (PodGroup/Queue/Job)。minAvailable まで保留し原子的 bind、アクション allocate/backfill/preempt/reclaim、階層キュー capability/deserved (DRF)、TFJob/PyTorchJob/RayJob をプラグインでカバー。1.10 [VERIFY]、Kueue 統合強化 [VERIFY]。独自 CRD のため Kubeflow Training Operator と二重管理になりやすい。

Kueue (SIG Scheduling、Google) は K8s 上位の workload admission controller。既存 (batch/Job, JobSet, RayJob, MPIJob) をラップし ClusterQueue/LocalQueue 2 層で admission 制御、スケジューラは変えない。Gang は JobSet + Kueue の all-or-nothing、v0.6+ で PodGroup 相当を JobSet 経由提供 [VERIFY]。Cohort で未使用枠借用の soft-fairness。Kueue v0.9 [VERIFY] → v1.0 GA は確認時点 2026-05 未確認。Kueue + Volcano 統合アーキ議論 [VERIFY: KEP 番号]。

YuniKorn (Apache、YARN 系譜) は階層キュー + preemption、1.5 [VERIFY]、Spark/Flink 中心。KAI Scheduler (NVIDIA、旧 Run:AI OSS) は買収 (2024 [VERIFY]) 後 OSS 化、time-slicing/MIG/MPS とキュー管理統合 [VERIFY]、NVLink island 内 gang bind + bin-packing。DRF (Ghodsi, NSDI 2011) は支配リソースのマックスミンで Volcano Queue / Kueue ClusterQueue が変形採用。

トポロジー認識配置

帯域階層: (1) NVLink island / NVSwitch domain = 同一 NVSwitch GPU 群 (H100 SXM5 8GPU、GB200 NVL72 単一)、NVLink 4 = 900 GB/s/GPU 双方向 (tech-71)。(2) IB/RoCE rail = HDR 200 → NDR 400 Gb/s ([VERIFY])、rail-optimized。(3) Rack/spine。K8s Topology Manager が CPU/NUMA/PCI alignment、NVIDIA GFD が nvidia.com/gpu.topology ラベルで nodeAffinity を可能化。Volcano/KAI の topology-aware scoring は PodGroup を同一 NVSwitch domain へ詰める。KEP-3521 Pod Scheduling Readiness [VERIFY] は schedulingGates で topology チェック完了まで Pending 化。GB200 NVL72: 単一 NVLink domain で 72 未満ジョブの domain 分割が課題、スケジューラ対応は確認時点 2026-05 未確認。MIG-aware では nvidia.com/mig-1g.10gb 系を付与。

リソース共有 — MIG / MPS / Time-slicing

MIG (A100/H100) は GPU HW 分割、A100 80GB で最大 7 instance、H100 80GB 最大数 [VERIFY]、K8s nvidia.com/mig-*。MPS は複数プロセスが 1 GPU context 共有、クラッシュ波及リスク。Time-slicing は GPU Operator v1.x+、リアルタイム推論に不向き。GPU Operator (v24.x [VERIFY]) は Driver/DCGM Exporter/GFD/MIG/MPS Manager を DaemonSet 管理、Network Operator で RDMA/GPUDirect も自動 provisioning。MIG profile はノード間で揃えないと drift (アンチパターン 2)。

弾性学習と障害耐性

torchrun --rdzv_backend=c10d は PyTorch Elastic、min_nodes/max_nodes で worker 増減、故障時に残りで継続。Pollux (OSDI 2021、arXiv:2008.12260 [VERIFY]) は資源 + バッチ/学習率を共同最適化しグッドプット最大化。KubeRay + RayTrain は K8s オートスケールで Actor 障害を自動リカバリ。NCCL hang は 1 ノード timeout が全 worker 無限待機を招く典型、PyTorch DDP は既定 30 分 [VERIFY] のタイムアウトで ProcessGroup 破壊 (NCCL Watchdog)。NeMo Fault Tolerance [VERIFY] は周期 checkpoint + 再起動。RTO ≈ $T$ + 置換 + 復元、$T = 15$–$30$ 分 [VERIFY]。Hot-spare pool で故障ノード即時交換 (Slurm spare partition)。

Slurm vs Kubernetes — 収斂と Slinky

Slurm の強み: MPI gang・checkpoint・preemption・fair-share、--gres=gpu:h100:8 + GPUDirect RDMA、sbatch --array。23.11/24.05 [VERIFY] が 2024–2025 系。K8s-native は OCI 再現性・Karpenter スポット・KServe/TorchServe 同居・Argo Workflows GitOps。

Slinky (Slurm on Kubernetes、SchedMD 2024 [VERIFY]) は Slurm スケジューラを K8s Pod として動かすハイブリッド。Slurm 移行コスト削減 + MPI/gang + コンテナ統合が動機。GA は確認時点 2026-05 未確認。

ML プラットフォームオーバーレイ

KubeRay (CNCF Sandbox 2023 [VERIFY]) は RayCluster/RayJob/RayService を CRD 管理、autoscaler が worker を増減し RayTrain/RayServe を抽象化、v1.1+ で Kueue 対応 [VERIFY]。Kubeflow Training Operator は TFJob/PyTorchJob/XGBoostJob/MPIJob を CRD 管理 (v1.7 [VERIFY])、v2 は JobSet API 移行予定 [VERIFY]、schedulerName: volcano で Volcano gang。Determined AI (HPE) は実験管理 + 分散学習 + Adaptive ASHA (0.28.x [VERIFY])。Run:AI → NVAIE: NVIDIA 2024 買収 [VERIFY]、Dynamic GPU Fractions・階層キュー・scheduler plugin を NVAIE 統合、KAI Scheduler OSS 化 [VERIFY]。SageMaker HyperPod (AWS) は Slurm/EKS 選択可のマネージドで自動健全性・自動置換・RDMA/EFA (2024 GA [VERIFY])。GKE Autopilot for AI は H100/TPU 自動スケール + DWS スポット予約 [VERIFY]。AKS + KAITO は LLM operator [VERIFY]。tech-74。

観測性 — DCGM・MFU・straggler 検出

DCGM (NVIDIA 公式メトリクスデーモン) は DCGM Exporter で DCGM_FI_DEV_GPU_UTIL/MEM_COPY_UTIL/NVLINK_BANDWIDTH_TOTAL 等を Prometheus expose、DCGM 3.x [VERIFY] が GPU Operator 同梱。dcgmi health -g <group> -c で PCIe/NVLink/ECC を検出。MFU = 実 FLOP/s ÷ 理論ピーク、H100 SXM5 BF16 ピーク 989 TFLOP/s [VERIFY]、大規模 LLM 学習で 35–55% 目標 [VERIFY]、低 MFU はデータローディング/通信/straggler 要因 (PaLM Chowdhery 2022)。Straggler は GPU clock throttling・NIC 障害・ECC 修正が原因、同期 AllReduce で最遅ノードがバリア、step time 標準偏差で検出。NCCL_DEBUG=INFO + NCCL_ALGO=Ring で遅延可視化 [VERIFY]、nccl-tests で帯域検証。推奨: DCGM Exporter + kube-prometheus-stack + Grafana。

落とし穴 — 頻発する 10 の失敗モード

1. [Critical] デフォルト K8s で多ノード学習 → partial-pod deadlock。対策: gang (Volcano PodGroup / Kueue + JobSet)。
2. [High] MIG profile のノード間 drift → 要求 GPU 不在。対策: GPU Operator MIG Manager + GitOps。
3. [High] topology-aware なし AllReduce → NVLink island またぎで IB 律速。対策: nodeAffinity + topology label。
4. [High] checkpoint なし/低頻度 → 故障で数時間〜数日の学習消失。対策: 15–30 分 + S3/GCS 非同期保存。
5. [Medium] NCCL タイムアウト既定依存 → 大規模で legitimate バリア待ちが 30 分超 [VERIFY]。対策: NCCL_TIMEOUT/init_process_group(timeout=...)。
6. [Medium] 学習・推論の PriorityClass 未設定 → SLA 違反か学習圧迫。対策: PriorityClass + preemptionPolicy。
7. [Medium] spot で checkpoint 未考慮 → 即中断。対策: checkpoint-restart + restartPolicy: OnFailure。
8. [Medium] GPU リソースリーク OOM ループ → CUDA context 未解放で OOM 再起動。対策: nvidia-smi 残留確認、終了フックで cleanup [VERIFY]。
9. [Low] 単一グローバルキューに全投入 → HPO sweep と事前学習が競合。対策: 用途別 Queue + quota。
10. [Low] observability なし → straggler/ECC 累積で劣化。対策: DCGM/Prometheus/Grafana。

2026 フロンティア

Run:AI → NVAIE: 買収 [VERIFY: 2024 前半] 後統合、KAI Scheduler OSS 化 [VERIFY]、NVIDIA Mission Control は名称・GA とも確認時点 2026-05 未確認。Slinky GA: Slurm 24.05+ プロトタイプ [VERIFY]、2026 GA 未確認、NERSC/ANL 等が評価中 [VERIFY]。Kueue v1.0 GA: 2025 年内予定 [VERIFY]、MultiKueue・Provisioning Admission Check (Karpenter/NAP)・改良 preemption [VERIFY]、Volcano 統合 KEP 予定 [VERIFY: KEP 番号]。GB200 NVL72: 72 Blackwell GPU + 36 Grace CPU の NVSwitch single-domain [VERIFY]、NVLink 1.8 TB/s 級 [VERIFY]、72 未満ジョブのフラグメンテーション課題、対応整備中 [VERIFY]。EKS/AKS/GKE: EKS + Karpenter で Kueue + Provisioning Admission Check 自動 provisioning [VERIFY]、AKS + KAITO [VERIFY]、GKE Autopilot DWS で H100/TPU スポット予約 [VERIFY]。

See also

• tech-48 分散学習 — DP/TP/PP/SP-CP/EP
• tech-66 コンテナ化とオーケストレーション — OCI/runc/containerd/K8s
• tech-71 分散コンピュート基盤 — GPU/NVLink/IB/冷却
• tech-74 クラウド ML プラットフォーム — SageMaker/Vertex/Azure ML/Databricks