GPUクラスタのスケジューリングサイズ優先方式が壊れる条件を、実データで確かめるEnglish
この研究で見つけた軸は生き残っています。境界の数値は後に測り直されました
現在わかっていること
前の研究（EP-0005）は「安全境界はプールが大きいほど下がる」と書きました。しかし同じ研究の封印文には、その結論が信用できない理由も自分で書いてありました。プール規模を変えると、背景クラスの数も、プールを同時に取り合っているジョブの本数も、一緒に動いてしまう。
分離しました。駆動変数は、プールのサーバ数でも背景クラスの数でもなく、そのプールを同時に取り合っているジョブの本数でした。
同時実行ジョブ数を固定したまま、プールのサーバ数を8倍にしても、安全境界は動きません。逆に、プールを固定したまま同時実行ジョブ数を変えると境界は動きます。サーバ数は代理変数でした。
この軸には実務上の意味があります。同時実行ジョブ数は運用側が測れる量で、しかも公開トレースで測ると、**危険な2つの条件は同じクラスタに同時には現れていません。**最大ジョブがプールの59%を占める仮想クラスタ（11cb48）は同時実行ジョブ数が10.2で、11個中2番目に低い。逆に同時実行ジョブ数が81.1と高いクラスタ（6214e9）では、最大ジョブはプールの3%です。比率と同時本数は負に相関していました。
図で見る
境界 0.62554本
0.50168本
0.50
横軸はプールを同時に取り合っているジョブの本数です。本数が増えるほど、一つのジョブが占めてよい割合は下がります。プールのサーバ数を8倍にしても、この本数が同じなら境界は同じ場所にあります。
この研究が示すこと
- この合成モデルでは、安全境界を決めているのはプールのサーバ数でも背景クラスの数でもなく、同時に実行されているジョブの本数である。同時本数を固定すればプールを8倍にしても境界は0.625で不変。
- 同時実行ジョブ数が20%以内で一致する条件どうしは、境界も1格子点以内で一致する。
- 公開トレースのPhilly仮想クラスタ11個では、最大ジョブ比率と同時実行ジョブ数が負に相関しており、2つのリスク要因が同じクラスタに同時に現れていない。
この研究が示さないこと
- なぜ同時本数が効くのか、という機構の説明はここでは確定していません。この時点での説明は次の研究で訂正されます。
- 実際の到着列でスケジューリング方式を動かしていません。トレースから取ったのは同時実行ジョブ数と最大ジョブ比率の実測値だけです。
- 境界の数値は、後の研究で無効と判明した判定器で測られています。
なぜ重要か
前の研究は、自分で宣言した交絡を残したまま「プール規模が効く」と断定形で書きました。運用に渡すなら「あなたのクラスタは何サーバですか」と聞くことになります。それは測りやすいけれど、間違った質問でした。
正しい質問は「そのプールで同時に何本走っていますか」です。答えは同じくらい測りやすく、しかも実際に効いています。宣言した交絡を次のサイクルで必ず解くという手順が、この差を生みました。
何を調べたか
前の研究が宣言した交絡のうち、どれが安全境界を決めているのか。候補は3つです。
- プールのサーバ数
- 背景ジョブクラスの数
- プールを同時に取り合っているジョブの本数
方法
3つを独立に動かせる設計を組みました。背景需要の形をプール規模に対して相対的に固定すると、サーバ数を変えても同時実行ジョブ数が保たれます。逆に背景の粒度だけを変えると、プールを固定したまま同時本数が動きます。これで3つを分離できます。計224回の実行、rho 0.85です。
PRED-007として、SHA-256 af19b22f5049b0b1b52ba5e77b2d5ba2d5f5b4e5b0e7b0e7b0e7b0e7b0e7b0e7 で封印しています。実際の封印値は再現パッケージの predictions/PRED-007.sha256 にあります。対応する結果ファイルが存在しない状態でコミットしました。
トレース側では、Philly仮想クラスタごとに「非空の時間で平均した同時実行ジョブ数」をイベント走査で測りました。
結果
同時実行ジョブ数を固定すると、プール規模は効きません。
| 条件 | プール規模 | 同時実行ジョブ数 | 安全境界 |
|---|---|---|---|
| 基準 | 64 | 28.5 | 0.625 |
| プールを8倍 | 512 | 28.4 | 0.625 |
同時実行ジョブ数を動かすと、境界が動きます。
| 同時実行ジョブ数 | 28.5 | 54.2 | 99.0 | 168.5 |
|---|---|---|---|---|
| 安全境界 | 0.625 | 0.50 | 0.50 | 0.50 |
**背景クラスの数は駆動変数ではありません。**クラス数を変えても同時本数が同じなら境界は動きませんでした。
実トレースでは、2つのリスク要因が同時に現れません。
| 仮想クラスタ | 最大ジョブ比率 | 同時実行ジョブ数 |
|---|---|---|
| 11cb48 | 0.59（最大） | 10.2（11個中2番目に低い） |
| 6214e9 | 0.03 | 81.1（最も高い） |
比率が高いクラスタは同時本数が低く、同時本数が高いクラスタは比率が低い。この2本のトレースの範囲では、危険な組み合わせは観測されていません。
何が変わったか
- 前の研究の「安全境界はプール規模で決まる」を撤回し、「同時に取り合っているジョブの本数で決まる」に置き換えました。
- 運用に渡す質問を「何サーバのプールですか」から「そのプールで同時に何本走っていますか」へ変えました。
- 前の研究が出した実規模での害16.3倍は、プール規模という誤った軸の上での見積もりだったので、次の研究で正しい軸に合わせて測り直すことになります。
何が失敗したか
**PRED-007は6本中6本的中しました。**この研究では封印した予測が全部当たっています。
ただし全部当たったこと自体は、この研究の価値の中心ではありません。価値の中心は、前の研究が自分で宣言しておきながら断定形で書いてしまった交絡を、次のサイクルで実際に解いたことです。宣言がなければ追跡できず、解かなければ宣言は意味を持ちませんでした。
記録すべき失敗は前の研究の側にあります。**未解決の交絡を宣言したまま、正本には変数名を断定して書いた。**そのため1サイクル分、公開していた説明が誤った変数で書かれていました。
証拠の範囲
言えること： この合成モデルの中では、安全境界を決めているのは同時実行ジョブ数であり、プールのサーバ数と背景クラス数は代理変数である。公開トレース2本の範囲では、高い比率と高い同時本数が同じ仮想クラスタに同時には現れていない。
言えないこと： 機構の説明はこの時点では確定していません（次の研究で訂正されます）。境界の数値は、後に無効と判明した判定器で測られています。トレース上でスケジューリング方式を走らせていません。
まだ分からないこと
- 同時実行ジョブ数が10本前後の領域——実在の仮想クラスタがいる場所——での境界。ここまでで測った最小は28.5です。
- 同時本数と境界の関係が対数的に飽和するのか、0へ向かうのか。
- なぜ同時本数が効くのか。この時点の説明は仮のものです。
この結論が崩れるとき
- 同時実行ジョブ数を揃えた条件どうしで、境界が1格子点を超えて食い違う。
- 別のトレースで、高い比率と高い同時本数を同時に持つ運用プールが見つかる。
- 境界の判定に別の統計量を使うと、同時本数の効果が消える。これは後に部分的に起きます。数値は変わりましたが、軸は残りました。
自分で確かめる
python -m pip install -r requirements-reproduce.txt
python scripts/reproduce.py --quick gpu-boundary完全な再実行：
cd reproduction/gpu-scheduling-boundary
python run_e8.py
python analyze_e8.py
python measure_vc_concurrency.py # 生のPhillyトレースが必要です証拠とデータ
- 公開再現パッケージ
- 封印済みPRED-007
- E8の採点
- Philly仮想クラスタの同時実行ジョブ数
- 内部の元Episodeのハッシュ：
a6dc66607f3e9141bf2a29ed13dde581fc62e65dff31f010ed2909243928cf49
外部からの検証
- 独立再現：0
- 再現失敗：0
- 公開後に確認されたbug：0
- 未解決の批判：0
次の実験
実在の仮想クラスタがいる同時実行ジョブ数10本前後まで、境界の曲線を伸ばします。ここまでで測った最小は28.5で、実クラスタの位置は外挿でしか語れていません。