2026__MLSys2026__Industry Track Oral Benchmarks and Evaluation 解説

# MLSys2026 Industry Track Oral: Benchmarks and Evaluation 解説 ## 要旨 - 対象は [[MLSys2026]] Day 4 の Industry Track Oral: Benchmarks and Evaluation。 - セッション名は「ベンチマークと評価」だが、主題はモデル精度の比較ではない。 - 中心的な問いは、大規模な機械学習システムを本番規模でどう観測し、再現し、改善につなげるかである。 - 共通する問題意識は以下である。 - GPU/TPU が稼働していることと、生産的な進捗があることは異なる。 - 推論・学習の遅さは、モデル、通信、メモリ、入出力、スケジューラ、コンパイラの複合要因で生じる。 - 本番ワークロードは機密性が高く、モデルやデータをそのまま共有できない。 - 単発のスコアでは、継続的な運用改善やハードウェア・ソフトウェア協調設計に十分でない。 ## セッション全体の見取り図 - 観測基盤 - [[2026__MLSys2026__XProf - An Open Scalable and Extensible Profiling System for the Modern ML Stack|XProf]] - [[2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler|ProfInfer]] - 推論評価基盤 - [[2026__MLSys2026__AIRS - Scaling Live Inference in Resource Constrained Environments|AIRS]] - クラスタ実証と運用トレース - [[2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System and Its Observed Workload Dynamics in a Single-Tenant LLM Development Environment|SAKURAONE]] - 標準化された実行トレース - [[2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces|MLCommons Chakra]] - フリート効率指標 - [[2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput|Machine Learning Fleet Efficiency]] ## XProf - XProf は、OpenXLA エコシステム向けの大規模機械学習プロファイラである。 - 目的は、CPU、TPU/GPU、コンパイラ、ランタイム、通信をまたいで、ボトルネックを同じ文脈で診断できるようにすることである。 - 重要な設計点は、観測のオーバーヘッドを小さく保つことである。 - TPU では 1% 未満のオーバーヘッドを目標とする。 - ホスト側収集オーバーヘッドは TPU で一貫して 0.3% 未満とされる。 - 観測によって実行挙動が大きく変わると、プロファイル結果の意味が失われる。 - 主な構成要素は以下である。 - TraceMe による軽量なホスト計装。 - XLA/HLO メタデータとの結合。 - TPU Global Timestamp Counter による分散時刻同期。 - MapReduce 型の分散後処理。 - PJRT C API 拡張によるデバイス非依存な統合。 - 技術的な要点は、低レベルのハードウェアイベントを高レベルのモデルコードや HLO 演算へ対応づける点にある。 - これにより、単に「アクセラレータ利用率が低い」と見るのではなく、以下の原因を切り分けられる。 - 入力パイプラインの詰まり。 - ホスト・デバイス間通信の待ち。 - 集合通信の遅延。 - メモリ帯域律速。 - コンパイラ生成コードの非効率。 - 電力・温度変動による影響。 - 産業的な意味は、プロファイリングを単発のデバッグではなく、フリート規模の継続的な効率改善基盤へ引き上げている点にある。 ## AIRS - AIRS は、Google 検索品質評価における LLM 評定器の推論基盤である。 - 背景には、検索結果や AI 機能の品質を評価するための評定需要の増大がある。 - 日次 1 億件以上の評定リクエストが発生する。 - TPU はライブユーザトラフィック向けに優先確保される。 - 評価用の TPU 供給は需要に対して制約される。 - AIRS の中心課題は、限られた推論資源を使って、重要な評価メトリクスを十分に速く生成することである。 - システムは大きく 2 層で構成される。 - Rating Fulfillment: 評定タスクの受理、キャッシュ確認、キュー、再試行、完了管理を担う。 - Model Management: モデルホスティング、TPU 利用率追跡、リソーススケールを担う。 - 採用している制御は実務的である。 - キャッシュ。 - キューイング。 - バッチング。 - クォータ会計。 - バックプレッシャ。 - 優先度制御。 - Page Quality や Needs Met の評定では 90 日の鮮度窓を使い、既存評定を再利用する。 - 平均 40% のキャッシュヒット率を達成。 - 実際にモデルへ流れる QPS をピークの 1-4% まで削減。 - 本発表の要点は、LLM-as-a-judge の精度評価そのものではない。 - 評価基盤が大規模推論システムになったとき、支配的な問題は以下へ移る。 - 評定の鮮度。 - 優先度。 - デッドライン。 - 共有 TPU プールの資源配分。 - 低優先度トラフィックの遅延許容。 - プロダクト評価を LLM 化すると、モデル単体ではなく、評価ワークフロー全体の制御設計が性能を決める。 ## SAKURAONE - SAKURAONE は、100 ノード、800 基の H100 GPU から成る AI HPC クラスタである。 - 特徴は、SONiC、RoCEv2、800GbE を用いたオープン Ethernet ベースの構成である。 - 主張は、専用寄りの InfiniBand スタックに対して、オープンな Ethernet スタックでも LLM 訓練に実用的な性能を出せるという点にある。 - 評価はピーク FLOPS に閉じていない。 - HPL。 - HPL-MxP。 - HPCG。 - IO500。 - MLPerf Training。 - 実ジョブトレース。 - 障害分析。 - MLPerf Training GPT-3 175B では、NVIDIA Eos との差が 9-17% 程度と報告される。 - クラスタ設計上の重要点は以下である。 - GPU-NIC アフィニティ。 - rail 最適化トポロジ。 - GPU 間通信とストレージ入出力パスの分離。 - leaf-spine Clos 構成。 - RoCEv2 の輻輳制御設定。 - 実ジョブトレースからは、GPU クラスタ運用に典型的な偏りが観測される。 - 1 ノードジョブはジョブ数の 76.9% を占める。 - 1 ノードジョブの GPU 占有時間は 1.8% にすぎない。 - 17 ノード以上のジョブはジョブ数では 3.3% だが、GPU 占有時間の 73.3% を占める。 - CANCELLED ジョブが GPU 占有時間の 73.5% を占める点も重要である。 - これは単純な失敗ではなく、損失曲線や検証結果を見て早期停止する LLM 開発の運用を反映している。 - FAILED ジョブの GPU 占有時間は小さく、早期に検知される失敗は長時間リソースを消費しない。 - 障害分析では、fabric よりも GPU 関連障害が支配的である。 - GPU 関連障害は 21 件中 9 件、42.9%。 - この発表の意義は、クラスタをベンチマークで評価するだけでなく、実際の開発フェーズ、ジョブ分布、キャンセル、障害まで含めて運用実態を示した点にある。 ## MLCommons Chakra - Chakra は、分散 AI/ML ワークロードの実行を標準化された実行トレースとして表す取り組みである。 - 背景には、実ワークロード共有の難しさがある。 - フロンティアモデルや本番ワークロードは機密性が高い。 - モデル、データ、コードをそのまま共有できない。 - しかしハードウェア設計やネットワーク設計には、実際の計算・通信パターンが必要である。 - Chakra の中心は、実行を DAG として表すスキーマである。 - ノードは計算、メモリ、通信を表す。 - エッジはデータ依存、制御依存、同期依存を表す。 - 集合通信は AllReduce、AllGather、ReduceScatter、All-to-All などとして表現する。 - tensor parallelism、pipeline parallelism、data parallelism、expert parallelism を同じ形式で扱う。 - Chakra の用途は複数ある。 - トレース解析。 - 実システム上でのリプレイ。 - Astra-sim などを用いたシミュレーション。 - 物理スイッチや NIC に対するハードウェア・イン・ザ・ループ検証。 - 重要なのは、モデル本体を共有せずに、性能上重要な実行挙動を共有できる点である。 - ケーススタディでは、MoE 的な All-to-All と AllReduce の混在がネットワーク輻輳制御に悪影響を与えることを示す。 - 高レートの AllReduce が輻輳制御を発火させる。 - All-to-All の多数の小フローが不均衡に絞られる。 - straggler が発生し、ジョブ完了時間を悪化させる。 - Chakra は、MLPerf のような固定ベンチマークを置き換えるというより、協調設計サイクルの共通言語を提供する。 - 本番で観測する。 - 代表的なトレースとして再現する。 - シミュレータやエミュレータで設計案を評価する。 - 実装して再び本番で検証する。 ## ProfInfer - ProfInfer は、eBPF を用いた LLM 推論向けの細粒度プロファイラである。 - 対象は、llama.cpp のようなオンデバイス推論エンジンである。 - オンデバイス推論では、TTFT や TPOT のような粗い指標だけでは原因分析が難しい。 - どの演算子が遅いのか。 - CPU、GPU、NPU のどこが律速なのか。 - メモリ帯域が問題なのか。 - ディスク入出力やページフォルトが問題なのか。 - 他タスクとのスケジューリング干渉があるのか。 - ProfInfer は、ソースコードを変更せずにプローブを取り付ける。 - uprobe / uretprobe でユーザ空間関数の入口・出口を観測する。 - tracepoint でスケジューリングイベントを観測する。 - PMC によりキャッシュミス、メモリアクセス、stall cycles などを取得する。 - 観測粒度は以下である。 - Token-level。 - Graph-level。 - Operator-level。 - Scheduler-level。 - `ggml_tensor` 構造体を読み、演算子種別、テンソル形状、依存関係を復元する。 - 主な観測結果は以下である。 - TTFT/TPOT の 97% 超が MatMul に費やされる。 - matrix-vector 乗算では CPU サイクルの大きな割合が stall になる。 - 一部の MoE モデルでは、ボトルネックがメモリ帯域ではなくディスク入出力になる。 - 活性化エキスパートがメモリから追い出されると、major page faults と実行時間が増える。 - オーバーヘッドは小さく、libbpf 構成では decode 速度低下が 1.19% 程度、全機能有効でも数% 台とされる。 - この発表の意義は、エッジ LLM の最適化対象をモデル圧縮だけでなく、実行時の演算子配置、ページング、スケジューリング、バックエンド選択へ広げている点にある。 ## Machine Learning Fleet Efficiency - 本発表は、Google の本番 TPU フリート効率を測るための ML Productivity Goodput（MPG）を提案する。 - 問題意識は明確である。 - 利用率が高いことは、生産的な進捗があることを意味しない。 - アクセラレータが busy でも、入力待ち、チェックポイント待ち、プリエンプション後のやり直し、冗長計算をしている可能性がある。 - capacity、occupancy、duty cycle は busy-ness を測るが、forward progress を直接測らない。 - MPG は以下の 3 成分に分解される。 $ \text{MPG} = \text{SG} \times \text{RG} \times \text{PG} $ - Scheduling Goodput（SG） - 分散ジョブに必要な全リソースが同時に割り当てられている割合。 - スケジューラやトポロジ制約の影響を表す。 - Runtime Goodput（RG） - 割り当てられた時間のうち、チェックポイントに残る生産的な進捗があった割合。 - 入力待ち、コンパイル待ち、チェックポイント、プリエンプション損失を反映する。 - Program Goodput（PG） - 生産的に実行している時間が、理論ピークにどれだけ近いかを表す。 - HLO グラフと演算形状から予測した実行時間と、実実行時間を比較する。 - PG は単純な演算単位の roofline 効率とは異なる。 - 演算単体ではなく、fusion や通信・計算オーバーラップを含む全体実行時間を評価する。 - コンパイラ最適化の効果やリグレッションをフリート規模で追跡できる。 - 報告された改善例は以下である。 - 通信と計算のオーバーラップにより、500B パラメータ級 LLM、1024 TPU チップで最大 1.38 倍のスループット改善。 - XLA の algebraic simplification により、上位 150 ワークロードの PG が 1.06-1.07 倍程度改善。 - CATWILD により TPU 訓練フリートの約 70% を継続チューニング。 - MPG の意義は、フリート効率を単一の利用率で見るのではなく、改善対象の層へ分解する点にある。 - SG が低ければスケジューリング問題。 - RG が低ければランタイムやプリエンプション、チェックポイント、入力処理の問題。 - PG が低ければプログラム、コンパイラ、ハードウェア適合の問題。 ## 横断的な論点 - 観測の低侵襲化 - XProf と ProfInfer は、観測者効果を抑えながら、抽象度の異なる層を結合する。 - 本番規模では、プロファイラのオーバーヘッドとデータ量が診断可能性を左右する。 - 実行挙動の共有 - Chakra は、モデルやデータを晒さずに、性能上重要な実行パターンを共有する。 - 協調設計では、固定ベンチマークよりも実行トレースの再利用性が重要になる。 - 評価基盤の推論システム化 - AIRS は、評価そのものが巨大な LLM 推論ワークロードになることを示す。 - 精度だけでなく、鮮度、優先度、デッドライン、資源配分が評価品質を決める。 - クラスタ評価の運用化 - SAKURAONE は、ピーク FLOPS だけでなく、実ジョブ分布、キャンセル、障害を含む評価を行う。 - LLM 開発では、早期停止やフェーズ遷移がクラスタ利用を大きく変える。 - 利用率から生産的進捗へ - MPG は、busy であることと productive であることを明確に分ける。 - 大規模フリートの改善には、スケジューリング、ランタイム、プログラム効率の分解が必要である。 ## まとめ - このセッションは、機械学習システムの評価軸が単発の性能スコアから、本番運用における継続的な観測・再現・改善へ移っていることを示す。 - ベンチマークは、固定されたモデルとデータセットで順位を出すためだけのものではない。 - 本番に近い評価では、以下が同時に必要になる。 - 低オーバーヘッドなプロファイリング。 - 機密性を保った実行トレース共有。 - 推論評価ワークロードの資源制御。 - クラスタの実利用トレース分析。 - 生産的進捗を測る指標。 - MLSys2026 のこのセッションは、「速いかどうか」ではなく、「どの層が、どの条件で、どれだけ意味のある進捗に貢献しているか」を測る方向への変化を示している。