# 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]]) ## 未解決の問い - [[HiveD]] の VC 抽象はノード・ラックレベルのセル階層を扱うが、LLM 訓練の DP/TP/PP 3 次元並列化が要求する「IB ドメイン内 PP ステージ」「ラック内 TP グループ」などの複合トポロジ制約を表現するには VC をどう拡張すべきか。 - Jeon 2019 の 2017 年 DNN 訓練トレースで見えた断片化待ち・同居干渉・失敗ジョブの GPU 時間浪費は、現代の Transformer/LLM 訓練クラスタでもどこまで再現するか。 - マルチテナント公平性と、長時間・大規模ジョブの局所性確保を同時に満たすスケジューラは、ジョブ長や収束進捗をどこまで予測すべきか。 - 事前の単一 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 でも同程度の繰り返し性があるか、それともプロンプトの多様性で予測可能性は低下しているか。 ## 関連 - ソース: [[@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]] - エンティティ: [[Philly]] / [[philly-traces]] / [[Microsoft]] / [[HiveD]] / [[Hanyu Zhao]] / [[Yanjie Gao]] / [[Qizhen Weng]] / [[Alibaba PAI]] / [[Alibaba GPU Cluster Trace]] - 概念: [[GPUクラスタ運用]] / [[LLM分散学習]] / [[並列化戦略]] / [[ストラグラー]] / [[Virtual Private Cluster]] / [[共有異常]] - 関連 MOC: [[分散深層学習 - MOC]] / [[HPC - MOC]] ## 出典 - [[@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)