2026__MLSys2026__公開向けレポート

# MLSys 2026 公開向けレポート ## TL;DR MLSys 2026 は、機械学習モデルそのものよりも、それを訓練し、配備し、評価し、運用するシステムが競争力を決める段階に入ったことを示した会議だった。本稿はこの変化を三つの転換として捉える。 - **推論サービング**: GPU 上でモデルを速く回す問題から、KV キャッシュという状態を管理する分散システムへ広がった。 - **開発**: AI エージェントがカーネルからシステムコードまで書き始めた結果、生成ではなく検証が律速になった。 - **クラスタ運用**: 利用率と事後復旧の管理から、グッドプットと予防的な健全性の管理へ移った。本文は推論サービング、訓練、クラスタ運用と耐障害性、AI for Systems の 4 章で構成し、8 本の Keynote は関係する章に織り込む。特にクラスタ運用と耐障害性は、SRE やインフラ運用の読者が MLSys へ入る入口として詳しく扱う。個々の発表の一覧は付録の発表カタログにまとめる。 ## MLSys とは何を扱う分野か MLSys は Machine Learning and Systems の略であり、機械学習と計算機システムの接点を扱う分野である。 MLSys 2026 は、2026 年 5 月 18 日から 22 日にかけて米国ワシントン州 Bellevue の Hyatt Regency Bellevue で開催された第 9 回会議である [1][2][3]。機械学習研究だけを見ると、モデル構造、損失関数、データ、評価指標が主役に見える。しかし実際の AI サービスでは、同じモデルでも、どの GPU に載せるか、どのように並列化するか、要求をどの順番で処理するか、障害時にどこまで巻き戻るかによって、費用、遅延、品質、可用性が大きく変わる。 MLSys はこの実装と運用の層を研究対象にする。本稿で繰り返し使う用語(推論、サービング、プリフィル、デコード、KV キャッシュ、グッドプット、MoE、ストラグラー、SLO)は、付録Cの用語集にまとめた。本文でも、各語の初出時に短い定義を添える。 ## MLSys 2026 の三つの転換 Modular の recap は、MLSys 2026 の推論系発表から、エージェントによるカーネルやシステムコードの生成、KV キャッシュの支配的サブシステム化、異種ハードウェアの積極活用という三つの流れを挙げている [4]。 Ashok Emani の LinkedIn recap は、MLSys 2026 を systems-driven AI の会議として捉え、ツール呼び出しと閉ループ評価をエージェント実用化の中心条件に挙げている [5]。本稿は、これらの観察と 8 本の Keynote を合わせて、MLSys 2026 を三つの転換として整理する。一つ目の転換はサービングに起きた。 LLM サービングは、入力を受け取りモデルを一回実行して出力を返すリクエスト処理から、状態を管理する分散システムへ広がった。以前なら推論エンジン内部の実装詳細だった **KV キャッシュ**(アテンション計算で再利用する key と value の中間状態)が、長コンテキスト、検索拡張生成、エージェントの履歴を支える共有資源として独立した設計対象になった。プリフィルとデコードの分離、異種ハードウェアの活用、SLO と電力の同時制御も、この転換の一部である。第1章で扱う。二つ目の転換は開発に起きた。 AI エージェントは利用者向けアプリだけでなく、GPU カーネル、システムコード、ハードウェア記述の生成に入り始めた。その結果、律速はコードを書くことから、生成されたものを測り、隔離し、採用する検証側へ移った。第4章で扱う。三つ目の転換は運用に起きた。巨大クラスタでは、GPU が忙しく見えることと、訓練が進み SLO が守られていることは別である。測定は利用率から**グッドプット**(有用な進捗に寄与した処理量)へ、障害対応は事後復旧から予防的な健全性管理へ移った。第3章で扱う。大規模訓練の並列化(第2章)は、この三つの転換が交わる場所にある。長コンテキストと MoE は並列化の再構成を迫り、クラスタの故障と異種性は訓練の進捗を直接削る。従来の MLSys は、訓練をどう速くするか、推論をどう安くするか、モデルをどう小さくするかという問いに分かれて見えやすかった。 MLSys 2026 では、その境界が薄くなった。エージェントがコードを生成すれば、評価とセキュリティがシステム問題になる。長コンテキストが増えれば、KV キャッシュがメモリ階層と障害復旧の問題になる。クラスタが巨大化すれば、利用率ではなくグッドプットで運用を見直す必要がある。 ### 本稿の構成と読み方本文の 4 章は、この三つの転換を AI インフラのスタック上に配置したものである。 ```mermaid flowchart BT P["電力とデータセンター"] --> H["アクセラレータとネットワーク"] H --> K["カーネル、コンパイラ、ランタイム"] K --> S["推論サービング(第1章)"] K --> T["訓練(第2章)"] O["クラスタ運用と耐障害性(第3章)"] -. 観測と制御 .-> S O -. 観測と制御 .-> T A["AI for Systems(第4章)"] -. コード生成と検証 .-> K ``` 8 本の Keynote は独立した章にせず、関係する章の中で扱う(講演と章の対応は付録Bを参照)。本文で個別に解説する発表は代表的なものに絞り、会議全体の発表は付録Aの発表カタログにまとめた。初学者は第1章から順に読むとよい。 SRE やインフラ運用の読者は、第3章から読み始めて自分の専門に引き寄せる読み方もできる。 ## 第1章推論サービング: 状態を管理する分散システムへ LLM サービングの基本は、限られた GPU メモリと計算時間を多数の要求で共有することにある。 **推論**とは訓練済みモデルが入力から出力を生成する処理であり、**サービング**とはその推論を利用者やアプリケーションからの要求に応じて継続的に提供する仕組みである。 vLLM のようなページ化 KV キャッシュ、連続バッチング、prefix キャッシュ、要求スケジューリングは、この制約に対する標準的な道具になっている。これらは、同時要求数を増やし、トークン生成の待ち時間を下げ、GPU メモリの断片化を抑えるために使われる。ただし従来の設計では、KV キャッシュは推論エンジン内部の一時状態として扱われがちだった。長コンテキスト、RAG、エージェントメモリでは、その一時状態が巨大になり、要求間で再利用できる資産にもなる。 MLSys 2026 のサービング系発表は、この資産をどう管理するかという問いを共有している。キャッシュをどこへ置くか、どの精度で残すか、どの要求間で共有するかが、計算量と同じくらい重要な設計変数になった。 ### KV キャッシュのデータ層化 Yuhan Liu の Keynote は、KV キャッシュを AI ネイティブなデータ型として位置づけた [8]。 KV キャッシュは、過去トークンに対応する key と value の中間状態であり、次のトークンを生成するときに再利用される。長い会話や検索拡張生成では、この状態が巨大化し、GPU メモリを圧迫する。 LMCache の見方では、KV キャッシュは保存、圧縮、転送、共有、再利用、検索の対象になる [8]。 GPU メモリに収まらない部分を CPU メモリやリモートストレージに逃がし、必要な時点で戻す設計が必要になる。講演では、CacheGen による圧縮や、CacheBlend による非 prefix な再利用が紹介された。非 prefix な再利用とは、プロンプトの先頭から完全一致する場合だけでなく、検索拡張生成のように一部の文脈が共有される場合にも KV を再利用する考え方である。これは、LLM サービングを単なるバッチ処理ではなく、状態管理を伴うデータシステムとして見る発想に近い。 Modular recap が指摘した KV キャッシュの中心化は、この講演と直結する [4]。一般セッションの発表も同じ方向を向いており、再利用の単位は、完全一致する prefix から、文書片、会話履歴、検索結果、エージェント記憶へ広がった。 ContextPilot は、prefix cache の前提を広げた発表である [19]。従来の再利用は、プロンプトの先頭から同じ文字列が続く場合に強い。しかし RAG やエージェントでは、同じ文書片や会話履歴が別の位置や別のセッションに現れる。 ContextPilot は、コンテキストアラインメント、重複排除、アノテーションを使い、非完全一致の文脈を再利用しやすくする [19]。長コンテキスト推論では、再利用の単位を文字列 prefix から文脈部品へ移すことが効く。 Kitty は、KV キャッシュ圧縮の代表発表である [18]。標準的な KV キャッシュは FP16 や BF16 で保持されることが多く、長コンテキストと大きなバッチで GPU メモリを圧迫する。 Kitty は key cache のチャネル感度差を使い、大部分を 2 bit にし、重要チャネルだけ精度を上げる [18]。単純な一様量子化ではなく、精度劣化が出やすい場所にだけ予算を割く。 KV キャッシュを保存するか捨てるかではなく、どの部分に精度を残すかを選ぶ方向である。 BatchLLM は、大量の要求をまとめて処理するオフライン推論を扱う [45]。オンライン対話向けの continuous batching は有効だが、グローバルに見れば同じ prefix を何度も読み直している場合がある。 BatchLLM は、あらかじめ共有 prefix を特定し、prefix-sharing group と token batching で処理順を決める [45]。ここでは cache hit は偶然起きる高速化ではなく、バッチ構成を決める計画情報になる。検索結果生成やランキングなど、同じ指示文を大量データへ適用する業務で意味が大きい。 LEANN は、RAG の検索インデックスを低ストレージ化する [46]。標準的なベクトル検索では、埋め込みベクトルとグラフ構造が元データより大きくなることがある。 LEANN は、埋め込みを常時保持せず、必要時に再計算し、検索グラフを枝刈りする [46]。生成が支配的な RAG では、検索側で少し計算が増えても、ストレージを下げる価値がある場合がある。オンデバイス RAG や大規模社内検索では、このトレードオフが実用上の制約になる。 From Tokens to Layers は、MoE サービングの見方を変える発表である [47]。 **MoE**(Mixture of Experts)とは、入力ごとに一部の専門家ネットワークだけを動かして大規模化と計算効率を両立させるモデル構造である。標準的な chunked prefill はトークン方向に分割するため、MoE の expert weight をチャンクごとに読み直しやすい。 Layered Prefill は、処理単位をトークンからレイヤへ移し、プロンプト全体をレイヤ方向にまとめて処理する。 MoE では FLOP だけでなく重み移動が支配的になるため、分割軸を変えるだけでサービング性能が変わる。この発表は、MoE サービングを単なる All-to-All 最適化として見ないための入口になる。このほか、reasoning モデルの長い思考列で KV 生成と保存を文単位で省く SkipKV、アテンションヘッドの時間的安定性で KV を階層管理する FlexiCache など、KV 管理の発表は本会議で厚い一角を占めた [20][49]。 ### プリフィルとデコードの分離と異種ハードウェア LLM 推論は一つの処理に見えるが、内部では性質の異なる二つの段階に分かれる。 **プリフィル**はプロンプト全体を読み込んで初期状態を作る段階であり、入力トークン全体を処理するため計算集約的になりやすい。 **デコード**はその状態を使って次のトークンを順に生成する段階であり、一トークンずつ進むため逐次性が強く、メモリ帯域や KV キャッシュの配置に制約されやすい。従来は同じ GPU プール上で両者をまとめて処理し、バッチ化によって平均スループットを上げる方式が中心だった。しかし入力長、出力長、到着率が変わると、プリフィルとデコードの最適な資源比率はすぐに変わる。 MLSys 2026 では、プリフィルとデコードを分離し、それぞれに合う資源へ割り当てる設計が増えた。 GPU、CPU、専用アクセラレータ、superchip、異なる世代の GPU を、単なる余剰資源ではなく役割の異なる部品として扱う。 A Pragmatic Exploration of Prefill-Decode Disaggregation は、P/D 分離を万能な最適化ではなく、配備設計問題として扱う [50]。大きなモデル、長い入力、prefill-heavy なトラフィックでは分離の利点が出やすい。一方で、小さいモデルや decode-heavy なトラフィックでは、同じ GPU 上に置く構成が競争力を持つ場合がある。この発表は、固定の prefill 対 decode 比ではなく、負荷に応じた rate matching が必要だと示す。 P/D 分離はランタイム機能ではなく、継続的な配備制御の対象になる。 TriInfer は、この分離をマルチモーダル大規模モデルへ広げ、encode、prefill、decode の三段の分離実行と異種ハードウェア活用を組み合わせた [23]。 BOute は、モデルルーティングと GPU 配備を同時に扱う [21]。小さいモデルを安い GPU に、大きいモデルを高性能 GPU に置くだけでは、品質、遅延、費用の全体最適にならない。 BOute は、多目的ベイズ最適化により、モデル選択、ルーティング閾値、GPU 割当を同じ探索空間に入れる [21]。異種ハードウェア活用は、「余った GPU を使う」ことではない。モデル能力、品質要件、GPU 特性を対応づける設計である。 FaaScale は、サーバレス推論のスケールアウトを扱う [51]。従来のサーバレス方式では、モデルを完全にロードしてから推論を始めるため、大規模 LLM ではコールドスタートが大きい。 FaaScale は、モデルをブロック単位で転送し、完全な複製を待たずにパイプライン推論を始める [51]。バースト負荷では、平均スループットより、最初のトークンまでの時間と GPU 追加の速さが効く。この発表は、推論クラスタの弾力性をモデル転送と実行計画の問題として扱う。このほか、分散 LLM 推論で計算と通信を重ねる TokenWeave、プリフィル長の違いをキューと CUDA Graph bucket で扱う PLA-Serve も同じ流れにある [24][53]。 ### SLO と電力と品質の同時制御 **SLO**(Service Level Objective)とは、応答遅延、成功率、可用性などについてサービスが守るべき目標値である。配備設計では、平均スループットだけでなく、SLO、電力、モデル品質、GPU 単価、プリフィルとデコードの比率を同時に見る必要がある。これは推論基盤を、ランタイムの実装問題から、継続的な構成探索と制御の問題へ移す。特に電力最適化では、SLO を守ったうえでどこまで周波数や資源量を下げられるかが、性能最適化と同じ設計空間に入った。 Esha Choukse の Keynote は、この制御問題の射程を最も広く示した [7]。従来のサービングは、入力を受け取り、モデルを一回実行し、出力を返す処理として考えられがちだった。しかしエージェント型システムでは、モデル、ツール、検索、検証器、外部状態、複数ターンの計画が一つのワークフローを作る。この講演は、品質を単なるモデル精度ではなく、システム全体の資源配分として扱った。すべての出力を重い検証器に通せば品質は上がるかもしれないが、遅延と費用は増える。一方で危険な箇所だけを選択的に検証できれば、品質、遅延、費用の折り合いがよくなる。これは SLO と品質を同じ制御問題に入れる考え方である。講演では、Sherlock のような選択的検証の方向性と、Streamwise のような対話的な動画生成システムの方向性が示された。前者は、どのノードや出力を検証すべきかを学習し、不要な検証のオーバーヘッドを減らす。後者は、生成処理を有向非巡回グラフとして扱い、締切、ハードウェア、品質ノブをまたいで計画する。サービングは、モデルを速く動かすだけではなく、品質をどこで測り、どこで落とし、どこで回復するかを、ハードウェア、スケジューラ、検証器と一緒に設計する問題になった。 BEAM は、SLO を守ったあとに残る余裕を電力削減へ使う [22]。 LLM 推論では、prefill と decode で計算律速とメモリ律速の性質が違う。バッチサイズやチャンクサイズが変わると、最適な GPU 周波数も変わる。 BEAM は、チャンク、マイクロバッチ、GPU 周波数をイベント駆動で同時に調整する。高速化だけでなく、SLO の範囲内でどこまで低電力にできるかが論点になる。 SuperInfer は、superchip のメモリ階層を SLO 制御に使う [52]。 KV キャッシュが HBM を圧迫すると、単純な PCIe オフロードでは TTFT と token-by-token の遅延を守りにくい。 SuperInfer は、要求ごとの SLO 緊急度を用いて、HBM と CPU メモリの間でリクエストを先回りして移動する [52]。 NVLink-C2C のような帯域を、単なる退避経路ではなくスケジューリング対象にする点が特徴である。このほか、過負荷時に量子化レイヤを入れ替えて空いたメモリを KV キャッシュへ回す MorphServe、早期終了モデルを複数使い分ける HELIOS は、モデル品質そのものをサービング時の調整変数にする [54][55]。 ### 生成を待たせないカーネルと投機的復号生成モデル高速化の標準的な道具は、計算を減らすものと、同じ計算をよりうまくハードウェアへ載せるものに分かれる。 FlashAttention 系はアテンションのメモリ移動を抑え、投機的復号は軽い draft と重い検証を組み合わせ、早期終了や近似アテンションは不要な計算を省く。拡散モデルでは、生成ステップ数を減らすことが低遅延化の中心になる。これらの手法は、モデル出力を大きく変えずに計算量、メモリ移動、逐次依存を削ることを狙う。ただし、どの手法が効くかは、モデル構造、生成長、バッチサイズ、GPU 世代、実装されたカーネルに強く依存する。 MLSys 2026 の特徴は、単一アルゴリズムの改善ではなく、ワークロードとハードウェアの非対称性を前提にした点にある。 Tensor Core、共有メモリ、指数演算、通信帯域は同じ比率で伸びないため、古い世代でよかったカーネル設計が次世代でも最適とは限らない。投機的復号でも、理論上のトークン削減だけではなく、本番推論エンジンでのバッチング、KV 管理、検証の遅延が効く。 diffusion、3D Gaussian Splatting、点群処理も、低遅延な生成体験を作るという点では同じ問題を共有する。このため、アテンションカーネル、投機的復号、diffusion 生成、3D 生成、点群処理が、「生成を待たせない」ためのシステム設計として近づいた。 FlashAttention-4 は、Blackwell 世代の GPU で何が律速になるかを前提に attention を再設計する [25]。 Tensor Core 性能が伸びても、共有メモリ帯域や指数演算が同じ比率で伸びるとは限らない。 FlashAttention-4 は、大きなタイル、非同期 MMA、指数関数の近似、再スケーリングの省略、TMEM 利用を組み合わせる [25]。 FlashAttention 系は、単なるメモリ節約手法ではなく、GPU 世代ごとに再設計される標準 primitive になった。 BLASST は、密 attention の上に動的な sparsity を載せる [56]。従来の sparse attention は、学習時の構造や別途作ったマスクに依存しがちだった。 BLASST は、FlashAttention のオンライン softmax 中に得られる統計から、寄与の小さい block を実行時に判断する [56]。 prefill と decode の両方に使え、複数の attention 形態にも対応する。導入しやすい sparse attention kernel という点で、モデル側の変更を要求する手法と異なる。 Sparse Self-Speculative Decoding は、reasoning model の長い生成を対象にする [26]。通常の投機的復号は別の小型 draft model を用意するが、この発表は同一モデル内で軽い draft と正確な target を作る。 draft 側だけを sparse attention で軽くし、検証側は full attention で正しさを保つ。大規模 reasoning model では生成長が長いため、単発の低遅延化よりも、遅延検証、KV 管理、スケジューリングを含む設計が効く。 SpecDiff-2 は、draft token を 1 個ずつ出す前提を崩す [57]。 diffusion language model を使い、複数位置の候補を並列に提案する。単に token を当てるのではなく、検証器が連続して受理しやすい draft を作る方向で訓練する。投機的復号と diffusion acceleration が合流する発表である。一方で、Speculative Decoding: Performance or Illusion? は、投機的復号の高速化を vLLM など本番寄りの条件で再評価し、理論上のトークン削減がそのまま速度に変わるとは限らないことを示す [74]。 SwiftGS は、3D Gaussian Splatting の実行時間を GPU 上の sorting と rasterization から削る [58]。ガウシアン数を減らして画質を落とすのではなく、実行手順の冗長性を減らす。 adaptive early sorting、axis-shared rasterization、動的閾値により、既存の 3DGS pipeline に近い品質を保つ。生成モデル高速化が LLM と diffusion だけでなく、neural rendering へ広がっていることを示す。このほか、動画拡散をストリーミング生成へ載せる StreamDiffusionV2、点群の sparse convolution を高速化する Spira、GPU カーネル記述を移植しやすくする ParallelKittens なども同じ流れにある [72][59][60]。 ### エッジとオンデバイスへの広がりエッジやオンデバイス推論では、クラウド GPU の前提をそのまま持ち込めない。スマートフォン、ノート PC、衛星、ロボット、ブラウザでは、電力、メモリ、ネットワーク遅延、発熱、プライバシーが強い制約になる。量子化、蒸留、早期終了、端末向けランタイム、クラウドとエッジの分割実行は、この制約に対する標準的な道具である。しかしモデルを小さくするだけでは、実行基盤、メモリ階層、センサーや通信のタイミングまでは解決しない。特にマルチモーダルでは、画像、音声、テキスト、センサー入力がそれぞれ違う計算特性と遅延制約を持つ。 MLSys 2026 では、モデル圧縮より広い意味で、データ発生源と実行環境に近いところで推論を組み立てる方向が見えた。端末ランタイムは、研究用モデルを各社 NPU やモバイル GPU へ持ち込むための変換層ではなく、配備の標準層になりつつある。衛星や動画会議のような領域では、ネットワークに送ってから処理するのでは遅すぎる場合がある。この場合、現場で何を推論し、何を送信し、何を生成的に補完するかがシステム設計になる。 ExecuTorch は、オンデバイス AI の配備基盤として代表的である [28]。従来は、PyTorch で研究したモデルを ONNX、TFLite、CoreML、各社 NPU SDK へ変換し、その過程で量子化や演算意味の差を抱えやすかった。 ExecuTorch は、PyTorch からの export、Core ATen、バックエンド委譲、量子化、小型ランタイムをまとめる [28]。クラウド側の推論基盤だけでなく、端末側にも標準的な実行層を作る流れである。 Efficient, VRAM-Constrained xLM Inference on Clients は、クライアント推論の実用制約を扱う [68]。 PC やノート PC では、LLM が GPU メモリを独占できるとは限らない。この発表は、CPU と GPU のプロファイルに基づいてサブレイヤーを分割し、アテンション、KV キャッシュ、FFN の優先度を変えて配置する。全面量子化で精度を落とすのではなく、限られた VRAM の中でどの部分を GPU に残すかを決める。 EarthSight は、エッジ AI が分散システムになることを示す [29]。従来の衛星画像処理は、画像を地上へ下ろしてから解析するため、ダウンリンク機会が遅延を決める。 EarthSight は、衛星上でマルチタスク推論を行い、地上局が帯域予測と優先度を与える [29]。データ発生場所の近くで推論する理由は、低遅延だけではなく、帯域、電力、観測機会を制御するためである。 Rethinking DVFS for Mobile LLMs は、モバイル LLM の省エネを OS と SoC の制御問題として扱う [69]。既存の Android では、CPU、GPU、メモリの DVFS ガバナが独立に動き、互いに低利用率を見て周波数を下げることがある。 CORE は、prefill と decode の性質を分け、統合的に周波数設定を選ぶ。モデル圧縮だけではなく、端末の電力管理が LLM 推論性能を左右する。 REPARO は、動画会議の損失耐性を生成モデルで扱う [70]。従来は、再送や FEC でパケットロスを埋めるが、遅延や帯域の制約がある。 REPARO は、欠落したトークンやフレーム成分を生成的に補完する [70]。リアルタイム通信では、正確に届くまで待つより、遅延予算内で視覚品質を回復する設計が有効になる。このほか、attention を完全整数化する IntAttention、TinyML 向けの HyperTinyPW なども含め、エッジ系の発表一覧は付録Aにまとめた [67][71]。 ## 第2章訓練システム: 並列化とデータの再構成大規模 LLM 訓練では、単一 GPU にモデル、活性、オプティマイザ状態を載せることはできない。データ並列、テンソル並列、パイプライン並列、FSDP、MoE のエキスパート並列は、モデルとバッチを複数 GPU へ分けるための標準的な道具である。 AllReduce、ReduceScatter、All-to-All などの集合通信は、それぞれの並列化を成立させる基盤になる。従来の設計では、モデル構造に合わせて並列化方式を選び、その上で通信を隠すか、メモリを節約するかを調整することが多かった。しかし長コンテキスト、MoE、異種 GPU、低帯域リンクが組み合わさると、固定の並列化だけでは負荷の偏りを吸収しにくい。 MLSys 2026 では、並列化を固定した前提ではなく、注意計算、通信、メモリ、異種資源の形に合わせて再構成する方向が強まった。長コンテキストでは、アテンションが訓練全体の支配的な部分になり、sequence をどう分けるかだけでは不十分になる。 MoE では、エキスパートの配置、複製、token dispatch、中間活性、All-to-All の偏りが同時に効く。 FSDP や ZeRO 系の shard でも、量子化ブロックやオプティマイザ構造を壊さずに分割する必要がある。第1章の TokenWeave は分散推論側の発表だが、計算と通信を重ねる考え方は訓練の集合通信にも通じる [24]。このクラスタの進歩は、並列化を「どの次元で割るか」から、「どの計算をどの粒度で再配置するか」へ進めた点にある。 ### 並列化の再構成 DistCA は、長コンテキスト LLM 訓練で支配的になる core attention を分離する [27]。従来の context parallelism は sequence を分割して通信しながら attention を計算するが、計算量、メモリ、通信の不均衡が残る。 DistCA は attention task と attention server を導入し、attention だけを別単位で再バッチし、再配置する [27]。長コンテキスト部分をモデル本体から切り出すことで、固定の DP、PP、CP 構成に縛られにくくなる。 veScale-FSDP は、FSDP の柔軟性と性能のトレードオフを扱う [61]。標準的な FSDP や ZeRO は、パラメータを均等に shard しやすい一方で、量子化ブロックや optimizer 構造を壊しやすい。 veScale-FSDP は、構造を保った shard と通信バッファ設計により、既存モデルの構造を壊さず大規模化する [61]。大規模訓練では、単にメモリを節約するだけでなく、モデル実装の意味を保つことが必要になる。 MoEBlaze は、MoE 訓練のメモリ壁に焦点を当てる [62]。標準的な MoE 実装では、expert に送る token を物理的に並べ替え、大きな中間テンソルを保持する。 MoEBlaze は、軽量 index、on-the-fly gather、kernel fusion、activation checkpointing により、この実体化を減らす [62]。 MoE の効率は、All-to-All だけでなく、token routing の中間表現をどれだけ作らずに済むかにも左右される。 FCP は、context parallelism のスケジューリングを強化する [63]。 RingAttention 系は実装が素直だが、sequence 長や attention workload が不均一な場合に負荷が偏る。 FCP は、固定サイズ block を単位に分割し、P2P 通信と congestion-free planning で実行順を決める。 DistCA が attention を分離する方向なら、FCP は context parallelism 自体をより柔軟にする方向である [27][63]。 DreamDDP は、低帯域の地理分散訓練を扱う [66]。標準 DDP は頻繁な全量同期を前提にし、WAN や低帯域リンクでは通信が支配的になる。 DreamDDP は、毎回全層を同期せず、層単位の部分同期を backward と重ねる [66]。通信量を減らすだけではなく、収束率を意識して同期対象を選ぶ点が特徴である。このほか、DP、PP、TP、EP、CP を精度一貫性を保ちながら elastic に変える FlexTrain、MoE の blocking All-to-All を残差経路で隠す FarSkip-Collective、異種 GPU で訓練を組み立てる HexiScale などが同じ流れにある [64][65][40]。 ### データと事前学習の見直し(Luke Zettlemoyer) Luke Zettlemoyer の Keynote は、事前学習をデータとアーキテクチャの観点から見直した [13]。近年はポストトレーニングや強化学習が注目されるが、講演では多くの能力が事前学習段階ですでに埋め込まれている可能性が強調された。ポストトレーニングは、その能力を引き出す操作として理解できる場合がある。データの重要性を示す例として、少量の高品質データで大きな効果が出る LIMA や、数学や推論の事例が挙げられた。これは、事前学習データの構成、来歴、品質を、単なる巨大コーパスの量ではなく、後工程で引き出せる能力の源泉として扱う発想である。アーキテクチャ面では、トークナイザを使わない Byte Latent Transformer と、データ来歴ごとに専門家を分ける FlexOlmo が紹介された。前者はノイズや表記揺れに強い表現を狙う。後者は、データを混ぜるだけでなく、追加、削除、非公開化しやすい形でモデルに入れる方向である。この講演は、訓練システムの課題をデータ管理へ広げる。巨大クラスタを効率よく使うだけでなく、どのデータをどの専門家に入れ、後からどう差し替えるかが、システム設計の一部になる。 MLSys 2026 では、事前学習も単なる学習レシピではなく、データ、モデル、クラスタ運用をまたぐ問題として扱われた。 ## 第3章クラスタ運用と耐障害性: 利用率からグッドプットへクラスタ運用と耐障害性は、MLSys 2026 の中でも特に実運用色が強い領域だった。従来の発想では、GPU を多く確保し、NCCL テストや GPU バーンインを通し、障害が起きたらチェックポイントから再開する、という運用が中心だった。しかし frontier-scale の訓練や大規模推論では、この受け身の方式だけでは不十分である。受け身の方式が不十分になる理由は三つある。 - クラスタが大きくなるほど、どこか一つのノードが遅くなる確率が上がる。 - 同期型の訓練では、最も遅いノード(**ストラグラー**)が全体のステップ時間を決める。 - 推論サービングでは、障害復旧のために KV キャッシュや重みを再構成する時間が、そのまま利用者の遅延や失敗率に現れる。このため MLSys 2026 では、利用率、NCCL テスト、バーンイン、単純な再計算、全複製、固定 worst-case の保守計画から、より細かいグッドプット、健全性、予備資源、軽量復旧、確率的予測へ進む流れが見えた。本章の各発表は、次の三つに分けて並べる。 - **測る**: グッドプットと観測基盤 - **備える**: 健全性管理と確率的計画 - **耐える**: 障害を前提にしたサービング ### 知能のアーキテクチャ(Amin Vahdat) Amin Vahdat の Keynote は、AI の進歩を支える計算基盤を、データセンター全体の再設計問題として扱い、本章のスケール感を与えた [12]。講演では、AI が mind multiplier として社会的需要を増幅し、計算需要も急速に伸びるという前提が置かれた。この需要に応えるには、単一チップの高速化だけでは足りない。焦点は、エネルギー、データセンター、アクセラレータ、ネットワーク、ソフトウェアを含む垂直統合である。 TPU のような専用アクセラレータ、訓練向けと推論向けのチップ分化、ボード上の接続、光回線交換、データセンター内通信、広域ネットワークが一体で設計される。 AI インフラは、ラックに GPU を並べるだけではなく、電力と通信を含む巨大な計算機として考える必要がある。ソフトウェア側では、フリート管理とグッドプットが重要になる。アクセラレータが忙しく見えても、それが有用な訓練進捗や推論品質に結びつかなければ意味がない。推論カーネル、KV キャッシュ、スケジューラ、障害復旧は、すべて大きな知能インフラの部品である。個別最適ではなく、スタック全体で効率を上げることが、今後の MLSys の中心課題になる。 ### 測る: 利用率からグッドプットへ #### ML Productivity Goodput: フリート効率の分解 ML Productivity Goodput は、利用率から生産性へ測定軸を移し、フリート効率を Scheduling Goodput、Runtime Goodput、Program Goodput の積として捉える [32]。 Scheduling Goodput は、必要な資源が同時に割り当てられているかを測る。 Runtime Goodput は、割り当てられた時間がチェックポイントに残る進捗へ変わったかを測る。 Program Goodput は、進んでいる時間が理論的な実行時間にどれだけ近いかを測る。この分解の価値は、単に指標を増やしたことではない。従来の capacity、occupancy、duty cycle は、資源が存在するか、割り当てられているか、動いているかを測る。しかし分散学習では、全 GPU が動いていても、データローダを待っている、チェックポイント後に巻き戻される、コンパイラが非効率なコードを出している、通信と計算が重なっていない、といった理由で生産性が失われる。 MPG は、障害や性能劣化を単なるインシデントではなく、フリート生産性の損失として扱い、損失がどの層で出ているかを示す。この分解は、運用改善の責任境界をスケジューラ、ランタイム、プログラムへ分ける。これは SRE 的にも重要である。可用性だけを上げても、実験が進まなければ研究開発速度は上がらない。逆に、瞬間的な利用率を下げる予備資源や保守が、長期のグッドプットを上げる場合がある。この考え方は、CATWILD と AIRS にもつながる [75][76]。 CATWILD は、実フリートから profile を集め、XLA の graph-level flag と op-level tile を offline に探索し、安全に配信する [75]。標準的な compiler autotuning は、単一ジョブや単一 kernel の探索に閉じがちだが、CATWILD は、構成の陳腐化、配信リスク、検証、投資対効果を含む fleet-wide compiler operations として扱う [75]。 AIRS は、Google Search の LLM autorater のような評価用 LLM 推論を、cache、queue、batch、quota、back-pressure、priority を備えた共有 TPU プール上で大規模に運用する [76]。 MPG が「どこで有用な進捗が失われたか」を分けるなら、CATWILD と AIRS は、観測した損失を自動改善や評価フリート運用へ戻す例である [75][76]。 #### XProf と Chakra: 観測できなければ改善できない XProf は、大規模 ML ワークロードのプロファイリングをスケールさせるための基盤である [33]。大規模分散ジョブでは、単一プロセスのプロファイルを取るだけでは、ホスト側の待ち、デバイス側の実行、通信同期、コンパイル、I/O の関係が見えない。また、詳細トレースを全ノードから集めると、観測そのものが重くなる。 XProf の価値は、ホストとデバイスをまたぐトレース、低オーバーヘッドの計測、時刻同期、分散処理による分析を一つのプロファイリング体験に近づけた点にある [33]。クラスタ運用では、観測の粒度が粗いと、ストラグラーを平均値の中に埋めてしまう。一方で観測が重すぎると、本番ジョブを妨げる。 XProf は、この二つの間で実用的な観測基盤を作る試みであり、MPG のようなフリート指標と対になる [33]。 MPG がどの層で生産性が落ちたかを示すなら、XProf はその原因をコード、カーネル、通信、待ち時間まで掘る道具になる [33]。 MLCommons Chakra は、実行トレースを交換可能な基盤にする [30]。固定ベンチマークだけでは、モデル、並列化、通信、ハードウェアの共同設計に必要な依存関係が見えにくい。 Chakra は、計算、通信、依存を標準形式のトレースとして表現する。これにより、シミュレータ、エミュレータ、ハードウェア設計者が同じワークロード表現を使える。まとめると、MLSys 2026 の観測基盤は、profile を見る道具(XProf)、trace を交換する形式(Chakra)、生成物を継続評価する基盤へ分かれている。三つ目の継続評価基盤は、AI 生成カーネルの評価と不可分なので、FlashInfer-Bench として第4章で扱う [78]。 #### SAKURAONE: オープン Ethernet の AI HPC と実ワークロードの観測 SAKURAONE は、100 ノード、800 基の H100 GPU、2 PB の all-flash Lustre、SONiC と RoCEv2 による 800 GbE の leaf-spine 構成を持つ AI HPC システムである [38]。発表の価値は、システム構成そのものに加えて、単一テナントの LLM 開発環境における実ワークロードの観測を示した点にある。観測では、小規模ジョブが件数では多数を占める一方で、GPU 時間では少数の大規模ジョブが支配的になる。これは HPC でもよく知られた偏りだが、LLM 開発環境でも同じ構造が現れる。また、開発フェーズが進むにつれて、初期の大規模訓練から中規模の反復実験へ資源利用が移る。この発表は、クラスタ運用を平均値で見てはいけないことを示す。ジョブ件数の多さと GPU 時間の多さは別であり、キャンセル、障害、ネットワーク、NVLink、PCIe、ストレージが複合的に効く。オープンな Ethernet スタックで大規模 AI クラスタを構成する試みは、専用ネットワークだけに依存しない運用選択肢としても重要である。 ### 備える: 予防的な健全性管理と確率的な運用計画 #### Guard: NCCL テストとバーンインを通過するグレーノードを検知する Guard は、大規模訓練クラスタのストラグラー検知とノード健全性管理を扱う [34]。問題設定は明快である。 NCCL テストや GPU バーンインは、主に機能的な正しさや短時間の負荷耐性を見る。しかし本番訓練では、クラッシュしないが遅いグレーノードが、何日も何週間もグッドプットを削る。 Guard は、オンライン性能モニタリングとオフラインノードスイープを組み合わせる [34]。オンライン側では、同じジョブ内のピアノードと比較しながら、GPU 温度、クロック、消費電力、ネットワーク転送率、エラー、ステップ時間を監視する。固定しきい値ではなく、同じ役割のノード間の相対比較を使うため、ワークロードや機種差にある程度適応できる。オフライン側では、本番投入前や隔離後にノードスイープを実行し、演算性能と通信性能を現実的な負荷で検証する。これにより、短時間テストでは見逃すサーマルスロットリング、ネットワーク経路劣化、GPU メモリや電力の不安定性を発見しやすくなる。発表ノートでは、Guard により MFU が最大 1.7 倍改善し、実行間のステップ時間分散が 20% から 1% に下がったと報告されている [34]。この進歩は、障害対応を事後復旧から予防的な健全性管理へ移す点にある。クラスタ運用では、障害を完全になくすことはできない。しかし、遅いノードを早く見つけ、隔離し、再投入前に資格確認することで、長期の訓練グッドプットを守れる。 Guard の設計は、ML を使う運用制御にも一般化できる [34]。 Virtual Machine NUMA Placement at Scale は、平均性能を学習しながら tail 側の異常を shielding する発表であり、When Machine Learning Isn't Sure は、ML 予測が不確かなときにヒューリスティックへ退避する考え方を扱う [40]。本番運用で ML を使う場合、予測が当たる平均ケースだけではなく、外れたときの逃げ道を設計する必要がある。 #### Sparing Strategies: 予備資源は無駄ではなく保険である Sparing Strategies は、Meta の大規模 LLM 訓練クラスタにおける予備資源の設計を解析する [35]。単純に考えると、予備 GPU は使われていないので利用率を下げる。しかし実際には、障害時にすぐ置き換えられる資源がなければ、巨大な同期ジョブ全体が止まり、チェックポイントからの復旧、再スケジューリング、巻き戻しで大きな損失が出る。この発表の重要点は、予備資源を経験則ではなく、グッドプット最大化の設計変数として扱ったことである。コンピュートブロックサイズ、ブロック間スペア、ブロック内スペア、故障率、修理時間、チェックポイント周期、配置制約をモデルに入れる。連続時間マルコフ連鎖により、障害と修理の確率過程を近似し、どの構成が長期のグッドプットを上げるかを比較する。ここでは、予備資源の効果は単に障害時の待ち時間削減にとどまらない。ブロック内スペアがあると、使われていない電力枠を稼働 GPU に再配分できる場合がある。一方で、並列化の配置制約により、スペアリングで節約したはずの容量が stranded resource になることもある。つまり、予備資源はハードウェア、電力、並列化、スケジューリングをまたぐ設計問題である。 Sparing Strategies は、利用率だけを見る運用への反例である。短期的には空いている GPU が、長期的には訓練ジョブを止めないための保険になる。クラスタ規模が大きいほど、この保険の設計を数理的に扱う必要がある。 #### Acela: 固定 worst-case 保守から確率的な保守計画へ Acela は、データセンターのソフトウェアアップグレード時間を予測し、保守スケジュールの利用効率を上げる [39]。従来の保守計画では、アップグレードにかかる時間を安全側の固定 worst-case として見積もりやすい。この方式は失敗を避けやすいが、保守ウィンドウを過小利用し、多くの作業を後回しにする。 Acela は、量子化回帰、SLO を意識したモデル選択、ストラグラーを意識した訓練により、過小予測と過大予測の非対称なコストを扱う。過小予測はウィンドウ超過やキャンセルを招く。過大予測は本来入れられる作業を捨てる。したがって、平均誤差を最小化するだけでは不十分であり、運用上の費用関数に合わせた予測が必要になる。クラスタ運用の観点では、Acela は AI クラスタ固有の発表ではないが、MLSys 2026 の重要な流れに合っている。固定 worst-case を守るだけの運用から、リスクを定量化して保守枠を使い切る運用へ進んでいる。これは MPG や Sparing Strategies と同じく、保守、障害、空き資源をグッドプットの設計変数にする発想である。 Sparing Strategies は予備 GPU を、Acela は保守時間を、Virtual Machine NUMA Placement at Scale は配置リスクを扱い、いずれも固定ルールを守る運用ではなく、コスト関数と tail risk を明示して運用判断を行う [35][39][40]。 ### 耐える: 障害を前提にしたサービング #### RaidServe: 推論サービングの GPU 欠損を前提にする RaidServe は、GPU が部分的に利用不能になる状況でも、高性能な tensor-parallel LLM サービングを続けるためのシステムである [36]。標準的な tensor parallelism は、同じ数の GPU が正常に揃っていることを前提にしやすい。しかし実運用では、一部 GPU が壊れる、退避する、別ジョブに取られる、性能が落ちるといった不規則な状態が起きる。 RaidServe は、非一様なテンソル並列、循環的な KV キャッシュ配置、hybrid attention、負荷を見たルーティングを組み合わせる [36]。さらに、KV キャッシュの予防的バックアップと、必要時の重み復旧により、再計算や全複製のコストを避ける。発表では、障害時の復旧レイテンシを大幅に下げ、irregular GPU availability の下でスループットを改善する結果が示された [36]。この発表の意味は、推論クラスタを完全に均質で正常な GPU 集合として見ない点にある。訓練ではストラグラーがステップを遅らせる。推論では GPU 欠損が要求の遅延や失敗に直結する。 RaidServe は、障害を例外ではなく通常状態の一部としてサービング設計に入れる方向を示している [36]。この論点は cold start や serverless scaling にも広がる。 Breaking the Ice は vLLM 起動遅延を分解し、第1章の FaaScale はモデル転送と推論実行を重ねてスケールアウトを速くする [77][51]。推論クラスタは、GPU が常に温まり、モデルが常に載り、全ノードが均質に動くという前提から離れつつある。 #### GhostServe: KV キャッシュを軽量に守る GhostServe は、LLM サービング中の transient KV キャッシュを軽量に保護する [37]。長いコンテキストや会話型ワークロードでは、KV キャッシュが高価な状態になる。障害時に KV キャッシュを失うと、プロンプト全体を再計算する必要があり、利用者の応答遅延が大きくなる。単純な対策は、KV キャッシュを丸ごと複製することだ。しかし全複製はメモリを大きく消費する。もう一つの対策は、失ったら再計算することだ。しかし長コンテキストでは再計算が重い。 GhostServe は、その中間として、ホストメモリに erasure coding のパリティ断片を置き、軽量なチェックポイントと復旧を行う [37]。この発表は、KV キャッシュを性能最適化だけでなく耐障害性の対象として扱った点で重要である。第1章の LMCache が KV キャッシュをデータ層として扱ったのに対し、GhostServe はそのデータ層を障害からどう守るかを扱う [8][37]。長コンテキスト時代の推論サービングでは、キャッシュを保存するか捨てるかだけでなく、どの程度の冗長性で守るかが設計変数になる。 ### 運用上の含意これらの発表を合わせると、クラスタ運用の標準像はかなり変わる。 - **利用率は十分な指標ではない。** GPU が忙しいことと、訓練が進んでいること、推論 SLO が守られていること、保守が予定通り消化されていることは別である。 - **ヘルスチェックは機能的正しさだけでは足りない。** NCCL テストとバーンインを通過しても、本番ワークロードで遅いノードは残る。Guard のように、ピア比較、オンライン監視、オフラインスイープを組み合わせる必要がある [34]。 - **障害復旧は再計算だけでは足りない。** 訓練では予備資源とチェックポイントが、推論では KV キャッシュ保護と不規則な GPU 可用性への対応が必要になる。RaidServe と GhostServe は、推論サービングでも耐障害性が一級の設計課題になったことを示している [36][37]。 - **運用計画は固定 worst-case から確率的な意思決定へ移る。** Sparing Strategies は予備資源を確率モデルで選び、Acela は保守時間を費用関数付きで予測する。この方向は、AI クラスタを単なる計算資源ではなく、故障し、劣化し、修理され、再配置される生産システムとして扱うものである。 ## 第4章 AI for Systems: 生成より検証へ従来のシステム最適化では、人間がカーネル、演算子、スケジューラ、コンパイラ規則を設計し、オートチューナがその範囲内を探索していた。探索空間はテンプレート、パラメータ、既存の手書き実装に強く制約される。 CI とベンチマークは退行を検出できるが、新しい設計候補を自分で増やすわけではない。このため、性能改善は熟練者の仮説、プロファイリング、実装、再測定の反復に依存していた。 MLSys 2026 では、この反復に LLM エージェントが入り始めた。エージェントは候補設計を生成するだけでなく、プロファイル、テスト、リンタ、シミュレータ、サンドボックス、監査ログと接続される。これにより、設計空間は人間が事前に列挙したチューニング範囲から、生成されたコードやハードウェア記述を含む広い範囲へ広がる。一方で、生成物を採用するには、正しさ、性能、不正な近道、保守性を判定する評価システムが必要になる。この領域の進歩は、「AI が書く」ことそのものではなく、「AI が書いたものをどう測り、隔離し、採用するか」がシステム研究の対象になった点にある。 8 本の Keynote のうち 4 本がこの問題に集中したことも、MLSys 2026 の重心を示している。 ### 保守者の視点: 生成の民主化と保守の負荷(Roger Wang) Roger Wang の Keynote は、AI エージェントによってオープンソース開発が簡単になるという楽観論に対し、保守者側の負荷を扱った [6]。 vLLM のような広く使われるシステムでは、外部からのプルリクエストが増えるほど、コード量ではなく、設計整合性、検証、レビュー、長期保守が律速になる。講演の中心は、AI が生成したコードそのものよりも、そのコードがどの問題を解こうとしているのか、既存設計とどのように整合するのかを人間が理解し続ける必要があるという点にある。ローカルなバグ修正は、システム全体の抽象化を壊すことがある。ベンチマークだけを通す修正は、症状を隠して根本原因を残すことがある。報酬付きの issue や bounty は、AI エージェントによる低品質な投稿を増幅しうる。この講演は、AI エージェント時代の開発速度を否定していない。むしろ、速度が上がるほど保守者が持つべき判断能力が変わると述べている。人間の価値は、構文を書くことから、問題を選び、設計を説明し、変更の責任を引き受けることへ移る。したがって保守者は、ロードマップ、設計文書、レビューしやすい粒度、CI、ベンチマーク、会話の場を整備する必要がある。 AI がシステムを作るなら、システム側は AI の出力を検証し、受け入れ、拒否し、長期的に保守する仕組みを持たなければならない。エージェントは開発者の代替ではなく、保守プロセスに新しい入力源を追加する存在として扱うべきである。 ### 報酬ハックと出力空間の設計(Mark Saroufim、Lidong Zhou) Mark Saroufim の Keynote は、AI が GPU カーネルやシステムコードを書く時代の評価問題を扱った [10]。 GPU MODE の leaderboard では、LLM を使って多くの参加者が高性能カーネルを提出する。これは、専門家だけが GPU カーネルを書けるという前提を崩す。一方で、提出されたコードは必ずしも信頼できない。講演では、出力を固定値にする、同期を避けて計測をだます、キャッシュを悪用する、テスト時だけ正しく見せるといった報酬ハックが紹介された。これは競技システムだけの問題ではなく、AI が自動最適化するすべての環境に現れる。講演の焦点は、AI が生成したコードを AI が監査する形の Kernel Guard である [10]。ただし、監査 AI を置くだけでは十分ではない。競技者、攻撃者、監査者、評価基盤が相互に進化する閉ループを作る必要がある。ここでも、単発のベンチマークではなく、評価系そのものの設計が中心になる。 Lidong Zhou の Keynote は、この問題への一つの答えとして、AI をシステムの外部利用者ではなく、システムの共同設計者として扱う構図を提示した [11]。講演のキーワードは system intelligence である。これは、AI を使ってシステムを動かすだけでなく、システムが AI を取り込みながら自己改善する方向を指す。例として、集合通信スケジューリングが扱われた。 AI に全コードを自由生成させるのではなく、スケジュールという限定された出力だけを生成させ、検証、コード生成、実行はシステム側が担う。この分担により、AI の探索能力を使いながら、実行の正しさと安全性を保てる。もう一つの例は、形式検証である。 AI に仕様や証明を書かせると、証明を省く、仕様を弱める、前提条件を強めるといった形で検証器をだますことがある。そのため、人間が上位意図と信頼境界を定め、AI がその内部で証明の鎖を埋める構造が必要になる。二つの講演はよく響き合う。 AI に自由度を与えるほど成果は出るが、同時に検証可能性を失いやすい。 MLSys 2026 の共通教訓は、AI をシステムに入れるなら、出力空間を設計し、検証可能なインターフェースを作るべきだという点にある。 ### エージェント型開発を支える基盤 AccelOpt は、AI がシステムコードを書く流れを最も直接に示す発表である [14]。対象は AWS Trainium の NKI カーネルであり、公開知識が多い CUDA よりもエージェントの探索能力が試される。システムは候補生成、実装、プロファイル、正当性検証、成功例からの知識抽出を繰り返す。一回のコード生成ではなく、失敗を次の設計候補へ戻す閉ループが特徴である。この点で、Mark Saroufim の Keynote が警告した報酬ハック問題ともつながる [10]。 OpenHands は、エージェント型開発をデモから運用基盤へ移すための発表である [15]。中心はモデル能力ではなく、状態、実行環境、ツール、秘密情報、サンドボックス、リモート実行をどう分離するかである。イベントソーシングにより、会話とツール実行を再生できる単位として残し、クラッシュ復旧と監査を可能にする。エージェントがコードを書くほど、実行ログ、権限境界、失敗時の復元が開発基盤の一部になる。 Agentic Operator Generation for ML ASICs は、AI 生成を性能チャンピオン競争ではなく、バックエンド網羅性に使った例である [43]。新しい ML ASIC では、少数の重要カーネルだけでなく、多数のフレームワーク演算子を安定して動かす必要がある。この発表は、ATen 演算子実装を生成し、リンタ、JIT、実機またはシミュレータ、OpInfo テストを通して失敗を構造化して返す。 AI が自由に書いたコードをそのまま採用するのではなく、既存の検証パイプラインへ押し込む設計である。 ADR は、エージェントを作る側ではなく、エージェントを監視する側のシステムである [41]。従来の EDR はファイル、プロセス、ネットワークを観測するが、エージェントの意図、推論、ツール呼び出しの連鎖は見えにくい。 ADR は、エージェントセッションを観測し、危険なツール利用やポリシー違反を検出する。エージェントが社内システムへ接続されるほど、検知対象は OS イベントだけでなく、プロンプトから実行結果までの流れになる。 VeriMoA は、LLM によるハードウェア生成をエージェント構成の問題として扱う [42]。 HDL は通常のソフトウェアより、並行性、タイミング、合成可能性の制約が強い。 VeriMoA は複数の生成経路と品質スコアを使い、低品質な候補が後段へ伝播しにくい構造を作る [42]。この発表は、AI for Systems がソフトウェア最適化からハードウェア設計支援へ広がっていることを示す。このほか、PyTorch 推論コードを CUDA や Triton 実装へ変換する探索パイプライン、並列化構成を複数エージェントで提案する PROMPTS なども同じ流れにある [16][17]。 ### 評価の探索化と継続的ベンチマーク(Lisa Li ほか) Lisa Li の Keynote は、安全性評価とレッドチーミングを、探索問題として定式化した [9]。目的は、ターゲットモデルに隠れている望ましくない振る舞いを、多様なプロンプトを通じて引き出すことである。単に一つの jailbreak を見つけるのではなく、複数の失敗モードを網羅することが重要になる。講演では、investigator agent がターゲットの振る舞いを条件として、多様な攻撃プロンプトを生成する。従来の勾配ベース攻撃や手作業の探索は、一つのモードに過適合しやすい。それに対して、事後分布を近似するように探索を設計すれば、より広い振る舞いの空間を調べられる。ここでのシステム的な意味は、評価が固定ベンチマークから能動的な探索へ変わる点にある。エージェントはサービスを作るだけでなく、サービスを壊す入力を探す役割も担う。閉ループ評価が重要だという LinkedIn recap の観察は、この講演にも当てはまる [5]。 MLSys の文脈では、安全性はモデルカードや方針文書だけで完結しない。評価エージェント、ログ、再現環境、失敗例のクラスタリング、修正後の回帰検査までを含むシステムが必要である。一般セッションでも、評価そのものをシステムとして設計する発表が続いた。 OSWorld-Human は、コンピュータ利用エージェントを成功率だけでなく、人間比の操作効率で評価する [44]。 FlashInfer-Bench は、ベンチマークを AI 生成カーネルの改善サイクルに組み込む [78]。単発の microbenchmark では、実際の sequence length、batch、KV キャッシュ、演算子組み合わせの分布を外しやすい。 FlashInfer-Bench は、trace、正当性、性能、leaderboard、本番エンジン差し替えをつなぐ [78]。これは、ベンチマークを論文の採点表ではなく、生成されたシステム部品を本番へ近づける継続的評価基盤として扱う方向であり、第3章の XProf、Chakra と合わせて MLSys 2026 の観測、評価基盤の三点目を成す [30][33]。 ## 2027 年に向けて MLSys 2026 の中心メッセージは、AI の進歩がモデル単体からシステム全体へ移ったということだ。推論では、KV キャッシュ、長コンテキスト、分離実行、異種ハードウェア、SLO、電力が一つの設計空間になった。開発では、AI エージェントがコード、カーネル、検証、評価へ入り、保守者と検証器の役割が重くなった。訓練と運用では、並列化、通信、データ、チェックポイント、障害復旧が絡み合い、巨大クラスタをどう使い切るかが主要課題になった。この転換は、来年以降に向けた問いを残している。 - **配備構成の制御を誰が作るか。** P/D 分離、モデルルーティング、電力調整は、いずれも負荷に応じた継続的な制御問題になった。BOute のようなベイズ最適化や PROMPTS のようなエージェント設計が候補に挙がっており、制御器そのものの生成と検証が次の主題になりうる [17][21]。 - **検証系の供給が追いつくか。** 生成が民主化された今、Kernel Guard のような監査、VeriMoA のような品質ゲート、FlashInfer-Bench のような継続評価が律速になる [10][42][78]。Lidong Zhou の system intelligence の構図に従えば、検証系自体を AI で組み立てる方向が予想されるが、検証器をだます報酬ハックとの共進化は避けられない [11]。 - **KV キャッシュのデータ層化がどこまで進むか。** 保存、圧縮、共有まで来た以上、分散データシステムの古典的な主題(整合性、耐障害性、階層化、ガベージコレクション)が推論基盤へ順に持ち込まれると考えられる。GhostServe の erasure coding はその先例である [37]。 - **運用の確率化が SRE の実践と合流するか。** グッドプット、予備資源、確率的保守計画は、SRE が扱ってきた SLO、エラーバジェット、キャパシティ計画と同じ形をしている。AI クラスタの運用知識と SRE の方法論を橋渡しする報告は、まだ少ない。初学者は、MLSys を「高速化の会議」と狭く見ないほうがよい。高速化は確かに大きな柱だが、その背後には、何を測るか、どこまで正しさを保証するか、どの資源を冗長化するか、どの失敗を許容するかという設計判断がある。 MLSys 2026 は、その判断がモデル品質、利用者体験、開発速度、クラスタ費用を同時に左右することを示した会議だった。 ## 付録A 発表カタログ本文で扱った発表と、公式の paper title list [40] で確認した関連発表を、章別に一覧する。参照欄に個別の番号が付く発表は詳細ノートまたは一次資料に基づく。参照欄が [40] のみの発表は、タイトルと概要の確認にとどまる。 ### 第1章関連: KV キャッシュと長コンテキスト | 発表 | 一言 | 参照 | | --- | --- | --- | | ContextPilot | 非完全一致の文脈再利用で長コンテキスト推論を高速化 | [19] | | Kitty | チャネル感度に応じた 2 bit KV キャッシュ量子化 | [18] | | BatchLLM | 共有 prefix を計画情報にするオフライン推論 | [45] | | LEANN | 埋め込み再計算とグラフ枝刈りによる低ストレージなベクトル検索 | [46] | | From Tokens to Layers | MoE 向けにプリフィルの分割軸をレイヤへ移す | [47] | | SkipKV | reasoning モデルの思考列で KV 生成と保存を文単位で省く | [20] | | OPKV | paged KV cache に recallable sparsity を組み込む | [48] | | FlexiCache | アテンションヘッドの時間的安定性による KV 階層管理 | [49] | | Using Span Queries to Optimize Cache and Attention Locality | RAG や会話を span query として KV と attention locality を最適化 | [40] | | MAC-Attention | 似た query の attention map を修正して再利用 | [40] | | When Enough is Enough | RAG の検索を早期終了で軽くする | [40] | | Hippocampus / AgenticCache / Ontology-Guided Long-Term Agent Memory | エージェントの長期記憶と会話型 RAG | [40] | | TeleRAG / Stream2LLM | 検索や文脈到着を生成と重ねる | [40] | | Demystifying the Mixture of Experts Serving Tax / CRAFT | MoE サービングの重み移動と専門家複製 | [40] | | MixLLM / Search Your NVFP4 Scales / Attribution-based Sparse Activation | 重み精度、量子化、疎活性化をサービング制約へ接続 | [40] | ### 第1章関連: 分離、異種ハードウェア、SLO と電力 | 発表 | 一言 | 参照 | | --- | --- | --- | | A Pragmatic Exploration of Prefill-Decode Disaggregation | P/D 分離を配備設計問題として評価 | [50] | | TriInfer | マルチモーダル推論の encode、prefill、decode 分離 | [23] | | BOute | モデルルーティングと GPU 配備の多目的ベイズ最適化 | [21] | | BEAM | SLO 内でチャンク、マイクロバッチ、GPU 周波数を同時調整 | [22] | | FaaScale | ブロック単位のモデル転送でサーバレス推論のコールドスタートを短縮 | [51] | | SuperInfer | superchip のメモリ階層を SLO 緊急度で使い分け | [52] | | TokenWeave | 分散 LLM 推論で計算と通信を重ねる | [24] | | PLA-Serve | プリフィル長の違いをキューと CUDA Graph bucket で扱う | [53] | | Optimizing Deployment Configurations for LLM Inference | Meta の推論配備で 5D 並列、P/D 分離、MoE、異種資源を探索 | [40] | | MorphServe | 過負荷時に量子化レイヤを入れ替え KV キャッシュへメモリを回す | [54] | | HELIOS | 早期終了モデルの使い分けと必要レイヤのみのロード | [55] | | Meeting SLOs, Slashing Hours | 企業内 LLM の圧縮、品質ゲート、SLO 認証のワークフロー化 | [40] | | SHIP / Dataflow Is All You Need | SRAM ベース低遅延パイプラインとデータフロー実行 | [40] | ### 第1章関連: カーネル、投機的復号、生成モデル高速化 | 発表 | 一言 | 参照 | | --- | --- | --- | | FlashAttention-4 | Blackwell 世代のハードウェア非対称性に合わせた attention 再設計 | [25] | | BLASST | オンライン softmax 統計による動的 block sparsity | [56] | | Sparse Self-Speculative Decoding | 同一モデル内の sparse draft と full attention 検証 | [26] | | SpecDiff-2 | diffusion drafter による複数位置の並列 draft 提案 | [57] | | Speculative Decoding: Performance or Illusion? | 投機的復号を本番寄り条件で再評価 | [74] | | PRISM | draft model の処理を予測ステップごとに分ける | [40] | | ReSpec / Beat the Long Tail | RL 訓練の rollout 生成に投機的復号を使う | [40] | | CDLM / TiDAR | diffusion と autoregressive 生成の境界の組み替え | [40] | | StreamDiffusionV2 | 動画拡散のストリーミング生成 | [72] | | db-SP | 視覚生成の sparse attention と sequence parallelism の組み合わせ | [40] | | SwiftGS | 3D Gaussian Splatting の sorting と rasterization を削減 | [58] | | Spira | 点群ネットワークの sparse convolution 高速化 | [59] | | Flashlight | PyTorch の attention 変種から融合カーネルを生成 | [40] | | HipKittens / ParallelKittens | GPU カーネル記述の移植性向上 | [60] | ### 第1章関連: エッジ、オンデバイス、マルチモーダル | 発表 | 一言 | 参照 | | --- | --- | --- | | ExecuTorch | PyTorch からのオンデバイス配備基盤 | [28] | | Efficient, VRAM-Constrained xLM Inference on Clients | プロファイルに基づくサブレイヤー分割配置 | [68] | | EarthSight | 衛星上のマルチタスク推論と地上局の優先度制御 | [29] | | Rethinking DVFS for Mobile LLMs (CORE) | prefill と decode を分けた統合周波数制御 | [69] | | REPARO | 動画会議のパケットロスを生成的に補完 | [70] | | IntAttention | attention の完全整数化によるエッジ推論 | [67] | | HyperTinyPW | TinyML 向け pointwise mixer の生成圧縮 | [71] | | Locality-Aware Beam Scheduling | コンシューマ GPU で test-time compute の KV 転送を削減 | [73] | ### 第2章関連: 訓練、並列化、MoE、通信 | 発表 | 一言 | 参照 | | --- | --- | --- | | DistCA | core attention の分離と再配置による長コンテキスト訓練 | [27] | | veScale-FSDP | 構造を保った shard と通信バッファ設計 | [61] | | MoEBlaze | token routing の中間テンソル実体化を減らす MoE 訓練 | [62] | | FCP | 固定サイズ block と congestion-free planning の context parallelism | [63] | | DreamDDP | 層単位の部分同期による低帯域地理分散訓練 | [66] | | FlexTrain | 精度一貫性を保った elastic なハイブリッド並列 | [64] | | MTraining | ultra-long context 訓練向け balanced sparse ring | [40] | | FarSkip-Collective | MoE の blocking All-to-All を残差経路で隠す | [65] | | HexiScale / Zorse / AXLearn | 異種 GPU、異種バックエンドでの大規模訓練 | [40] | | ProTrain | ZeRO、FSDP、CPU offload、checkpointing の自動選択 | [40] | | CAGE / PyLO | 勾配推定や learned optimizer のシステム実装 | [40] | | BOOST / FP8-Flow-MoE / FreeScale / GriNNder / HetRL / Learning from Less | 低ランク訓練、FP8 MoE、推薦、GNN、RL 訓練の効率化 | [40] | | NEST / fabric-lib / A Lightweight High-Throughput Collective-Capable NoC | 配置、RDMA、NoC の通信基盤 | [40] | ### 第3章関連: 観測、フリート効率、運用と耐障害性 | 発表 | 一言 | 参照 | | --- | --- | --- | | ML Productivity Goodput | フリート効率を三つのグッドプットの積で測る | [32] | | XProf | ホストとデバイスをまたぐスケーラブルなプロファイリング | [33] | | MLCommons Chakra | 交換可能な標準実行トレース | [30] | | CATWILD | フリート規模の XLA コンパイラ自動チューニング | [75] | | SAKURAONE | オープン Ethernet AI HPC と実ワークロード観測 | [38] | | Guard | ピア比較とノードスイープによるグレーノード検知 | [34] | | Sparing Strategies | 予備 GPU 構成をグッドプット最大化で設計 | [35] | | Acela | 保守時間の費用関数つき予測 | [39] | | RaidServe | GPU 欠損下の非一様 tensor-parallel サービング | [36] | | GhostServe | erasure coding による KV キャッシュ保護 | [37] | | ProfInfer | eBPF による細粒度 LLM 推論プロファイリング | [31] | | AIRS | 評価用 LLM 推論の大規模フリート運用 | [76] | | Breaking the Ice | vLLM の cold start を起動段階ごとに分解 | [77] | | Charon / DriftBench / Hawkeye | シミュレーション、インフラ drift、非決定性再現 | [40] | | Virtual Machine NUMA Placement at Scale | ML による配置制御と tail shielding | [40] | | When Machine Learning Isn't Sure | ML 予測の不確実性と fallback 設計 | [40] | ### 第4章関連: AI for Systems とエージェント型開発 | 発表 | 一言 | 参照 | | --- | --- | --- | | AccelOpt | Trainium NKI カーネルの自己改善エージェント | [14] | | OpenHands | エージェント開発の運用基盤(状態、サンドボックス、監査) | [15] | | Agentic Operator Generation for ML ASICs | ATen 演算子生成を検証パイプラインへ接続 | [43] | | ADR | エージェント向け EDR(意図、推論、ツール呼び出しの監視) | [41] | | VeriMoA | Mixture-of-Agents による Spec-to-HDL 生成 | [42] | | OSWorld-Human | コンピュータ利用エージェントの人間比効率評価 | [44] | | FlashInfer-Bench | AI 生成カーネルの継続評価基盤 | [78] | | Optimizing PyTorch Inference with LLM-Based Multi-Agent Systems | PyTorch 推論コードの CUDA / Triton 変換探索 | [16] | | PROMPTS | 訓練とサービングの並列化構成を複数エージェントで提案 | [17] | | Automated Algorithm Design for Auto-Tuning Optimizers | オートチューニング用最適化アルゴリズム自体を LLM が設計 | [40] | | Unified LLM Model for Power, Performance, and Area Prediction from Hardware Code | Verilog から電力、性能、面積を予測 | [40] | | ApproxMLIR / Wave / Event Tensor / DynaFlow | 複合 ML システムと高性能カーネルの開発基盤 | [40] | ## 付録B Keynote 一覧 | 講演者 | 主題 | 本文での扱い | 参照 | | --- | --- | --- | --- | | Roger Wang | AI エージェント時代のオープンソース保守 | 第4章 | [6] | | Esha Choukse | エージェント型システムのクロススタック協調設計 | 第1章 | [7] | | Yuhan Liu | LMCache と KV キャッシュのデータ層化 | 第1章 | [8] | | Lisa Li | investigator agent による振る舞いの誘出 | 第4章 | [9] | | Mark Saroufim | AI がシステムコードを書く時代の評価と不正対策 | 第4章 | [10] | | Lidong Zhou | system intelligence とシステムの共同設計 | 第4章 | [11] | | Amin Vahdat | 知能のアーキテクチャとしてのデータセンター | 第3章 | [12] | | Luke Zettlemoyer | 事前学習のデータとアーキテクチャの見直し | 第2章 | [13] | なお、Christos Kozyrakis の Keynote は詳細ノートがないため、本稿の解説対象から外した。 ## 付録C 用語集 - **推論**:訓練済みモデルが入力を受け取り、トークン、画像、分類結果などの出力を生成する処理。 - **サービング**:推論を利用者やアプリケーションからの要求に応じて継続的に提供する仕組み。 - **プリフィル**:プロンプト全体を読み込んで初期状態を作る段階。 - **デコード**:プリフィルで作った状態を使って次のトークンを順に生成する段階。 - **KV キャッシュ**:Transformer のアテンション計算で再利用する key と value の中間状態を保存したもの。長い会話、検索拡張生成、エージェントの履歴再利用で支配的なメモリ資源になりやすい。 - **グッドプット**:単に資源が稼働している割合ではなく、最終的な進捗に寄与した有用な処理量を測る考え方。 - **MoE**:Mixture of Experts の略。入力ごとに一部の専門家ネットワークだけを動かして大規模化と計算効率を両立させるモデル構造。 - **ストラグラー**:分散ジョブ内で他より遅いノードや GPU。同期型の訓練やサービングでは全体の進行を止める原因になる。 - **SLO**:Service Level Objective の略。応答遅延、成功率、可用性などについてサービスが守るべき目標値。 ## 参考文献 [1] MLSys, "MLSys 2026," Machine Learning and Systems, 2026, https://mlsys.org/. [2] MLSys, "MLSys 2026 Dates," Machine Learning and Systems, 2026, https://mlsys.org/Conferences/2026/Dates. [3] MLSys, "MLSys 2026 Hotel Information," Machine Learning and Systems, 2026, https://mlsys.org/Conferences/2026/HotelInformation. [4] Modular, "Three trends from MLSys 2026," Modular Blog, May 29, 2026, https://www.modular.com/blog/three-trends-from-mlsys-2026. [5] Ashok Emani, "MLSys 2026 Recap: Systems-Driven AI and Tool Calling Critical for Success," LinkedIn, 2026, https://www.linkedin.com/posts/ashok-emani-10731296_just-wrapped-up-mlsys-2026-here-in-bellevue-activity-7464929045064028160-1m9f/. [6] Roger Wang, "Rethinking Open Source Contribution in the Age of AI Agents," MLSys 2026 Invited Talk, 2026, https://mlsys.org/virtual/2026/invited-talk/10000. [7] Esha Choukse, "Beyond Model Serving: Cross-Stack Co-Design for Agentic Systems," MLSys 2026 Invited Talk, 2026, https://mlsys.org/virtual/2026/invited-talk/3650. [8] Yuhan Liu, "LMCache: An Efficient KV Cache Layer for Enterprise-Scale LLM Inference," MLSys 2026 Invited Talk, 2026, https://mlsys.org/virtual/2026/invited-talk/3646. [9] Lisa Li, "Eliciting Language Model Behaviors with Investigator Agents," MLSys 2026 Invited Talk, 2026, https://mlsys.org/virtual/2026/invited-talk/3645. [10] Mark Saroufim, "When AI Starts Writing Systems Code," MLSys 2026 Invited Talk, 2026, https://mlsys.org/virtual/2026/invited-talk/3655. [11] Lidong Zhou, "The Next Horizon of Systems: From MLSys to System Intelligence," MLSys 2026 Invited Talk, 2026, https://mlsys.org/virtual/2026/invited-talk/3665. [12] Amin Vahdat, "Keynote," MLSys 2026 Invited Talk, 2026, https://mlsys.org/virtual/2026/invited-talk/3684. [13] Luke Zettlemoyer, "Rethinking Pretraining: Data and Architecture," MLSys 2026 Invited Talk, 2026, https://mlsys.org/virtual/2026/invited-talk/3706. [14] "AccelOpt: A Self-Improving LLM Agentic System for AI Accelerator Kernel Optimization," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3808. [15] "The OpenHands Software Agent SDK: A Composable and Extensible Foundation for Production Agents," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3749. [16] "Optimizing PyTorch Inference with LLM-Based Multi-Agent Systems," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3823. [17] "PROMPTS: PeRformance Optimization via Multi-Agent Planning for LLM Training and Serving," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3843. [18] "Kitty: Accurate and Efficient 2-bit KV Cache Quantization with Dynamic Channel-wise Precision Boost," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3746. [19] "ContextPilot: Fast Long-Context Inference via Context Reuse," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3810. [20] "SkipKV: Selective Skipping of KV Generation and Storage for Efficient Inference with Large Reasoning Models," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3864. [21] "BOute: Cost-Efficient LLM Serving with Heterogeneous LLMs and GPUs via Multi-Objective Bayesian Optimization," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3795. [22] "BEAM: Joint Resource-Power Optimization for Energy-Efficient LLM Inference under SLO Constraints," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3849. [23] "TriInfer: Hybrid EPD Disaggregation for Efficient Multimodal Large Language Model Inference," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3756. [24] "TokenWeave: Efficient Compute-Communication Overlap for Distributed LLM Inference," OpenReview, 2026, https://openreview.net/forum?id=rh2Ylffkq6. [25] "FlashAttention-4: Algorithm and Kernel Pipelining Co-Design for Asymmetric Hardware Scaling," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3759. [26] "Accelerating Large-Scale Reasoning Model Inference with Sparse Self-Speculative Decoding," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3733. [27] "DistCA: Efficient Long-Context Language Model Training by Core Attention Disaggregation," GitHub, 2026, https://github.com/hao-ai-lab/DistCA. [28] "ExecuTorch: A Unified PyTorch Solution to Run AI Models On-Device," MLSys 2026 Session, 2026, https://mlsys.org/virtual/2026/session/3659. [29] "EarthSight: A Distributed Framework for Low-Latency Satellite Intelligence," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3792. [30] "MLCommons Chakra: Advancing Performance Benchmarking and Co-design using Standardized Execution Traces," MLSys 2026 Session, 2026, https://mlsys.org/virtual/2026/session/3717. [31] "ProfInfer: An eBPF-based Fine-Grained LLM Inference Profiler," MLSys 2026 Session, 2026, https://mlsys.org/virtual/2026/session/3717. [32] Arissa Wongpanich et al., "Machine Learning Fleet Efficiency: Analyzing and Optimizing Large-Scale Google TPU Systems with ML Productivity Goodput," arXiv, 2025, https://arxiv.org/html/2502.06982v2. [33] "XProf: An Open, Scalable, and Extensible Profiling System for the Modern ML Stack," OpenReview, 2026, https://openreview.net/pdf?id=KqRLAdGK6C. [34] Guanliang Liu et al., "Guard: Scalable Straggler Detection and Node Health Management for Large-Scale Training," arXiv, 2026, https://arxiv.org/abs/2605.17879. [35] Kevin J. Quirk et al., "Sparing Strategies to Minimize Reliability Impact on Large Training Jobs," MLSys 2026 Slides, 2026, https://mlsys.org/media/mlsys-2026/Slides/3862_xkbT8SW.pdf. [36] Ziyi Xu, Zhiqiang Xie, Swapnil Gandhi, and Christos Kozyrakis, "RaidServe: High-performance Resilient Serving," OpenReview, 2026, https://openreview.net/forum?id=5pl9fdbEkq. [37] "GhostServe: A Lightweight Checkpointing System in the Shadow for Fault-Tolerant LLM Serving," OpenReview, 2026, https://openreview.net/forum?id=xKjYiUgeOK. [38] Fumikazu Konishi, Yuuki Tsubouchi, and Hirofumi Tsuruta, "SAKURAONE: An Open Ethernet-Based AI HPC System and Its Observed Workload Dynamics in a Single-Tenant LLM Development Environment," arXiv, 2026, https://arxiv.org/abs/2604.13600. [39] "Cost-aware Duration Prediction for Software Upgrades in Datacenters," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3765. [40] MLSys, "MLSys 2026 Papers," Machine Learning and Systems, 2026, https://mlsys.org/virtual/2026/papers.html?filter=titles. [41] "ADR: An Agentic Detection System for Enterprise Agentic AI Security," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3853. [42] "VeriMoA: A Mixture-of-Agents Framework for Spec-to-HDL Generation," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3855. [43] "Agentic Operator Generation for ML ASICs," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3817. [44] "OSWorld-Human: Benchmarking the Efficiency of Computer-Use Agents," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3865. [45] "BatchLLM: Optimizing Large Batched LLM Inference with Global Prefix Sharing and Throughput-oriented Token Batching," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3833. [46] "LEANN: A Low-Storage Overhead Vector Index," MLSys 2026 Session, 2026, https://mlsys.org/virtual/2026/session/3659. [47] "From Tokens to Layers: Redefining Stall-Free Scheduling for MoE Serving with Layered Prefill," OpenReview, 2026, https://openreview.net/forum?id=yyDbI3HXco. [48] "OPKV: A High-Throughput Plugin-Driven Framework for Recallable Sparsity in Paged KV Cache Systems," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3844. [49] "FlexiCache: Leveraging Temporal Stability of Attention Heads for Efficient KV Cache Management," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3838. [50] "A Pragmatic Exploration of Prefill-Decode Disaggregation in Large Scale Inference," MLSys 2026 Session, 2026, https://mlsys.org/virtual/2026/session/3709. [51] "FaaScale: Unlocking Fast LLM Scaling for Serverless Inference," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3769. [52] "SuperInfer: SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips," OpenReview, 2026, https://openreview.net/forum?id=RuslSHdIHa. [53] "PLA-Serve: A Prefill-Length-Aware LLM Serving System," MLSys 2026 Papers, 2026, https://mlsys.org/virtual/2026/papers.html?filter=titles. [54] "MorphServe: Efficient and Workload-Aware LLM Serving via Runtime Quantized Layer Swapping and KV Cache Resizing," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3816. [55] "HELIOS: Adaptive Model And Early-Exit Selection for Efficient LLM Inference Serving," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3846. [56] "BLASST: Dynamic BLocked Attention Sparsity via Softmax Thresholding," MLSys 2026 Session, 2026, https://mlsys.org/virtual/2026/session/3659. [57] "SpecDiff-2: Scaling Diffusion Drafter Alignment For Faster Speculative Decoding," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3755. [58] "SwiftGS: Algorithm and System Co-Optimization for Fast 3D Gaussian Splatting on GPUs," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3773. [59] "Spira: Exploiting Voxel Data Structural Properties for Efficient Sparse Convolution in Point Cloud Networks," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3797. [60] "ParallelKittens: Systematic and Practical Simplification of Multi-GPU AI Kernels," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3845. [61] "veScale-FSDP: Flexible and High-Performance FSDP at Scale," GitHub, 2026, https://github.com/volcengine/veScale. [62] "MoEBlaze: Breaking the Memory Wall for Efficient MoE Training on Modern GPUs," MLSys 2026 Papers, 2026, https://mlsys.org/virtual/2026/papers.html?filter=titles. [63] "Unleashing Scalable Context Parallelism for Foundation Models Pre-Training via FCP," MLSys 2026 Papers, 2026, https://mlsys.org/virtual/2026/papers.html?filter=titles. [64] "FlexTrain: Scalable Hybrid-Parallel Training with Elastic Resource Utilization and Consistent Accuracy," OpenReview, 2026, https://openreview.net/forum?id=h2yhNcbwSL. [65] "FarSkip-Collective: Unhobbling Blocking Communication in Mixture of Experts Models," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3743. [66] "DreamDDP: Accelerating Low-Bandwidth Geo-Distributed LLM Training with Layer-wise Partial Synchronization," GitHub, 2026, https://github.com/trl730109/DreamDDP. [67] "IntAttention: A Fully Integer Attention Pipeline for Efficient Edge Inference," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3848. [68] "Efficient, VRAM-Constrained xLM Inference on Clients," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3802. [69] "Rethinking DVFS for Mobile LLMs: Unified Energy-Aware Scheduling with CORE," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3814. [70] "REPARO: Loss-Resilient Generative Codec for Video Conferencing," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3839. [71] "HyperTinyPW: Generative Compression for TinyML," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3818. [72] "StreamDiffusionV2: A Streaming System for Dynamic and Interactive Video Generation," MLSys 2026 Session, 2026, https://mlsys.org/virtual/2026/session/3659. [73] "Locality-Aware Beam Scheduling for Efficient Test-Time Compute with a Consumer-grade GPU," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3788. [74] "Speculative Decoding: Performance or Illusion?," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3782. [75] "CATWILD: Compiler Autotuning for TPU Workloads in the Wild," OpenReview, 2026, https://openreview.net/forum?id=hB3nov3gIP. [76] "AIRS: Scaling Live Inference in Resource Constrained Environments," MLSys 2026 Session, 2026, https://mlsys.org/virtual/2026/session/3717. [77] "Breaking the Ice: Analyzing Cold Start Latency in vLLM," MLSys 2026 Oral, 2026, https://mlsys.org/virtual/2026/oral/3784. [78] "FlashInfer-Bench: Building the Virtuous Cycle for AI-driven LLM Systems," arXiv, 2026, https://arxiv.org/abs/2601.00227.