「2つの数で決まる」を撤回した

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

現在わかっていること

前の3本の研究で、この分野の看板はこうなっていました。

この問題は2つの数で決まる。ジョブがプール容量の何割を要求するか、そのプールを同時に取り合っているジョブが何本か。

撤回します。

最大ジョブ比率・その頻度・同時実行ジョブ数を独立に操作できる完全要因計画を組み、496回走らせました。同時実行ジョブ数はLittleの法則で設計でき、狙い9.98/14.96/29.93に対し実測9.98/14.97/29.94——誤差0.1%で固定できています。

その上で**最大ジョブの頻度を25倍に振ると、境界は3つの同時本数すべてで1格子点動きました。**しかも動く向きが揃っていません。同時10本では下がり、15本では下がってから戻り、30本では上がります。

さらに大きかったのは背景需要の分布族です。同時本数・比率・頻度をすべて揃えても、背景の分布族を変えると流量が最大0.164動きました。頻度の効果（最大0.151）より大きい。

そしてこの研究は、採点結果を過去と突き合わせる過程でもっと重い問題を見つけています。公開してきた運用表の2行は、判定線からの余裕が +0.0006 と +0.0064 しかありませんでした。同じ統計量のシード間標準偏差は0.012〜0.105です。運用表の2行は、実質的にノイズで決まっていました。

図で見る

横軸は、大クラスの流量をその要因がどれだけ動かすかです。公開していた運用表の余裕（0.0006〜0.0064）は、この図の左端よりさらに内側にあります。

この研究が示すこと

• 同時実行ジョブ数と最大ジョブ比率を揃えても、最大ジョブの頻度は境界を1格子点動かす。連続量で測ると0.037〜0.069で、シード標準誤差の3〜50倍である。
• 背景需要の分布族は頻度より大きく効く（流量で最大0.164）。
• Littleの法則を使えば、同時実行ジョブ数を誤差0.1%で設計できる。
• 負荷を固定するかぎり、プール全体を要するジョブが頻繁に来る世界と、同時実行ジョブ数が多い世界は両立しない。これはワークロードの代数であって、実験設計の漏れではない。
• 健全な領域でも、大ジョブを頻繁にすると大ジョブ自身の待ち時間は伸びる（14群中13群）。

この研究が示さないこと

• 頻度そのものが効いているのか、その頻度が担う仕事量の割合が効いているのかは、この設計では分離できません。比率と平均ジョブ幅を固定すると両者は比例します。
• 格子で測った境界は、真の境界より保守側へ系統的にずれます。連続量で測り直すと、同時30本の目安は0.625ではなく約0.76でした。
• 判定に使った統計量そのものの妥当性は、この研究では検査していません。次の研究で無効と判明します。

なぜ重要か

「2つの数で決まる」は、運用に渡すのにちょうどよい形をしていました。形が良いほど、条件の外で使われます。

実際には4つ目まであります。比率、同時実行ジョブ数、頻度、背景分布の形。前の2つが支配的ですが、後の2つも境界を1格子点動かす大きさを持ちます。頻度の列がない表を渡すと、大ジョブが稀なクラスタには保守側、頻繁なクラスタには危険側の数字を渡すことになります。

そして運用表の2行がノイズで決まっていたという発見のほうが、おそらく分野をまたいで役に立ちます。**主張する差が、その統計量の分解能やばらつきの何倍かを、主張と並べて書く。**この一行があれば、最初の研究で止まっていました。

何を調べたか

前の研究が残した最優先の未解決点。最大ジョブの頻度は、独立の第三変数か。

方法

3因子を独立に設定できる構成を組みました。最大ジョブ比率は最大クラスが要求するサーバ数で、頻度はその確率で、同時実行ジョブ数は平均ジョブ幅をLittleの法則で翻訳して設定します。背景の分布は、平均が指定値にちょうど一致するよう二分法で当てます。これで3つが互いに動きません。

• 要因腕：比率7水準 × 同時本数3水準 × 頻度3水準、完全交差、315回
• 頻度拡張腕：頻度を0.05まで伸ばす、70回
• 再走ゲート：前の研究の84回を完全再現、差0を確認
• 対照腕：EASY backfill、27回

計496回。PRED-011として、SHA-256 8f0fbd64ff019671a58499aa552bcf5aaa2a24923cf1068705e543be924e3765 で封印しています。対応する結果ファイルが存在しない状態でコミットしました。

決定予測Z2は「境界は頻度に対して不変」、すなわちその時点の看板が反証されうる側に指名し、外れた場合に何を削除するかを封印文に書いてあります。

結果

境界は頻度とともに動きます。

3水準すべてで1格子点動き、向きが揃っていません。シードノイズではありません。連続量で測った境界のシード間標準誤差は0.001〜0.024で、頻度による移動0.037〜0.069より一桁小さい値です。

**背景分布族のほうが大きく効きます。**同じ同時本数・比率・頻度で、背景の族だけを変えると流量が最大0.164動きました。

運用表の余裕を測り直します。

同じ統計量のシード間標準偏差は0.012〜0.105です。

格子丸めの系統誤差。連続量で測り直すと、同時30本の目安は0.625ではなく0.677〜0.817でした。格子上の「最後に通った点」を境界と呼ぶと、格子幅ぶん手前に寄ります。

何が変わったか

• 「この問題は2つの数で決まる」を撤回しました。
• 運用表に頻度の列が必要だと明記し、同時30本の行を0.625から約0.76±0.07へ訂正しました。
• EP-0007の「別構成で0格子点の再現」を、同じ背景分布族の中に限ると狭めました。
• 格子で測る境界を主統計量から降ろしました。

何が失敗したか

PRED-011は11本中7本的中。決定予測Z2が外れました。

外れたのは予測の内容だけではありません。この研究は自分の分野が3本の研究にわたって出してきた数字が、統計量のばらつきの内側で決まっていたことを、採点の過程で見つけました。予測を外したから見つかったのであって、当たっていたら見つかっていません。

さらに、EP-0010で「格子丸めで保守側に外れている」として上方修正したこと自体が、**次の研究で誤った方向への修正だったと判明します。**格子丸めの保守性が、別の誤りを打ち消していたからです。

証拠の範囲

言えること： この合成モデルの中では、境界は少なくとも4つの量に依存する。比率と同時実行ジョブ数が支配的で、頻度と背景分布族は1格子点ぶんの大きさを持つ。Littleの法則で同時本数を誤差0.1%で設計できる。

言えないこと： 頻度と仕事量割合の分離。判定に使った統計量の妥当性。実トレース上での挙動。単一の負荷・プール規模・サービス分布・背景族です。

まだ分からないこと

• 頻度の効果がU字である（仕事量割合0.2〜0.3で最悪、0.5超で回復）という観測は、封印外の探索的なものです。
• 背景分布族の効果は、族を要約する少数の量で説明できるのか。
• **判定線0.9そのものが妥当なのか。**この分野の運用数値は全部この線に依存しています。

この結論が崩れるとき

• 同じ仕事量割合を異なる(頻度, 比率, 平均幅)の組で作ったとき、境界が重なる。そうなら効いているのは頻度ではなく仕事量割合です。
• 判定線を動かすと、条件間の順序が入れ替わる。
• 観測窓を伸ばすと境界が大きく動く。次の研究がこれを調べ、予想と違う形で答えが出ます。

自分で確かめる

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

完全な再実行：

cd reproduction/gpu-scheduling-boundary
python run_e12.py
python analyze_e12.py

証拠とデータ

• 公開再現パッケージ
• 封印済みPRED-011（決定予測と、外れた場合に何を削除するかを含む）
• E12の採点
• 内部の元Episodeのハッシュ：f23d5954db2632ef6d7c385817ebc06c44389bd1bd1e0c4f95a0cd478be8d17b

外部からの検証

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

次の実験

判定線そのものを検定します。観測窓を30,000ジョブから120,000ジョブまで振り、判定線を0.8/0.9/0.95で振り、過去の境界を連続量で測り直します。この分野の運用数値は全部この線の関数なので、線が妥当でなければ数字は全部やり直しです。

ここに至るまで