実際のGPUクラスタには、プール全体を占めるジョブが来ていなかった

GPUクラスタのスケジューリングサイズ優先方式が壊れる条件を、実データで確かめるEnglish

ここで出した数値は撤回済みです

「0.75は暫定的な安全境界」と「実測比0.59では1GPUジョブの7.4倍」は、どちらも引用できません。害の倍率は軸の訂正に伴い7.4倍→16.3倍→5.1倍と2度書き換えられ、境界はプール規模ではなく同時実行ジョブ数で決まるとEP-0006が示しました。そして境界の判定器自体がEP-0011で無効と判明しています。現在の数値はEP-0012（頻度の列を含む運用表）とEP-0013（Phillyの余裕0.33）にあります。 実トレースの測定——11個の仮想クラスタのどれにもプール全体ジョブが来ていない——はEP-0013の再計数で生き残っています。

現在わかっていること

GPUクラスタでは、短いジョブを先に通す「サイズ優先」のスケジューリングが平均待ち時間を下げます。ただし前の研究で、クラスタ全体を占有するような巨大ジョブが混じると、そのジョブだけが永久に順番を取れなくなる（飢餓）ことが分かっていました。その比率は30,000本中15本（0.0005）で十分でした。そこで前の研究は「まずクラスタ全体を要するジョブが来るか確認せよ」という運用上の規則を出しました。

今回、実際の運用トレース2本でその前提を測りました。Phillyが実際にスケジューリングしている11個の仮想クラスタのどれにも、プール全体を占めるジョブは来ていませんでした。 最も大きいジョブでも、そのプールの59%までです。前の研究が警告した条件は、実測データの中に存在しませんでした。

そうなると重要なのは、前の研究が一度も測っていない帯——プールの半分から全体までのジョブ——です。ここを掃いてみると、はっきりした閾値はありません。劣化は連続的で、しかも急です。完全な飢餓が起きるのは、ちょうどプール全体の大きさのときだけでした。実用上の安全側の目安は、最大ジョブがプール容量の0.75までです。実測された最悪値0.59では、そのジョブクラスは飢えません。ただし1GPUジョブの7.4倍遅くなります。

したがって現在の結論は、「クラスタ全体のジョブが来るか」ではなく「最大ジョブがプール容量の何割か」を見ること、そして予想される害は無限の待ちではなく数倍の遅れだ、ということです。害は実在しますが、種類が違います。

前の研究（EP-0003）の運用規則は、この結果を受けて取り下げました。仕組みそのものはモデルの中では変わらず成立しています。狭まったのは、それが当てはまる範囲です。

図で見る

横軸は「最大ジョブが必要とするGPU数 ÷ プール容量」です。左から右へ連続的に悪化し、段差はありません。実測された最悪の仮想クラスタは0.59で、目安の0.75より左にあります。

この研究が示すこと

• この2本の公開トレースでは、1GPUジョブが大半を占め、大きいジョブの裾は薄い。実測した11個のPhilly仮想クラスタのどれにも、プール全体を必要とするジョブは来ていない。
• 64スロットの合成シミュレーションでは、害は「最大ジョブ ÷ プール容量」に沿って連続的に変化し、処理が到着に追いつかなくなる境目は暫定的に0.75にある。

この研究が示さないこと

• 実際の到着列の上でスケジューリング方式を動かしてはいません。トレースから使ったのは需要の形だけです。
• 0.75という目安は、実測プールの規模（217〜603 GPU）ではまだ確かめていません。この2本以外のトレースでも確かめていません。

なぜ重要か

モデルの中で示した仕組みが注目に値するのは、その前提がモデルの外でも成り立つときだけです。前提を確かめずに仕組みだけを公開すると、「クラスタ全体のジョブが来るか確認せよ」という実務的に聞こえる規則が、実測データには含まれない条件に紐づいたまま残ります。読んだ人は、起きない事象に備えることになります。

置き換えた規則は種類が違い、それでも行動に移せます。見るべきは最大ジョブとプール容量の比で、予想される失敗は飢餓ではなく数倍の遅れです。

何を調べたか

1. 実在のGPUクラスタの需要分布は、前の研究の仕組みが要求するジョブクラス（プール全体を占めるジョブ）を含むか。
2. プールの半分から全体までの間に、はっきりした閾値があるのか、それとも連続的な劣化なのか。

方法

E5：需要の形を測る。 Microsoft Philly（cluster_job_log、GPUジョブ112,018本）とAlibaba PAI v2020（10万件標本、82,184本）から、各ジョブが要求するGPU数を取りました。PRED-004として、SHA-256 7ef0f5b21d46318e6008a1be3021e9c1ffbefbe3fb23e959c3cffa7268048cbe で封印しています。封印とは、結果を見る前に予測文と判定基準を確定し、ハッシュで固定することです。

Phillyは仮想クラスタ単位でスケジューリングします。そこで仮想クラスタごとの同時GPU使用数のピークを取れば、プール容量を仮定ではなく実測できます。ピーク同時使用は容量の下界なので、本当の割当枠がもっと大きければ比はさらに小さくなります。結論はこの向きには頑健です。

E6：誰も測っていない帯を掃く。 小さいジョブの背景群に、m 個のGPUを要求する大きいジョブのクラスを1つ加え、確率0.002で到着させます。m をN/2からNまで動かします。N = 64、rho 0.7と0.85、シード5本、全セルで120,000ジョブ分の観測長を確認しました。計463回の実行です。PRED-005として、SHA-256 fe3e27d68d27c5c8eb9fb6633d133e17fd6c4ba09158ab80d901dc4630ccb902 で封印しています。

ServerFillingは2のべき乗を要求するアルゴリズムなので、m ∈ {32, 64} でのみ実行しました。他のサイズで数字を出すのはアルゴリズムの誤用になります。

どちらの封印も、対応する結果ファイルが存在しない状態でコミットしました。

結果

需要の形。 どちらのトレースも1GPUジョブが支配的で、大きいジョブの裾は薄いです。

仮想的な64 GPUプールを想定すれば、PAIの0.00164は前の研究の閾値の3.3倍で、封印した予測は当たりました。しかし封印の後で足した測定のほうが、問いにはずっと直接答えていました。

実測されたプールに、プールを占め切るジョブは来ていません。

11cb48だけが、プールの半分から全体までの帯に入りました。前の研究がN/2（飢えない）とN（飢える）の2点しか測っていなかった、まさにその帯です。

その帯は連続で、閾値はありません。 rho 0.85、greedy SRPTでの結果です。flow balance（そのクラスが自分の到着に追いついている度合い）が1.0なら追いついています。

封印文には、仕組みから導いた予想も書いてありました。m = N だけは「優先度順で1位にならなければそもそも起動できない」という質的に違う性質を持つが、m < N は容量をめぐる連続的な競争にすぎない。だから劣化はN/2で段差を作るのではなく、急だが滑らかになるはずだ、と。そのとおりになりました。

安全側の目安は0.75。 ここまでは大クラスのflow balanceが0.9以上に保たれます。Phillyの実測比0.59ではそのクラスは飢えませんが、1GPUジョブの7.4倍遅くなります。

EASY backfillはどの比でも大クラスを飢餓させず、最悪のflow balanceは0.999、最大JCTは6.7でした。4本の研究を通じて一度も破綻していない唯一の方式です。preemptionを使わない版はすべての点でgreedy SRPTより悪く、0.75の時点で既にflow balance 0.308、0.875以上では0.000です。

何が変わったか

前の研究の運用規則を取り下げました。データを見る前に封印文へ書いた約束の履行です。

決定予測が的中した場合、運用規則を「プール全体を占めるジョブが来るか確認せよ」から「最大ジョブが容量の r_safe を超えるか」という条件文へ格下げし、分野の見出しをモデルでは実在するが、調べた2本の公開トレースでは飢餓として未観測に書き換える。

• 取り下げ： 「クラスタ全体を要するジョブが来るか最初に確認せよ」。実測したプールに、そのようなジョブは来ていません。
• 置き換え： 最大ジョブがプール容量の0.75を超えるかを見る。Phillyの最悪クラスタは0.59で、この目安の下にあります。
• 害の形を改訂： 実際の比率が生むのは無限の待ちではなく、数倍の遅れです。

仕組みそのものは変わっておらず、モデルの中では依然として成立します。変わったのは、それが届く範囲です。

何が失敗したか

PRED-004は10本中5本的中。 情報量が大きいのはS8の外し方で、この研究自身の主張を弱める向きに外れました。実トレースの裾は、先行研究で使った合成分布より軽いのです。E[k]を揃えたとき、合成のp(k ≥ 64)は0.00403に対しPAIは0.00164、0.00073に対しPhillyは0.00035で、2.1〜2.5倍の差があります。合成の設定は、飢餓の仕組みに有利な側へ寄っていました。 S3・S4・S7・S10も外れ、いずれも実トレースの裾を重く見積もりすぎたためです。

事前に決めた取り下げの引き金は作動しませんでしたが、作動すべきでした。 引き金は仮想的なプール容量についての予測2本に紐づいていて、うち1本が的中したためです。仮想クラスタ単位の実測は同じ問いにより直接答え、しかも逆を指していました。封印した時点で選んだ測定量が、決着させたい問いの代理として不適切だった——自分の約束に守られてしまう形です。教訓として記録しました。封印するときは「この測定はこの問いの代理として妥当か」を一行書くこと。

PRED-005は10本中9本的中。 外れたのはT6だけです。比率が同じなら結果も同じという不変性は近似にすぎず、ずれは大きいプールほど危険という向きに系統的でした。m/N = 1.0 でのflow balanceは、N = 64で0.390、N = 128で0.236です。実在の仮想クラスタは217〜603 GPUで、ここで測ったどれより大きいため、実際の規模では r_safe がさらに低い可能性があります。

決定予測T4はこの研究自身の主張に不利な側、すなわちPhillyの実測比では大クラスが飢えないという側に指名してありました。的中したので、格下げが自動的に実行されました。

証拠の範囲

言えること： この2本の公開トレースでは1GPUジョブが支配的で裾が薄く、Phillyのどの仮想クラスタも、実測容量の全体を要するジョブを受け取っていない。モデルの中では、半分から全体までの帯の劣化が連続で、実用的な目安が0.75にある。実測された比では、大クラスは飢餓ではなくおよそ7倍の遅れを被る。

言えないこと： 実トレースから取ったのは需要の形だけです。実際の到着列でスケジューリング方式を動かしてはおらず、閾値実験は実測した比率を合成モデルに入力したものです。容量は公表された割当枠ではなく、ピーク同時使用から推定しました。この2本のトレースはGPUクラスタ全体を代表する標本ではありません。また、この測定は既存の公開データを後から見る形であり、著者は事前の予想を持っています。したがって、事前登録した前向きの検証としては数えません。

まだ分からないこと

• r_safe が負荷でどう動くか。rho 0.7では0.875でもflow balanceが0.856を保つので、負荷が上がれば目安は下がりますが、細かくは測っていません。
• 比率不変からのずれが、N = 512や1024でも続くか。実在の仮想クラスタはその領域にあり、ずれの向きは不利です。
• PAIの割当枠グループ構造での同じ分析。10万件標本ではなく完全トレースが必要です。
• PhillyとPAI以外のトレース。Alibaba v2023はノードあたり8 GPU上限のため対象外です。
• preemptionのコストが0でないときとの相互作用。まだ測っていません。

この結論が崩れるとき

• これらの仮想クラスタの公表された割当枠が、ピーク同時使用よりはるかに小さい容量を示す。その場合、実際のジョブがプール規模に達していた可能性が戻ります。
• 別の運用トレースが、スケジューリング対象プールの容量以上を要求するジョブクラスを含む。
• より細かい掃引が、半分から全体の帯の内側に不連続を見つける。その場合、閾値としての読みが復活します。
• 512または1024サーバで測った r_safe が0.59を下回る。その場合、Phillyの最悪クラスタは害のある領域に戻ります。

自分で確かめる

データと採点の簡易確認

python -m pip install -r requirements-reproduce.txt
python scripts/reproduce.py --quick gpu-phase

封印した4本のハッシュ、採点、そして実測されたどの仮想クラスタにもプールを占め切るジョブが存在しないことを検証します。

完全な再実行

cd reproduction/gpu-scheduling-phase
python run_e6.py
python analyze_e6.py

トレースの測定そのものには生の公開トレースが必要で、ここでは再配布していません。analyze_traces.py は同梱してあり、それが生成したトレース別・仮想クラスタ別の測定値を results/E5_traces.json に置いています。トレースは msr-fiddle/philly-traces と alibaba/clusterdata から取得してください。

証拠とデータ

• 公開再現パッケージ
• 封印済みPRED-004（作動しなかった取り下げ条件を含む）
• 封印済みPRED-005（決定予測と、それが起動する格下げを含む）
• トレースから導出した測定値
• E6閾値掃引の採点
• 内部の元Episodeのハッシュ：6ec6a9dba06e28147c46effd2d7ca5d9867a55b9a0ff918f05649c40ab586653

外部からの検証

• 独立再現：0
• 再現失敗：0
• 公開後に確認されたbug：0
• 未解決の批判：0

次の実験

64、128、256、512サーバで r_safe を測ります。この研究で唯一外れた予測は、比率不変が成り立たず、ずれが「大きいプールほど悪い」向きであることを示しました。実在の仮想クラスタはここまでに測ったどれよりも大きいので、Phillyの0.59が本当に安全側かどうかは、その測定で決まります。

ここに至るまで