GPUクラスタのスケジューリングサイズ優先方式が壊れる条件を、実データで確かめるEnglish
ここで出した境界の数値は、後に判定器ごと置き換えられました
現在わかっていること
前の研究（EP-0006）が駆動変数を同時実行ジョブ数へ訂正しましたが、測った範囲は28.5本以上でした。実在の仮想クラスタで最も危ない位置にいる11cb48は同時実行ジョブ数10.2で、測定範囲の外です。前の研究はそこを外挿で「安全側」と言っていました。
外挿を測定に変えました。同時実行ジョブ数9.8で安全境界は0.875、実測比率0.59に対する余裕は0.285です。方向は変わりませんが、根拠が外挿から測定になりました。
そしてもう一つ、この研究は自分が4本の研究にわたって載せてきた説明を取り下げています。
取り下げた説明はこうでした。「プール全体を要するジョブは、優先度順で1位にならなければ起動できない。待っているあいだは残り時間が減らないので、永久に1位にならない。これは構造的な罠であり、負荷とは無関係である。」
強すぎました。プール全体ジョブの流量は、同時実行ジョブ数とともに0.078から0.850まで連続的に変化します。同時本数が7.4のときは飢餓しません。1位になれるかどうかは競合の数の問題であって、質的に別格な条件ではありませんでした。
図で見る
余裕 0.2850.875 同時9.8での境界
実在の仮想クラスタは同時実行ジョブ数が少ない側にいます。そこでは一つのジョブがプールの大部分を占めても通ります。測定した曲線の上で、実測比率0.59は境界0.875の左側にあります。
この研究が示すこと
- この合成モデルでは、安全境界は同時実行ジョブ数の減少関数である。同時本数 7.4 / 9.8 / 14.6 / 28.4 / 54.2 / 98.9 に対し、境界は 0.875 / 0.875 / 0.8125 / 0.625 / 0.50 / 0.50。
- 実在の仮想クラスタ11cb48がいる位置（同時本数約10）は、外挿ではなく測定で安全側にある。
- プール全体を要するジョブの飢餓は、質的に別格の現象ではなく、同時本数に沿った連続量である。
この研究が示さないこと
- 境界の数値は、後に無効と判明した判定器で測られています。
- 実際の到着列でスケジューリング方式を動かしていません。実クラスタからは比率と同時本数の実測値を入力しただけです。
- 「別構成での再現」は、同じ背景分布族の中での再現です。族をまたいだ再現は後の研究で通りませんでした。
なぜ重要か
「構造的な罠」という言葉は、4本の研究にわたって公開文書に載っていました。質的に強い言葉は、読んだ人の行動を変えます。「構造的で負荷と無関係」なら、負荷を下げても意味がないことになります。実際には負荷——正確には同時に走っている本数——こそが効いていました。
**強い言葉は、その言葉が反例を許さないと主張している軸を掃いてから書く。**1点の観測から「構造的」と書いたのが誤りでした。
何を調べたか
- 実在の仮想クラスタがいる同時実行ジョブ数（約10本）での安全境界はいくつか。
- プール全体を要するジョブの飢餓は、本当に質的に別格の現象なのか。
方法
プールを256サーバに固定し、背景需要の粒度を変えることで同時実行ジョブ数を7.4から98.9まで掃きます。各点で比率を7段階振ります。計168回の実行、rho 0.85です。
PRED-008として封印しています。digestは再現パッケージの predictions/PRED-008.sha256 にあります。対応する結果ファイルが存在しない状態でコミットしました。
前の研究（EP-0006）はプール規模を変えて背景を相対固定する構成、この研究はプールを固定して背景を粗くする構成です。別々の作り方で同じ同時本数を作れば、同じ境界が出るはずという再現の検査を組み込みました。
結果
境界は同時実行ジョブ数の減少関数です。
| 同時実行ジョブ数 | 7.4 | 9.8 | 14.6 | 28.4 | 54.2 | 98.9 |
|---|---|---|---|---|---|---|
| 安全境界 | 0.875 | 0.875 | 0.8125 | 0.625 | 0.50 | 0.50 |
**別構成で一致しました。**EP-0006（プールを変えて背景を相対固定）とEP-0007（プールを固定して背景を粗く）が、同時本数28.5付近で同じ境界0.625を出しました。格子上の差は0点です。
プール全体ジョブの飢餓は連続量でした。
| 同時実行ジョブ数 | 98.9 | 54.2 | 28.4 | 14.6 | 9.8 | 7.4 |
|---|---|---|---|---|---|---|
| プール全体ジョブの流量 | 0.078 | 0.178 | 0.265 | 0.519 | 0.693 | 0.850 |
0.078から0.850まで、段差なく変化します。同時本数が少なければ、プール全体を要するジョブでも通ります。
実クラスタの位置での害。比率0.625・同時本数9.8で、大ジョブクラスは背景クラスの5.1倍遅くなります。前の2つの見積もり（7.4倍、16.3倍）はどちらも誤った軸の上で測られていました。
何が変わったか
- 「プール全体ジョブの飢餓は構造的な罠であり負荷と無関係」という説明を取り下げ、同時実行ジョブ数に沿った連続量に置き換えました。この説明は4本の研究にわたって載っていました。
- 実クラスタの位置を外挿から測定へ格上げしました。
- 害の見積もりを、7.4倍（EP-0004）→16.3倍（EP-0005）→5.1倍（この研究）と、軸の訂正に合わせて2度改訂しました。
何が失敗したか
**PRED-008は6本中4本的中。**情報量が大きいのは外れたW5です。
W5は「プール全体ジョブは同時本数が下がっても飢餓したままである」という、構造的な罠という説明が正しければ必ず当たるはずの予測でした。外れました。流量は0.850まで上がります。予測を外した瞬間に、4本ぶんの説明が撤回対象になりました。
もう一つのW6は「その位置での害は5倍未満で軽微」という自分の定義に対する予測で、実測5.1倍で僅差で外れています。
**害の倍率を3度書き換えたことも失敗として記録します。**7.4倍、16.3倍、5.1倍。数字そのものが悪いのではなく、軸が確定する前に運用へ渡せる形の数字を出し続けたことが問題でした。
証拠の範囲
言えること： この合成モデルの中では、安全境界は同時実行ジョブ数の減少関数で、実在の仮想クラスタがいる位置は測定範囲の内側にあり安全側である。プール全体ジョブの飢餓に質的な境界はない。
言えないこと： 境界の数値（判定器が後に無効と判明）。トレース上でのpolicy比較。背景分布族をまたいだ再現。
まだ分からないこと
- 同時本数が7.4と9.8でどちらも0.875なのは飽和なのか、格子の上端に当たっているだけなのか。
- 同時本数98.9より上での振る舞い。
- 負荷rhoへの依存。
- 背景分布の形を変えたときの再現性。
この結論が崩れるとき
- 背景の粒度を変えるだけで、同じ比率・同じプール・同じ負荷のまま飢餓が現れたり消えたりする。これは次の研究でそのまま起きます。
- より細かい格子で、同時本数7.4と9.8の境界が分離する。
- 別の判定器で測ると曲線の形が変わる。これも後に起きます。形は残り、値は変わりました。
自分で確かめる
python -m pip install -r requirements-reproduce.txt
python scripts/reproduce.py --quick gpu-boundary完全な再実行：
cd reproduction/gpu-scheduling-boundary
python run_e9.py
python analyze_e9.py証拠とデータ
- 公開再現パッケージ
- 封印済みPRED-008
- E9の採点
- 内部の元Episodeのハッシュ：
b821fb81d95ecfca2fef66f048b85812d98e15ddf39672b666170522b001d27f
外部からの検証
- 独立再現：0
- 再現失敗：0
- 公開後に確認されたbug：0
- 未解決の批判：0
次の実験
この研究の看板結論——需要分布のsupportがプール全体を含むと飢餓する——を、自分で壊しにいきます。同じ比率・同じプール・同じ負荷のまま、背景の粒度だけを変えて飢餓が消えるかを測ります。