# FlashAgents: Accelerating Multi-Agent LLM Systems via Streaming Prefill Overlap > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 2 (May 19 / Tue)、15:30 - 15:45 PDT > - **登壇者:** Taosong Fang ら > - **URL:** https://mlsys.org/virtual/2026/oral/3760 > - **OpenReview:** https://openreview.net/forum?id=m14PPUfgEc > [!abstract] 概要 > LLM はマルチエージェントシステム（MAS）において協調エージェントとして広く展開されているが、エージェント間の逐次的なやり取りが深刻なレイテンシのボトルネックを生む。従来のサービングシステムでは、下流エージェントがプリフィルを開始する前に上流エージェントの生成完了を待つ必要があり、エージェント間遷移で大きなアイドル時間が発生する。本研究では FlashAgents を提案する。トークンレベルのストリーミングとプレフィクス対応の協調により、マルチエージェントワークフローを高速化するシステムである。エージェント間ストリーミングとインクリメンタルプリフィルにより、上流のデコードと下流のプリフィルをオーバーラップさせてエージェント間レイテンシを削減する。同一ターン内のプレフィクスキャッシュ（intra-turn prefix cache）は、ラディックスツリーに基づき同時リクエスト間で共有プレフィクスを検出・再利用し、冗長なプリフィル計算を排除する。SGLang 上に実装し、実ワークフローで最大 40% のエンドツーエンドレイテンシ削減、制御された二エージェントベンチマークで 3.5 倍の高速化を達成した。 ## 問題設定：エージェント間アイドル時間 - 現代の MAS ではユーザーの 1 リクエストが多数の依存 LLM 呼び出しを引き起こす。ユーザーが体感するのはワークフロー全体のレイテンシであり、個々の呼び出しレイテンシではない - 従来のサービングシステムはリクエストを独立に扱い、エージェント間の依存関係を認識しない。下流エージェント B は上流エージェント A の生成完了後にはじめてプリフィルを開始するため、A のデコード中は B の GPU が完全にアイドル状態となる - 既存最適化の分類（スライド 4）： - **リクエスト内最適化**（FlashAttention、PagedAttention、チャンクドプリフィル等）は解決済み - **リクエスト間最適化**（コンティニュアスバッチング、RadixAttention プレフィクスキャッシュ、投機的デコーディング等）も解決済み - **エージェント間最適化**（A.decode → B.prefill のハンドオフ、同時共有プレフィクスの再利用、ポジション安定プリフェッチ）は**未対処** - プリフィルとデコードのスループットギャップは縮小傾向にある。MTP やスペキュレーティブデコーディング、ヘテロジニアス構成（SLM をサブエージェントとする構成）によって上流の生成速度が向上し、オーバーラップの余地が拡大する（スライド 5、Figure 1）。例えば Qwen3-8B では A100-80GB 上でプリフィルが 7,644 tokens/s、デコード（bs=1..32）が 2,554 tokens/s、MTP 上限が 5,766 tokens/s である ## 提案手法 1：エージェント間ストリーミングとインクリメンタルプリフィル（IASIP） - 中核アイデア：エージェント A のデコードフェーズ中に生成トークンをトークン単位で下流エージェント B にストリーミングし、B がインクリメンタルにプリフィルを実行する - 動作手順（Algorithm 1）： 1. エージェント A がデコードを開始し、生成トークンをバッファ $Buf_B$ に逐次追加 2. バッファサイズがチャンクサイズ閾値に達するかストリーム終端に到達すると、エージェント B のエンジンがインクリメンタルプリフィル（IncPrefill）を実行し KV キャッシュ $KV_B$ を更新 3. IncPrefill はコーザルアテンションにより因果整合性を保証する。$i$ 番目のチャンク処理時、クエリトークン $Q_i \in \mathbb{R}^{n_i \times d}$ は過去全チャンクの累積キーバリューペアに対してアテンションを行う：$\text{Attention}(Q_i, K_{:i}, V_{:i}) = \text{softmax}\left(\frac{Q_i K_{:i}^\top}{\sqrt{d}}\right) V_{:i}$ 4. A の完了後、残余トークンを処理し B がデコードフェーズに移行 - レイテンシモデル： - 逐次実行：$L_{\text{seq}} = T_{\text{decode,A}} + T_{\text{prefill,B}} + T_{\text{decode,B}}$ - FlashAgents：$L = T_{\text{decode,A}} + T_{\text{prefill,B}} - T_{\text{overlap}} + T_{\text{decode,B}}$ - オーバーラップ上限：$T_{\text{overlap}} \leq \min(T_{\text{decode,A}},\ T_{\text{prefill,B}})$ - カーネル変更不要。SGLang の既存プリフィルパス上の薄いレイヤーとして実装される ## 提案手法 2：ターン内プレフィクスキャッシュ（Intra-Turn Prefix Cache） - 問題：複数の下流エージェントが同時にインクリメンタルプリフィルを実行する場合、同一のシステムプロンプト＋ドキュメントといった共有プレフィクスが N 回再計算される。既存の RadixAttention の永続キャッシュはリクエスト完了後にしか更新されないため、処理中（in-flight）のリクエスト間でプレフィクスを共有できない - 解決策：プリフィルトリガー発火時に一時的なラディックスツリーを構築し、バッファ済みトークン列から共有プレフィクスを検出する（Algorithm 2） - Step 1: 全リクエストのバッファ列 $\{U_r\}$ を共有ラディックスツリー $\mathcal{T}$ に挿入。共通プレフィクスは自然にツリー構造で表現される - Step 2: 新規生成ノードのみをトポロジカル順（浅→深）で走査し、各ノードの KV キャッシュを親ノードの KV を拡張して算出。1 つのユニークプレフィクスにつき 1 回だけプリフィルを実行 - Step 3: 各リクエスト $r$ のルートからリーフまでのパス上の KV デルタを収集し、完全な KV キャッシュを組み立てる - 構築計算量は全未処理トークン数に対して線形：$O(\sum_r |U_r|)$。メモリオーバーヘッドはユニークプレフィクス拡張数に限定される - 永続 RadixAttention は変更せず、そのブラインドスポット（in-flight リクエスト間共有）を補完する ## 複雑トポロジへの拡張 - **リニアチェーン**：A → B → C のように各リンクで IASIP を直列適用しパイプライン効果を得る - **Fan-out**：A → {B, C} の場合、A のトークンを並列に複数受信者へストリーミング - **Fan-in**：{B, C} → D の場合、RoPE の位置エンコーディング依存により、ポジションが確定したセグメント（position-stable）のみインクリメンタルプリフィル可能。具体的には D のプロンプトが [system prompt || output_B || output_C] と線形化される場合、システムプロンプトと output_B は B の出力確定に伴いインクリメンタルプリフィルできるが、output_C のプリフィルは B の長さ確定まで遅延される。正確性を担保する保守的戦略を採用 ## 実装 - SGLang のランタイムをストリーミングおよびプレフィクス対応の協調機能で拡張。コア RadixAttention ツリーは変更せず、モジュラーな拡張レイヤーとして Algorithm 1・2 を実現 - AutoGen との統合：非同期クライアントがストリーミングリクエストを管理。上流エージェントの生成をストリーミングモードで送信し、下流リクエストがそのストリームからインクリメンタルにプリフィルを実行 - エラーハンドリング：上流エージェント障害時に下流エージェントへ通知し、利用可能トークンでプリフィルを完了するか中断する仕組みを備える ## 実験 ### マイクロベンチマーク（Agent A → Agent B カスケード） - 評価構成：Qwen2.5-7B、Qwen3-235B（高スループット上流）、Qwen3-235B（低スループット上流）の 3 構成。同時実行数 {1, 2, 4, 8}、合計 240 設定 - ハードウェア：NVIDIA A100-80GB GPU、CUDA 12.6。7B/32B は単一 A100、235B は TP=8 で 8 枚の A100 を使用 - 性能指標：下流応答レイテンシ $T = t_{\text{first}}^B - t_{\text{first}}^A$（上流エージェントの最初のトークンから下流エージェントの最初のトークンまでの経過時間） - **結果**：全 240 構成で FlashAgents がベースラインを上回り、高速化は **1.05 倍から 3.52 倍**の範囲 - Qwen2.5-7B：同時実行数 1 では 1.05〜1.2 倍だが、同時実行数 2 でピーク **3.52 倍**を達成。プレフィクスキャッシュと GPU 利用率向上の複合効果による - Qwen3-235B：大型モデルではプリフィルフェーズが長くオーバーラップ機会が増大し、単一リクエストでも高い高速化を実現 ### 実ワークフロー（エンドツーエンド） - **Chain**（AutoGen 旅行プランナー、4 エージェント）：Qwen2.5-7B（A100）を上流、Qwen2.5-32B（別 A100）を下流に使用。2,500 トークンの共有ガイドを含む逐次パイプライン（Planner → Local → Language → Summary） - N=1 で **1.8%** のレイテンシ削減、N=8 で intra-turn prefix cache が冗長プリフィルを排除し **11.9%** のレイテンシ削減 - **MapReduce**（文献レビュー、3 レビューア + メタレビューア）：ベースラインは 3 レビューアを逐次実行（AutoGen デフォルト）。FlashAgents は並列化しメタレビューアの共有プレフィクスをデコード中にプリウォーム - N=1 で **40.3%** のレイテンシ削減、N=8 では 32B GPU での共有デコード競合により **14.7%** に低下 - **PPTAgent**（プレゼンテーション生成）：VLM アナライザ（Qwen2.5-VL-7B-Instruct、GPU 0）が 12 スライドのアウトラインを生成し、12 個の並列コンテンツジェネレータ（Qwen3-14B、GPU 1）がスライドを生成。各ジェネレータのプロンプト中 3,013 トークン（sys_prompt + doc_content）がポジション安定な共有プレフィクスであり、アナライザのデコード中にプリウォーム可能。残りは outline_item + slide_instr の約 300 トークンのみ - FlashAgents は 3.41 秒でベースライン 4.49 秒に対し **24.1%（1.32 倍）** のレイテンシ削減 ### アブレーションスタディ - Qwen3-32B、上流 TPS=50 での比較（Table 1）： - 同時実行数 1：IASIP のみで 1.09〜1.16 倍（プレフィクスキャッシュの寄与は最小） - 同時実行数 8、prefix=2000：IASIP のみで 5.32 秒、Full FlashAgents で 4.20 秒（プレフィクス重複排除により **21% の追加削減**）。総合 **2.40 倍**の高速化 - IASIP がハンドオフバリアを除去し、intra-turn prefix cache が同時実行時の冗長計算を排除する相補的な役割を確認 ### オーバーヘッド分析 - インクリメンタルプリフィルのオーバーヘッドは 2 つの要因に起因：(1) コンテキスト分割による計算強度低下（メモリバウンド化）、(2) モデル重み・蓄積 KV キャッシュへの反復アクセス - チャンクサイズ 128 では単一パスプリフィルの最大 3 倍のオーバーヘッドだが、チャンクサイズ 512 で **約 1.2 倍**に収束 - KV キャッシュ履歴アクセスの追加コストは全モデルで 4.6〜7.9% と軽微 ### スケジューリング直交性 - FlashAgents と SJF（Shortest Job First）スケジューリングの組み合わせを評価（Figure 9） - 同時実行数 1 では FlashAgents のストリーミングオーバーラップが支配的（57% 削減）、SJF 単独で 65〜70% 削減、組み合わせで **56%（44% + α）** 削減 - 同時実行数 10 では組み合わせで **63%（37% + α）** 削減。両者は独立かつ相補的に動作し、Kairos 等の既存スケジューラとの共存が可能 ## 結論 - マルチエージェント LLM サービングにおける新たなボトルネックとして**エージェント間アイドル時間**を特定し、トークンレベルのストリーミングとインクリメンタルプリフィルによりこれを解消する FlashAgents を提案した - ストリーミング＋インクリメンタルプリフィルが下流の状態準備（プリフィル、KV キャッシュロード）を上流デコード中に移動し、intra-turn prefix cache がこのアイデアを同時実行下にスケールさせる - SGLang 上に実装し AutoGen と統合。ワークフロー構造の事前知識や定義済みテンプレートを必要とせず、動的なワークフローにも適応する - 今後の課題として、オーバーラップ中の非生成的操作の実行、適応的ストリーミングポリシー、メモリフットプリント・オーバーラップ機会・公平性を統合的に考慮する高度なスケジューリング戦略を挙げている