実クラスタについての主張は、19,100本中1本のジョブに乗っていた

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

現在わかっていること

前の研究で運用表が戻りましたが、表には頻度の列があります。この分野が実在のクラスタについて唯一している主張——Philly仮想クラスタ11cb48は安全側にいる——には、その頻度が測られていませんでした。表の頻度0.002の行なら安全比率0.92（余裕0.33）、0.02の行なら0.72（余裕0.13）。2.5倍の幅があります。

シミュレーションを一切使わず、既にあるトレースから測りました。

11cb48で容量の半分以上を要求したジョブは、19,100本のうち1本です。頻度 5.2×10⁻⁵。表の最も低い頻度の行より38倍稀です。境界は頻度が下がるほど上がるので、その行の0.92をそのまま下界として使えます。

余裕は0.33（下界）に確定しました。

ただし、この研究がいちばんはっきりさせたのは余裕の値ではありません。射程の狭さです。

• 11個の仮想クラスタのうち10個には、容量の4分の1を超えるジョブが1本も来ていません。
• 唯一の例外11cb48でも、容量の4分の1超は6本、半分超は1本です。
• どのクラスタにも、プール全体を占めるジョブは来ていません（再計数で確認）。

この分野が実在のクラスタについて主張してきたことは、Philly トレース全体で1本のジョブに乗っています。

図で見る

11cb48の最大ジョブは128 GPU、容量は217 GPUです。その1本を除くと、このクラスタで容量の4分の1を超えるジョブは5本しかありません。

結果

P(≥0.5) の 0.000052 は、19,100本中1本です。

この研究が示すこと

• Philly 11cb48の最大比率クラスの到着頻度は 5.2×10⁻⁵。α基準の運用表の最低頻度行より38倍稀である。
• したがって比率0.59に対する余裕は 0.33（下界）。前の研究の0.13〜0.33という幅は、広い端に確定した。
• 11個の仮想クラスタのうち10個には、容量の4分の1を超えるジョブが存在しない。
• どのクラスタにもプール全体を占めるジョブは来ていない（EP-0004の看板結論が再計数で生存）。

この研究が示さないこと

• **頻度の軸で「2つのリスク要因が同時に現れない」かは検定できていません。**容量の40%を超えるジョブを持つクラスタは11cb48だけで、残る10個は0で並んでいます。変動がないので、相関の向きを主張できません。支持も反証もされていない状態です。
• 連続分布を単一クラスの頻度へ写す方法は一意ではありません。仕事量の割合で写すと別の行になる可能性があります。
• 表は256サーバ・rho 0.85・指数サービス時間で測ったもので、Phillyはそのどれとも一致しません。実クラスタをモデルの軸の上に置いた評価であり、トレース上でスケジューリング方式を走らせた結果ではありません。

なぜ重要か

「実トレースで確認した」という言葉は強く響きます。この研究は、その言葉の中身が実際にはどれくらいの規模かを数字にしました。1本です。

実務的な含意は、値そのものより手順にあります。自分のクラスタを評価するなら、まず「容量の半分以上を要求するジョブが年に何本来るか」を数えてください。0本なら、この分野の境界の議論は当面あなたに関係しません。11個中10個がその状態でした。

何を調べたか

Philly仮想クラスタで、大きいジョブは実際にどれだけ頻繁に来るのか。11cb48はα基準の表のどの行に落ちるのか。

方法

Phillyの cluster_job_log から、500ジョブ以上の仮想クラスタごとに、容量（ピーク同時使用GPU数）、同時実行ジョブ数、最大ジョブ幅、そして P(必要GPU数 ≥ q × 容量) を q = 0.25 / 0.40 / 0.50 / 0.59 / 0.75 / 1.00 で測ります。新規シミュレーションはありません。

PRED-014として、SHA-256 9fedc330b067f8cc3616f1fcc896f55ba4bb3887ebf523dfcf4493ad539ee281 で封印しています。対応する結果ファイルが存在しない状態でコミットしました。

封印文には測定量の選び方の理由も書いてあります。連続分布を単一クラスの頻度へ写す方法は一意ではないので、選んだ写像が保守的でない側（上界側）に倒れることを明記しました。容量をピーク同時使用から取ることも、比率を上界側にします。どちらも「測ったリスクを過小に見せない」向きです。

何が変わったか

• Phillyの余裕を、0.13〜0.33という幅から 0.33（下界） へ確定しました。
• 「実トレースで確認した」の中身を、1本のジョブという規模で明記しました。
• 前の研究の「実トレースでは比率と同時実行ジョブ数が負に相関し、2つのリスク要因が同時に現れない」を、同時実行ジョブ数の軸では有効、頻度の軸では検定できていないに分けました。

何が失敗したか

PRED-014は6本中4本的中。決定予測K1は的中しました。

K2が外れました。そして外れた理由は、私が封印した閾値そのものです。

11cb48の容量は217 GPU、最大ジョブは128 GPU。比率は 128 ÷ 217 = 0.5899 です。封印文には閾値 q = 0.59 と書きました。すると 0.59 × 217 = 128.03 となり、比率を定義しているまさにそのジョブが、0.03 GPUの差で除外されました。

P(≥0.59) が0なのは物理ではなく、丸めた比率を閾値として書き戻した結果です。閾値を0.5に置けば該当1本、K2の判定式も満たします。

これは、この分野が繰り返し見つけてきた失敗の5例目です。格子丸め、判定線、標本数、窓正規化、そして閾値の丸め。今回は封印時に「該当が0本でないこと」を条件に入れていたので、**採点の瞬間に検出できました。**条件を書いていなければ「該当0本」という強い結論をそのまま出していた可能性が高い。

**K4が外れました。ただし反証ではありません。**比率と頻度の相関は+0.50（p=0.117）で封印基準（≤0）を満たしません。しかし容量の40%を超えるジョブを持つクラスタは11cb48だけで、残る10個は0で並んでいます。**相関は「逆だった」のではなく、「このトレースには変動がない」のです。**事前約束は実行しましたが、書き方は「頻度軸へ広がらない」ではなく「このトレースでは検定できない」としました。

**手続き上の不備。**採点スクリプトを封印コミットに含めませんでした。前の3本では予測ファイルと同じコミットに入れていました。判定式は予測本文に全部書いてあるので採点自体は機械的ですが、規律としては一段落ちます。results/E15_grading.json に grading_script_not_sealed: true として記録しました。

証拠の範囲

言えること： Philly 11cb48の最大比率クラスの頻度は19,100本中1本。11個中10個の仮想クラスタには容量の4分の1を超えるジョブが存在しない。どのクラスタにもプール全体ジョブは来ていない。これらはすべてトレースの実測です。

言えないこと： 頻度軸での2つのリスク要因の関係（検定不能）。トレース上でのスケジューリング方式の比較。余裕0.33は実測頻度を合成モデルの表へ入力した評価です。

まだ分からないこと

• 頻度軸で「2つのリスク要因が同時に現れない」か。Phillyだけでは変動がないので、他のトレースが要ります。
• 実クラスタの頻度は表の格子上に来ません。11cb48は最低行よりさらに下にあり、表の外側に置いて下界として読むしかない状態です。
• 連続分布から単一クラスの頻度への写し方を変えたときの感度。

この結論が崩れるとき

• 公表された割当枠が、ピーク同時使用よりはるかに小さい容量を示す。その場合、比率が上がり余裕が縮みます。
• 別の運用トレースに、高い比率と高い頻度を同時に持つプールが見つかる。
• 頻度の写し方を仕事量の割合に変えると、表の別の行に落ちる。

自分で確かめる

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

この簡易確認は、19,100本中1本という測定値を結果ファイルから再計算し、どの仮想クラスタにもプール全体ジョブが無いことを確かめます。

完全な再実行には生のPhillyトレースが必要です（ここでは再配布していません）。msr-fiddle/philly-traces から取得して data/trace-data/ に置いてください。

cd reproduction/gpu-scheduling-boundary
python run_e15.py

証拠とデータ

• 公開再現パッケージ
• 封印済みPRED-014（測定量の選び方の理由を含む）
• E15の測定値
• E15の採点（封印されなかった採点スクリプトの記録を含む）
• 内部の元Episodeのハッシュ：990cbc3e360d78ce5f7cd1cde10e7550a97c79bbd88d8cedf3e5417d5f4a32ea

外部からの検証

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

次の実験

運用表の頻度軸を細かくします。現在は0.002と0.02の2行しかなく、実クラスタの実測値5.2×10⁻⁵は表の外側にあります。下端を10⁻⁴まで伸ばし、中間の格子を足して、実測頻度を丸めずに読めるようにします。

ここに至るまで