# ML Productivity Goodput ## 定義 ML Productivity Goodput（MPG）は、ML フリート全体の効率を「有用な計算をどれだけ達成したか」の観点で測る合成指標である。[[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]] が提案し、Google の本番 TPU フリートで実証した。 ``` MPG = Scheduling Goodput × Runtime Goodput × Program Goodput = SG × RG × PG SG = all-allocated / capacity 「リソースが正しくスケジューリングされている割合」 RG = productive / all-allocated 「スケジューリングされたとき、実際に処理が進んでいる割合」 PG = predicted / productive 「処理が進んでいるとき、理論的な最適時間にどれだけ近いか」 ``` 分母・分子の具体的な対応はジョブのライフサイクルに沿って定まる: - SG: Borg（スケジューラー層）で「同時実行中（simultaneously running）」か「部分的に割り当て済みまたはダウンタイム」かを区別。 - RG: ホスト層で init・訓練・プリエンプション廃棄・チェックポイント復元を区別し、実際に訓練ステップが進んでいる時間の比率を取る。 - PG: デバイス/コンパイラー層で「実際のステップ時間」と「操作の融合・オーバーラップを考慮した予測ステップ時間」を比較する。roofline 効率ではなく predicted time を分母に使う点が特徴（理由は下記）。 ### 従来指標との違い | 従来指標 | 限界 | MPG 対応成分 | |---------|------|------------| | Capacity（展開済みリソース） | スケジューリング制約を無視 | SG | | Occupancy（割り当て済みリソース） | 割り当て ≠ 利用 | RG | | Duty Cycle（アクティブリソース） | アクティビティ ≠ 生産的仕事 | PG | ### Program Goodput と roofline 効率の違い roofline 効率はオペレーターを独立に評価するため、融合や通信計算オーバーラップによって削れる時間が見えない。例として Reshape（メモリ帯域律速）と Convolution（演算律速）を独立に評価すると両者とも roofline スコアは高いが、融合後の予測時間は MemoryTime(Reshape) + ComputeTime(Conv) を下回る。PG は predicted step time を分母とすることで、この余地をコンパイラー最適化の成果として定量的に追跡できる。 ## 横断的知見 - （現在 1 ソース目。横断的知見は 2 ソース以上で積み上がる。以下は 1 ソースから見えた観察を暫定的に記録） - **「件数より GPU 時間で測れ」原則の TPU フリートへの拡張**: [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] や [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]] が示した「障害コストは件数でなく GPU 時間で測る」原則を、MPG は「効率も件数・割り当て率でなく生産的ステップ時間の比率で測る」方向にさらに精密化した形である。3 成分への分解は、クラスタ全体の利用率指標では見えなかった「どの層がボトルネックか」の判断を可能にする。(Source: [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]], [[GPUクラスタ運用]]) - **スケジューリング Goodput > 95% は大規模フリートの達成可能な上限に近い可能性**: Google TPU フリートで全ジョブサイズにわたり SG > 95% を達成（プリエンプション調整）という結果は、スケジューリング層の余地が限られることを示唆する。改善余地の主戦場がランタイム層・プログラム層に移っている可能性がある。ただし単一組織の単一スケジューラー（Borg）での結果であり、Slurm・Kubernetes ベースのフリートへの汎化は未検証。(Source: [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]]) ## 未解決の問い - MPG の 3 成分のうち、実際のフリートで最も大きな改善余地はどこにあるか（スケジューリング > 95% なら残りはランタイムとプログラム？）。 - PG の「predicted step time」はどのように推定するか——コンパイラーが静的に計算するのか、実行時にプロファイルするのか。 - MPG の定義は Borg（Google）固有か、Slurm・Kubernetes ベースのスケジューラーにも一般化できるか。特に SG の「all-allocated」の定義がスケジューラーにより異なる可能性。 - TPU 特有の設計（XLA コンパイラー、Borg スケジューラー）に依存した部分と、GPU + CUDA ベースのフリートに移植可能な部分の切り分けはどこか。 - 異種ハードウェア混在（TPU v4・v5・v6 等）では、predicted step time をどの世代の roofline で正規化すべきか。 ## 関連 - ソース: [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]] - エンティティ: [[Google]] / [[Arissa Wongpanich]] / [[Vijay Janapa Reddi]] / [[Borg]] - 概念: [[GPUクラスタ運用]]（同じ問題空間をより広い視点で扱う） / [[LLM分散学習]] / [[ストラグラー]]（Runtime Goodput の損失要因の一つ） - 関連 MOC: [[分散深層学習 - MOC]] / [[HPC - MOC]] ## 出典 - [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]]（MLSys 2026 Industry Track、Google TPU フリート。スライド 32 ページ + abstract）