# 機械学習システムの国際会議MLSys 2026 Recap さくらインターネット研究所の坪内（[@yuuk1t](https://x.com/yuuk1t)）です。 2026年5月、米国ワシントン州ベルビューにて、機械学習とシステムの交差領域を扱う国際会議 [MLSys 2026](https://mlsys.org/) が開催されました。 当研究所からは、AI/HPC クラスタ「さくらONE」に関する論文が Industry Track に採択され、共著者3名で現地発表を行いました。 その発表内容と現地の様子は、すでに [MLSys 2026でAI/HPCクラスタ「さくらONE」の設計・性能評価・運用データ分析を発表](https://research.sakura.ad.jp/blog/mlsys2026-report) で報告しています。 本記事はその続編として、MLSys 2026 という会議全体で何が議論されたのかを報告します。 135本の採択論文と、5本の Keynote および4本の Invited Talk を通して見えたのは、機械学習の競争力を決める場所が、モデルそのものから、それを訓練し、配備し、評価し、運用するシステムへ移ったという事実でした。 ![[836C1FF4-AEC9-4B23-8ACD-040303C6155B_4_5005_c.jpeg]] *会場ホテルのレジストレーション案内。* ## 会議の規模 Opening Remarks で示された数字から確認します。 MLSys 2026 への投稿は504件で、前年の271件から86%増加しました。 採択は135本、採択率は26%です。 内訳は Research Track が107本、今回新設された Industry Track が28本でした。 査読数も前年比82%増で、1本の論文につき最低3名の査読者が付いています。 著者は約1200名、プログラム委員と査読者は約1800名、現地参加者は約1100名でした。 ![[Pasted image 20260716165340.png]] *採択論文の内訳（Opening Remarks より）。Research Track 25%、Industry Track 32% の採択率。* ![[Pasted image 20260716164048.png]] *Keynote 登壇者と会議の規模（Opening Remarks より）。* Industry Track では査読支援に AI が使われました。 論文そのものを AI に査読させるのではなく、人間が書いた査読文を AI にレビューさせる形式です。 LLM が各査読文を評価して事実誤認、記述の薄さ、語調、スコアと本文の不一致などを指摘し、チェアがそのフラグを検証したうえで、査読者に改稿を依頼します。 初回の査読文の格付けは GOOD が53%、OK が25%、要確認が22%でした。 そのうえで、AI の出力によって評価スコアを変えてはならないという制約が付されています。 査読の品質保証に AI を入れつつ、評価の責任は人間に残す設計です。 ![[Pasted image 20260716165502.png]] *Industry Track で試行された AI 支援による査読検証（Opening Remarks より）。* ## 三つの主要トピック MLSys 2026 の発表群は、次の三つの主要トピックとして整理できます。 - **推論サービング**：GPU 上でモデルを速く回す問題から、KV キャッシュという状態を管理する分散システムへ広がった。 - **クラスタ運用**：利用率と事後復旧の管理から、グッドプットと予防的な健全性の管理へ移った。 - **開発**：AI エージェントがカーネルからシステムコードまで書き始めた結果、生成ではなく検証が律速になった。 KV キャッシュの共有も、グッドプットという指標も、AI によるコード生成も、数年前から個別に論じられてきました。 今年の会議で目立ったのは、これらが個々の最適化テクニックとしてではなく、システムを設計するときの前提として扱われていた点です。 同様の観察は、Modular による [Three trends from MLSys 2026](https://www.modular.com/blog/three-trends-from-mlsys-2026) にも見られます。 ## トピック1: 推論サービングは状態を管理する分散システムになった LLM サービングの基本は、限られた GPU メモリと計算時間を多数の要求で共有することにあります。 vLLM のようなページ化 KV キャッシュ、連続バッチング、prefix キャッシュ、要求スケジューリングは、この制約に対する標準的な道具になりました。 ここで **KV キャッシュ** とは、アテンション計算で再利用する key と value の中間状態を保存したものです。 従来の設計では、これは推論エンジン内部の一時状態として扱われがちでした。 しかし長コンテキスト、検索拡張生成、エージェントの履歴が絡むと、この一時状態は巨大化し、同時に要求間で再利用できる資産にもなります。 MLSys 2026 のサービング系発表は、この資産をどう管理するかという問いを共有していました。 ### KV キャッシュのデータ層化 Yuhan Liu の Invited Talk [LMCache: An Efficient KV Cache Layer for Enterprise-Scale LLM Inference](https://mlsys.org/virtual/2026/invited-talk/3646) は、KV キャッシュを AI ネイティブなデータ型として位置づけました。 保存し、圧縮し、転送し、共有し、再利用し、検索する対象として扱う、という見方です。 講演では、圧縮を担う CacheGen と、非 prefix な再利用を担う CacheBlend が紹介されました。 非 prefix な再利用とは、プロンプトの先頭から完全一致する場合だけでなく、検索拡張生成のように一部の文脈だけが共有される場合にも KV を再利用する考え方です。 一般セッションの発表も同じ方向を向いており、再利用の単位は、完全一致する prefix から、文書片、会話履歴、検索結果、エージェント記憶へ広がっています。 [ContextPilot](https://mlsys.org/virtual/2026/oral/3810)（エディンバラ大学）は、コンテキストアラインメント、重複排除、アノテーションによって、完全一致しない文脈を再利用しやすくします。 既存手法は、完全一致の prefix しか当たらないためキャッシュミスを起こすか、位置エンコーディングの不整合を無視して再利用し精度を落とすかのどちらかに寄っていました。 ![[Pasted image 20260717033543.png]] *既存の KV 再利用手法が抱えるトレードオフ（ContextPilot 発表スライドより）。* [Kitty](https://mlsys.org/virtual/2026/oral/3746)（Together AI）は、key cache のチャネルごとの感度差を利用し、大部分を2ビットに落としつつ重要なチャネルだけ精度を上げます。 一様な量子化ではなく、精度劣化が出やすい場所にだけ予算を割く設計です。 KV キャッシュを保存するか捨てるかではなく、どの部分に精度を残し、どの単位で共有するかを選ぶ方向だと言えます。 ![[Pasted image 20260730144311.png]] *チャネル単位で INT2 と INT4 を混在させる Kitty の量子化（発表スライドより）。* ### プリフィルとデコードの分離 LLM 推論は一つの処理に見えますが、内部では性質の異なる二つの段階に分かれます。 **プリフィル** はプロンプト全体を読み込んで初期状態を作る段階で、計算集約的になりやすい。 **デコード** はその状態を使って次のトークンを順に生成する段階で、逐次性が強く、メモリ帯域と KV キャッシュの配置に制約されます。 ![[Pasted image 20260730113023.png]] *プリフィルとデコードを別プールへ分離する構成。両者は KV キャッシュを介して接続される（NVIDIA 発表スライドより）。* 従来は同じ GPU プールで両者をまとめて処理し、バッチ化で平均スループットを上げる方式が中心でした。 しかし入力長、出力長、到着率が変われば、両者の最適な資源比率もすぐ変わります。 [A Pragmatic Exploration of Prefill-Decode Disaggregation in Large Scale Inference](https://mlsys.org/virtual/2026/session/3709)（NVIDIA）は、この分離を万能な最適化ではなく配備設計問題として扱いました。 数十万の設計点を評価した結果、大きなモデルと prefill が多いトラフィックでは分離の利点が出やすい一方、小さいモデルや decode が多いトラフィックでは同居構成が競争力を持つ場合がある、と報告しています。 固定の比率ではなく、負荷に応じた動的な rate matching が要るという結論です。 P/D 分離はランタイムの機能ではなく、継続的な配備制御の対象になりました。 ![[Pasted image 20260730163658.png]] *スループットとインタラクティビティの Pareto フロンティア。領域によって同居と分離のどちらが有利かが変わる（NVIDIA 発表スライドより）。* 異種ハードウェアの扱いも、余った GPU を使うという発想から離れつつあります。 [BOute](https://mlsys.org/virtual/2026/oral/3795)（ケンブリッジ大学）は、モデル選択、ルーティング閾値、GPU 割当を多目的ベイズ最適化の同じ探索空間に入れ、モデル能力、品質要件、GPU 特性を対応づける設計問題として扱いました。 ![[Pasted image 20260730165131.png]] *小さいモデルはコンシューマ向け GPU、大きいモデルはデータセンター向け GPU が有利になる（BOute 発表スライドより）。* ### SLO と電力と品質の同時制御 Esha Choukse の Invited Talk [Beyond Model Serving: Cross-Stack Co-Design for Agentic Systems](https://mlsys.org/virtual/2026/invited-talk/3650) は、この制御問題の射程を最も広く示しました。 エージェント型システムでは、モデル、ツール、検索、検証器、外部状態、複数ターンの計画が一つのワークフローを作ります。 講演は、品質をモデル精度ではなくシステム全体の資源配分として扱いました。 すべての出力を重い検証器に通せば品質は上がりますが、遅延と費用は増えます。 危険な箇所だけを選択的に検証できれば、品質、遅延、費用の折り合いはよくなります。 サービングは、モデルを速く動かすだけでなく、品質をどこで測り、どこで落とし、どこで回復するかを、ハードウェア、スケジューラ、検証器と一緒に設計する問題になりました。 [BEAM](https://mlsys.org/virtual/2026/oral/3849)（韓国科学技術院）は、SLO を守ったあとに残る余裕を電力削減へ回します。 prefill と decode では計算律速とメモリ律速の性質が異なり、バッチサイズやチャンクサイズが変われば最適な GPU 周波数も変わります。 BEAM はチャンク、マイクロバッチ、GPU 周波数をイベント駆動で同時に調整しました。 高速化だけでなく、SLO の範囲内でどこまで低電力にできるかが論点になっています。 ![[Pasted image 20260730165637.png]] *SLO を満たす範囲の中で消費エネルギーが最小になる制御点を探す（BEAM 発表スライドより）。* ### 高速化手法とエッジ推論 生成モデルの高速化そのものも、単一アルゴリズムの改善から、ワークロードとハードウェアの非対称性を前提にした設計へ移りました。 [FlashAttention-4](https://mlsys.org/virtual/2026/oral/3759)（プリンストン大学）は、Tensor Core 性能が伸びても共有メモリ帯域や指数演算が同じ比率では伸びないという前提から、Blackwell 世代向けにアテンションを再設計しています。 一方で [Speculative Decoding: Performance or Illusion?](https://mlsys.org/virtual/2026/oral/3782)（カリフォルニア大学バークレー校）は、投機的復号を vLLM など本番寄りの条件で再評価し、理論上のトークン削減がそのまま速度に変わるとは限らないことを示しました。 エッジとオンデバイスでは、モデル圧縮より広い意味で、データ発生源の近くで推論を組み立てる方向が見えます。 [ExecuTorch](https://mlsys.org/virtual/2026/session/3659)（Meta）は、PyTorch からの export、量子化、バックエンド委譲、小型ランタイムをまとめ、端末側にも標準的な実行層を作ります。 ![[Pasted image 20260730173312.png]] *PyTorch モデルを端末上の実行まで運ぶ ExecuTorch の経路（発表スライドより）。* [EarthSight](https://mlsys.org/virtual/2026/oral/3792)（ジョージア工科大学）は、衛星上でマルチタスク推論を行い、地上局が帯域予測と優先度を与える構成を示しました。 データ発生場所の近くで推論する理由は、低遅延だけではなく、帯域、電力、観測機会を制御するためでもあります。 ### 最優秀論文賞: LEANN 最優秀論文賞は [LEANN](https://mlsys.org/virtual/2026/session/3659)（カリフォルニア大学バークレー校）が受賞しました。 RAG の検索インデックスを低ストレージ化する研究です。 ![[Pasted image 20260716165959.png]] *最優秀論文賞の発表（Opening Remarks より）。* 標準的なベクトル検索では、埋め込みベクトルとグラフ構造が元データより大きくなることがあります。 発表では、76GB の文書集合に対してインデックスが約200GB に膨らむ例が示されました。 ![[Pasted image 20260730173631.png]] *ベクトルインデックスのストレージオーバーヘッドと、LEANN による削減幅（発表スライドより）。* LEANN は埋め込みを常時保持せず、必要時に再計算し、検索グラフを枝刈りします。 生成が支配的な RAG では、検索側で計算が少し増えても、ストレージを下げる価値がある場合があるためです。 派手なモデル高速化ではなく、検索インフラの物理制約を扱う研究が選ばれた点は、この会議の重心を示しています。 ## トピック2: クラスタ運用は利用率からグッドプットへ移った クラスタ運用と耐障害性は、MLSys 2026 の中でも実運用の色が強い領域でした。 従来の運用は、GPU を多く確保し、NCCL テストや GPU バーンインを通し、障害が起きたらチェックポイントから再開する、という形が中心です。 しかし frontier-scale の訓練や大規模推論では、この受け身の方式では足りません。 クラスタが大きくなるほど、どこか一つのノードが遅くなる確率は上がります。 同期型の訓練では、最も遅いノード（**ストラグラー**）が全体のステップ時間を決めます。 推論サービングでは、障害復旧のために KV キャッシュや重みを再構成する時間が、そのまま利用者の遅延や失敗率に現れます。 Amin Vahdat の [Keynote](https://mlsys.org/virtual/2026/invited-talk/3684) は、この領域のスケール感を与えました。 講演者は Google の SVP 兼 Chief Technologist として AI とインフラを統括する立場にあります。 焦点は、エネルギー、データセンター、アクセラレータ、ネットワーク、ソフトウェアを含む垂直統合です。 AI インフラは、ラックに GPU を並べるだけでなく、電力と通信を含む巨大な計算機として設計する必要がある、という主張でした。 そのうえでソフトウェア側ではフリート管理とグッドプットが重要になる、と述べています。 アクセラレータが忙しく見えても、それが有用な訓練進捗や推論品質に結びつかなければ意味がないからです。 以下、この領域の発表を「測る」「備える」「耐える」の三つに分けて紹介します。 ### 測る [ML Productivity Goodput](https://arxiv.org/html/2502.06982v2)（Google）は、測定軸を利用率から生産性へ移し、フリート効率を三つの積として捉えます。 - **Scheduling Goodput**：必要な資源が同時に割り当てられているか。 - **Runtime Goodput**：割り当てられた時間が、チェックポイントに残る進捗へ変わったか。 - **Program Goodput**：進んでいる時間が、理論的な実行時間にどれだけ近いか。 ![[Pasted image 20260717035119.png]] *フリート効率を三つの比の積へ分解する（ML Productivity Goodput 発表スライドより）。* この分解の価値は、指標を増やしたことではありません。 分散学習では、全 GPU が動いていても、データローダを待っている、チェックポイント後に巻き戻される、コンパイラが非効率なコードを出している、通信と計算が重なっていない、といった理由で生産性が失われます。 三つへ分けることで、失われた生産性がスケジューラ、ランタイム、プログラムのどの層に帰属するかが分かり、運用改善の責任境界を引けるようになります。 損失の在り処が分かっても、原因まで掘るには観測基盤が要ります。 [XProf](https://openreview.net/pdf?id=KqRLAdGK6C)（Google）は、ホストとデバイスをまたぐトレース、低オーバーヘッドの計測、時刻同期、分散処理による分析を一つのプロファイリング体験へまとめました。 観測の粒度が粗いとストラグラーは平均値に埋もれ、観測が重すぎると本番ジョブを妨げます。 XProf はこの二つの間で実用的な均衡を探る試みです。 ![[Pasted image 20260730145259.png]] *ホストとデバイスをまたぐトレースを一つのタイムラインで見る XProf の画面（発表スライドより）。* [MLCommons Chakra](https://mlsys.org/virtual/2026/session/3717)（NVIDIA）は、計算、通信、依存関係を標準形式の実行トレースとして表現し、シミュレータやハードウェア設計者が同じワークロード表現を使えるようにします。 ![[Pasted image 20260730161010.png]] *トレースの収集から解析、リプレイ、シミュレーションまでをつなぐ Chakra の構成（発表スライドより）。* ### 備える [Guard](https://arxiv.org/abs/2605.17879)（Amazon）は、大規模訓練クラスタのストラグラー検知とノード健全性管理を扱います。 問題設定は明快です。 NCCL テストや GPU バーンインは、主に機能的な正しさと短時間の負荷耐性を見ます。 しかし本番訓練では、クラッシュしないが遅いグレーノードが、何日も何週間もグッドプットを削ります。 Guard は、オンラインの性能監視とオフラインのノードスイープを組み合わせます。 オンライン側では、同じジョブ内のピアノードと比較しながら、GPU 温度、クロック、消費電力、ネットワーク転送率、エラー、ステップ時間を監視します。 固定しきい値ではなく同じ役割のノード間の相対比較を使うため、ワークロードや機種の差にある程度適応できます。 オフライン側では、本番投入前や隔離後に現実的な負荷でスイープを実行し、短時間テストでは見逃すサーマルスロットリング、ネットワーク経路の劣化、GPU メモリや電力の不安定性を発見します。 発表では、Guard の導入により MFU が最大1.7倍改善し、実行間のステップ時間の分散が20%から1%へ下がったと報告されています。 ![[Pasted image 20260730174717.png]] *監視、隔離、修理、スイープによる資格確認、復帰までを一巡させる Guard のノード健全性管理（発表スライドより）。* [Sparing Strategies](https://mlsys.org/media/mlsys-2026/Slides/3862_xkbT8SW.pdf)（Meta）は、予備資源を経験則ではなくグッドプット最大化の設計変数として扱いました。 コンピュートブロックサイズ、ブロック間スペア、ブロック内スペア、故障率、修理時間、チェックポイント周期、配置制約をモデルに入れ、連続時間マルコフ連鎖で障害と修理の確率過程を近似します。 単純に考えれば、予備 GPU は使われていないぶん利用率を下げます。 しかし障害時にすぐ置き換えられる資源がなければ、巨大な同期ジョブ全体が止まり、復旧、再スケジューリング、巻き戻しで大きな損失が出ます。 短期的に空いている GPU が、長期的には訓練ジョブを止めないための保険になる、という構図です。 ![[Pasted image 20260730174915.png]] *障害の検知から代替ノードの確保、チェックポイントからの復元までに失われる時間（Sparing Strategies 発表スライドより）。* [Cost-aware Duration Prediction for Software Upgrades in Datacenters](https://mlsys.org/virtual/2026/oral/3765)（パデュー大学）は、保守計画を固定の worst-case 見積もりから確率的な意思決定へ移します。 過小予測は保守ウィンドウの超過やキャンセルを招き、過大予測は本来入れられる作業を捨てます。 このコストの非対称性を扱うため、量子化回帰と SLO を意識したモデル選択を用いました。 平均誤差の最小化では足りず、運用上の費用関数に合わせた予測が要るという主張です。 ### 耐える [RaidServe](https://openreview.net/forum?id=5pl9fdbEkq)（上海交通大学）は、GPU が部分的に利用不能になる状況でも tensor-parallel な LLM サービングを続けるシステムです。 標準的なテンソル並列は、同じ数の GPU が正常に揃っていることを前提にしがちです。 しかし実運用では、一部の GPU が壊れる、退避する、別ジョブに取られる、性能が落ちる、といった不規則な状態が起きます。 RaidServe は、非一様なテンソル並列、循環的な KV キャッシュ配置、負荷を見たルーティングに加え、KV キャッシュの予防的バックアップと必要時の重み復旧を組み合わせ、再計算や全複製の費用を避けます。 障害を例外ではなく通常状態の一部としてサービング設計に入れる方向です。 [GhostServe](https://openreview.net/forum?id=xKjYiUgeOK)（セントラルフロリダ大学）は、サービング中の KV キャッシュを軽量に保護します。 障害時に KV キャッシュを失うと、プロンプト全体の再計算が必要になり、応答遅延が大きくなります。 丸ごと複製すればメモリを大きく消費し、再計算に頼れば長コンテキストで重くなります。 GhostServe はその中間として、ホストメモリに erasure coding のパリティ断片を置き、軽量なチェックポイントと復旧を行います。 LMCache が KV キャッシュをデータ層として扱ったのに対し、GhostServe はそのデータ層を障害からどう守るかを扱っている、と整理できます。 ### 運用上の含意 これらを合わせると、クラスタ運用の標準像はかなり変わります。 - **利用率は十分な指標ではない。** GPU が忙しいことと、訓練が進んでいること、推論 SLO が守られていること、保守が予定通り消化されていることは、それぞれ別である。 - **ヘルスチェックは機能的な正しさだけでは足りない。** NCCL テストとバーンインを通過しても、本番ワークロードで遅いノードは残る。 - **障害復旧は再計算だけでは足りない。** 訓練では予備資源とチェックポイントが、推論では KV キャッシュの保護と不規則な GPU 可用性への対応が要る。 - **運用計画は固定 worst-case から確率的な意思決定へ移る。** 予備資源も保守時間も、確率モデルと費用関数の上で選ばれる。 この方向は、AI クラスタを単なる計算資源ではなく、故障し、劣化し、修理され、再配置される生産システムとして扱うものです。 さくらONE の発表で報告した、ジョブ件数と GPU 占有時間の乖離や、キャンセルされたジョブが GPU 占有時間の多くを占めるという観測も、平均値では運用を見られないという同じ論点に属します。 ## トピック3: 開発の律速は生成から検証へ移った 従来のシステム最適化では、人間がカーネル、演算子、スケジューラ、コンパイラ規則を設計し、オートチューナがその範囲内を探索していました。 探索空間はテンプレート、パラメータ、既存の手書き実装に強く制約されます。 MLSys 2026 では、この反復に LLM エージェントが入り始めました。 エージェントは候補設計を生成するだけでなく、プロファイラ、テスト、リンタ、シミュレータ、サンドボックス、監査ログと接続されます。 その結果、設計空間は人間が事前に列挙したチューニング範囲を超えて広がる一方で、生成物を採用するには、正しさ、性能、不正な近道、保守性を判定する評価システムが必要になりました。 本記事で扱う8本の招待講演のうち、Keynote 2本と Invited Talk 2本がこの問題を扱ったことは、会議の重心を示しています。 Roger Wang の Invited Talk [Rethinking Open Source Contribution in the Age of AI Agents](https://mlsys.org/virtual/2026/invited-talk/10000) は、保守者側の負荷を扱いました。 vLLM のような広く使われるシステムでは、外部からのプルリクエストが増えるほど、コード量ではなく、設計整合性、検証、レビュー、長期保守が律速になります。 局所的なバグ修正はシステム全体の抽象化を壊すことがあり、ベンチマークだけを通す修正は症状を隠して根本原因を残すことがあります。 講演は開発速度の向上を否定していません。 速度が上がるほど保守者が持つべき判断能力が変わる、と述べています。 Mark Saroufim の Keynote [When AI Starts Writing Systems Code](https://mlsys.org/virtual/2026/invited-talk/3655) は、評価そのものの脆さを扱いました。 GPU MODE の leaderboard では、LLM を使って多くの参加者が高性能カーネルを提出しており、専門家だけが GPU カーネルを書けるという前提はすでに崩れています。 一方で提出コードは信頼できるとは限らず、出力を固定値にする、同期を避けて計測をだます、キャッシュを悪用する、テスト時だけ正しく見せる、といった報酬ハックが紹介されました。 これは競技システムに限った問題ではなく、AI が自動最適化するすべての環境に現れます。 講演は、AI が生成したコードを AI が監査する Kernel Guard を示しつつ、監査 AI を置くだけでは足りず、競技者、攻撃者、監査者、評価基盤が相互に進化する閉ループが要ると述べました。 Lidong Zhou の Keynote [The Next Horizon of Systems: From MLSys to System Intelligence](https://mlsys.org/virtual/2026/invited-talk/3665) は、これに一つの答えを示しました。 例として挙げられたのは集合通信のスケジューリングです。 AI に全コードを自由生成させるのではなく、スケジュールという限定された出力だけを生成させ、検証、コード生成、実行はシステム側が担います。 この分担により、AI の探索能力を使いながら実行の正しさと安全性を保てます。 形式検証についても、AI に仕様や証明を書かせると証明を省いたり仕様を弱めたりして検証器をだますことがあるため、人間が上位の意図と信頼境界を定め、AI がその内部で証明の鎖を埋める構造が要る、と述べています。 二つの講演は響き合っています。 AI に自由度を与えるほど成果は出ますが、同時に検証可能性を失いやすい。 AI をシステムに入れるなら、出力空間を設計し、検証可能なインターフェースを作る必要がある、というのが共通の教訓でした。 一般セッションでも、この構図に沿った発表が続きました。 [AccelOpt](https://mlsys.org/virtual/2026/oral/3808)（スタンフォード大学）は、AWS Trainium の NKI カーネルを対象に、候補生成、実装、プロファイル、正当性検証、成功例からの知識抽出を繰り返します。 一回のコード生成ではなく、失敗を次の設計候補へ戻す閉ループが特徴です。 [Agentic Operator Generation for ML ASICs](https://mlsys.org/virtual/2026/oral/3817)（Meta）は、AI 生成を性能チャンピオン競争ではなくバックエンドの網羅性に使い、生成した演算子実装をリンタ、JIT、実機またはシミュレータ、既存のテスト群へ通して失敗を構造化して返します。 [ADR](https://mlsys.org/virtual/2026/oral/3853)（Uber）は、エージェントを作る側ではなく監視する側のシステムです。 従来の EDR がファイル、プロセス、ネットワークを観測するのに対し、ADR はエージェントセッションを観測し、危険なツール利用やポリシー違反を検出します。 評価の側も変化しています。 Lisa Li の Invited Talk [Eliciting Language Model Behaviors with Investigator Agents](https://mlsys.org/virtual/2026/invited-talk/3645) は、安全性評価とレッドチーミングを探索問題として定式化しました。 一つの jailbreak を見つけるのではなく、複数の失敗モードを網羅することが目的になります。 [FlashInfer-Bench](https://arxiv.org/abs/2601.00227)（ワシントン大学）は、トレース、正当性、性能、leaderboard、本番エンジンの差し替えをつなぎ、ベンチマークを論文の採点表ではなく、生成されたシステム部品を本番へ近づける継続的な評価基盤として扱います。 ## 大規模訓練: 三つのトピックが交わる場所 大規模 LLM 訓練では、単一 GPU にモデル、活性、オプティマイザ状態を載せることはできません。 データ並列、テンソル並列、パイプライン並列、FSDP、MoE のエキスパート並列が標準的な道具になっています。 しかし長コンテキスト、MoE、異種 GPU、低帯域リンクが組み合わさると、固定の並列化だけでは負荷の偏りを吸収しにくくなります。 長コンテキストと MoE は並列化の再構成を迫り、クラスタの故障と異種性は訓練の進捗を直接削ります。 MLSys 2026 では、並列化を固定した前提ではなく、アテンション計算、通信、メモリ、異種資源の形に合わせて再構成する方向が強まりました。 [DistCA](https://github.com/hao-ai-lab/DistCA)（カーネギーメロン大学）は、長コンテキスト訓練で支配的になる core attention を分離し、attention だけを別単位で再バッチして再配置します。 [MoEBlaze](https://mlsys.org/virtual/2026/papers.html?filter=titles)（Meta）は、エキスパートへ送るトークンを物理的に並べ替えて大きな中間テンソルを保持する実装を避け、軽量な index と on-the-fly gather によってその実体化を減らしました。 MoE の効率は All-to-All だけでなく、トークンルーティングの中間表現をどれだけ作らずに済むかにも左右される、という指摘です。 訓練の課題はデータ管理へも広がりました。 Luke Zettlemoyer の Keynote [Rethinking Pretraining: Data and Architecture](https://mlsys.org/virtual/2026/invited-talk/3706) は、多くの能力が事前学習の段階ですでに埋め込まれている可能性を強調し、ポストトレーニングをその能力を引き出す操作として位置づけました。 アーキテクチャ面では、トークナイザを使わない Byte Latent Transformer と、データの来歴ごとに専門家を分ける FlexOlmo が紹介されています。 後者は、データを混ぜるだけでなく、追加、削除、非公開化しやすい形でモデルに入れる方向です。 巨大クラスタを効率よく使うだけでなく、どのデータをどの専門家に入れ、後からどう差し替えるかが、システム設計の一部になりつつあります。 ## 2027年に向けて MLSys 2026 の中心メッセージは、AI の進歩を決める場所がモデル単体からシステム全体へ移ったということでした。 三つの主要トピックは、いずれも来年以降に向けた問いを残しています。 - **配備構成の制御を誰が作るか。** P/D 分離、モデルルーティング、電力調整は、いずれも負荷に応じた継続的な制御問題になった。制御器そのものの生成と検証が次の主題になりうる。 - **検証系の供給が追いつくか。** 生成が民主化された今、監査、品質ゲート、継続評価が律速になる。検証系自体を AI で組み立てる方向が予想されるが、検証器をだます報酬ハックとの共進化は避けられない。 - **KV キャッシュのデータ層化がどこまで進むか。** 保存、圧縮、共有まで来た以上、分散データシステムの古典的な主題（整合性、耐障害性、階層化、ガベージコレクション）が推論基盤へ順に持ち込まれると考えられる。GhostServe の erasure coding はその先例である。 - **運用の確率化が SRE の実践と合流するか。** グッドプット、予備資源、確率的な保守計画は、SRE が扱ってきた SLO、エラーバジェット、キャパシティ計画と同じ形をしている。AI クラスタの運用知識と SRE の方法論を橋渡しする報告は、まだ少ない。 ## おわりに MLSys 2026 で扱われていたのは、高速化の手法だけではありませんでした。 何を測るか、どこまで正しさを保証するか、どの資源を冗長化するか、どの失敗を許容するか。 こうした設計判断が、モデル品質、利用者体験、開発速度、クラスタ費用を同時に左右することを示した会議だったと思います。 さくらインターネット研究所では引き続き、日本の AI 研究と産業競争力を支える大規模 AI インフラの研究開発に取り組んでまいります。 本会議で得られた議論やフィードバックも、今後のさくらONE の発展と新たな研究課題の探索に活かしていきます。