履歴は書き換えず、KVキャッシュを捨てる：エージェント向け「キャッシュエンジニアリング」

どんな論文か

清華大学（Tsinghua University）を中心とするチームの論文です（著者の1人は香港中文大学の所属）。対象としているのは、何百ラウンドも続くLLMエージェントでKVキャッシュ（過去のトークンについて計算済みの中間状態。残しておけば再計算せずに済む）が膨らみ続ける問題です。論文によると、KVキャッシュの読み出しはAPI費用全体の82.4%を占めます。そこで著者らは、エージェント自身がKVキャッシュの一部を「注意の対象から外す」操作を行う「キャッシュエンジニアリング」を提案しました。あわせて、この仕組みを正確かつ高速に動かす推論サーバー「AKV」も開発しています。

この論文の肝

一言でいうと、テキストの履歴には手を付けず、KVキャッシュだけを削るアプローチです。

これまでの対策は「コンテキストエンジニアリング」でした。古いメッセージを削ったり要約したりして、履歴のテキスト自体を短くする手法です。しかし、履歴の前半を書き換えると、それ以降のキャッシュがすべて使えなくなり、残した部分まで計算し直し（再prefill）になってしまいます。論文はこの問題を明確に指摘しています[引用1]。

そのため既存のハーネスは、コンテキストが一定の長さに達するまで我慢します。上限に達したところで履歴の大半をまとめて要約し、再prefillを短く抑えるために直近の数ラウンドだけを残すのです。その代償として、途中のラウンドの情報は一気に消えてしまいます。費用を取るか、正答率を取るかの板挟みでした。

この論文は、テキストを残したまま、選んだKVエントリだけを以後の注意（attention）から外しました。残ったキャッシュは計算し直さずにそのまま使えます。だからこそ古いキャッシュを少しずつ捨てることができ、同じ費用でも新しい履歴をより多く残せるのです。

図1　履歴を縮める2つのやり方。テキストを書き換えるコンテキストエンジニアリングと、KVだけを捨てるキャッシュエンジニアリングの違い。

もう1つの新しさは、これをサーバー側の課題として正面から扱った点にあります。通常のKVキャッシュは「同じトークン列なら同じキャッシュ」になります。ところがキャッシュを捨てる操作が入ると、同じトークン列でも「いつ捨てたか」によってキャッシュの中身が変わってしまいます。著者らはこれを「履歴依存性」と呼び、prefixの一致だけではキャッシュを正しく使い回せないと指摘しました。

使いどころと価値

意味: 「エージェントのコンテキストを縮める」という課題には、これまで2つの流れがありました。テキストを編集するコンテキストエンジニアリングと、注意の重要度といった低レベルな信号でキャッシュを捨てるKVキャッシュの退避です。この論文はその間をつなぎました。メッセージの役割（思考かツール出力か）や新しさといった高いレベルの判断基準で、エージェントやハーネスがキャッシュを捨てられるようにしたのです。さらに、それを複数リクエスト間で正しく使い回すサーバーまで実現しました。

価値: 3モデル・4ベンチマークの平均で、しきい値で要約する標準方式と比べて費用は27.7%減り、スコアは1.7点上がりました。サーバー性能でも、ピーク時の比較で出力スループットが1.18倍、P95の遅延が1.51倍速くなっています。推論コストを払う運用者には費用の削減が、利用者には待ち時間の短縮が直接のメリットになります。

使いどころ（筆者の見方を含みます）:

• 自前のGPUでSGLang系の推論サーバーを立て、SWE-benchのようなコーディングエージェントを何百ステップも回している環境。150ラウンド目あたりで要約が走り、それまでの調査結果を忘れて同じファイルを読み直す、といった事態が減りそうです。
• 検索とドキュメント取得を何十回も繰り返すディープリサーチ系のエージェント。古くなった長い検索結果（ツール出力）は捨て、エージェントの思考メモは残すという方針がそのまま当てはまります。
• 多数のエージェントを同時に走らせ、KVキャッシュのメモリが逼迫している環境。論文では、同時実行数が多いほど標準方式との差が開いています。

今日からできること: コードは github.com/thu-nics/AKV で公開されています。AKVはSGLang v0.5.20の上に作られており、通常のチャットAPIのリクエストに cache 欄を足すだけでdropとreposを指定できます。サーバーを差し替えられない場合でも、考え方自体は取り入れられます。ハーネス側で「古いツール出力から先に消し、思考は残す」という方針をとるやり方です。ただしテキストを消すと、そこから後ろのキャッシュは使えなくなります。論文が示す費用の利点は得られず、確かめられるのは正答率の面だけです。筆者が下で試したのは、まさにこの簡易的なやり方です。

向かない場面・前提: 自分でKVキャッシュを操作できる推論サーバーが必要です。外部の商用APIを呼ぶだけの構成では、キャッシュに直接手を入れられません。また、位置の付け替え（repos）はRoPE（回転による位置埋め込み）を前提としています。著者らは線形attentionのモデルへの対応を今後の課題に挙げています。

仕組み

キャッシュエンジニアリングでは、3つの操作を定義します。

• append: 通常の推論と同じく、新しいトークンのKVを足します。
• drop: 選んだKVエントリを以後の注意から外します。残ったエントリもテキストの履歴も変えません。
• repos: 残ったキーの位置番号を0から振り直し、次のトークンの位置番号もリセットします。dropだけだと位置番号が増え続け、キャッシュは小さくてもモデルが扱える位置の上限に達してしまうためです。RoPEの回転をかけ直すだけで済み、再計算は不要です。値（V）はそのまま使います。

どこを捨てるかは、注意の分布を見て決めています。BrowseComp-Plusの軌跡を分析すると、古いトークンほど注意が少なく、同じ相対位置でもツール出力は思考（assistantメッセージ）より注意が少なかったそうです。そこで基本方針を「ツール出力のローリング削除」としました。思考と直近12回分のツール出力のキャッシュは残し、それより古いツール出力から順に捨てていきます。

図2　ツール出力のローリング削除とAKVの流れ。エージェントがキャッシュ操作を指定し、AKVが正しく使い回す流れ。

サーバーAKVの設計方針は「インターフェースはステートレス、中身はステートフル」です。クライアントは毎回、メッセージ全体とともに「どのメッセージの後でどれをdropし、どこでreposするか」を送ります。サーバー上にどのキャッシュが残っているかをクライアントが気にする必要はありません。

サーバー内部には3つの工夫があります。1つめは、拡張したradix tree（共通の先頭部分を共有する木構造）です。dropを「dropノード」、reposを「repositionノード」として木に記録し、トークン列だけでなく操作の履歴まで一致したときだけキャッシュを使い回します。2つめは、dropを考慮した退避です。どのリクエストも使わなくなったキャッシュから順にメモリを空けます。完了したリクエストのキャッシュよりも、捨てられたキャッシュを優先して空ける仕組みです。3つめは、segment-batch attentionです。退避されたキャッシュを復元する際、注意の計算だけをdropやreposの地点で区切ります。FFNは系列全体を1回で処理するため、復元は1回のforwardで完了します。

たとえるなら、ノートの文章は消さずに、古いページへの付箋だけを剥がしていくようなものです。剥がした付箋のページを読んで書いたメモには、その内容がまだ残っています。論文でも、残ったキャッシュには捨てた履歴の情報が含まれうると述べられています。

結果

比較相手は2つあります。1つは「Standard」で、モデルごとに高めのしきい値（GPT-OSS-120BとMiniMax-M2.7は96K、MiroThinker-1.7-Miniは192Kトークン）に達した時点で要約します。もう1つは「Text Engineering」で、同じ要約を48Kトークンで行います。モデルはMiniMax-M2.7、GPT-OSS-120B、MiroThinker-1.7-Miniの3つ、ベンチマークはBCP、GAIA-Text、SWE-Verified、xbench-DSの4つです。

平均スコアはどのモデルでもAKVがトップでした。MiniMax-M2.7では52.4（Standard）・52.8（Text Engineering）に対してAKVが53.7、GPT-OSS-120Bでは51.0・48.3に対して53.1、MiroThinker-1.7-Miniでは44.1・37.1に対して45.8を記録しています。費用は、全体の平均でStandardより27.7%、Text Engineeringより21.9%下がりました[引用2]。GPT-OSS-120Bの平均費用で見ると、1タスクあたり11.2セント（Standard）・10.2セント（Text Engineering）に対して7.3セントに収まっています。

図3　GPT-OSS-120Bの1タスクあたり平均費用。4ベンチマーク平均のAPI換算費用（セント）。低いほど良い。

正答率が上がった理由として、著者らは長さ別の分析を示しています。48Kトークンまでは3方式とも同程度でした。しかしText Engineeringは48〜96Kの範囲で、Standardは96K超で、それぞれ最も低くなります。どちらも要約が走るしきい値の直後です。履歴を一気に縮めると情報が失われる、という説明と合致する結果です。

サーバー性能はGPT-OSS-120BとSWE-Verifiedの長い80タスクで計測しました。それぞれのピーク設定（AKVは同時実行14、Standardは12）で比べると、平均遅延が1.36倍、P95遅延が1.51倍速くなりました。入力スループットは1.53倍、出力スループットは1.18倍に達します。高速化の主な要因は注意計算の短縮です[引用3]。同じバッチサイズで比べると、full-attentionの時間が59.8%、デコード1ステップの時間が16.0%減りました。

アブレーションでは、reposを加えることでBCPの正答率が55%から62%に伸びました。一方、思考のキャッシュまで捨てると、ツール出力だけを捨てた場合より正答率が下がっています。再帰的自己改善（RSI、エージェント自身にキャッシュ方針を探させ、改良させる手法）では、人が設計した方針よりさらに費用が7.1%下がりました。キャッシュ管理をツールとしてエージェントに渡す方式（Cache-As-Tool）は、BCPの100タスクでGPT-OSS-120Bが61.0%、MiniMax-M2.7が64.0%と最高の正答率を出しています。ただしMiniMax-M2.7では、ターン数が増えたぶん費用が5.4セントから5.9セントに上がりました。

限界と注意

著者ら自身が挙げる限界は、キャッシュ方針のさらなる探索、この方式のもとでのエージェントの学習、そして線形attentionモデルへの対応です。いずれも今後の課題としています[引用4]。

評価にも注意点があります。費用はGroqやMiniMaxなどの公開価格から算出したAPI換算の金額であり、実際の請求額ではありません（repos分はキャッシュヒット料金で上乗せし、控えめに見積もったとしています）。サーバー性能はGPT-OSS-120Bだけで測定されており、記録した軌跡を再生する方式のためツールは再実行していません。また、小規模なGPT-OSS-20Bでは、GAIA-Textやxbench-DSのスコアなどAKVが勝てなかった指標もあります。著者らは、小さいモデルが残った情報をうまく活用できないためだと分析しています。さらに、ベンチマークのうち3つは採点にLLM（GLM-5.2）を使っています。

論文のサーバー性能の実験には、NVIDIA A800-80GB 8枚（prefill用4枚、デコード用4枚）の構成が使われました。A800がMXFP4に対応していないため、重みはBF16としています。

筆者は論文を読んで解説しており、手元で動かしたのは下の小さな実験だけで、論文の追試は行っていません。

手元で試した結果

これは論文の追試ではなく、アイデアの一部を小さく試した実験です。確かめたかったのは「古いツール出力を捨てて思考を残せば、しきい値で要約するより途中のラウンドの情報が残る」という主張です。KVキャッシュには触れず、代わりにテキスト履歴から古いツール出力を消す形をとりました。

設定は次のとおりです。サプライヤー選定の作業履歴を16ラウンド分合成しました。条件Aは比較相手の要約方式に合わせ、ラウンド1〜12を要約1段落にまとめ、13〜16は全文を残しています。条件Bはローリング削除に合わせ、ラウンド1〜12のツール出力を消して思考メモはすべて残し、直近4ラウンドのツール出力も残しました（論文では直近12回分を残しています）。質問は11問です。前半から中盤の細かい数値や名前を使う問題と、要約や直近の履歴だけで解ける問題を混ぜました。モデルはclaude-haiku-4-5-20251001を使い、1問1回だけ回答させています。

予想ではBが少し勝つ程度だろうと思っていました。ところが結果は、Aが5/11問正解（45.5%）、Bが11/11問正解（100.0%）と、予想よりはるかに大きな差がつきました。たとえば「割引後のNordhavenの総額（送料込み）はKestrelより何ドル高いか」（答えは1400）のように、途中の数値を組み合わせる問題で差が出ています。平均出力はAが450.5トークン、Bが320.5トークンでした。一方、平均入力はAの1134.2トークンに対してBは1706.5トークンと長くなっています。

気をつけたい点もあります。差の大きさは、筆者が書いた要約に何を残したかでほぼ決まりますし、問題も11問しかありません。古いツール出力にしか書かれていない細部がBで失われる弱点は、この問題セットでは測れていません。また、KVを使い回すことによる費用や速度の利点と、捨てた履歴の情報が残りのキャッシュに残る効果は、テキスト操作では再現できません。

手元で試すなら

コードは github.com/thu-nics/AKV で公開されています。AKVはSGLang v0.5.20の上に実装されており、リクエストの messages に加えて cache 欄でdropとrepositionを指定する形式です。

原文からの引用

[引用1] However, modifying the trajectory prefix invalidates subsequent cached states and triggers costly re-prefilling of retained context.

（訳）しかし軌跡の先頭部分を書き換えると、それ以降のキャッシュ状態が無効になり、残した文脈の高コストな再prefillが発生する。

[引用2] AKV also reduces inference cost by 27.7% relative to Standard and 21.9% relative to Text Engineering, averaged across all three models and four benchmarks.

（訳）AKVは3モデル・4ベンチマークの平均で、推論コストをStandardより27.7%、Text Engineeringより21.9%削減する。

[引用3] Dropping older tool-response cache shortens the active context, reducing both KV reads and attention computation at each decode step.

（訳）古いツール出力のキャッシュを捨てるとアクティブなコンテキストが短くなり、各デコードステップでのKV読み出しと注意計算の両方が減る。

[引用4] Further exploration of cache engineering strategies, training agents under this scheme, and extending serving support to linear attention models remain future work.

（訳）キャッシュエンジニアリング戦略のさらなる探索、この方式の下でのエージェントの学習、線形attentionモデルへのサーバー対応の拡張は今後の課題である。