全員が「最優先」では、短い確認作業も待たされる

学習ジョブ（学習用の計算作業）で共有GPU（並列計算に使う装置）が埋まっているとき、初期化処理のバグを5分だけ確かめたい開発者は、どうすればよいでしょうか。自分のジョブを「最優先」にしても、他の利用者が同じ指定をしていれば、優先度だけで実行順に差をつけられません。これは本稿の説明用の例です。

GPUは機械学習などの並列計算に使う装置です。ジョブは投入する計算作業、スケジューラはジョブに計算資源を割り当てる仕組みを指します。クラスタは、複数の計算機を連携させた環境です。アレン人工知能研究所（Ai2）が2026年10月9日に公開した運用報告では、旧方式の末期に、スケジュール済みジョブのすべてが最高優先度を指定していました。低い優先度の仕事はGPU時間（GPU台数と利用時間の積）を得られなくなっていたといいます。[3]

旧方式ではジョブが中断を拒否でき、チームごとに保護対象GPUの同時利用上限がありました。短いデバッグの起動待ちを避けるため、何もしないジョブを置き、必要になったら接続する「GPU squatting」も発生していました。[1, 2] GPUを先に確保しておく行動は、共有資源の配分を難しくする可能性があります。

固定配分では、そのチームに仕事がない間はGPUが空き、他のチームが待つという問題が残ります。Ai2が選んだのは、装置の取り分を固定する代わりに、GPUを使う「時間」の予算を組織階層に配分する方式でした。[4]

GPU時間の予算では、利用時間を組織階層に配分する

GPU時間は、使う台数と時間の積です。例えば2台を1時間使えば2 GPU時間になります。Ai2では、研究プログラム、プロジェクト、研究者に至る階層に沿って、管理者がGPU時間の予算比率を決めます。[5] GPU時間の予算比率を決めるのは管理者です。スケジューラは、その比率と利用実績に基づいて配分します。[9]

次は、本稿が設定する配分説明用の仮の例です。同じ親組織の下にあるA・B両チームに、同じ時間予算があるとします。

状況固定のGPU枠時間予算とfair-share（利用実績に応じた公平配分）
Bが仕事を投入していないB専用のGPUが空く場合があるAが空き資源を使える
Aが多く使い、Bが少なく使った後、Bが仕事を投入B専用枠の範囲で起動する予算に対して利用の少ないBの優先順位が高まる（即時起動は保証されない）

fair-shareは、予算と実際の占有時間を比べて、使い足りていないグループを優先する公平配分です。Ai2は既定で直近7日間の利用履歴を使います。[6, 7] このため、同じ時間予算でGPUをA・Bが共有し、片方が使わない間はもう一方が空き資源を使えます。

起動できる時刻は、必要なGPU台数を同時に確保できるか、実行中の仕事を中断できるかにも左右されます。この仕組みは、継続的に十分な需要があるグループへ、一定期間を通じて予算に見合うGPU時間を配分することを目指します。[6] 利用実績は直近7日間の範囲で評価され、起動はその時点の資源状況にも制約されます。

階層型fair-shareにはSlurm Fair TreeやHadoop YARN Fair Schedulerなどの先行例があります。Ai2自身も原理は新しくないと説明しています。[8] 今回の特徴は、研究組織の構造と管理者の時間予算を、その配分に使う点です。Ai2原文のResults節では、ジョブの優先度は引き続き指定でき、チーム内の順序付けに使うと説明されています。

中断契約で、進捗を守りながら資源を返す

公平な順番を決めても、長い学習ジョブが何日もGPUを離さなければ、他のチームへ時間を渡せません。そこでAi2は、ジョブが「意味のある進捗に必要な最小実行時間」と「再開可能か」を申告する契約を導入しました。[10, 11]

予算に計上されるジョブは、申告した時間の間、中断して資源を別の仕事へ渡すプリエンプションから保護されます。保護時間の上限は8時間です。[13] 例えば、開発者がジョブの最小実行時間として10分を申告すると、そのジョブは起動後10分間、中断から保護されます。この10分は本稿の例です。利用者は、実行するジョブごとに申告時間を決めます。

8時間は保護時間の上限です。保護期間が終わっても配分上の優先順位を保っていれば、そのジョブは実行を継続できます。スケジューラは、別のジョブを優先する必要が生じると、対象のジョブを中断できます。再開可能なジョブは、スケジューラが自動で待機キュー（実行待ちジョブの一覧）に戻します。[11, 13]

最小実行時間を0にした「未配分利用」は、チーム予算を消費せず空き時間を使える代わりに、開始時から中断可能です。[12, 14] ここで無料というのは、内部の時間予算に計上しない扱いです。GPUの購入費や電力費は引き続き発生します。保護を得るために何もしないジョブを置けば、自チームの予算を消費します。

再キューは、ジョブを待機キューに戻す処理です。学習を途中から再開するには、モデルの重み（学習で調整した数値）や最適化状態（更新計算に使う内部情報）などを保存するチェックポイントと復元手順が必要です。PyTorchの公式ガイドも、学習再開用の保存対象を説明しています。このガイドは一般的な学習実装を説明する資料です。Ai2の状態保存・復元の仕様は別途確認する必要があります。

待ち時間の改善は、測定対象を分けて読む

Ai2の報告では、実運用のデバッグジョブのp90待ち時間が約2時間から30秒に短縮しました。p90は、観測値の90%がその値以下に収まる水準です。待ち時間の長い側の傾向を読む指標です。旧方式のデバッグはサンプルが少なく、測定のばらつきが大きかった点も明記されています。[16]

別のシミュレーションでは約6時間から約5分という結果でしたが、こちらは過去ログに十分なデバッグがなかったため、手作りのテスト需要を使った推定です。[15] 実運用の「2時間→30秒」とシミュレーションは、異なる母集団の結果として別々に扱います。

また、報告中の二つの「98%」は分母が異なります。

指標98%の意味読み取れないこと
30日間のGPU時間受領率配分枠を1時間ごとの実需要で上限化した「受け取るべきGPU時間」に対する実受領量[18]全チームに、需要の有無を問わず予算全量を渡したという保証
クラスタ占有率（occupancy）利用可能時間のうち、ジョブへ割り当てた割合。導入前後とも98%[19]GPUの計算利用率が98%へ改善したという結果

ジョブがGPUを占有していても、データ待ちなどで演算を十分に行っていない可能性があります。占有率はジョブへの割当時間、利用率（utilization）は実際に使った計算容量の割合を示します。[17] Ai2原文のThe future節では、今後は計算利用率を高めるため、起動処理、チェックポイント、学習処理自体の効率化に取り組むと説明されています。

引用した測定値の評価主体はAi2です。自組織への適用には、環境や投入するジョブの違いを踏まえた検証が必要です。自組織では、短いデバッグと大型学習を分けて比較し、改善の分布を確認する必要があります。

導入判断は、再開できる仕事と失う状態から

時間予算と中断は、利用者の作業方法にも影響します。Ai2では、研究者が計算環境を操作しながら使う対話型セッションの中断により、保存していないメモリ上の状態を失い、手作業の再構築が必要になる場合があります。CPU（中央処理装置）専用の開発クラスタや、別環境へ状態を復元できるセッションは今後の計画です。[20, 21]

大型ジョブに必要なGPUを同時に確保できる空き資源が不足する問題は、Ai2が調査している潜在的な課題です。大型ジョブの起動には、必要なGPU台数と配置を同時に確保する必要があります。保護中のジョブが残っていると、大型ジョブを配置するために多数のジョブを一度に中断できる機会が減る可能性があります。Ai2はこの容量断片化（空きGPUが分散し、大型ジョブに必要な台数を同時に確保しにくくなる状態）を、影響の有無や大きさを調べる潜在的な問題として扱っています。[22]

本稿の整理として、導入前には次の三点を確認したいところです。

  1. 再開可能の申告を、復元試験で確かめる。 モデルの重みだけで十分か、最適化状態や処理済みデータの位置も必要かを確認し、別ノード（クラスタを構成する計算機）で再開する試験を行います。状態保存の所要時間と、失ってよい作業時間も保護時間の判断材料になります。
  2. 短い仕事と大きい仕事を別々に測る。 全体の改善を評価するには、デバッグの待ち時間に加え、最大規模の学習の待ち時間も確認します。必要なGPU台数、待ち時間、中断回数、再開までの時間を仕事の種類ごとに見ます。
  3. 予算と中断理由を利用者に説明できるようにする。 運用担当者は、現在の使用量、比較に用いる履歴期間、保護終了時刻を利用者に示します。7日・8時間はAi2の選択であり、自組織の需要周期と再開コストに合わせて検討する値です。

この事例は、共有GPUの配分に、優先度ラベル、組織が決める時間予算、ジョブが申告する中断・再開条件を組み合わせる設計を示しています。導入時は起動待ちの短縮に加え、失う状態と大型ジョブの配置条件まで評価する必要があります。

一次資料