# GPUクラスタスケジューリング ## 定義 GPUクラスタスケジューリングは、GPU を使う機械学習訓練ジョブに対し、要求 GPU 数、ジョブ長、ユーザー間の公平性、局所性、同居干渉、失敗時の再実行を考慮して、クラスタ上の GPU・CPU・メモリ・ネットワークを割り当てる取り組みである。[[Philly]] の本番トレース分析では、GPU は細粒度共有しにくい一枚岩の資源であり、分散訓練ジョブはギャングスケジューリングを要し、同一サーバ/同一 RDMA ドメインへの局所性が利用率と実行時間に影響する。(Source: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]]) ## 横断的知見 - **クォータ(GPU 本数)による資源予約はアフィニティ保証を提供せず、マルチテナントクラスタで「共有異常」を引き起こす**: [[HiveD]](OSDI 2020)は本番 2,232 GPU クラスタで、クォータ十分なテナントが私有クラスタなら経験しないはずの最大 1,000 分超のキューイング遅延を被る[[共有異常]]を実証した。YARN-CS / Gandiva / Tiresias という設計思想の異なる 3 スケジューラ全てで発生しており、スケジューラの改良だけでは解決できない。解決にはアフィニティ階層ごと予約する[[Virtual Private Cluster]](VC)抽象が必要。(Source: [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees]]) - **「待ち時間を短くする配置」と「長時間ジョブの実行効率を上げる配置」は衝突する**: [[Philly]] は局所性制約を待った後に緩和することでキューイングを抑えるが、Jeon 2019 は分散配置と同居干渉により 16 GPU ジョブの利用率が 2 サーバ 43.66% から 8 サーバ 28.56% へ落ちると示す。一方、後続の [[LLM分散学習]] 系ソース(MegaScale/SAKURAONE)は、巨大ジョブほど通信局所性と並列化配置が MFU を左右することを示す。したがって GPU スケジューリングは、短い待ち時間を最適化するだけでなく、ジョブ長と並列化構成を見て局所性を待つ価値を見積もる必要がある。(Source: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **GPU allocation 率はクラスタ効率の代理指標として不足する**: Jeon 2019 は「割り当て済み GPU」の処理サイクル利用率が全ジョブ平均 52.32% に留まると示し、クラスタが埋まっていることと GPU が有効に使われていることを分離する。これは現代 LLM 訓練で MFU が主要指標になる流れと同じ問題意識であり、割り当て率ではなく実効計算利用率を測る必要がある。(Source: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]], [[LLM分散学習]]) - **スケジューリング改善とジョブコード改善は異なる層で GPU 利用率に作用し、互いを代替できない**: Jeon 2019 は局所性制約・ギャングスケジューリング・ジョブ失敗をクラスタ単位の低利用率の根本原因として特定した。一方、[[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]] は同じく Microsoft 社内の DL プラットフォームでも、観点を「個々のジョブのコードロジック」に絞り込むと最多原因がホスト-GPU データ転送の非効率(27.90%)・バッチサイズ不適切(25.64%)・モデルチェックポイント(16.43%)であることを示す。ギャングスケジューリングを改良しても DataLoader の `pin_memory` 設定ミスは残り、逆もしかり——クラスタ側とジョブ側の最適化は直交しており、どちらか一方で他方を自動的に解決することはない。スケジューラ設計は、クラスタ全体の利用率指標に加えて「ジョブのコードレベルの問題を投入前に検出・排除する仕組み」を補完的に備えることで初めてエンドツーエンドの GPU 利用率向上に至る。(Source: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]], [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]]) - **ジョブ所要時間が不明な場合でもアテインドサービス(実行済み資源量)のみで効率的スケジューリングが可能**: [[@2019__NSDI__Tiresias - A GPU Cluster Manager for Distributed Deep Learning|Tiresias]]([[@2019__NSDI__Tiresias - A GPU Cluster Manager for Distributed Deep Learning]])は 2DAS(二次元アテインドサービス)スケジューラにより、GPU 数×経過時間の積を優先度指標として用い、ジョブ長が不明でも YARN-CS 比で平均 JCT 最大 5.5 倍改善を達成した。MLFQ 式の離散化キューでプリエンプションコストを抑制する。これは Jeon 2019 が指摘した「DNN ジョブの実行時間予測困難」という前提に対する運用レベルの解法を示した。(Source: [[@2019__NSDI__Tiresias - A GPU Cluster Manager for Distributed Deep Learning]], [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]]) - **ギャングスケジューリングの配置感度は公平性の古典理論を破壊する**: [[Themis]]([[@2020__NSDI__Themis - Fair and Efficient GPU Cluster Scheduling]])は、ML ジョブがギャングスケジューリングを要し配置に敏感であるという 2 特性が、DRF や LAS の共有インセンティブ・パレート効率性・嫉妬自由性の同時達成を不可能にすることを示した。仕上がり時間公平性(finish-time fairness)を指標とし、部分割り当てオークションを多ラウンド実施することで公平性を既存スケジューラ比 2.25 倍以上改善しつつクラスタ効率も向上した。HiveD の VC 抽象が「配置保証」で共有異常を解く一方、Themis は「公平性メトリクスの再定義+オークション」で同問題に別角度からアプローチしている。(Source: [[@2020__NSDI__Themis - Fair and Efficient GPU Cluster Scheduling]], [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees]]) - **異種混合 GPU クラスタでは GPU 共有が要求 GPU 数を平均 50% 削減するが、CPU 競合が新たなボトルネックになる**: Alibaba PAI の 6,742 GPU 本番トレース([[@2022__NSDI__MLaaS in the Wild - Workload Analysis and Scheduling in Large-Scale Heterogeneous GPU Clusters]])は、インスタンスの中央値 SM 使用率が 0.042 GPU であり粗粒度割り当てでは極端に低い利用率になることを示した。GPU 共有(時分割多重)で必要 GPU 数をピーク 73% 削減する一方、共有に伴う CPU 競合がインスタンス遅延の主因として浮上し、GPU 競合との相関は見られない。Philly の同種 GPU クラスタでは CPU ボトルネックが議論されなかった点と対照的であり、異種混合・推論混在型 MLaaS では CPU/メモリの共有制御が GPU スケジューリングと同等に重要になる。(Source: [[@2022__NSDI__MLaaS in the Wild - Workload Analysis and Scheduling in Large-Scale Heterogeneous GPU Clusters]], [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]]) - **タスクの繰り返し実行は所要時間予測を実用化する**: Alibaba PAI トレースではタスクの 65% が 5 回以上繰り返し実行され、過去の実行時間からの予測誤差が 25% 以内に収まる。この予測を SJF スケジューリングに適用すると FIFO 比で平均完了時間が 63% 短縮する。Tiresias が「ジョブ長不明」前提で 2DAS を設計したのに対し、MLaaS 環境ではタスクの繰り返し性が予測情報を提供するという実用上の重要な差異がある。(Source: [[@2022__NSDI__MLaaS in the Wild - Workload Analysis and Scheduling in Large-Scale Heterogeneous GPU Clusters]], [[@2019__NSDI__Tiresias - A GPU Cluster Manager for Distributed Deep Learning]]) - **異種GPUクラスタでは「ワークロード(モデル)とGPU種別の親和性」がスケジューリングの決定変数になる**: 訓練クラスタを扱う先行研究(Philly/HiveD/Tiresias/Themis/Alibaba PAI)は主に GPU 台数・局所性・公平性を最適化対象とし、GPU 世代の違いはコスト・性能の一次元的な差として扱われがちである。これに対し推論サービングを扱う BOute([[@2026__MLSys__BOute - Cost-Efficient LLM Serving with Heterogeneous LLMs and GPUs via Multi-Objective Bayesian Optimization]])は、モデルサイズ(小/大)とGPU世代(RTX 5090/H100等)の組み合わせによって単位コストあたり性能が非対称に変化すること(小モデルは安価GPUで、大モデルは高性能GPUでそれぞれ1.5〜2倍低いP95レイテンシ)を実証し、この親和性を GP カーネルへの選好重み付け(preference-weighted kernel)として明示的にスケジューリング探索へ組み込む。異種GPUクラスタスケジューリングは「どれだけ資源を割り当てるか」だけでなく「どのワークロードをどの世代のGPUに割り当てるか」を最適化変数として持つべきことを示唆する。(Source: [[@2026__MLSys__BOute - Cost-Efficient LLM Serving with Heterogeneous LLMs and GPUs via Multi-Objective Bayesian Optimization]]) - **推論サービングのスケジューリングは訓練クラスタスケジューリングと異なり「品質」という第2の最適化目標を持つ**: Philly/HiveD/Tiresias/Themis はいずれもジョブ完了時間(JCT)や公平性を単一目的として最適化する。一方 BOute はレイテンシ最小化と応答品質最大化(GSM8K正答率・LLM-as-a-Judgeスコア等)を同時に扱う多目的最適化として定式化し、両者のPareto最適解集合を探索する(qNEHVI獲得関数)。これは推論サービングのGPUスケジューリングが、訓練スケジューリングの延長ではなく、品質制約という独自の軸を持つ問題であることを示す。(Source: [[@2026__MLSys__BOute - Cost-Efficient LLM Serving with Heterogeneous LLMs and GPUs via Multi-Objective Bayesian Optimization]]) - **クラスタスケジューリング研究は GPU 割り当て粒度を所与とするが、ドライバレベルのプーリングはその粒度自体を可変にする**: [[GPUクラスタスケジューリング]] 系のソース(Philly・HiveD・Synergy・Muri・Cassini・SiloD 等)は、局所性・公平性・配置最適化を扱う一方、GPU 1 枚単位の割り当てを前提として構成される。[[@2026__IEEE TPDS__gPooling - An Elastic GPU Resource Management Framework for On-Demand Virtualization in Shared Accelerator Clusters]] はこれらと直接競合するのではなく、Slurm の GRES 機構に弾力的な vGPU/vNPU を挿入することでスケジューラに見える資源粒度そのものを細粒度化し、クラスタスケジューリング層に新しい割り当て単位を提供する立場を取る。gPooling の大学クラスタ本番運用では、この粒度細分化だけでキュー圧力が平均 5.3 倍・待ち時間中央値が 5.4 倍改善しており、スケジューリングポリシーを変えずとも割り当て粒度の変更単独でキュー逼迫を大きく緩和できることを示す。(Source: [[@2026__IEEE TPDS__gPooling - An Elastic GPU Resource Management Framework for On-Demand Virtualization in Shared Accelerator Clusters]], [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees]]) - **アカデミアが積み上げた「配置保証」「公平性オークション」の理論は、Kubernetesネイティブのギャングスケジューリング実装ではAlpha/Betaの時点でほぼ全て将来課題として先送りされている**: [[HiveD]](配置保証のためVirtual Private Cluster抽象)・[[Themis]](配置感度がDRF/LASの公平性理論を破壊すると証明しオークションで対処)は「ギャング全体をどこに置くか」を理論的に厳密化する方向で研究を進めた。対して[[Kubernetes Workload・PodGroup API]]([[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]])は、North Star Visionとして最適配置・デッドロック回避・ワークロードレベルプリエンプション等8要件を明示的に列挙しながら、Beta時点では「同種(homogeneous)なPodGroupなら配置が存在すれば発見できる」という限定的保証しか提供せず、異種PodGroupの最適配置やHiveD/Themis級の公平性機構は範囲外としている。プロダクショングレードのKubernetesコアAPIは「動くビルディングブロック」を先に提供し、高度な保証は後続KEPへ委ねる段階的経路を選んでいる。また同KEPは、Volcano.sh・Kueue・Co-scheduling plugin等「kube-scheduler外で少なくとも4回実装されてきた」ギャングスケジューリングをコアへ吸収する設計判断であり、[[Dynamic Resource Allocation (DRA)]]がデバイスプラグインAPIをコアへ吸収したのと同じパターンの反復である。(Source: [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]], [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees]], [[@2020__NSDI__Themis - Fair and Efficient GPU Cluster Scheduling]]) - **実証研究群(Philly/HiveD/Tiresias/Themis)が「スケジューラ」と呼ぶものは、一般的な計算機インフラの語彙では「スケジューラ」と「オーケストレータ」の機能を併せ持つ**: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 10 MLOpsにおけるインフラとツール]] §10.3.1は、スケジューラを「いつジョブを実行するか」(DAG・優先度付きキュー・ユーザーレベルクオータといった抽象化されたジョブ単位で考える)、オーケストレータを「そのリソースをどこで得るか」(マシン・インスタンス・クラスターといった下位レベルの資源を抽象化して考える)という異なる関心事を持つ層として区別し、Google の Borg を「ジョブが実際に必要とするリソースの値を推定し、使用されないリソースを他のジョブに再利用してリソースの利用率をさらに最適化する高度なスケジューラ」の例として挙げる(引用元は Verma et al., "Large-Scale Cluster Management at Google with Borg," EuroSys '15 — 本 concept が集約する実証研究群とは独立の一次資料)。本 concept が集約する GPU クラスタスケジューリング研究(Philly・HiveD・Tiresias・Themis)は、いずれも「いつ実行するか」(優先度・公平性・ジョブ長予測)と「どこに配置するか」(局所性・アフィニティ)を単一の「スケジューラ」設計として統合的に扱っており、10 章が立てるスケジューラ/オーケストレータの層分離とは異なる粒度で問題を定式化している。GPU クラスタでは通信局所性(§で言う「どこ」)がジョブの実行効率(§で言う「いつ」)に直結するため、この2つの関心事を分離しにくいことが、一般的な計算機インフラの語彙とGPU スケジューリング研究の語彙が食い違う一因と考えられる。(Source: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 10 MLOpsにおけるインフラとツール]] §10.3.1, [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]], [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees]]) - **クラスタスケジューリング研究の局所性(locality)問題意識は、Kubernetes ネイティブな宣言的 API として体系化されつつある**: Philly の局所性制約待ち・HiveD の Virtual Private Cluster によるセル階層予約は、いずれも研究プロトタイプ・大規模クラスタマネージャ独自の実装として局所性を扱ってきた。これに対し [[Kueue]] の[[トポロジ考慮型スケジューリング]](TAS、[[@2024__KEP__KEP-2724 Topology Aware Scheduling]])は、ノードラベルという Kubernetes ネイティブな抽象化の上に、required/preferred の 2 段階要求・多層スライス制約・BalancedPlacement アルゴリズムという具体的な API 群として局所性最適化を実装した。ただし TAS は単一ワークロードの配置制約(required/preferred)に閉じており、HiveD の VC 抽象が扱う「テナント間の階層的な予約保証」までは踏み込んでいない点で、両者は補完関係にある。(Source: [[@2024__KEP__KEP-2724 Topology Aware Scheduling]], [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees]]) - **ノード内トポロジ考慮スケジューリングは、Philly/HiveD等のノード間局所性研究に約2年先行してSC(HPC)コミュニティで確立していた**: [[@2017__SC__Topology-Aware GPU Scheduling for Learning Workloads in Cloud Environments]](SC17)は、単一マシン内のNVLink/PCI-e/ソケット間バスという物理トポロジに対して通信要求グラフをマッピングするアルゴリズムを提案・実測している。Philly(2019)やHiveD(2020)がクラスタスケール(サーバ・ラック単位)の局所性を扱うのに対し、SC17はノード内(GPU-GPU間)の粒度でトポロジを扱う点で対象スケールが異なる。両者は「局所性が性能を左右する」という同じ問題意識を、階層の異なるレベル(ノード内 vs. ノード間)で独立に確立しており、[[トポロジ考慮型スケジューリング]](Kubernetes TAS)はさらに後発でノード間の階層をKubernetesネイティブなAPIとして体系化した——SC17→Philly/HiveD→TASという時系列は、トポロジ考慮の問題意識がHPC単一ノードから徐々にクラスタスケール・宣言的APIへと一般化していった経路を示す。(Source: [[@2017__SC__Topology-Aware GPU Scheduling for Learning Workloads in Cloud Environments]], [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]], [[トポロジ考慮型スケジューリング]]) - **同居干渉の定量化は、クラスタスケールの「共有異常」問題をノード内の粒度でも先取りしていた**: SC17は、通信集約的な小バッチジョブ2つを同居させると単独実行比で最大約30%のスローダウンが生じることを実測し、干渉を効用関数の独立項として扱った。HiveD(2020)が指摘した「クォータ十分でもアフィニティ保証がなければ共有異常が起きる」という問題は、SC17が単一ノード内の同居干渉として先に実証していた現象のクラスタスケール版と見なせる。ただしSC17の対処(効用関数による事前配置回避)は、HiveDのVirtual Private Cluster抽象(階層ごとの事前予約による構造的保証)とは異なり、統計的なプロファイルに基づく最適化にとどまる点で保証の強さが異なる。(Source: [[@2017__SC__Topology-Aware GPU Scheduling for Learning Workloads in Cloud Environments]], [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees]]) - **推論バッチワークロードでは、GPU スライシングによる並列度向上が「スライスあたりの実行時間劣化」を上回るため、静的な GPU 全体割り当てより動的スライシングが有利になる**: Red Hat + Illinois Institute of Technology の産業論文は、NVIDIA MIG を just-in-time で動的スライスする Dynamic Accelerator Slicer(DAS)を Whisper 音声認識バッチジョブに適用し、限定同時実行数(8 ジョブ)を固定した比較実験ではスライス使用によりジョブ完了時間がやや悪化する(平均 14→17 分、GPU 利用率 45%→19%)ことを確認しつつ、DAS を用いて実際に並列実行ジョブ数を GPU 数(8)からスライス数(25)へ増やした全データセット実験では、平均ジョブ完了時間が 28→18 分(36% 削減)に改善したことを示した。これは、[[gPooling]] が示した「弾力的な sub-GPU 粒度の導入だけでキュー圧力が大幅に緩和する」という知見の、MIG ベース実装かつバッチ ASR 推論ワークロードでの別事例であり、粒度細分化の効果が学習ワークロードだけでなく推論バッチワークロードにも及ぶことを示す。(Source: [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]], [[@2026__IEEE TPDS__gPooling - An Elastic GPU Resource Management Framework for On-Demand Virtualization in Shared Accelerator Clusters]]) - **MIG スライス割当の「スライスパディング」により、粒度細分化は GPU 利用率の単調増加をもたらすとは限らない**: 同論文は、DAS 使用時に Tensor Core 利用率・DRAM アクティビティが約 3 倍に向上した一方、平均 GPU 利用率はわずかに低下した(44%→38%)と報告する。これは特定のスライス割当パターン(例: 2 つの `3g.20gb` プロファイルを単一 A100 GPU にスケジュール)で残余キャパシティが割当不能になり、一部の Streaming Multiprocessor がアイドルのまま残る現象に起因する。粒度細分化(gPooling・DAS のような sub-GPU 割当)は待ち時間・並列度の面では明確に有利だが、GPU 利用率という単一指標だけでは細分化の効果を正しく評価できない可能性を示唆する。(Source: [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]]) - **大規模訓練(Hero jobs)の障害復旧において、再キュー遅延の排除と優先度ブーストはMTTR短縮の不可欠な柱となる**: 数千GPU規模の分散学習では、ハードウェア故障・ノード障害による中断が不可避である。Slurm 25.11([[@2026__GTC__Orchestrate Next-Generation AI Workloads With Open-Source Slurm]])で導入された Expedited Requeue(`--requeue=expedite`)は、従来の120秒再試行遅延を排除し、ノード障害またはジョブ+Epilog失敗時に最上位優先度 `EXPEDITING` へ遷移して即座に代替ノードの再割当を行う。これは、チェックポイント/リストア機構だけでなく、スケジューラ側の再試行プロトコルが訓練ジョブの有効計算時間(Goodput)に直接的な影響を与えることを示している。(Source: [[@2026__GTC__Orchestrate Next-Generation AI Workloads With Open-Source Slurm]]) ## 未解決の問い - SC17のノード内トポロジ考慮アルゴリズム(効用関数ベースのグラフマッピング)は、Philly/HiveD等のノード間局所性(サーバ・ラック単位)と統合的に扱えるか。単一の階層(GPU内リンク→ノード→ラック→ブロック)として一貫したグラフマッピングを構成する設計はあり得るか。 - 10 章のスケジューラ/オーケストレータの層分離を GPU クラスタスケジューリング研究に厳密に当てはめると、Philly・HiveD・Tiresias・Themis の各設計のどの部分がスケジューラ層でどの部分がオーケストレータ層に相当するか。両者を明示的に分離した設計と統合した設計とで、公平性・局所性のトレードオフはどう変わるか。 - gPooling が示す「弾力的な sub-GPU 粒度の導入だけでキュー圧力が大幅に緩和する」という結果は、[[HiveD]] の VC 抽象や [[Themis]] の公平性オークションのような既存スケジューリングポリシーと組み合わせたとき、相加的に効くか、それとも粒度細分化がスケジューリングポリシーの必要性自体を弱めるか。 - [[HiveD]] の VC 抽象はノード・ラックレベルのセル階層を扱うが、LLM 訓練の DP/TP/PP 3 次元並列化が要求する「IB ドメイン内 PP ステージ」「ラック内 TP グループ」などの複合トポロジ制約を表現するには VC をどう拡張すべきか。 - Jeon 2019 の 2017 年 DNN 訓練トレースで見えた断片化待ち・同居干渉・失敗ジョブの GPU 時間浪費は、現代の Transformer/LLM 訓練クラスタでもどこまで再現するか。 - マルチテナント公平性と、長時間・大規模ジョブの局所性確保を同時に満たすスケジューラは、ジョブ長や収束進捗をどこまで予測すべきか。 - DAS(Dynamic Accelerator Slicer)のような動的 MIG スライシングと Kueue のようなキューイングスケジューラの統合(2026 年時点で開発中)が完成した後、「スライスパディング」による GPU 利用率低下は quota 設計やスライスプロファイル選択でどこまで緩和できるか。(Source: [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]]) - 事前の単一 GPU/小規模プール実行で捕まえられるユーザーエラーを、どの段階で本番スケジューラから分離すべきか。 - スケジューラは投入前にジョブのコード品質をどこまで検証すべきか。静的解析(DataLoader 設定・バッチサイズ・チェックポイント方式のチェック)をアドミッションコントロールに組み込む設計は、運用コストと効果のトレードオフとしてどう評価されるか([[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]] が提起する「コードアドバイザー」方向)。 - クラスタ利用率目標(割り当て率ではなく SM Activity などの実効利用率)をスケジューリングの最適化目標に組み込んだとき、ジョブの局所性・公平性・スループットとの間でどう優先度を設定するか。 - Alibaba PAI では CPU 競合がインスタンス遅延の主因だが、CPU 割り当てを GPU と連動制御するスケジューラ設計はまだ確立されていない。異種 GPU + CPU 共有の最適な資源抽象はどうあるべきか。 - MLaaS トレースの繰り返しタスク比率(65%)は 2020 年収集。LLM 推論が台頭した現在の MLaaS でも同程度の繰り返し性があるか、それともプロンプトの多様性で予測可能性は低下しているか。 - BOute のモデル-GPU親和性(preference-weighted kernel)は Llama・Qwen3・DeepSeek-distill という transformer decoder系モデルで検証されている。MoE モデルや将来のハードウェア世代(B100等)でも同様の親和性パターン(小モデル→安価GPU、大モデル→高性能GPU)が成立し続けるか、あるいはモデルアーキテクチャの多様化とともにより複雑な非線形の親和性関数が必要になるか。 - 訓練クラスタスケジューリング(Philly/HiveD/Tiresias/Themis)が培ってきた公平性・局所性保証の枠組みは、BOute のような品質制約付き多目的推論スケジューリングにどこまで転用できるか。特に複数テナントが異なる品質要件を持つ場合、Themis の finish-time fairness のような指標は「レイテンシ」と「品質」の2軸でどう再定義すべきか。 - [[Kubernetes Workload・PodGroup API]] のBeta実装(Workload Scheduling Cycle)が同種PodGroupに限定して提供する配置発見保証は、[[HiveD]] のVirtual Private Cluster抽象や[[Themis]]の公平性オークションと将来どう統合され得るか。Kubernetesコアが今後どこまでこれらアカデミアの理論を追いかけるか、それともKueue/Volcano.sh等のエコシステム側に委ね続けるかは本KEPでは明示されていない。 - [[LeaderWorkerSet]] の [[@2025__KEP__KEP-407 Gang Scheduling (LeaderWorkerSet)]] が採る「ワークロードコントローラ側でPodGroup実装をプラガブルに切り替える」設計と、[[Kubernetes Workload・PodGroup API]] が目指す「kube-schedulerコア側でPodGroup APIを標準化する」設計は、Philly/HiveD/Themisが積み上げた配置保証・公平性理論の受け皿としてそれぞれどこまで有効か。詳細は [[Kubernetes Workload・PodGroup API]] の横断的知見を参照。 - Expedited Requeue のような即時・最上位優先度での再スケジュール機構をマルチテナント環境で運用する際、プリエンプション機構と組み合わせた場合に生じる「他ジョブのカスケード中断(カスケードプリエンプション)」の blast radius はどのように抑制すべきか。 ## 関連 - ソース: [[@2017__SC__Topology-Aware GPU Scheduling for Learning Workloads in Cloud Environments]] / [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]] / [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees]] / [[@2019__NSDI__Tiresias - A GPU Cluster Manager for Distributed Deep Learning]] / [[@2020__NSDI__Themis - Fair and Efficient GPU Cluster Scheduling]] / [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]] / [[@2022__NSDI__MLaaS in the Wild - Workload Analysis and Scheduling in Large-Scale Heterogeneous GPU Clusters]] / [[@2026__MLSys__BOute - Cost-Efficient LLM Serving with Heterogeneous LLMs and GPUs via Multi-Objective Bayesian Optimization]] / [[@2026__IEEE TPDS__gPooling - An Elastic GPU Resource Management Framework for On-Demand Virtualization in Shared Accelerator Clusters]] / [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 10 MLOpsにおけるインフラとツール]](スケジューラ対オーケストレータの一般的語彙、Borgへの言及) / [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]] / [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]] - エンティティ: [[Philly]] / [[philly-traces]] / [[Microsoft]] / [[HiveD]] / [[Hanyu Zhao]] / [[Yanjie Gao]] / [[Qizhen Weng]] / [[Alibaba PAI]] / [[Alibaba GPU Cluster Trace]] / [[gPooling]] / [[Kubernetes]] / [[Marcelo Amaral]] / [[Barcelona Supercomputing Center]] / [[Dynamic Accelerator Slicer]] / [[Red Hat]] - 概念: [[GPUクラスタ運用]] / [[LLM分散学習]] / [[並列化戦略]] / [[ストラグラー]] / [[Virtual Private Cluster]] / [[共有異常]] / [[LLMサービング管理]] / [[ベイズ最適化]] / [[GPUプーリング]] / [[Kubernetes Workload・PodGroup API]] / [[Dynamic Resource Allocation (DRA)]] / [[トポロジ考慮型スケジューリング]] / [[コンテナオーケストレーション]] - 関連 MOC: [[分散深層学習 - MOC]] / [[HPC - MOC]] - 追記: [[@2025__KEP__KEP-407 Gang Scheduling (LeaderWorkerSet)]] / [[LeaderWorkerSet]] ## 出典 - [[@2017__SC__Topology-Aware GPU Scheduling for Learning Workloads in Cloud Environments]](§3 Pack vs. Spread実測と同居干渉、§4 TOPO-AWARE/TOPO-AWARE-Pアルゴリズムと効用関数、§5 プロトタイプ・大規模シミュレーション評価) - [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]](§2 Philly, §3 Impact of Locality Awareness, §4 Training Progress and Completion, §5 Design Implications) - [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees]](§2 Background, §3 HiveD Design, §5 Evaluation) - [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]](§3 分類体系: 4 次元 15 カテゴリ, §4 代表的修正と効果, §5 研究方向の提案) - [[@2022__NSDI__MLaaS in the Wild - Workload Analysis and Scheduling in Large-Scale Heterogeneous GPU Clusters]](6,742 GPU 異種混合クラスタの 2 か月トレース、GPU 共有、CPU ボトルネック、タスク繰り返しと SJF) - [[@2026__MLSys__BOute - Cost-Efficient LLM Serving with Heterogeneous LLMs and GPUs via Multi-Objective Bayesian Optimization]](異種モデル×異種GPUの親和性を活用した多目的ベイズ最適化スケジューリング、既存手法比コスト15〜61%削減) - [[@2026__IEEE TPDS__gPooling - An Elastic GPU Resource Management Framework for On-Demand Virtualization in Shared Accelerator Clusters]](§VI 関連研究: Synergy/Muri/Cassini/SiloD/Philly/HiveD との位置づけ、本番運用でのキュー圧力5.3倍・待ち時間5.4倍改善) - [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 10 MLOpsにおけるインフラとツール]](§10.3.1 cron・スケジューラー・オーケストレーターの区別、Borgへの言及) - [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]](KubernetesネイティブのギャングスケジューリングAPI。Workload/PodGroup分離設計、North Star Vision、Alpha/Betaの実装範囲)