AKV：長時間エージェントのKVキャッシュを直接管理する仕組み

LLMエージェントは、推論し、ツールを呼び、その応答を受けて次の行動を決める。この繰り返しで履歴が長くなると、KVキャッシュの保存と読み出しが大きな負担になる。KVキャッシュとは、次の生成でattentionが参照する計算済みのキーと値の状態である。文章の保存とは別に、この状態を扱う必要がある。履歴がモデルの最大文脈長を超える問題も生じる。

検索結果を読みながら調査を進めるエージェントを考えよう。古いツール応答が増えても、途中の推論や最近得た応答は残したい。しかし、参照できる量には制約がある。本論文は、このとき「残す文章」と「次に参照する計算済み状態」を分けて管理する。例としての調査作業は仕組みを理解するためのもので、すべての業務で同じ保持方策が有効だと示されたわけではない。

従来の文脈管理は、古い文章を削除したり要約したりして履歴を短くする。ところが、文章の前方を編集すると、それより後のKVも無効になる。後続部分は、編集前の履歴を条件に計算されていたからだ。残す文章についても、入力を処理してKVを作るprefillをやり直す必要がある。

この再計算の負担は、何を残すかの判断にも影響する。再prefillを安く済ませようとすれば、有用な中間履歴まで大きく削る選択につながりうる。調査の例なら、古い検索結果を短くするために、その後に積み上げた推論も再処理することになる。論文が変えようとするのは、この結び付きである。文章の履歴を編集せず、必要なKVだけを次の参照対象に残せれば、保持した状態の再計算を避けられる。

提案方式を読むうえで重要なのが、active cacheという区別だ。これは、後続のattentionに参加するKVを指す。active context長は、そのKVエントリの数であり、文章として記録された論理履歴のトークン数とは異なる。また、GPU上に物理的に残っているKVの量とも同じではない。

古いツール応答のKVを参照対象から外しても、文章の記録は残せる。一方、参照対象から外したからといって、その瞬間に物理保存まで必ず消えるわけではない。逆に、物理的に失われた状態が必要になれば、復元の問題が生じる。論文は、参照対象を選ぶcache engineeringと、それを実際の再利用・退避・復元につなぐ配信システムAKVを組み合わせている。

cache engineeringの基本操作は三つある。appendは、現在のactive cacheを条件に新しいトークンのKVを計算して追加する。dropは、指定したKVを将来のattentionから外す。dropを行っても、文章の履歴や、残したKVの状態、位置符号は変えない。

調査の例では、古いツール応答のKVをdropし、推論と最近の応答のKVを残す。残った推論のKVは、古い応答を参照して計算された状態のままである。そのため、文章を削って残りを再計算する方式とは、保持状態が異なる。もっとも、これは古い応答の情報を完全に保持できるという保証ではない。

もう一つのreposは、保持したKVの位置を、論理的な順序を保って先頭から詰め直す。論文ではRoPEという位置符号を使うキーを変換し、値は変えない。位置を詰めることで位置範囲を管理するが、KV数を削減する操作ではない。参照する量を減らすdropと、位置を整えるreposには、別の役割がある。

この方式の難所は、操作の順序が状態を変えることにある。古いツール応答を参照して推論のKVを作り、その後で応答をdropした場合と、先にdropしてから推論のKVを作った場合を比べる。最後に残るトークンが同じでも、推論を計算したときの参照先が違うため、KVは同じとは限らない。これが論文でいう履歴依存性である。

通常の、トークン列の先頭部分が一致するかという照合だけでは、安全に再利用できる状態を判定できない。AKVは文章と操作の両方の履歴を受け取り、計算履歴が合う状態を再利用する。要求ごとに履歴を自己完結的に記述し、サーバー側が状態の再利用、退避、復元を担う設計だ。

内部では、トークンに加えて操作と位置の違いを記録する。欠けたKVを復元するときも、単に現在の文章を読み直すのではなく、各区間が当初参照したKVと位置を再現する。操作境界ごとにattentionの参照先を分け、まとめて一回のprefillで復元する。保持状態の再計算を避けるには、こうした配信側の管理も必要になる。

主実験のAKV方策は、すべての推論メッセージのKVと、直近12件のツール応答のKVを保持する。それ以前のツール応答は順次dropする。したがって、主結果はエージェントが自由に削除対象を選んだ結果ではなく、この手作業の保持方策による結果である。

比較対象のStandardは、GPT-OSS-120BとMiniMax-M2.7で96K、MiroThinker-1.7-Miniで192Kトークンに達すると要約する。Text Engineeringは全モデルで48Kを閾値にする。AKVのrepos閾値は、各モデルのStandardと同じだ。要約には共通のPi由来の手順を使い、直近20,000トークンを残し、16,384トークンを予約する。要約を行うモデルと推論設定も、エージェント本体とそろえている。

評価はこの3モデルと、BCP、GAIA-Text、SWE-bench Verified、xbench-DeepSearch-2510の4ベンチマークを組み合わせる。GPT-OSS-120Bはhigh reasoning effort、残る2モデルはthinking modeを用いる。GAIA-Textはテキストのみの検証103問である。設定をそろえた比較だが、結果はこれらのモデル、タスク、保持方策の範囲で読む必要がある。

質問応答の3ベンチマークはGLM-5.2による採点、SWE-bench Verifiedは公式テストによる評価である。質問応答の成功率には採点モデルの判断が入る。供給資料には、その採点誤差を独立に検証した結果はない。

費用は、主エージェントと要約呼び出しのトークンに、固定単価を適用したAPI相当額である。キャッシュに一致しない入力、一致する入力、出力を別単価で数え、repos対象にもキャッシュ一致時の単価を課す。実際の請求額やGPU原価ではなく、検索、ウェブ抽出、採点を含む全運用費でもない。

配信評価は別に行われた。SGLang v0.5.20を基盤に、GPT-OSS-120BのBF16重みをA800-80GB計8台で動かし、入力処理と出力生成に各4台を割り当てる。要約しない場合の最大文脈長が大きいSWEの上位80タスクを選び、各方式が自分の方策で集めた軌跡を再生した。ツール応答と出力長は記録に基づくため、自由に進む業務全体の実測とは区別する必要がある。

著者によれば、主評価のAKVはStandardより平均成功率が1.7パーセントポイント高く、平均API相当費用は27.7%低かった。Text Engineeringに対する平均費用削減率は21.9%だった。成功率の差はポイント差であり、費用の数値は相対的な削減率である。

4ベンチマークのモデル別平均でも、成功率は3モデルとも上がった。StandardからAKVへの変化は、MiniMax-M2.7が52.4%から53.7%、GPT-OSS-120Bが51.0%から53.1%、MiroThinkerが44.1%から45.8%だった。平均タスク費用は、それぞれ5.0から4.4、11.2から7.3、20.4から14.8米セントに下がった。

ただし、平均値は全条件での優位を意味しない。GPT-OSS-120Bのxbench成功率は38.5%から37.5%に低下した。SWEでも、MiniMaxは75.2%から74.4%、MiroThinkerは7.8%から7.4%に下がった。GAIAの費用が増えたモデルもある。対象業務の成功率を確認せず、平均削減率だけで採用を決める根拠にはならない。

要素を変えて効果を見るアブレーションでは、drop対象とreposの役割が分かれる。GPT-OSS-120BでBCPとSWEの各先頭100タスクを評価したところ、ツール応答だけをdropする設定にreposを加えると、BCP成功率は55.0%から62.0%へ上がった。一方、費用も7.1から10.9米セントに増えた。SWE成功率は41.0%のままで、費用は9.4から9.5米セントだった。

reposを使っていても、推論KVを削る設定の成功率は、ツール応答だけを削る設定より低かった。これは、何を削るかと位置をどう管理するかを分けて評価すべきだという材料になる。ただし、reposによる成功率向上は、この比較でもタスク共通ではない。

方策自体にも改善余地がある。MiniMax-M2.7がBCPの20タスクで方策を改良し、別の100タスクで評価した実験では、著者はStandardの精度を維持し、手作業方策より費用をさらに7.1%減らしたと報告する。一方、削減時点と対象をエージェント自身がツールとして選ぶCache-As-Toolでは、MiniMaxの成功率が56.0%から64.0%へ上がるとともに、費用も5.4から5.9米セントへ増えた。成功率向上と費用削減は、常に同時には得られない。

配信評価では、各方式の出力スループットが最大となる設定同士を比較している。Standardの並列度12に対し、AKVは14である。著者報告では、出力スループットは313から369トークン毎秒へ増え、1.18倍になった。P95リクエスト遅延、つまり遅延分布の95パーセンタイル値は43.16秒から28.49秒へ短くなり、速度比は1.51倍だった。

同じバッチサイズで処理の内訳を比べる別の分析では、full-attention時間が59.8%、出力生成の一ステップ全体が16.0%短くなった。著者はattentionの短縮を主な要因としている。ただし、その分析の具体的なバッチサイズは供給本文に示されていない。

適用範囲には注意が要る。配信負荷は長文脈の上位80タスクに絞られ、方式ごとに軌跡、ターン数、出力予算が異なる。同一の固定リクエスト列を比較した実験ではない。測定窓も一律ではなく、主要比較のAKVは先頭30タスクの完了時点までを測り、Standardの高並列2設定は未完了要求を含む1時間で切っている。一般的な業務負荷でも同じ速度比になるとはいえない。

主方策は推論KVを残すため、active contextは推論の蓄積とともに増え続ける。成長を遅くする効果はあっても、無制限の実行を可能にする仕組みではない。reposも位置を詰めるだけで、KV数そのものの増加は解消しない。

位置変換を用いた再利用の正しさは、固定モデルと位置符号設定、厳密演算のもとで論じられている。有限精度の計算には丸め誤差があり、再計算した状態とのビット単位の一致を主張するものではない。さらなる方策探索、この方式でのエージェント学習、linear attentionモデルへの配信対応も今後の課題だ。

導入検証の候補は、長いツール応答が蓄積し、推論と最近の応答を優先して残したい用途になる。ただし、操作履歴に応じたKVを追跡・復元できる基盤が必要である。標準の文章APIだけで完結する環境では、この結果をそのまま利用できない。次に確かめたいのは、対象業務の負荷で保持方策を変えたとき、成功率、遅延、全運用費がどう動くかである。