> [!abstract] 概要 > AI アプリケーションはますます長文脈推論に依存するようになっており、LLM はより強い推論を支えるために大量のコンテキストを消費する。代表例には検索拡張生成(RAG)、エージェントのメモリ層、マルチエージェントオーケストレーションが含まれる。入力コンテキストが長くなるにつれ、プリフィルレイテンシが主要なボトルネックになる。しかし今日のプリフィル高速化技術はトレードオフに直面している。すなわち、推論品質を保つが KV キャッシュ再利用がほとんど得られないか、再利用を改善する代わりに推論品質が劣化するかのいずれかである。 > 本論文では ContextPilot を提示する。これは、より高速な長文脈推論のための新しいメカニズムとしてコンテキスト再利用を導入することでプリフィルを高速化するシステムである。ContextPilot は、LLM とのやり取り(例えば複数ユーザーやターンをまたぐもの)にわたって重複するコンテキストブロックを識別するコンテキストインデックスを導入する。さらに、KV キャッシュ再利用を最大化するためのコンテキスト整列と重複排除の技術を提案する。再利用のもとで推論品質を保つために、品質劣化を防ぐ簡潔なコンテキスト注釈を導入する。最後に、ContextPilot は既存の推論エンジンと統合するクリーンなインタフェースを備えたモジュラーアーキテクチャの上に構築されている。広範な評価により、ContextPilot は最先端手法に比べて LLM のプリフィルレイテンシを最大3倍削減しつつ推論品質を保つことが示される。文脈長がより長くなると、推論品質を改善することさえある。ContextPilot は次で公開されている: https://github.com/EfficientContext/ContextPilot。 ## 論文情報 - タイトル: ContextPilot: Fast Long-Context Inference via Context Reuse - 著者: Yinsicheng Jiang*・Yeqi Huang*(共同筆頭)・Liang Cheng・Cheng Deng・Xuan Sun・Luo Mai(いずれも [[University of Edinburgh]]) - 媒体: 第9回 MLSys Conference(MLSys 2026, Bellevue, WA, USA)採択論文(Oral) - arXiv: 2511.03475(v4, 2026-05-06 改訂)。初回投稿は2025-11-05 - コード: https://github.com/EfficientContext/ContextPilot - スライド: MLSys 2026 発表資料(25ページ、大学ロゴから著者全員が [[University of Edinburgh]] 所属と確認) ## 概要 長文脈推論では、検索文書・エージェントメモリ・過去の会話ターンなどのコンテキストブロック(CB)を LLM に与えるたびにプリフィル計算が発生し、これがレイテンシの支配要因になっている。既存の KV キャッシュ再利用手法は「完全一致でしか再利用できず再利用率が低い」か「近似一致で再利用率は上がるが精度が落ちる」かの二択であった。ContextPilot は、実世界ワークロードでコンテキストブロックがセッション間・ターン間で大きく重複するという観察に基づき、コンテキストの並び替え(整列)と重複排除によって KV キャッシュのヒット率を上げつつ、簡潔な注釈でその副作用による精度劣化を打ち消すアプローチを取る。 ## 問題設定 - 入力: ユーザープロンプトと、検索システム(FAISS、Qdrant、ElasticSearch 等)やメモリストア([[Mem0]] 等)、エージェントのツール呼び出しから取得された複数のコンテキストブロック(CB)。 - 前提: 推論エンジン([[SGLang]]、[[vLLM]]、TensorRT-LLM 等)がプリフィル時に KV キャッシュを計算し、prefix cache(トライ木・ハッシュテーブル等)で以降のリクエストと共有する。 - 課題: CB の集合は同じでも、検索クエリごとに関連度順が異なるため CB の並び順が変わり、既存の完全一致 prefix cache では共有できない。また、マルチターン会話では既出の CB が形を変えて再度取得され、内容レベルでも重複が生じる(例: 同じ「ケネディの死亡日」という情報が複数の CB にまたがって出現する)。 ## 提案手法 ContextPilot は3つのコントリビューションから構成される。 - **アーキテクチャ**: `Context Store`(検索システム・エージェントメモリ) → `ContextPilot`(コンテキストの並べ替え・重複排除) → `Inference Engine` という構成を取る。ContextPilot 内部は `Context Index`(prefix cache 状態の追跡)、`Context Operations`(Align/Deduplicate)、`Cache-aware Scheduling` の3層からなる。推論エンジンの prefix cache に対しては request ID の追跡のみを要求し、既存機能に影響を与えずに `POST /v1/completion` と `POST /evict` の2エンドポイントで連携する。 **Figure: システムアーキテクチャ** ![[_attachments/mlsys2026-contextpilot/slide-system-architecture.png]] (ContextPilot はユーザープロンプトと検索済みコンテキストを受け取り、Context Index に問い合わせて Align/Deduplicate を行い、更新済みコンテキストを Cache-aware Scheduling 経由で推論エンジンに渡す。推論エンジンからのエビクション通知は `POST /evict` で Context Index に反映される。Source: 論文 Figure 3 相当、MLSys 2026 発表スライド。) - **(1) コンテキストインデックス(Context Index)**: prefix cache の階層構造を鏡写しにした木構造で、内部ノードは子ノードの共有コンテキストを、葉ノードは完全なコンテキストを表す。コンテキスト間の距離関数を新たに定義し、共有文書数(overlap rate)と、共有文書の位置一致度(positional alignment)の両方を考慮する: $d_ij = 1 − |S_ij| / max(|C_i|, |C_j|) + α · Σ_{k∈S_ij} |p_i(k) − p_j(k)| / |S_ij|$ ここで `S_ij` は共有文書集合、`p_i(k)` はコンテキスト `i` における文書 `k` の位置、`α ∈ [0.001, 0.01]` は重複数を支配的要因としつつ位置整合を加味する重み。木構築は階層的クラスタリングで `O(N²)` 時間(N はコンテキスト数)、2,000コンテキストで CPU 8秒・GPU 0.82秒。検索は木の高さに比例し実測約 0.068ms/リクエスト。 **Figure: コンテキストインデックスと距離関数** ![[_attachments/mlsys2026-contextpilot/slide-context-index-distance.png]] (3つのリクエスト R1{2,1,3}・R2{5,1,2}・R3{4,1,0}から、共有文書1を持つ根ノードと、R1・R2が共有する {1,2} を持つ中間ノードが階層的クラスタリングで構築される様子。距離関数は overlap rate 項と context ranking distance 項の和。Source: 論文 Figure 4 相当、MLSys 2026 発表スライド。) - **(2) コンテキスト整列(Context Alignment)とスケジューリング**: 新規コンテキストをインデックスに問い合わせ、既存 prefix cache との共有部分を先頭に揃えて並べ替える(未共有文書は元の順序を保つ)。1リクエストあたり約 0.047ms。整列後は、prefix cache の生成・退避ポリシーを意識したスケジューラが、共有プレフィックスを持つリクエスト群をまとめて連続実行する(グルーピング `O(N)` + グループ内ソート `O(N log N)`)。RAGCache や SGLang の LPM が毎回 `O(N log M)+O(N log N)` でグローバルな木の再探索を行うのに対し、ContextPilot はグループ単位の逐次消化により `M`(既存ノード数)に依存しない複雑度を保つ。 整列は「並び替えても LLM が意味を取り違えない」という観察に基づく。DEmO 順序感度研究(Guo et al., 2024)を新しいモデルで再現したところ、SST2・SNLI・SUBJ・CR の4データセットで GPT-3.5 の平均82.9→83.0(ランダム→DEmO)に対し GPT-5.1 は86.9→86.7とほぼ差がなく、現代の LLM は入力順序への感度が大幅に低いことを確認した。それでも整列だけでは QASPER で −1.1% のように軽微な精度低下が残るため、コンテキストの**元の関連度順を伝える簡潔な注釈**("Please read the context in the following priority order: [CB 2] > [CB 1] > [CB 4]")を質問の直前に挿入し、トークンオーバーヘッドをほぼゼロに保ったまま精度を回復する。 **Figure: 整列とアノテーションによるキャッシュヒット率・精度への効果** ![[_attachments/mlsys2026-contextpilot/slide-alignment-annotation-results.png]] (3リクエストの CB を共有プレフィックスで揃えると、キャッシュヒット率がシステムプロンプトのみの5%から33〜67%に向上する。整列による精度低下は約0.1〜3.3%にとどまり、優先順位アノテーションの付加でほぼ回復する。Source: MLSys 2026 発表スライド。) - **(3) コンテキスト重複排除(Context De-Duplication)**: マルチターン会話で既出の CB 全体が再度取得された場合、インデックスの会話履歴から一致を検出し、CB 全体を「[CB 1] を参照」のような位置注釈に置き換える(ContextPilot w/o annotations でも実施可能だが精度回復に注釈が要る)。さらに CB 単位を越えて、文書内部の部分的重複(例: 複数 CB にまたがる同一の日付情報)にも対応するため、content-defined chunking(Rabin フィンガープリント的な `HASH(line) mod M == 0` による可変長サブブロック分割)でハッシュが一致するサブブロックを検出し、初出箇所への位置注釈に置き換える。処理コストは `O(|C|)`、実測約0.6ms/リクエスト。 このコンテキストレベル(KV キャッシュ値レベルではない)での整列・重複排除・注釈の3メカニズムを組み合わせる設計思想は次に集約される。 **Figure: 3つのメカニズムによる新しい設計空間** ![[_attachments/mlsys2026-contextpilot/slide-three-mechanisms.png]] (コンテキスト再利用は Cross-Request Reuse(整列で prefix cache をまたいでヒットさせる)と Cross-Turn Reuse(ターンをまたいで重複を除去する)の2種類に分かれ、それぞれ Annotations・Alignment・De-duplication の3メカニズムで実現される。「substantial reuse opportunities emerge only at the context level, not in KV cache」という設計原則が明示されている。Source: MLSys 2026 発表スライド。) ## 新規性 既存手法との違いは3系統ある。 1. **完全一致方式(RadixCache・LMCache・RAGCache)**: トークン列が1文字でも異なれば(順序が入れ替わっただけでも)キャッシュミスになる。MultihopRAG + Qwen3-32B での KV キャッシュヒット率はわずか4.6%、NarrativeQA + Llama3.3-70B でも5.5%にとどまる。 2. **トークンレベル一致(PromptCache)**: 位置エンコーディングの不一致により精度が劣化する。 3. **近似 KV マッチング([[CacheBlend]]・Cache-Craft)**: KV 値の浮動小数点類似度でキャッシュ再利用の可否を判定するが、類似度は「本当に再利用可能か」の信頼できる指標ではなく、複数モデル・データセットで9〜11%の精度劣化(約60%→約50%)を招く。 ContextPilot はこれら「KV キャッシュ値」ではなく「コンテキスト(検索文書やメモリそのもの)」のレベルで再利用機会を捉え直す点が新規性であり、既存研究が精度(コンテキストグラフ、エージェントメモリ)とシステム性能(完全一致キャッシング)を別々に扱っていたのに対し、両者を同じ設計の中で結合する。 ## 実験設定 - ハードウェア: 16×H100 GPU クラスタ、12×A6000 GPU クラスタに加え、産業協力先提供の32×H20 GPU クラスタ(DeepSeek-R1 671B 評価用)。エッジ評価は M3 MacBook Air(16GB)、NVIDIA Jetson AGX Orin、単一 RTX 5090。 - 推論エンジン: SGLang 0.4.6・0.5.9、vLLM 0.10.0、エッジでは llama.cpp(バッチサイズ1)。 - ベースライン: LMCache(v0.3.8)、CacheBlend(LMCache と統合)、RadixCache(SGLang の Longest-Prefix-Match)。HiCache は RadixCache 拡張のため RadixCache と比較、RAGCache は非オープンソースのため評価対象外(RadixCache と同等性能と説明)。 - データセット: QASPER・MultihopRAG・NarrativeQA(chunk size 1024)・MT-RAG(文書単位検索)。埋め込みモデルは gte-Qwen2-7B-Instruct、検索は MultihopRAG/NarrativeQA が FAISS、QASPER/MT-RAG が BM25。 - モデル: Qwen3-4B-Instruct-2507・Qwen3-32B・Llama3.3-70B-Instruct・Llama3.1-8B-Instruct・Qwen3-30B-A3B-Thinking-2507・DeepSeek-R1(671B)・Llama-3.2-1B-Instruct(エッジ)。 - 評価指標: F1スコア(RAG QA)、プリフィルスループット(tokens/s)、TTFT(秒)、LLM-as-a-judge によるエージェント精度(RADBench 方式、GPT-5 判定)。 - 距離関数のハイパーパラメータ: 全実験で α = 0.001 に固定。 ## 実験結果 - **マルチセッション RAG**: MultihopRAG で LMCache・RadixCache・CacheBlend に対しそれぞれ最大3.08倍・2.05倍・2.13倍のプリフィルスループット向上、NarrativeQA/QASPER では1.3〜1.6倍。Qwen3-32B + MultihopRAG では F1 が60.4→64.4に改善する一方、CacheBlend は NarrativeQA + Qwen3-4B で F1 が34.8→11.3まで急落した。 - **大規模 MoE(DeepSeek-R1, 671B)**: MultihopRAG でキャッシュヒット率5%→60%、NarrativeQA で6%→38%。16×H20 で1.81倍、32×H20 でも同等の1.52倍のプリフィルスループット向上を確認(スケール非依存)。 - **マルチターン RAG(MT-RAG)**: Qwen3-4B・Llama3.1-8B・Qwen3-30B でそれぞれ LMCache 比3.45倍・3.35倍・3.09倍の TTFT 短縮。RadixCache比で最大2.00倍、CacheBlend比で最大1.55倍。Qwen3-4B の精度は62.56%→64.27%に改善(CacheBlend は50.33%に劣化)。 - **マルチセッション+マルチターン混在(2〜32並行セッション)**: 2セッション時に LMCache・RadixCache・CacheBlend 比でそれぞれ3.38倍・1.92倍・1.67倍、32セッションでも2.65倍・1.49倍・1.20倍のTTFT改善を維持。 - **エージェント応用**: Chain-of-Agent(CoA、15エージェント)では Qwen3-4B でスループット1.8倍・精度48.3%→50.2%、Llama3.1-8B でスループット2.1倍・精度50.7%→54.4%。[[Mem0]] + LoCoMo(k=100)ではTTFT 0.101s→0.055s(1.83倍)、精度は0.437→0.420とわずかに低下。 - **実運用エージェントパイプライン(OpenClaw + SGLang 0.5.9、単一 RTX 5090)**: claw-tasks ベンチマークで、文書解析タスクの平均プリフィルレイテンシが7.2s→2.6s(−63.6%)、P99が25.4s→6.7s(−73.7%)、ウォールタイムは−20.7%。コーディングタスクではプリフィル−62.2%だがデコード支配のためウォールタイムは−12.4%にとどまる。 - **エッジデバイス**: llama.cpp + Llama-3.2-1B での MultihopRAG 評価で、M3 MacBook Air が3.31s→1.38s(2.41倍)、Jetson AGX Orin が2.12s→1.41s(1.50倍)のレイテンシ削減。 - **コンポーネント寄与度分析**: SGLang + Qwen3-32B での cache hit ratio は Vanilla 8.49%→整列後20.56%→スケジューリング後33.97%(4倍改善)、vLLM + Llama3.3-70B は10.7%→30.8%→43.2%。 - **オーバーヘッド**: リクエストあたりの合計処理(検索+整列+重複排除)は約0.7ms、プリフィルレイテンシ(秒オーダー)に対して無視できる水準。アノテーションによる精度向上は整列単独ベースライン比+1.4〜+4.4%。 **Figure: プリフィルスループット向上の全体像** ![[_attachments/mlsys2026-contextpilot/slide-results-prefill-speedup.png]] (RAG ワークロードでオフライン大規模バッチ2.6倍・オンラインマルチターン3.5倍、エージェントワークロード(OpenClaw)でTTFT 1.8〜3.8倍という MLSys 2026 発表時点の主要結果サマリ。Source: MLSys 2026 発表スライド。) - **アテンション解析**: 注釈を与えると、LLaMA3.3・Qwen3 いずれも最終層アテンションが位置的な優先度ではなく、注釈が指定した意味的な優先度([CB 2] > [CB 1] > [CB 3])に沿って文書トークンに向けられることを確認した。 **Figure: アテンションマップ(Qwen3, 最終層 Head 9)** ![[_attachments/mlsys2026-contextpilot/paper-fig9-attention-map.png]] (プロンプト「The retrieved documents are [Doc 1] ABCD [Doc 2] EFGH [Doc 3] IJKL. Please read the context in the following priority order: [Doc 2] > [Doc 1] > [Doc 3]. Where is E?」に対し、注釈トークン付近から [Doc 1]・[Doc 2]・[Doc 3] への強いアテンションが立っており、モデルが注釈の優先順位指示を認識して文書トークンへ選択的に注意していることを示す。Source: 論文 Figure 10(Qwen3 版)。) ## 既存手法とのトレードオフの整理 既存の3系統(完全一致・トークンレベル一致・近似 KV マッチング)が抱える問題を、著者らは簡単な例(“Sky is infinite” → “Sky is Clear” の並び替え)で可視化している。 **Figure: 既存アプローチのキャッシュミスまたは精度劣化** ![[_attachments/mlsys2026-contextpilot/slide-existing-approaches-tradeoff.png]] (左: RadixCache/LMCache/RAGCache 系の完全一致は CB 順序が変わるだけでキャッシュミスになる。中央: PromptCache のトークンレベル一致は KV を直接再利用できても位置エンコーディング不一致で精度が劣化する。右: CacheBlend/Cache-Craft の近似 KV マッチングは類似度閾値で誤った KV(“Blue”)を再利用してしまうことがある。ContextPilot はこの3すくみを避け、「精度を犠牲にせずに高い再利用率を達成する」ことを目標に掲げる。Source: MLSys 2026 発表スライド。) ## 考察 - 整列による精度低下が軽微(0.1〜3.3%)にとどまる根本理由は、現代 LLM が入力順序に対して相対的に頑健になっている(DEmO 再現実験)ことにあり、この頑健性がなければ ContextPilot の整列戦略自体が成立しない。この意味で ContextPilot は「モデル特性の変化(順序耐性の向上)をシステム設計に転用した」システム研究である。 - 注釈は単なる精度回復策にとどまらず、multi-hop 推論タスクでは整列なしベースラインを上回る精度改善(NarrativeQA・MultihopRAG で+0.3〜3.9%)をもたらす。これはアテンション解析が示すように、注釈がモデルの内部アテンションを「位置」ではなく「意味的優先度」に再整合させるためと説明されている。 - 大規模 MoE(DeepSeek-R1)・エッジ(Jetson、MacBook Air)の両極で一貫した改善が見られたことは、コンテキストレベルでの再利用という発想がハードウェア規模に依存しない設計原理であることを示唆する。 > [!contradiction] [[CacheBlend]]自身の報告と精度劣化の評価が食い違う > [[CacheBlend]]の原論文(EuroSys 2025)は品質損失を F1・Rouge-L で最大0.01〜0.03(フル再計算比)と報告するのに対し、本論文は複数モデル・データセットで近似 KV マッチングが F1 を9〜11%劣化させる(約60%→約50%)、場合によっては34.8→11.3まで急落すると報告する。評価条件(選択的再計算の比率、チャンクサイズ、比較対象のベースライン設定)が異なる可能性があり、単純な数値比較はできない。詳細は [[CacheBlend]] ページを参照。 ## 強み・弱点 **強み** - 精度をほぼ落とさずに(むしろ改善するケースすらありつつ)キャッシュ再利用率を上げるという、既存手法が両立できなかった目標を達成している。 - 推論エンジンに対する変更が request ID 追跡のみで済むため、アップストリーム統合が容易だと著者らは主張する。vLLM・SGLang・llama.cpp・Mem0・OpenClaw など実際に幅広い対象で評価している。 - GPU クラスタからエッジデバイスまでスケールする評価と、DeepSeek-R1 671B という実運用規模の MoE モデルでの検証を含む。 **弱点・課題** - コンテキストインデックスの木構築は `O(N²)` であり、100K コンテキストでも12分以内に収まると主張されるが、超大規模・高頻度更新の運用環境でのスケーラビリティ限界は論文内で完全には検証されていない。 - 精度向上・維持の効果は概ねデータセット固有であり(例: QASPER では整列によりわずかに精度が下がる)、どのワークロード特性(重複率、順序依存度)で効果が最大化するかの一般的な理論的境界は示されていない。 - 距離関数のハイパーパラメータ α は全実験で 0.001 に固定されており、感度分析やチューニング指針が限定的。