長い文脈を大型モデルに読ませない。AsymSpecが見つけたAIエージェント推論の抜け道
AIエージェントが長く働くほど、賢いモデルは遅くなります。
検索結果、ツールの返答、会話履歴が積み重なり、大型モデルは次の1語を出すたびに長い文脈を読み直すからです。文脈を圧縮すれば速くなりますが、今度は必要な細部まで消えてしまいます。
2026年8月26日に公開された論文「AsymSpec: Context-Asymmetric Speculative Decoding for Agentic LLMs」は、この二者択一を少し変わった分業で崩しました。
32Bの大型モデルには圧縮した短い文脈だけを読ませる。一方、4Bの小型モデルには元の長い文脈を読ませ、消えた情報が次の出力をどう変えるかを大型モデルへ伝える。論文の実験では、テキスト課題で完全な文脈を読んだ大型モデルの性能のおよそ90%を回復し、計算量を0.2倍から0.3倍、実測スループットを1.3倍から1.7倍にしました。
大きいモデルに全部読ませない。その代わり、小さいモデルを「削られた情報の案内役」にする。AsymSpecの新しさはここにあります。
文脈圧縮には、速さと正確さの交換条件がある
長時間動くエージェントは、同じ依頼に何度もモデルを呼びます。最初は短かった入力も、検索結果やツール実行が増えるにつれて太っていきます。
よく使われる対策は文脈圧縮です。検索文書を要約し、API仕様をシグネチャだけにし、古い会話を短くまとめます。大型モデルが読むトークンが減れば、推論は軽くなります。
ただし、圧縮には情報落ちがあります。
たとえばツール仕様から日時形式の秒や、配列の構造例が消えれば、モデルは呼び出し自体には成功しても、引数の細部を間違えます。長文QAでは、複数の資料をつなぐための一文が落ちただけで、答えへ届かなくなります。
従来の投機的デコーディングは、ここを救えませんでした。小型のドラフターが候補トークンを先に出し、大型の検証器がまとめて確認するので生成は速くなりますが、両者は同じ文脈を読むのが基本です。短い文脈を与えれば両方とも情報を失い、長い文脈を与えれば大型モデルの負担が戻ります。
つまり、速く読む技術はあっても、圧縮で消えた情報を取り戻す技術にはなっていなかったのです。
小型モデルだけに完全な文脈を見せる
AsymSpecは、小型モデルと大型モデルが同じ入力を見るという前提を外します。
- 大型の検証器：圧縮した文脈を読む
- 小型のドラフター：完全な文脈と圧縮文脈の両方を読む
主実験では、大型の検証器にQwen3-32B、小型のドラフターにQwen3-4Bを使いました。
小型モデルは、完全な文脈を読んだときの出力傾向と、圧縮文脈を読んだときの出力傾向を計算します。両者の差を取ると、小型モデル自身の言い回しの癖をある程度打ち消し、「完全な文脈にだけ含まれる情報が、次の語をどう動かしたか」を抽出できます。論文はこの差をコンテキスト利得信号と呼び、記号ではデルタとして表します。
大型モデルは短い文脈のまま候補を検証します。候補を受け入れられない位置では、このデルタを大型モデルの出力へ足し、消えた情報の方向へ出力を戻します。
ここで雑にデルタを足すだけでは、出力が不安定になります。そこでAsymSpecは、完全版と圧縮版に対する小型モデルの分布がどれだけ違うかをJensen-Shannon divergenceで測り、候補を通す基準を自動調整します。論文ではContext-Divergence Acceptance、略してCDAと呼んでいます。
情報差が小さい箇所では大型モデルの判断を尊重し、圧縮で分布が大きく変わった箇所では完全な文脈を読んだ小型モデルの候補を通しやすくする仕組みです。
ただし、これは通常の投機的デコーディングのように大型モデルの分布を厳密保存する方法ではありません。圧縮で失った情報を戻すため、意図的に大型モデルの出力を動かします。論文自身も、貪欲デコーディング向けのステアリング方式と位置づけています。
5種類の能力で、短い文脈だけより大きく回復した
研究チームは、長文の複数資料QA、複数ターン指示、ツール利用、画像推論に加え、GAIAとSimpleQAのエージェント実行で評価しました。
テキスト能力の主結果は次の通りです。
| 方法 | HotpotQA | 2WikiMQA | MuSiQue | MultiChallenge | API-Bank | 相対計算量 | |—|—:|—:|—:|—:|—:|—:| | 圧縮文脈だけの大型モデル | 49.4 | 52.8 | 32.7 | 23.4 | 57.7 | 0.11倍 | | 完全文脈の大型モデル | 64.9 | 76.5 | 55.0 | 26.4 | 66.1 | 1.00倍 | | AsymSpec | 64.0 | 66.8 | 48.4 | 23.5 | 63.5 | 0.23倍 |
HotpotQAでは64.0となり、完全な文脈を読んだ64.9にかなり近づきました。API-Bankも57.7から63.5へ上がり、完全版66.1との差を縮めています。
一方、2WikiMQAは66.8で、完全版76.5との差が残りました。小型モデルのログイット差だけで、複雑な推論経路をすべて再構成できるわけではありません。
論文は、圧縮で性能が大きく落ちるほどAsymSpecの回復幅が増えることも示しました。LongBenchで検証器の入力を500トークンに切ると、圧縮版25.8に対してAsymSpecは52.5でした。12,000トークンまで残すと、圧縮版63.1、AsymSpec63.9となり、差は0.8点に縮みます。
必要な情報がほぼ残っているなら、わざわざ案内役を立てる効果は小さい。削りすぎて困る場面ほど効くという、導入判断の分かりやすい特徴です。
実測速度は1.3倍から1.7倍。計算量ほどは伸びない
計算量が0.23倍なら、速度も4倍ほどになりそうに見えます。しかし実測はそこまで伸びません。
単一アクセラレータのeager modeでは、LongBenchが1.69倍、MultiChallengeが1.29倍、API-Bankが1.34倍でした。30B級のデコードはメモリ帯域にも縛られるため、FLOPsの削減がそのまま処理速度にはなりません。
エージェント全体では、さらにツール実行とネットワーク待ちがあります。
GAIAの完全な165問では、圧縮版の正解率19.4%に対しAsymSpecは24.2%。完全版の基準20.0%も上回り、LLM部分の速度は1.41倍、計算量は0.78倍でした。SimpleQAでは圧縮版63.0%、完全版66.0%、AsymSpec65.0%で、速度1.38倍、計算量0.80倍です。
GAIAの「完全版」はサブセットごとに異なる参照を組み合わせているため、24.2%が無条件に完全版を超えたとは読めません。それでも、実際の検索ループで圧縮版より改善した点は実用上の証拠になります。
ツール仕様の1文字を、小型モデルが拾い直す
論文には、仕組みが見えやすいAPI-Bankの例があります。
大型モデルが見たのは、RecordHealthDataというAPIの短いシグネチャだけでした。小型モデルは完全な仕様も読み、日時は秒まで含むこと、health_dataは辞書の配列であることを確認できます。
圧縮版の大型モデルは日時を「2021-09-17 10:30」と出し、health_dataを自由文にしました。AsymSpecでは小型モデルのコンテキスト利得信号が働き、「10:30:00」と辞書配列の形へ出力を寄せました。
これは小型モデルが答えを丸ごと代筆する話ではありません。大型モデルが短い文脈で考え、小型モデルが削除された仕様の方向だけを渡す。赤ペン先生というより、落とし物係に近い役目です。
実務に入れるなら、圧縮率より先に回復幅を見る
ここからは論文結果をもとにしたAICompanyの実務提案です。論文がCodexやOpenCodeの製品環境で直接検証した設計ではありません。
導入候補になるのは、次の条件が重なる場面です。
- 同じ長い文脈へ何度も大型モデルを呼ぶ。
- 圧縮すると正解率やツール引数の精度が明確に落ちる。
- 大型モデルと小型モデルのログイットへアクセスできる。
- JSONやツール呼び出しなど、貪欲デコーディングと相性がよい。
逆に、APIが生成文しか返さない場合は使えません。AsymSpecは検証器のログイットが必要です。ClaudeやOpenAIの一般的なテキスト生成APIへ、そのまま後付けできる技術ではありません。
自前の推論基盤で試すなら、いきなり全エージェントへ入れず、三つの基準を並べると判断しやすくなります。
- 大型モデルが完全な文脈を読む構成
- 大型モデルが圧縮文脈だけを読む構成
- 小型モデルだけが完全な文脈を読むAsymSpec型構成
20件から50件の実タスクで、正解率、ツール引数エラー、入力トークン、1秒あたりの生成トークン、エンドツーエンド時間を測ります。
重要なのは「完全版の何%まで戻ったか」です。圧縮版がすでに完全版と同じなら、分業を増やす意味は薄い。圧縮で大きく落ち、AsymSpec型で戻るなら、そのとき初めて複雑さに見合います。
まだ証明されていないこと
AsymSpecは魅力的ですが、適用範囲は狭く読んだほうが安全です。
第一に、主実験はQwen3-32BとQwen3の小型モデルです。QwenとLlamaの組み合わせも試していますが、語彙とログイット空間の明示的な対応が必要で、回復幅はモデルの組によって変わりました。
第二に、検証器のログイットが必要です。生成文だけを返すプロプライエタリAPIには適用できません。
第三に、評価は温度0の決定的な生成です。サンプリングを使う創作や対話で同じ安定性が得られることは示していません。
第四に、速度測定は単一アクセラレータのeager modeです。バッチ処理、graph capture、複数GPU、実際のネットワークやツール待ちを含む本番速度は別に測る必要があります。
第五に、GAIAではWeb部分とファイル部分で完全版の参照条件が異なり、SimpleQAは500問の無作為部分集合です。エージェント全体の結果は、静的ベンチマークより慎重に読む必要があります。
最後に、論文固有の公開コードは確認できませんでした。vLLMへの変更内容は付録にありますが、第三者が同じ環境をそのまま再実行できる状態ではありません。AICompanyもベンチマークを再実行していません。
結論
AsymSpecが示したのは、長い文脈を誰に読ませるかは、モデルの大きさと同じくらい重要だということです。
大型モデルへすべてを読ませると高い。全員へ短い文脈を渡すと細部が消える。そこで、小型モデルだけに完全な文脈を読ませ、消えた情報が出力を動かす方向を大型モデルへ渡す。
この分業により、論文のテキスト課題では完全版のおよそ90%を、0.2倍から0.3倍の計算量で回復しました。
ただし、誰でも使えるAPIテクニックではありません。ログイットへ触れられる自前の推論基盤で、しかも文脈圧縮の損失が大きい場面に向く方法です。
大きいモデルへ長文を読ませる前に、小さいモデルへ「何が消えたか」を聞く。AIエージェントの推論費用を下げるヒントは、意外とこの役割分担にありそうです。