AKVとは？Cache EngineeringでAIエージェントのKVキャッシュを最適化

AKVの要点：Context Engineeringの次にあるCache Engineering

AKVは新しい基盤モデルや商用APIではありません。AIエージェントが推論中に使うKey-Value cacheを、エージェント自身の判断で直接整理するagent policyと、操作を実行するSGLangベースのserving systemです。論文はこの設計領域をCache Engineeringと呼びます。

従来のcontext engineeringは、古い会話を要約する、tool結果を削る、重要情報だけをpromptへ戻すなど、モデルが読むtextを編集します。履歴を変更すると、残すtextを再prefillしてKV cacheを作り直す場合があります。AKVはtranscriptを編集せず、将来のattentionで参照するcache entryを直接dropし、残す位置をreposします。

公式実装はApache 2.0で公開され、2026年11月10日時点でGitHub 176 stars、19 forks、29 commitsです。まだ初期projectですが、論文だけでなくagent policy、server、benchmark codeが揃い、OpenAI互換Chat Completionsへ操作を追加する形まで確認できます。

この節の一次情報：AKV論文｜Cache Engineering for Agents ／ AKV公式GitHub

開発元と仕組み：drop・repos・拡張radix tree

著者は清華大学と香港中文大学の研究者です。中心となる考えは、モデルが処理済み履歴の各tokenに対応するK/V vectorを、単なる一時データではなく管理可能な作業記憶として扱うことです。AKV agentは次の推論で不要と判断したmessage内tokenを指定し、serverへcache操作を送ります。

dropは選んだentryを以後のattention対象から外します。reposは保持するkeyにRoPEの位置を付け直し、抜けた領域を詰めます。実装はSGLangのradix treeを、異なるcache viewを共有できるよう拡張し、segment-batch attentionで各requestの非連続segmentを処理します。単にGPU memoryから古いpageを消すevictionとは異なり、どの情報をモデルに見せ続けるかをagent側が決めます。

論文のpolicyは、tool結果や古い思考をどの時点で落とすかをルール化したexpert policyと、reward信号からpolicyを改善するRSIを評価しています。RSIはexpert設計よりさらに平均7.1%コストを下げたと報告されていますが、policy学習の汎用性や安全な自動化は今後の研究対象です。

この節の一次情報：AKV論文｜Cache operations and system design ／ AKV公式GitHub｜Agent and system modules

API仕様と導入条件：OpenAI互換だがhosted serviceではない

AKV serverはOpenAI互換のChat Completions APIを拡張します。requestにdrop_messageでmessage番号とtoken範囲を指定し、repositionへmessage番号を渡します。responseのusageにはcached_tokens、drop_skipped_tokens、repos_tokensが追加され、操作が実際に何tokenへ適用されたかを追えます。既存SDKが未知fieldを捨てないか、proxyやobservabilityがusageを保存できるかを確認してください。

公式READMEはPython 3.12、uv、Rust／Cargoを前提とし、SGLang v0.5.20を基にしたsystemを自分で起動します。対応modelとしてQwen系、Qwen3-MoE、AgenticQwen、GPT-OSS、MiniMax-M2が挙げられています。一般的なOpenAI、Anthropic、Googleのhosted APIへdrop／reposだけを送ることはできません。

利用料表、managed endpoint、region、SLA、support契約はありません。ソフトウェアはApache 2.0ですが、GPU、storage、network、deployment、SGLang forkの更新追随、policy評価が実費です。OSSで無料という表現は原価判断を誤らせます。

この節の一次情報：AKV公式GitHub｜Installation and API example

料金・速度：27.7%削減は著者のAPI換算値

論文はMiniMax-M2.7、GPT-OSS-120B、MiroThinkerの3系統を、BrowserCompPlus、SWE-Bench Verified、BrowseComp、xbench-DeepSearchの4種類で比較しました。threshold型のtext summarizationに対し、AKVは平均スコアを1.7ポイント上げ、平均コストを27.7%下げたと報告しています。分析対象ではKV readが推論コストの82.4%を占め、削減余地が大きい条件でした。

コストは実際のcloud請求ではなく、2026年10月15日に確認したAPI相当単価をtoken量へ掛けた値です。例えばGPT-OSS-120Bは100万tokens当たりcache miss入力0.15ドル、cache hit入力0.075ドル、出力0.60ドル。MiniMax-M2.7は0.30ドル、0.06ドル、1.20ドルを使用しています。GPUの減価償却、idle、network、開発・保守費は含みません。

server評価はGPT-OSS-120B BF16を8基のNVIDIA A800 80GBで動かし、prefillとdecodeへ4基ずつ割り当てた構成です。著者は出力throughput最大1.18倍、P95 latency最大1.51倍、同一batchでfull-attention時間59.8%減、decode step時間16.0%減を報告しています。最大値は全task・全負荷での保証ではありません。

この節の一次情報：AKV論文｜Main results and cost model

従来方式との違い：Prompt Cachingや要約を置き換えない

providerのPrompt Cachingは、同じprefixを再送したときにprefill結果を再利用し、入力単価やlatencyを下げます。AKVは1つの長時間sessionの途中でactive cacheを選択的に変えます。前者は再利用、後者は注意対象の整理であり、目的が違います。self-host環境なら両方を組み合わせる余地があります。

text要約は人が読み返せ、provider APIでも使え、モデルを問わず実装しやすい利点があります。AKVは要約で情報を言い換える損失や再prefillを避けますが、drop判断を後から説明しにくく、server実装へ深く依存します。監査性や移植性が重要なら、要約の方が合理的な場合があります。

論文表でもAKVが全cellで勝つわけではありません。MiniMaxのBrowserCompPlusはAKV 58.9に対してtext要約62.3、SWE-BenchはAKV 74.4に対して標準履歴75.2でした。平均値だけで置換せず、task別の品質低下を許容できるかを見る必要があります。

この節の一次情報：AKV論文｜Per-benchmark results ／ OpenAI公式｜Prompt Caching

海外で注目される根拠と、日本で広がる可能性

一次情報以外にも独立した海外レビューが複数あります。豪州Richland Technologyは、平均値の裏で一部benchmarkが低下すること、fork保守と『ghost information』の監査難度を指摘しました。Harness Hubはnovelでcode公開済みと評価する一方、比較baselineの狭さとself-host限定を理由に結論を慎重に扱っています。Auto Researchも論文を整理し、8基A800を要する完全実験は再現していないと明記しています。

これらはAKVの性能を独立再現した証拠ではありません。ただし、公式発表の転載ではなく、利用条件や負けたcaseまで議論されているため、技術カテゴリが検討対象になり始めたシグナルです。GitHubの176 starsも採用数ではなく初期関心の指標として扱います。

日本では論文紹介と小型modelによる個人PoCはあるものの、SGLang運用、原価範囲、監査性、Prompt Cachingとの違いまで導入判断へ結び付けた解説はまだ限定的です。coding agentやdeep researchが長時間化し、KV readが支配的なworkloadが増えると、Cache Engineering、KV cache最適化という検索・設計領域が後から立ち上がる可能性があります。

この節の一次情報：Richland Technology｜Independent technical review ／ Harness Hub｜Adversarial paper review ／ Auto Research｜AKV review and reproduction limits

向くケース・向かないケース

向くのは、self-host推論をすでに運用し、1sessionが長く、tool結果や古い推論が蓄積し、KV readとdecodeが大きな原価・latency要因になっているteamです。特にcoding、browser research、長いworkflowで、task成功を自動評価できる場合はpilotを設計しやすくなります。

向かないのは、短いchat、hosted APIだけを使う環境、contextが小さくKV負荷が支配的でない処理、監査で完全なtext履歴だけを根拠にしたい業務です。GPU規模が小さく、SGLang forkの保守担当がいないteamでは、要約、retrieval、Prompt Caching、上限設定を先に改善する方が低riskです。

制約・未検証事項：削った記憶と監査性を確認する

最重要の未検証事項は、独立teamによる同規模のend-to-end再現がまだないことです。数値は著者のhardware、model、agent、price model、benchmarkに依存します。productionのrate、batch mix、prefix sharing、failure、idleを含むGPU原価が27.7%下がるとは限りません。

dropしたtextがtranscriptに残っていても、保持cacheにはその情報の影響が『ghost』として残る可能性を論文自身が認めています。逆に必要なentryを落とすと、modelは後続stepで参照できません。cache viewとtext履歴が一致しない状態を、監査log、再現、incident調査でどう説明するかが課題です。

linear attentionへの対応、他のserving engine、model update時の互換性、RSI policyの安全性、multi-tenant isolation、障害時のcache復元、長時間稼働でのmemory fragmentationは十分に検証されていません。個人情報の削除要求も、transcript、KV cache、log、checkpointを分けて確認する必要があります。

• author benchmarkと自社productionのcost構成を分けたか
• drop前後のtask成功率を難度別・model別に測ったか
• active cacheの操作履歴をrequest単位で監査できるか
• SGLang本流のsecurity fixへ追随できるか
• 失敗時に標準履歴・要約方式へ切り戻せるか
• cache dataの保持・削除・tenant分離を確認したか

この節の一次情報：AKV論文｜Limitations and future work ／ Richland Technology｜Operational caveats

導入方法：shadow testで成功タスク原価を比較する

pilotは本番履歴をすぐdropせず、代表的な長時間taskを50〜200件固定してshadow実行します。標準履歴、既存の要約、AKV expert policyを同じmodel・temperature・tool環境で複数回走らせます。task成功率、active KV tokens、prefill／decode時間、GPU時間、再試行、人手確認を同じtask IDへ保存します。

判断単位は『品質を満たした1task当たり総原価』です。API換算token費だけでなく、GPU占有、idle、fork保守、policy更新、observability、失敗時の再実行を含めます。P50だけでなくP95、長いtask、品質低下cellを確認し、改善しないmodel・taskにはAKVを使わないroutingを残します。

最初のreleaseではdrop対象をtool出力など再取得可能な範囲へ限定し、reposの有無を別々にablationします。cache操作をfeature flagにし、操作前後のusage fieldとtask結果を保存します。論文と同じ削減率を目標にせず、自社のquality SLOを守った状態で総原価が下がるかを採用条件にしてください。

FAQ

Q. AKVはPrompt Cachingの代わりですか？ A. 代わりではありません。Prompt Cachingは同じprefixのprefillを再利用し、AKVは長時間session内のactive KV cacheを選択的に整理します。

Q. OpenAIやClaude APIでdrop／reposを使えますか？ A. 2026年11月10日時点では使えません。AKVはSGLangベースのserverへmodelをself-hostする実装です。

Q. AKVの料金はいくらですか？ A. softwareはApache 2.0で、hosted料金表はありません。GPU、network、storage、運用、fork保守、評価の費用がかかります。

Q. 27.7%安くなりますか？ A. 保証されません。3モデル・4benchmarkで著者がAPI相当単価を用いて算出した平均値です。自社の実請求・GPU原価で再計算してください。

Q. 今すぐ本番導入すべきですか？ A. self-hostの長時間agentでKV readが大きく、評価と切り戻しができるteamはshadow testの価値があります。hosted API中心なら、まず要約、retrieval、Prompt Caching、token上限を優先します。

まとめ：新しい最適化面だが、まだ研究実装

AKVの意義は、prompt本文だけでなく、推論中のKV cacheそのものをagentの設計対象にした点です。長時間agentでKV readが支配的になるなら、dropとreposはtext要約とは別のコスト・latency leverになり得ます。codeとAPI例が公開され、海外でも利点と制約の両方が議論され始めています。

一方、hosted productでも一般的なSGLang機能でもなく、著者数値の独立再現はありません。導入判断はGitHub starsや平均27.7%ではなく、quality SLO、実GPU費、fork保守、監査性を含む成功タスク原価で行います。今は全面置換ではなく、長いtaskを限定したshadow testが妥当な段階です。