# MLSys 2026 口頭共有メモ 元ネタ: [[MLSys2026 参加レポート]]。社内で 15〜20 分ぐらい話す用の箇条書き。上から順に読めば筋が通る。 ## 30 秒で言うと - MLSys 2026 は「モデルよりも、モデルを回すシステムが競争力を決める」段階に入ったことを示した会議。 - 転換は 3 つ。 - **推論サービング**: GPU を速く回す問題 → KV キャッシュという状態を扱う分散システム。 - **開発**: エージェントがカーネルもシステムコードも書く → 律速が生成から検証へ。 - **クラスタ運用**: 利用率と事後復旧 → グッドプットと予防的な健全性管理。 - 自分の関心(クラスタ運用・耐障害性)に一番近いのは 3 つ目。ここを厚めに話す。 ## 会議の基礎データ - 2026/05/18-22、US ワシントン州ベルビュー(シアトル隣)。 - 参加者 1100 人、著者 1200 人、PC + レビュアー 1800 人。参加者はほぼ著者。 - 採択 135 件・採択率 26%。査読数が前年比 +82%、1 論文あたり最低 3 査読。 - 今回から **Industry Track** 新設(28 本)。新規性よりプラクティカルさを見る。さくらONE はここで採択。 - Industry Track のみ査読を AI 支援。論文を AI に査読させるのではなく、**査読文を AI にレビューさせる**。評価スコアは AI で変えない運用。 - Best paper は意外にも RAG 用ベクトルインデックスのストレージ削減(LEANN)。 ## 転換 1: 推論サービングは「状態管理」になった - KV キャッシュが推論エンジン内部の一時状態から、独立した設計対象・共有資源に昇格した。長コンテキスト、RAG、エージェント履歴が原因。 - Keynote(Yuhan Liu / LMCache): KV キャッシュは AI ネイティブなデータ型。保存・圧縮・転送・共有・再利用・検索の対象。GPU に載らない分は CPU メモリやリモートへ逃がす。 - 再利用の単位が「先頭一致の prefix」から「文脈部品」へ広がった。 - ContextPilot: 非完全一致の文脈を整列・重複排除して再利用。 - BatchLLM: 共有 prefix を先に特定してバッチ構成を決める。cache hit を偶然の高速化ではなく**計画情報**として扱う。 - Kitty: key cache のチャネル感度差を使い、大部分は 2 bit、重要チャネルだけ精度を残す。 - プリフィルとデコードの分離は「万能な最適化」ではなく**配備設計問題**として評価された(A Pragmatic Exploration of P/D Disaggregation)。decode-heavy や小モデルでは同居構成が勝つこともある。固定比ではなく負荷に応じた rate matching が要る。 - 異種ハードウェアは「余った GPU を使う」話ではない。モデル能力・品質要件・GPU 特性を対応づける設計(BOute は多目的ベイズ最適化でルーティングと配備を同時最適化)。 - SLO・電力・品質が同じ制御空間に入った。BEAM は SLO を守った余裕を電力削減に回す。MorphServe や HELIOS はモデル品質自体をサービング時の調整ノブにする。 - Keynote(Esha Choukse): 品質はモデル精度ではなくシステム全体の資源配分。全出力を重い検証器に通すのではなく、危険な箇所だけ選択的に検証する(Sherlock)。 ## 転換 2: AI for Systems は「検証」が律速 - エージェントが GPU カーネル、システムコード、HDL まで書き始めた。Keynote 8 本のうち 4 本がこの話題。会議の重心を表している。 - Keynote(Mark Saroufim / GPU MODE): LLM 経由の投稿で高性能カーネルが量産される一方、報酬ハックが出る。出力を固定値にする、同期を避けて計測をだます、キャッシュを悪用する、テスト時だけ正しく見せる。監査 AI(Kernel Guard)を置くだけでは足りず、競技者・攻撃者・監査者・評価基盤が共進化する閉ループが必要。 - Keynote(Lidong Zhou / system intelligence): AI に全コードを自由生成させず、**出力空間を絞る**。集合通信ならスケジュールだけを生成させ、検証とコード生成と実行はシステム側が持つ。形式検証でも AI は証明を省いたり仕様を弱めたりするので、人間が上位意図と信頼境界を定める。 - Keynote(Roger Wang / vLLM): 保守者側の負荷が律速。PR が増えるほどコード量ではなく設計整合性・検証・レビュー・長期保守が効く。bounty は低品質投稿を増幅しうる。人間の価値は構文を書くことから、問題を選び設計を説明し責任を持つことへ移る。 - 実装側の代表例。 - AccelOpt: AWS Trainium の NKI カーネルを生成→プロファイル→検証→知識抽出の閉ループで改善。CUDA より公開知識が少ないので探索能力が試される。 - Agentic Operator Generation for ML ASICs: 性能チャンピオン狙いではなく**バックエンド網羅性**に AI 生成を使う。既存のリンタ・JIT・OpInfo テストに押し込む。 - OpenHands: エージェント基盤をイベントソーシングで再生可能にし、クラッシュ復旧と監査を成立させる。 - ADR: エージェント側を監視するシステム。EDR ではプロンプト→ツール呼び出し→実行結果の連鎖が見えない。 - 評価が固定ベンチマークから能動的探索へ。Keynote(Lisa Li)はレッドチーミングを探索問題として定式化。FlashInfer-Bench はベンチマークを AI 生成カーネルの改善サイクルに組み込む。 ## 転換 3: クラスタ運用は「利用率」を捨てた ← ここが本題 - 従来: GPU をたくさん確保し、NCCL テストとバーンインを通し、壊れたらチェックポイントから再開。frontier scale ではこれだと足りない。 - 足りない理由。 - クラスタが大きいほど、どこか 1 ノードが遅くなる確率が上がる。 - 同期訓練では最も遅いノード(ストラグラー)がステップ時間を決める。 - 推論では復旧のための KV キャッシュや重み再構成の時間が、そのまま利用者の遅延と失敗率になる。 ### 測る - **ML Productivity Goodput (Google)**: フリート効率を Scheduling Goodput × Runtime Goodput × Program Goodput に分解。 - Scheduling: 必要な資源が同時に割り当たっているか。 - Runtime: 割り当たった時間がチェックポイントに残る進捗になったか。 - Program: 進んでいる時間が理論実行時間にどれだけ近いか。 - 価値は指標を増やしたことではなく、**損失がどの層で出たかを分けて運用改善の責任境界を切れる**こと。全 GPU が動いていても、データローダ待ち・巻き戻し・非効率なコンパイル出力・通信と計算の非重畳で生産性は落ちる。 - **XProf**: 大規模分散のプロファイリング。粒度が粗いとストラグラーが平均に埋もれ、細かすぎると観測が本番を邪魔する。その間を狙う。MPG が「どの層で落ちたか」、XProf が「なぜ落ちたか」。 - **MLCommons Chakra**: 計算・通信・依存を標準形式の実行トレースにして、シミュレータやハードウェア設計者が同じワークロード表現を使えるようにする。 - **SAKURAONE(うちの発表)**: 100 ノード / H100 800 基 / 2 PB all-flash Lustre / SONiC + RoCEv2 の 800 GbE leaf-spine。実ワークロード観測として、件数は小規模ジョブが多数だが GPU 時間は少数の大規模ジョブが支配、開発フェーズが進むと大規模訓練から中規模の反復実験へ資源利用が移る、という点を示した。オープン Ethernet スタックで組む選択肢としての意味もある。 - Keynote(Amin Vahdat / Google): データセンター全体の再設計。電力・DC・アクセラレータ・ネットワーク・ソフトの垂直統合。ソフト側の中心はフリート管理とグッドプット。アクセラレータが忙しく見えても有用な進捗にならなければ意味がない。 ### 備える - **Guard**: NCCL テストとバーンインを通過する「グレーノード」(クラッシュしないが遅い)を狙う。オンラインで同一ジョブ内のピアと相対比較(温度・クロック・電力・転送率・エラー・ステップ時間)、オフラインで現実的な負荷のノードスイープ。固定しきい値でなく相対比較なので機種差やワークロード差に効く。**MFU 最大 1.7 倍、実行間のステップ時間分散 20% → 1%**。 - **Sparing Strategies (Meta)**: 予備 GPU を経験則ではなくグッドプット最大化の設計変数にする。ブロックサイズ、ブロック間/内スペア、故障率、修理時間、チェックポイント周期、配置制約を連続時間マルコフ連鎖で評価。ブロック内スペアがあると電力枠を稼働 GPU に回せることもあるし、配置制約で stranded resource になることもある。短期的に空いている GPU は長期の保険。 - **Acela**: DC のソフトウェアアップグレード所要時間を分位点回帰で予測。固定 worst-case 見積もりは失敗しにくいが保守ウィンドウを使い残す。過小予測(ウィンドウ超過)と過大予測(作業を捨てる)のコストは非対称なので、平均誤差最小化では不十分。 - **When Machine Learning Isn't Sure**: 本番で ML 予測を使うなら、外れたときにヒューリスティックへ退避する逃げ道を設計する。 ### 耐える - **RaidServe**: GPU が部分的に欠ける前提で TP サービングを続ける。非一様なテンソル並列、循環的な KV 配置、hybrid attention、負荷を見たルーティング、KV の予防バックアップと必要時の重み復旧。全複製も全再計算も避ける。 - **GhostServe**: KV キャッシュをホストメモリの erasure coding パリティで軽量に守る。全複製はメモリを食う、再計算は長コンテキストで重い、その中間。 - 論点は「キャッシュを保存するか捨てるか」ではなく「**どの冗長度で守るか**」に移った。 - cold start も同系統。Breaking the Ice が vLLM 起動遅延を分解、FaaScale がモデル転送と推論実行を重ねてスケールアウトを速くする。GPU が常に温まっていて全ノードが均質という前提から離れつつある。 ### 運用面の持ち帰り(SRE 目線) - 利用率は十分な指標ではない。忙しい ≠ 進んでいる ≠ SLO を守っている ≠ 保守が消化できている。 - ヘルスチェックは機能的正しさだけでは足りない。ピア比較 + オンライン監視 + オフラインスイープ。 - 障害復旧は再計算だけでは足りない。訓練は予備資源とチェックポイント、推論は KV 保護と不規則な GPU 可用性。 - 運用計画は固定 worst-case から確率的な意思決定へ。コスト関数と tail risk を明示する。 - グッドプット / 予備資源 / 確率的保守計画は、SRE の SLO・エラーバジェット・キャパシティ計画とほぼ同じ形。ただし両者を橋渡しする報告はまだほとんどない。**ここは空いている**。 ## 訓練システム(軽く触れる程度) - 並列化は「どの次元で割るか」から「どの計算をどの粒度で再配置するか」へ。 - DistCA: 長コンテキストで支配的になる core attention を attention task / attention server として本体から切り出す。 - MoEBlaze: MoE の token routing の中間テンソル実体化を減らす。効率は All-to-All だけで決まらない。 - veScale-FSDP: 量子化ブロックや optimizer 構造を壊さない shard。メモリ節約だけでなくモデル実装の意味を保つ。 - DreamDDP: 低帯域の地理分散訓練。層単位の部分同期を backward と重ね、収束率を見て同期対象を選ぶ。 - Keynote(Luke Zettlemoyer): 能力の多くは事前学習段階で埋め込まれ、ポストトレーニングはそれを引き出す操作という見方。少量高品質データ(LIMA)、トークナイザなしの Byte Latent Transformer、データ来歴ごとに専門家を分ける FlexOlmo。データを後から追加・削除・非公開化できる形でモデルに入れる方向。 ## 現地の感想(雑談枠) - AI インフラらしい話は意外に少ない。RDMA や IP CLOS のトポロジまで踏み込んでネットワークを話していたのは、さくらONE 以外にあと 1 件ぐらい。ML アプリと AI インフラの中間帯が広く扱われている印象。 - MLSys はまだ自分の専門外で、さくらONE の仕事で直接必要になる場面は多くない。ただ隣接分野の地図をぼんやり持っておくのは効く。 - 日本人参加者は我々以外に 2 人ぐらい。AnyScale の田仲さん(元 Microsoft、DeepSpeed 開発)と、NEC 研究所で LLM サービングをやっている方。 - SC や KubeCon のように、日本人コミュニティ単位で行く形があってもよさそう。 ## 補足 - レポート本文はエージェントで骨子を作った。手元の録音データ + 各講演の論文・スライド PDF を入力にして、全体傾向とトピック別傾向を整理させ、個別講演のまとめも生成した。作文規範は japanese-tech-writing を使用。 - 発表ごとの一覧は [[MLSys2026 参加レポート]] の付録 A、用語集は付録 C。 - 研究所ブログ: [MLSys 2026でAI/HPCクラスタ「さくらONE」の設計・性能評価・運用データ分析を発表](https://research.sakura.ad.jp/blog/mlsys2026-report)