# Beyond Model Serving: Cross-Stack Co-Design for Agentic Systems > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 1 (May 18 / Mon)、09:25 - 09:50 PDT > - **登壇者:** Esha Choukse（Microsoft Azure Research – Systems、Principal Researcher。MIT・UT Austin との共同研究） > - **URL:** https://mlsys.org/virtual/2026/invited-talk/3650 > - **関連研究:** https://aka.ms/azrs-ai > [!abstract] 概要（MLSys サイト） > AI は単一モデル推論から、対話的・マルチモーダル・エージェント的システムへ移行している。性能はモデルやハードウェア単体ではなく「フルスタックの協調設計（cross-stack co-design）」で決まる。ML とシステムの従来の境界を見直し、**精度・品質を「レイテンシ・コスト・エネルギーとトレードオフ可能な動的なシステムレベルの量」として扱う**ことを提唱する。 ## 全体の主張（テーゼ） - **システムアーキテクトの歩み:** クラシックシステム（固定計算・決定的正しさ・既知の目的）→ 単発 LLM 推論（1 プロンプト 1 応答・モデル中心最適化・クエリ単位のスループット/レイテンシ）→ エージェント的システム（多段の適応的実行・リアルタイム or 巨大なレイテンシ余裕のバックグラウンド実行・挙動はオーケストレーションから創発し実行中にも変化）。 - いま求められるのは「**不確実性下で、実行時に適応的な意思決定を伴う効率化**」。 - **抽象化のギャップ:** いまだにワークロードを「AI 推論呼び出しの周りに作ったクラシックシステム（ツール等）」として扱っている → 結果として「間違ったレイヤーで間違ったものを最適化」してしまう。エンドツーエンドで捉えられていない。 - **3 つの幻想（illusions）:** - ①**モデル＝システムであり品質を決める** → 実際はモデル品質は「潜在品質」にすぎず、実現量はその周りのエンドツーエンドのシステム（オーケストレーション・ランタイム・ツール・与えるデータ）が決める。 - ②**計算を増やせば精度が解決する** → 実際はワークフローの全部位が重要なわけでも、計算増で良くなるわけでもない。重要でない部位に計算を投じても精度は上がらない。 - ③**正しさは二値** → エージェント／マルチモーダルでは部分的正しさ・段階的劣化（progressive degradation）・文脈依存の有用性が生じる。自然言語・複数モダリティを扱う以上、正しさには「度合い」がある。 - **核心テーゼ:** 「**正しさはもはや述語（predicate）ではなく予算（budget）であり、精度はシステムのリソースである**」。問いは「どこでも正しいか」ではなく「**どこで正しさが重要で、その達成にいくらかかるか**」。精度をレイテンシ・コスト・エネルギーなど従来のトレードオフ軸と引き換えにする。 ## ケーススタディ 1: Sherlock — 与えられたコスト予算で最良の品質を出す > Yeonju Ro 他（UT Austin）, Haoran Qiu, Inigo Goiri, Rodrigo Fonseca, Ricardo Bianchini, Aditya Akella, Zhangyang Wang, Mattan Erez, Esha Choukse。論文は arXiv。元インターン Yeonju Ro 主導。 ### 課題: エージェントには検証（verification）が必須だが高コスト - 最初の生成が常に正しいとは限らないため検証が不可欠。代表的な検証フロー = **Self-Refine**（出力を別モデルに渡し改善ループ）/ **Advanced-Refine**（上位の高性能モデルを使用）/ **LLM-as-a-Judge**（同一/別モデルで 2 出力を生成し判定）/ **Debate**（合意まで複数ラウンド議論）/ **Self-Consistency**（複数サンプルの多数決）。 - 全ノードに verifier を付けると高コスト・高レイテンシ: スライド「Verifier overheads」では、単一ノードに verifier を付けるだけで正規化コストが最大 ~53×、正規化レイテンシが最大 ~29×（ベースライン比、verifier 種別・タスク依存）に達する。これを全ノードに付け、ドメイン特化ツールのノードにまで LLM 検証を加えればさらに膨らむ。→ テーゼに従い「**選択的検証（selective verification）**」を行う。 ### 脆弱ノードの特定 - クラシックシステムの **fault injection** 研究と同型と捉える（脆弱な部位/耐性のある部位を特定する問題）。 - フォルト生成には Berkeley の **MAST**（"Why Do Multi-Agent LLM Systems Fail?", Cemri et al., arXiv 2025）の障害分類を活用し、用途に合わせて拡張。 - Behavioral deviation faults（指示/役割の誤解 → プロンプト置換, 頻度 **28.63%**） - Context-loss faults（会話履歴の欠落・エージェント間情報の欠落 → コンテキスト落とし, **18.68%**） - Execution faults（誤った推論・タスク脱線・実行時エラー → 出力置換, **52.69%**） - **動的なノード特定:** 動的生成グラフのためオフラインプロファイリングに頼れない → **トポロジカル特徴**（root/terminal への近さ、fan-in/fan-out 次数）で脆弱性の優先順位付け。タスクベースの脆弱性予測器への拡張も可能。 ### verifier の選択（verifier selection problem） - タスク種別ごとに最適 verifier は異なり、さらに同種タスク内でも異なる。verifier が効果なく、むしろ精度を悪化させる場合すらある（タスク×verifier の効用 heatmap で可視化）。単純なバケツ分けでは不十分。 - 解: **軽量な verifier selector** をオフライン学習しオンライン選択にデプロイ。 - Encoder: distilbert-base、Policy optimizer: FC 層を **GRPO** で学習。 - 学習データ: `(prompt, verifier1_reward, ..., verifierN_reward)`。 - 報酬: 「verifier が誤答を訂正できたら +1、それ以外 0」を **コストで正規化**（normalize by cost）→ 精度とコストのトレードオフ。正規化軸が異なる目的の knob になる。 ### 結果 - **コスト×精度:** 固定予算（追加できる verifier 数）下で、ランダム配置／均等配置に対し精度で約 **10%** 改善。予算が厳しいほど効果大。コスト–精度のパレート最適フロンティアの点を捉えられる。 - **レイテンシ削減:** 検証完了を待たず次ノードを投機実行する **Speculative Run-ahead**。ノード応答内の信頼度メトリクスで「verifier 出力なしで進んだ場合に戻る確率」を見積もる → 平均 **約 48.7%** のレイテンシ削減。 - **まとめ（cross-stack）:** 精度を knob として、コスト–精度・レイテンシ–精度をトレードオフ。オーケストレータ（ワークフロー定義）層と AI ランタイム層をまたいで動作（verifier 間のハードウェア選択へ拡張可）。既存システム比でエンドツーエンドにコスト最大 ~2x、レイテンシ最大 ~3x 改善（一定精度下、他軸は変動）。 ## ケーススタディ 2: Streamwise — リアルタイム動画生成（レイテンシ–精度の綱渡り） - **動画生成ワークフロー:** LLM がプロンプトからスクリプト生成 → 各シーンで TTS(text→speech)、T2I→I2I→I2V、最後に V+A（video+audio）を合成しシーンをつなぐ。目標は ①リアルタイム ②コスト効率 ③人間視点で許容できる品質。Podcast/Short/Movie/Lecture/Dubbing 等、複数のワークフローを実装。 - **リアルタイムの定義:** TTFF（Time to First Frame）と TBF（Time between frames）。`TTFF_eff = max(TTFF, 平均TBF × #frames − video duration)`。要は「素早くストリーミング開始し、決して遅れない」（バッファリング待ちが直前シーンの再生時間を超えないようにする）。 - **現状の難しさ:** 10 分のポッドキャストを 1×8xA100 で生成すると **8.3 時間・$70**、時間の **99%** が動画／動画-音声生成（Diffusion Transformer; DiT）に費やされる。 - **knob:** レイテンシの主因は DiT の conditional/unconditional 実行（fidelity と variance のバランス）。精度の knob＝#frames・解像度・denoising steps。レイテンシの knob＝GPU の種類と台数（A100 を増やすほど短縮）。 - **Streamwise のシステム最適化:** - ①Deadline-aware DAG スケジューリング（早いシーンを優先） - ②ヘテロジニアスなハードウェア選択（レイテンシに応じ GPU を選ぶ） - ③適応的品質 knob（目標品質から開始し、デッドラインが危ういとき解像度・denoising steps・品質を早期に下げる） - ④Disaggregation とパイプライン（DiT (I2V vs V+I2V)・VAE を分離） - ⑤Autoscaling（並列度・インスタンス数） - **例:** Shot 1 は最速が必要なので 8xH100 + 低品質（640x400@10 steps）で実行、生まれた余裕で後続シーンを古いハードや高品質（1280x800@20 steps）に割り当て、「最初のフレーム表示後は決して遅れない」。 - **効果:** コスト×TTFF のパレート最適空間を探索（精度は当面 human perspective で評価、LLM-as-judge 化は今後の課題）。 ## 結論・オープン課題 - 2 ケースとも「**品質関連の knob をワークフロー内で露出し、コスト・レイテンシ（電力・エネルギーでも可）とトレードオフして、エンドツーエンドの有用性を協調最適化**」する例。共通レシピ: 1. 品質関連プロパティをランタイムに露出する 2. 選択的な実行判断を行う 3. エンドツーエンドの効用を協調最適化する - **オープン課題:** 不確実性に対する正しい抽象化とは何か／部分的信頼（partial trust）をどうファインチューンするか（実行の各点でのシステム判断へのフィードバック、どの粒度・頻度で得るか）。 - **Takeaway:** 計算だけでなく「**不確実性**」も管理するより良いシステムを作る。関連研究: https://aka.ms/azrs-ai ## Q&A - **Q1（Jenna Chen, UC San Diego）— 動画ストリーミングとモデル層の研究との関係:** 最近 Thinking Machines がリアルタイムの video+audio 生成モデルをリリースした。こうした「動画・音声両方のリアルタイム応答」を、本講演のパラダイム（システム側の最適化）にどう位置づけるか。ストリーミング動画が新たに持ち込む課題も含め興味がある。 - **A:** Thinking Machines の研究も、MLSys にある StreamDiffusion の研究も把握している。リアルタイム動画生成では多くの取り組みが進んでいるが、**レイヤーが異なる**。それらは「モデル層」で精度とレイテンシの本質的なトレードオフ（モデル自体の改変・ファインチューン）を行っている。一方、本講演で示したのは **システム研究者がモデルを変更・ファインチューンせずに実現できること**。両者は併用でき、組み合わせればさらに高速な動画生成が可能になる。 - **Q2 — verifier selector を頻繁に再学習する必要が生じる状況を想定しているか:** （Sherlock の verifier selector の運用について） - **A:** 現状は全タスク種別を理解しようとする **単一の verifier selector** を採用している。ただし論文に書いたとおり、より多くのユースケースへ拡張中で、**1 つの selector が理解できるドメイン数には限界**が見え始めている。そこで今は **ドメインごとに別々の verifier selector** を学習する方向を検討中。具体的には、データセンタ規模で Sherlock をデプロイし様々なワークフローを処理する中で、**フィードバックループ**を組んで「これは最近増えている新ドメインだ」と判定 → そのドメイン向けに新しい selector を学習、または既存 selector をファインチューン/再学習する、という仕組みを Sherlock に追加しているところ。