はじめに：GPUは常に足りない
AI研究機関Ai2のインフラチームは、数千台のNVIDIA H100、B200、B300 GPUをクラスタ化し、約150名の研究者に提供しています。問題はシンプルです。需要が供給の2〜3倍あります。すべてのGPU時間に対して2〜3のワークロードが競合している計算です。
従来は「優先度ベースのスケジューラ」を使っていました。HIGH優先度を付ければプリエンプション（横取り）から保護される仕組みです。しかしこの方式は予測可能な病理を生みました。
- GPUスクワッティング： 何も実行しないワークロードを置きっぱなしにして、必要時に接続する
- 優先度インフレ： 最終的に100%のワークロードがHIGHになり、下位優先度は飢餓状態に
- オンコール地獄： 保守が必要なホスト上の非プリエンプタブルなワークロードを止めるため、エンジニアが直接交渉
本記事は、Ai2がこの問題を**「スケジューリング」ではなく「予算配分」の問題として再定義**して解決した過程を扱います。根拠資料はHugging Faceブログで確認できます。
核心となるアイデア：スケジュールではなく予算
出発点は「コモンズの悲劇」を認めることでした。チームにGPUを丸ごと与える独占方式は粗すぎました。研究の季節性はチームごとに異なるため、一チームに独占させると、他のチームは遊んでいるGPUを待つことになります。
そこでAi2はGPUそのものではなく「GPU時間」を割り当てることにしました。管理者は投資家のように振る舞います。ワークロードが存在する前に、研究課題ごとにGPU時間をどれだけ出資するかを決めるのです。スケジューラはその情報を使って、到着するワークロードの優先順位を決定します。
[クラスタ全体の容量]
│
┌────┴────┐
Program A Program B
│ │
┌─┴─┐ ┌─┴─┐
A1 A2 B1 B2
35% 25% 20% 20%
ルールは単純です。すべてのGPUリクエストは予算で裏付けられなければならず、そうでなければプリエンプションから保護されません。 以前はHIGH優先度が無料だったため皆が使いましたが、今は何も無料ではありません。スクワッティングはチーム予算の無駄遣いになります。スケジューラを騙す方が、正直に予算を要求するよりも高くつくように設計したのです。
実装の詳細：階層型フェアシェアとタイムスライシング
予算ツールと併せて階層型フェアシェアスケジューラを導入しました。アルゴリズム自体は新しくありません。2009年のHadoop Fair Schedulerに遡り、現在もSLURMのFair TreeやYARNのFair Schedulerが同じ方式を採用しています。新しいのは入力です。ツリーは研究プログラム構造をそのまま反映し、重みは静的クォータではなく管理者が設定する予算です。
スケジューラは直近7日間（デフォルト）の稼働率を追跡し、過少利用の割り当てのワークロードを過剰利用の割り当てより上位に並べます。週単位で見れば、十分な需要を出し続けるチームは割り当てられたGPU時間を受け取れます。
さらに**「スケジューリング契約」を追加しました。ワークロードはクラスタアクセスの対価として最小実行時間（minimum runtime）**を宣言する必要があります。この間はプリエンプションから保護されます。研究者は進捗の保証を得て、スケジューラはその進捗が「積み立て」られた後に再配分する権利を得ます。再開可能なワークロードは自動的に再キューイングされます。
# ワークロード投入の例（概念図）
workload:
name: llm-pretrain-run-42
gpus: 64
min_runtime: 8h # この時間まではプリエンプト不可
resumable: true # チェックポイントから再開可能
budget_owner: program-a/a1
この契約が生んだ最大の副次効果は保守の自動化でした。状態の悪いホストは、ワークロードが最小実行時間に達した瞬間に自動でドレインされます。人手を要する修理は74%減少しました。
注意点とトレードオフ
ただ飯はありません。Ai2もいくつかの罠を踏みました。
- 学習曲線は想定より急でした。 クラスタごとに段階的ロールアウトしたため、初期はクラスタによって挙動が異なり、インターフェースに残った旧用語（'workload priority'など）が混乱を増幅しました。ドキュメントだけでは不十分で、ライブ説明会が有効でした。
- インタラクティブセッションはむしろ悪化しました。 データ分析やコーディング用のセッションは以前は一週間維持できましたが、今は8時間の保護上限を超えるとプリエンプトされます。状態を手動で復元する苦痛は大きいものでした。Ai2はこれを解決するため、CPU専用開発クラスタと復元可能セッションをロードマップに載せています。
- 容量の断片化の可能性。 最小実行時間の保護が、以前はプリエンプタブルで回していたジョブに適用されることで、大規模ワークロードの配置が難しくなる可能性があります。現在シミュレータで再現中です。
実務でこの種のスケジューラを導入するなら、まずシミュレータを作ってください。 Ai2は過去の投入データと仮想シナリオで、待ち時間、プリエンプションイベント、プロジェクト別GPU時間分布を数秒で分析しました。シミュレーション予測（デバッグジョブのp90待ち時間6時間→5分）は実結果（2時間→30秒）より保守的でしたが、方向性は正確でした。関連してAIが生成したコード、そのままデプロイすると起きる災厄とVercelの解決策のようなデプロイ前検証の文化に関する記事も併せてどうぞ。
まとめ：実務適用のためのチェックリスト
Ai2事例の本質は、「スケジューリングの議論」を「予算の議論」へ移したことです。この転換により、30日間のテスト期間中にチームは割り当ての98%を実際に受け取り、稼働率は98%で維持され、デバッグジョブのp90待ち時間は2時間から30秒に短縮されました。
日本国内の環境に適用するなら、以下を検討してください。
- 予算の決定権者を明確に。 Ai2はプロジェクトリード、PI、プログラムマネージャ、CEOへと階層を分けました。国内のSI/研究組織では意思決定ラインが曖昧になりやすく、予算制が「もう一つの政治」になりがちです。
- インタラクティブワークロードを分離する。 学習クラスタでノートブックセッションを動かすと、タイムスライシングポリシーと衝突します。CPU開発クラスタを別に用意するのが安全です。
- 用語を統一する。 旧優先度の概念を残すと、ユーザーは必ず誤解します。
次のステップとしては、Ai2が現在攻略中の**「utilization（稼働率）」**層を調べてみてください。ブートストラップ、チェックポイント、学習アプリケーション自体の効率を高める問題で、スケジューリングに劣らずインパクトが大きいです。類似の大規模マイグレーション事例としてSpotifyが1,800本のパイプラインを6ヶ月で移行した秘訣 HonkエージェントとFleet Managementの実践事例も参考になります。
