2026__MLSys2026__ContextPilot Fast Long-Context Inference via Context Reuse

# ContextPilot: Fast Long-Context Inference via Context Reuse > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 2 (May 19 / Tue)、Grand Ballroom 2、13:00 - 13:15 PDT > - **登壇者:** Yinsicheng Jiang（University of Edinburgh） > - **URL:** https://mlsys.org/virtual/2026/oral/3810 > - **関連研究:** https://github.com/EfficientContext/ContextPilot > [!abstract] 概要（MLSys サイト） > AI アプリケーションは長コンテキスト推論への依存を強めており、LLM は強力な推論を支えるために大量のコンテキストを消費する。代表例として RAG、エージェントメモリ層、マルチエージェントオーケストレーションがある。入力コンテキストが長くなるほどプリフィルレイテンシが主要なボトルネックとなる。しかし現行のプリフィル高速化技術にはトレードオフがあり、推論品質を維持すると KV キャッシュ再利用の恩恵が小さく、再利用を高めると推論品質が劣化する。本研究では ContextPilot を提案する。これはコンテキスト再利用（context reuse）を新たな仕組みとして導入し、長コンテキスト推論を高速化するシステムである。ContextPilot はコンテキストインデックスを導入して LLM インタラクション間（ユーザ間・ターン間など）で重複するコンテキストブロックを特定する。さらにコンテキストアライメントと重複排除の技法を提案し、KV キャッシュ再利用を最大化する。再利用下で推論品質を維持するため、品質劣化を防ぐ簡潔なコンテキストアノテーションを導入する。最後に ContextPilot はモジュラーアーキテクチャとクリーンなインターフェースで構築され、既存の推論エンジンと統合可能である。広範な評価により、ContextPilot は最先端手法と比較してプリフィルレイテンシを最大 3 倍削減しつつ推論品質を維持し、コンテキスト長が長い場合には推論品質を向上させることさえ示された。 ## 問題設定 - LLM のコンテキストウィンドウは 2023 年から 2026 年の 3 年間で約 5000 倍に拡大した（スライド: GPT-4 の 8K から LLaMA 4 Scout の 10M まで）。 - AI エージェントはタスクあたり数百万トークンを消費する（Terminal-Bench 2.0 で 1.55M、GAIA で 2M、SWE-bench Verified で 6M）。プリフィルレイテンシはコンテキスト長に対し超線形に増大する（50K トークンで 1.3 秒、200K トークンで 18.5 秒）。 - 32B 密モデルを単一 H100 GPU で実行する場合、推論エンジンは 20K--130K トークンのプリフィルを処理し、3--10 秒のレイテンシが発生する（論文 Section 2.2）。MoE モデルではさらに長くなる。 - 既存の KV キャッシュ再利用手法には二つの問題がある。 - **厳密プレフィックスマッチング**（RadixCache、LMCache、RAGCache）: トークン列が完全一致しないと再利用できず、キャッシュヒット率が極めて低い（MultihopRAG + Qwen3-32B で 4.6%、NarrativeQA + Llama3.3-70B で 5.5%）。 - **近似 KV キャッシュマッチング**（CacheBlend）: 浮動小数点類似度で再利用を判定しヒット率は上がるが、精度が 9--11% 低下する（約 60% から約 50% へ）。 ## 提案手法 ContextPilot はコンテキスト再利用（context reuse）を新たなメカニズムとして導入し、プリフィルを高速化する。システムは 3 つの柱から成る。 ### 1. コンテキストインデックス（Context Index） - プレフィックスキャッシュの状態を効率的に追跡する木構造インデックス。radix tree を「ミラー」する設計で、親ノードは子の共有プレフィックスを、葉ノードは完全なコンテキストを表す。 - 階層的クラスタリングでインデックスを構築する。コンテキスト間の距離関数は、重複するドキュメント数（オーバーラップ率）と位置類似度（コンテキストランキング距離）の 2 要素を組み合わせる。 $d_{ij} = 1 - \frac{|S_{ij}|}{\max(|C_i|,|C_j|)} + \alpha \cdot \frac{\sum_{k \in S_{ij}} |p_i(k) - p_j(k)|}{|S_{ij}|}$ ここで $S_{ij}$ は共有ドキュメント集合、$\alpha \in [0.001, 0.01]$。 - 構築の計算量は $O(N^2)$（N はコンテキスト数）で、CPU 並列化可能。2,000 コンテキストで CPU 8 秒 / GPU 0.82 秒。検索は $O(|C| \cdot \log n)$、リクエストあたり約 0.068 ms。 - 12K コンテキストで 7.48 秒、100K コンテキストでも 12 分以内で構築完了（Table 3c）。 ### 2. コンテキストアライメント（Context Alignment） - コンテキストブロックの並び順をプレフィックスキャッシュの構造に合わせて再配置し、キャッシュヒットを最大化する。 - アライメントによりキャッシュヒット率が劇的に向上する。MultihopRAG で 38.9%、NarrativeQA で 20.2%、QASPER で 16.5% に上昇し、ベースライン比 3--8 倍の利用率改善（論文 Section 3.2）。スライドでは、システムプロンプトのみの 5% ヒットから 33--67% ヒットへの改善を図示。 - アライメントによる精度擾乱は 0.1--3.3% と小さい（論文 Section 7.4）。現代の LLM はコンテキスト順序に対しロバストであり、DEmO 追試（Table 1）でも GPT-3.5 / GPT-5.1 ともに順序変更による精度差はほぼゼロ。 - キャッシュ認識スケジューリングを導入し、共有プレフィックスを持つコンテキストをグループ化して連続実行する。計算量は $O(N) + O(N \log N)$ で、radix tree 全体を再走査する既存手法（RAGCache、SGLang の LPM）より効率的。 ### 3. コンテキスト重複排除（Context De-duplication） - マルチターン会話でターン間に繰り返し検索されるコンテキストブロックを特定し除去する。MT-RAG の調査によるとターン間で平均 40% のドキュメントが重複する。 - ブロックレベル: コンテキストインデックスの会話記録を照会し、前ターンでキャッシュ済みのブロックを検出して除去。 - コンテンツレベル: 異なるコンテキストブロック間で共通するサブブロックを、コンテンツ定義チャンキング（ハッシュベースの可変長分割）で検出し重複排除。$O(|C|)$ 時間、リクエストあたり約 0.6 ms。 - 重複排除による精度低下は 1--3% で、アノテーションにより回復可能。 ### コンテキストアノテーション（Context Annotations） - アライメントと重複排除で生じる微小な精度擾乱を補償する軽量なテキスト指示。 - **順序アノテーション**（アライメント用）: 元の関連度順位を明示する指示をプロンプトに追加（例: "Please read in priority order: [CB2] > [CB1] > [CB4]"）。 - **位置アノテーション**（重複排除用）: 除去されたブロックの参照先を指示（例: "Refer to [CB4] in Turn 1."）。 - トークンオーバーヘッドは無視できる水準で、アライメント単独比で +1.4% から +4.4% の精度改善を達成。MultihopRAG + Qwen3-32B では F1 が +4.0% 向上（論文 Section 5.3）。 ### システムアーキテクチャ - ContextPilot はリトリーバル/メモリストア（ベクトル DB、Mem0 等）と推論エンジン（SGLang、vLLM、llama.cpp）の間にミドルウェアとして配置される。 - 推論エンジンへの変更はリクエスト ID 追跡のみ。SGLang 0.4.6 および vLLM 0.10.0 に対応。 - サポートマトリクス: 推論エンジン（vLLM、SGLang、llama.cpp）、RAG/メモリ（PageIndex、Mem0）、エージェントフレームワーク（OpenClaw、Hermes Agent、OpenCode）。 ## 実験・評価 ### マルチセッション RAG（Table 2） - データセット: MultihopRAG、NarrativeQA、QASPER。モデル: Qwen3-4B-Instruct-2507、Qwen3-32B、Llama3.3-70B-Instruct。H100 GPU クラスタ（16 基）。 - ContextPilot は LMCache、RadixCache、CacheBlend を全データセット・全モデルで上回る。 - MultihopRAG + Qwen3-32B: F1 64.4（LMCache 60.4、CacheBlend 60.4、RadixCache 60.4）、プリフィルスループット 36,296.1 tok/s（LMCache 14,708.6 の 2.5 倍）。 - スライド: オフラインバッチ RAG（Llama3.3-70B）でプリフィルスループット 30.0 K tok/s、LMCache 比 2.6 倍。 ### マルチターン RAG（Table 3a） - MT-RAG データセット、Qwen3-4B / Llama3.1-8B / Qwen3-30B で評価。 - TTFT を 3.45 倍（Qwen3-4B）、3.35 倍（Llama3.1-8B）、3.09 倍（Qwen3-30B）削減（対 LMCache）。RadixCache 比でも最大 2.00 倍、CacheBlend 比 1.55 倍。 - スライド: オンラインマルチターン RAG（Qwen3-4B）で TTFT 0.22 秒、LMCache 0.76 秒の 3.5 倍高速化。 - 精度も維持・向上（Qwen3-4B: 64.27%、LMCache 63.46%）。 ### ハイブリッド RAG（マルチセッション + マルチターン、Table 3b） - Qwen3-4B-Instruct-2507、H100 GPU 上でセッション数 2--32 で評価。 - 全並行度で最低 TTFT を達成。32 セッション時でも LMCache 比 2.65 倍、RadixCache 比 1.49 倍、CacheBlend 比 1.20 倍。 ### DeepSeek-R1（671B）MoE モデル - 32 基 H20 GPU クラスタで評価。MultihopRAG でキャッシュヒット率を 5% から 60% へ、NarrativeQA で 6% から 38% へ向上。 - 16xH20 で 1.81 倍、32xH20 で 1.52 倍のプリフィルスループット向上。 ### エージェンティックワークロード - **Chain-of-Agent (CoA)**: MultihopRAG 上で 15 エージェント構成。Qwen3-4B で精度 48.3% → 50.2%、スループット 1.8 倍。Llama3.1-8B で 50.7% → 54.4%、2.1 倍高速化。 - **Mem0（エージェントメモリ）**: LoCoMo ベンチマーク、Qwen3-4B、k=100 で TTFT を 0.101 秒から 0.055 秒へ削減（1.83 倍）、精度は 0.437 → 0.420 の微小な低下。スライドでは RadixCache 比 2.0 倍の TTFT 削減（0.1051 秒 → 0.0548 秒）かつ精度維持（0.418 → 0.421）。 - **OpenClaw（実エージェントパイプライン）**: RTX 5090 単体、SGLang 0.5.9、Qwen3-4B-Instruct-2507。ドキュメント解析タスク（60 タスク、22 文書、約 250 ターン）でプリフィルレイテンシを平均 63.6%、P99 で 73.7% 削減。プロンプトトークンを平均 24.4%、P99 で 52.7% 削減。ウォールタイムを平均 20.7% 削減。スライドでは TTFT を 1.8--3.8 倍高速化。 ### エッジデバイス（Table 5） - llama.cpp + Llama-3.2-1B-Instruct、MultihopRAG。 - M3 MacBook Air（16 GB）: 3.31 秒 → 1.38 秒（2.41 倍）。 - NVIDIA Jetson AGX Orin: 2.12 秒 → 1.41 秒（1.50 倍）。 ### オーバーヘッドとロバスト性 - リクエストあたりのオーバーヘッドは約 0.7 ms（検索 + アライメント + 重複排除の合計）で、プリフィルレイテンシ（秒単位）と比較して無視できる。 - アライメント単独での精度変動は 1% 以下。アノテーション追加により +1.4% から +4.4% 回復。 - 長時間ワークロードでもキャッシュヒット率約 34% を維持（ベースラインの約 7% の 5 倍）。 ## 結論・オープン課題 - ContextPilot はコンテキスト再利用という新たなメカニズムにより、長コンテキスト推論のプリフィルを最大 3.5 倍高速化しつつ精度を維持・向上させた。 - モジュラー設計により vLLM、SGLang、llama.cpp、およびエージェントフレームワーク（OpenClaw、Hermes Agent、OpenCode）と統合可能。データセンターからエッジデバイスまで幅広く適用できる。 - 今後の展望として、知識認識型キャッシュ再利用（knowledge-aware cache reuse）と、NanoClaw・Codex など更に広いエージェントフレームワークへの対応が挙げられている（スライド最終ページ）。 - コンテキスト再利用をコンテキストエンジニアリング、リプレイ、管理、圧縮最適化などの基盤ソフトウェアとして発展させる構想が示されている（論文 Section 9）。