先看证据
把机制串起来
Transformer 推理会为已处理的 token 保存 K（Key）和 V（Value），后续生成可直接读取它们，免去重复计算；但缓存越长，显存占用和读取开销也越高。RoPE 把位置信息编码进注意力计算，移动 token 的位置不能只改一个位置编号，必须相应旋转 key。理解 AKV 的关键是区分“对话文字还在不在”和“对应 KV 是否仍参与后续注意力”：两者可以不同。
AKV 提供 append、drop、repos：append 是正常追加新 token；drop 让指定 KV 不再参与后续注意力，但不改写客户端提交的文字；repos 则把保留 key 的位置编码压紧到连续位置，value 不变，也不重算隐藏状态。被删文字对应的信息仍可能已混入其他保留 token 的隐藏状态，因此 drop 不是对信息做严格擦除。难点在服务端：相同 token 前缀经不同 drop/reposition 历史会形成不同缓存，普通前缀匹配可能错误复用；AK
['适合工具调用多、轨迹长且缓存读取成本高的智能体', '先从滚动保留最近12个工具响应的策略做基线', '接入需部署兼容的 SGLang 服务；不是只换提示词或模型', '若任务依赖完整历史精确可见，先验证 drop 是否损害表现']
长历史的账单，不只来自上下文变长
清华大学与香港中文大学的研究者开源了AKV：一个基于SGLang的智能体推理服务系统，面向长程任务里不断累积的对话、推理和工具调用历史。它不提供新模型权重，而是尝试改变服务端管理KV缓存的方式。研究的出发点很具体：当智能体反复读取历史，缓存读取本身也可能成为成本的重要部分。
论文的成本分析称，KV缓存读取占总API成本的82.4%。常见做法是在上下文达到阈值后总结或裁剪文本，但前缀一旦改变，后续缓存状态可能失效，保留下来的内容还得重新预填充；总结也可能抹掉中间轮次的细节。AKV的选择是保留原始文本轨迹，不再把“历史太长”直接等同于“必须重写历史”。
它改的是注意力可见性，不是对话记录
AKV提供三种缓存操作：append为新token追加状态，drop让选定状态不再参与后续注意力计算，repos则重新安排保留状态的位置。Repos会把保留的key映射到连续位置，并通过RoPE旋转调整位置编码；value保持不变，因此不用重新计算隐藏状态。换句话说，drop不是删除消息，客户端仍可提交完整历史，系统改变的是哪些KV状态继续可见。
这使得保留部分可以直接复用，而不是因文本前缀变动而整段重算。论文的消融实验也显示，给GPT-OSS-120B加入repos后，BrowseComp-Plus通过率从55%升至62%。但这不是“位置整理必然提分”的通用结论，而是一个特定模型和任务上的实验结果；缓存操作与模型位置编码之间的配合，正是该方案需要验证的机制之一。
省下重算，服务层就必须记住更多状态
缓存工程把一部分难题从模型调用策略转移到了推理服务。相同的token序列，经历不同的drop或repos操作后，可能对应不同的缓存状态；如果仍用普通前缀匹配，就有机会复用错误状态。AKV扩展SGLang的radix tree来记录这类操作和缓存复用关系，并在没有活跃请求依赖被丢弃状态后才释放对应KV。
另一个配套机制是segment-batch attention，用一次预填充恢复被驱逐的状态。它说明AKV不是简单地在客户端加一个“删历史”开关，而是需要服务端理解缓存的操作历史、生命周期和恢复路径。代码采用Apache-2.0许可，接口保持无状态且兼容OpenAI格式；客户端可以通过drop_message和reposition字段传入操作，也可以使用基于轮次、token或模型的策略，或让模型通过CacheTool发起drop。
平均优势成立，但不等于每个任务都赢
论文在MiniMax-M2.7、GPT-OSS-120B和MiroThinker-1.7-Mini上，评估了BrowseComp-Plus、GAIA-Text、SWE-bench Verified与xbench-DeepSearch-2510。相对阈值触发的Standard总结方案，AKV报告平均成本降低27.7%、平均得分提高1.7分；相对Text Engineering，平均降本则是21.9%。两项降本数字对应不同基线，不能合并成一个不带条件的“节省比例”。
单项结果更能看出适用范围：GPT-OSS-120B在SWE-bench Verified上的单任务成本从20.0美分降至9.7美分，得分从40.0升至43.2；但MiniMax-M2.7在BrowseComp-Plus上得分58.9，低于Text Engineering的62.3。长运行任务也呈现另一面：BrowseComp-Plus达到96K token及以上时，GPT-OSS-120B的AKV得分为37%，Standard为24%，Text Engineering为32%。这些结果支持“缓存工程值得测试”，却不足以证明它对所有任务都更准确。
部署前要核算的是整条服务路径
AKV的性能结果也有明确边界。服务实验使用8张NVIDIA A800 80GB GPU，论文报告最高1.18倍输出吞吐和1.51倍P95请求延迟加速，但这两个峰值来自各方法各自的峰值吞吐设置，不能直接当作固定负载下的普遍加速比。成本数字则是按公开价格估算API等价成本，重定位后的token按缓存命中价格计费，这是一种偏保守的计价方式。
对技术负责人来说，合理的试点不是只比较token账单，而是同时记录任务得分、缓存命中与恢复开销、端到端延迟，以及服务端缓存占用和驱逐行为，并按模型与任务拆分结果。还要确认自己的服务栈能否正确追踪缓存操作历史，以及客户端传入完整消息历史时，实际计费与传输成本如何变化。现有材料报告的是作者在特定模型、基准和硬件上的实验，未提及独立复现结果；因此AKV更适合被视为一种可检验的服务架构选择，而不是已经普适成立的替代方案。