ReCache、ツールschemaを再利用可能なKVブロックに分割し、割り当てメモリを92.43%削減

ツール利用型エージェントがリクエストごとに受け取るAPI、MCPツール、スキルの組み合わせは異なる可能性がある。あるschemaがまったく変わっていなくても、従来のprefix cacheはprefix内の順序が一致しなければ機能しない。[ReCacheの論文](https://arxiv.org/abs/2608.19662)は、各リソースを個別にエンコードする手法を提案している。異なるschema間のattentionをmaskし、各ブロックの位置をそれぞれのローカルな先頭から再計算することで、生成されるKV表現が隣接するリソースや配列順序の影響を受けないようにする。

さらに、システムは2つの方向からコストを圧縮する。構造ルーティングでは、「特定のlayerまたはKV head groupだけを有効にした際、ツール呼び出しのlossがどれだけ低下するか」に基づいて順位付けし、呼び出し判断に重要な経路だけがリソースを参照できるようにする。semantic pruningではschema全体を保存せず、ツール名、parameter名、parameter description、末尾のaggregation tokenのみを残す。著者らはToolACE、APIGEN、WildToolBenchなど7つのdatasetを統合し、Qwen3-1.7BおよびQwen3-4Bでtrainingとevaluationを行った。

リソース単位のattentionのみを適用した場合、in-domain Inv-F1は82.3%で、dense baselineの82.4%とほぼ同等を維持しながら、TTFTを3.655倍高速化した。完全版ReCacheのin-domainおよび未見リソースに対するInv-F1は、それぞれ80.3%と60.8%だった。割り当てられるKV tensorのメモリ量は92.43%減少し、attention計算は1.423倍高速化した。リソースtokenが10Kを超えるグループでは、著者らはほぼ一定となる約5ミリ秒のprefill時間と、0.03 GiBのリソースKV割り当て量を測定した。[公開リポジトリ](https://github.com/EIT-NLP/ReCache)には、改変済みのQwen3 attention、DeepSpeedのtraining設定、evaluationコードがすでに含まれている。

これは既存サーバーに対して透過的に追加できるcache layerではない。モデルを新しいmaskと位置設定に適応させる必要があり、実験も主にQwen3-4Bに集中している。今後、エンジニアリングの観点では、より大規模なfrozen-weight modelへ拡張できるか、またツール間に依存関係がある場合やschemaが頻繁に更新される場合でも、リソース間のattentionを遮断することが安全かどうかを見極める必要がある。