@dair_ai:我们喜欢更深入底层的论文。这是一个很好的例子,将 agentic 上下文工程转向 agentic 缓存工程……

X AI KOLs Timeline 论文

摘要

一篇提出「缓存工程(cache engineering)」的论文:让 LLM 智能体通过 drop 和 repos 操作直接操纵自身的 KV cache,同时不使轨迹失效;该方法与 AKV 服务引擎协同设计,实现了 27.7% 的成本降低、1.2 倍吞吐量提升,并通过缓存策略的递归自我改进进一步节省 7.1%。

我们喜欢更深入底层的论文。 这是一个很好的例子,将 agentic 上下文工程转向 agentic 缓存工程。 他们还把递归自我改进应用于缓存策略,相比专家设计进一步降低了 7.1% 的成本。 具体而言,这项工作聚焦于长时间运行的智能体中的 KV cache 管理。 当智能体对其历史进行摘要或裁剪时,前缀的改变会使其后的缓存失效,保留下来的上下文必须重新预填充(prefill)。 缓存工程为智能体提供了两个作用于自身 KV cache 的操作。其中一个从未来的注意力计算中移除条目,另一个则调整保留的 key 的位置。轨迹文本保持不变。这本质上为智能体提供了一个可编程接口,使其能够定义并优化自己的缓存工程策略。 采用滚动丢弃旧工具响应的方式,比基于阈值触发的摘要高出 1.7 分,成本降低 27.7%。他们提出的 AKV 服务引擎可带来最高 1.2 倍的吞吐量提升,P95 延迟降低 1.5 倍。 https://arxiv.org/abs/2610.28577 与论文对话:https://academy.dair.ai/papers/cache-engineering-for-agents-2610.28577…
查看原文
查看缓存全文

缓存时间: 2026/10/21 18:35

我们喜欢深入到更底层的论文。

这是一个很好的例子,从 agentic context engineering 转向 agentic cache engineering。

他们还将递归自我改进(recursive self-improvement)应用于缓存策略,相比专家设计的策略进一步将成本降低了 7.1%。

具体来说,这项工作聚焦于长时间运行的智能体中的 KV cache 管理。

当智能体总结或裁剪其历史时,前缀的变化会使其之后的缓存失效,保留的上下文必须重新进行预填充(prefill)。

Cache engineering 为智能体提供了对自己 KV cache 的两个操作。一个将条目从未来的注意力中移除,另一个调整剩余 key 的位置。轨迹文本本身保持不变。这实质上为智能体提供了一个可编程接口,用于定义并优化自己的缓存工程策略。

滚动丢弃旧工具响应(rolling drop)的策略,比基于阈值触发的摘要方法得分高 1.7 分、成本低 27.7%。他们的 AKV 服务引擎最高可带来 1.2 倍吞吐量提升,P95 延迟快 1.5 倍。

https://arxiv.org/abs/2610.28577

与论文对话:https://academy.dair.ai/papers/cache-engineering-for-agents-2610.28577…


面向智能体的缓存工程(Cache Engineering for Agents)

来源:https://arxiv.org/html/2610.28577 Tianyu Fu††thanks:Equal contribution.†Corresponding author: Yu Wang ([email protected]).Ruoxi WangZihan MinZhongqi Ren单位:Tsinghua UniversityZhihao Li单位:Tsinghua UniversityTengxuan Liu单位:Tsinghua UniversityShengxu Mu单位:Tsinghua UniversityHanling Zhang单位:The Chinese University of Hong KongYu Wang

摘要

大语言模型(LLM)智能体能够处理日益复杂的任务,在长轨迹的观测与动作中穿行。随着这些轨迹不断增长,键值(KV)缓存的 I/O 与存储成为主要成本。轨迹还可能超出 LLM 的最大上下文长度,因此需要对活跃缓存的增长加以控制。已有工作利用 context engineering 通过裁剪或摘要历史来缩减缓存规模。然而,修改轨迹前缀会使其之后的缓存状态失效,并触发代价高昂的保留上下文重预填充。当为限制重预填充成本而保留的上下文过少时,任务准确率同样可能下降。我们提出 cache engineering 作为一种新方案。它允许智能体在不修改轨迹、也不重预填充保留上下文的前提下,直接控制其活跃 KV 缓存。具体而言,智能体可以主动使用 \operatorname{drop} 将选定的缓存排除在未来的注意力之外,并使用 \operatorname{repos} 调整保留 key 的位置编码。我们形式化了这些缓存操作,并指出历史依赖性是服务层面的挑战:相同的 token 序列在不同的缓存操作序列下可能产生不同的缓存状态,使前缀匹配不足以保证缓存的正确复用。因此,我们协同设计了 AKV 服务引擎。它提供了一个与现有服务 API 兼容的无状态接口,同时在内部管理有状态的缓存复用、逐出与恢复。实验表明,工具响应滚动丢弃缓存策略相比传统的阈值触发摘要,将平均基准得分提升 1.7 分,平均成本降低 27.7%。借助 AKV,其输出吞吐量最高可达 1.2\times,P95 请求延迟加速 1.5\times。对缓存策略的递归自我改进相比专家设计进一步降低了 7.1% 的成本。我们的代码位于 https://github.com/thu-nics/AKV 。

1 引言

大语言模型(LLM)智能体能够胜任周期越来越长的任务。智能体通常由一个负责推理与工具调用的 LLM,以及一个编排工具执行与上下文的 harness 组成。通过反复的推理、工具使用与环境交互,它们可以完成跨越数百轮的复杂工作(Ye et al., 2025 (https://arxiv.org/html/2610.28577#bib.bib7);Liu et al., 2025b (https://arxiv.org/html/2610.28577#bib.bib39))。

随着智能体轨迹变长,键值(KV)缓存的增长对推理成本和任务准确率都构成挑战。在成本方面,保留并反复访问不断累积的 KV 缓存会带来可观的存储与 I/O 开销(Wu et al., 2026 (https://arxiv.org/html/2610.28577#bib.bib2);Anthropic, 2026 (https://arxiv.org/html/2610.28577#bib.bib3))。如图 14 (https://arxiv.org/html/2610.28577#A1.F14) 所示,KV 缓存读取占总 API 成本的 82.4%。在任务准确率方面,如果参与注意力的 KV 状态数量或其位置范围超出 LLM 能可靠处理的限度,智能体可能严重退化(Hsieh et al., 2024 (https://arxiv.org/html/2610.28577#bib.bib38);Chen et al., 2026b (https://arxiv.org/html/2610.28577#bib.bib40);Zhou et al., 2025 (https://arxiv.org/html/2610.28577#bib.bib41))。因此,要实现高效且可靠的智能体执行,需要对活跃 KV 缓存进行精细控制。

已有工作通过 context engineering 来缩减不断增长的缓存,通常是裁剪或摘要历史消息。尽管较早的消息往往用处不大,但编辑它们会改变轨迹前缀,使后续 KV 状态失效并触发重预填充。编辑发生得越早,需要重预填充的保留轨迹后缀就越长。因此,常见的 harness 会推迟缩减,直到活跃上下文长度达到阈值,再裁剪或摘要大部分轨迹,仅保留最近几轮以控制重预填充的开销(Pi, 2026 (https://arxiv.org/html/2610.28577#bib.bib53);OpenAI, 2026 (https://arxiv.org/html/2610.28577#bib.bib54))。这种激进的缩减可能丢失中间轮次中的有用信息,暴露了重预填充成本与任务准确率之间的两难。

在本文中,我们提出 cache engineering,一种让智能体直接控制其活跃 KV 缓存的新方案。如图 1 (https://arxiv.org/html/2610.28577#S1.F1) 所示,它不修改文本轨迹,而只是将选定的 KV 条目排除在未来的注意力之外,并在无需重预填充的情况下复用所有保留的 KV 状态。这使得智能体可以在给定成本预算下增量式地丢弃较旧的 KV 条目,同时保留更多的后缀 KV。为支持这种控制,在通常为新 token 添加 KV 状态的 \operatorname{append} 操作之外,我们引入了两个额外的缓存操作:\operatorname{Drop} 将选定的 KV 条目从未来的注意力中移除,\operatorname{repos} 调整保留 key 所编码的位置。在整个执行过程中,LLM 与 harness 决定何时以及如何应用这些操作,并将其与 \operatorname{append} 反复交错以塑造活跃缓存。这种可编程的控制也使得智能体能够通过递归自我改进(RSI)来搜索、评估并优化缓存工程策略。

图 1:全上下文推理、context engineering 与 cache engineering。全上下文推理复用全部历史 KV。context engineering 移除无关文本并重新计算保留的历史。cache engineering 保留文本历史但丢弃选定的 KV 条目,无需重新计算即可复用保留的状态。嵌套色块展示了保留的 KV 仍如何承载被丢弃历史中的信息。

然而,cache engineering 的历史依赖特性对当前的 LLM 服务系统提出了挑战。在标准 KV 缓存中,token 前缀完全决定了缓存状态(Kwon et al., 2023 (https://arxiv.org/html/2610.28577#bib.bib52);Zheng et al., 2024 (https://arxiv.org/html/2610.28577#bib.bib20))。相比之下,相同的 token 前缀与保留位置,在不同的缓存操作历史下可能产生不同的缓存状态。如图 5 (https://arxiv.org/html/2610.28577#S3.F5) 所示,轨迹 1 和 2 都保留了 B 与 C 的 KV 条目,但由于 \operatorname{drop} 与 \operatorname{append} 操作的顺序不同,C 的 KV 在轨迹 1 中只对 A 进行了注意力计算。因此,服务系统必须同时考虑 token 历史与缓存操作历史,才能正确跟踪或复用缓存状态。

据此,我们协同设计了 AKV——一个面向 cache engineering 的易用且高效的服务系统。它提供与现有基于 API 的服务兼容的 无状态 接口,同时在内部处理 有状态 缓存管理的复杂性。智能体只需像往常一样提交消息并附带缓存操作指令,无需追踪服务器上仍驻留哪些 KV 状态。系统使用扩展基数树来正确复用并及时逐出历史依赖的缓存状态,而分段批量注意力(segment-batch attention)则在单次 prefill 过程中高效重建缺失状态。AKV 将 cache engineering 的理论效率潜力转化为真实智能体工作负载上更低的墙钟延迟与更高吞吐量。

  • •Cache engineering 的形式化:我们通过显式缓存操作及其轨迹对 cache engineering 进行形式化,为历史依赖的缓存状态提供清晰且确定性的描述。该形式化还为智能体提供了定义并优化自身缓存工程策略的可编程接口。
  • •面向 cache engineering 的服务系统:我们提出首个允许智能体直接控制其缓存的服务系统,而在此之前缓存完全由系统管理。我们协同设计了无状态接口、扩展基数树与分段批量注意力,以支持高效的缓存复用、逐出与恢复。
  • •效率与基准性能的提升:在三个 LLM 与四个智能体基准上,一个简单的工具响应滚动丢弃缓存策略相比传统的阈值触发摘要,平均成本降低 27.7%,平均基准得分提升 1.7 分。配合 AKV 服务端,这对应 1.18\times 的输出吞吐量与 1.51\times 的 P95 请求延迟加速。基于 RSI 的策略在留出任务上进一步降低 7.1% 的成本。

2 相关工作

智能体 context engineering。 在文本层面,context engineering 通过摘要或裁剪交互历史来降低成本,并使智能体能够超出 LLM 上下文窗口工作。现有方法通过启发式(Wu et al., 2025 (https://arxiv.org/html/2610.28577#bib.bib5))或智能体自身决策(Ye et al., 2025 (https://arxiv.org/html/2610.28577#bib.bib7);Sun et al., 2025 (https://arxiv.org/html/2610.28577#bib.bib9))触发摘要。后续工作通过强化学习(Lu et al., 2025 (https://arxiv.org/html/2610.28577#bib.bib6))或优化压缩准则(Kang et al., 2025 (https://arxiv.org/html/2610.28577#bib.bib8))来提升摘要质量。为避免摘要的成本与复杂度,裁剪方法(Lindenbauer et al., 2025 (https://arxiv.org/html/2610.28577#bib.bib4);Zhang et al., 2026 (https://arxiv.org/html/2610.28577#bib.bib37))直接移除相关性较低的上下文。然而,编辑较早的上下文需要对保留的后缀进行重预填充,从而在重预填充成本与信息保留之间形成两难。

KV 缓存压缩、逐出与复用。 在缓存层面,已有工作通过缩减缓存规模或近似复用现有状态来降低存储、访问与计算成本。压缩方法使用低秩表示(Liu et al., 2024a (https://arxiv.org/html/2610.28577#bib.bib12);Wang et al., 2024a (https://arxiv.org/html/2610.28577#bib.bib57))、量化(Liu et al., 2024b (https://arxiv.org/html/2610.28577#bib.bib13);Liu et al., 2026b (https://arxiv.org/html/2610.28577#bib.bib56))或聚合(Fu et al., 2025b (https://arxiv.org/html/2610.28577#bib.bib43);Wang et al., 2024b (https://arxiv.org/html/2610.28577#bib.bib58))来更紧凑地表示缓存条目。逐出方法通常依赖底层信号,如 token 位置(Xiao et al., 2024 (https://arxiv.org/html/2610.28577#bib.bib14))或基于注意力的重要性(Zhang et al., 2023 (https://arxiv.org/html/2610.28577#bib.bib15);Li et al., 2024 (https://arxiv.org/html/2610.28577#bib.bib16);Fu et al., 2025a (https://arxiv.org/html/2610.28577#bib.bib44);Yang et al., 2026 (https://arxiv.org/html/2610.28577#bib.bib55))来移除用处不大的缓存条目。复用方法通过位置编码调整(Gao et al., 2024 (https://arxiv.org/html/2610.28577#bib.bib22);Ma et al., 2026 (https://arxiv.org/html/2610.28577#bib.bib27);Ordonez and Parnell, 2026 (https://arxiv.org/html/2610.28577#bib.bib28))或部分重算(Wang et al., 2025 (https://arxiv.org/html/2610.28577#bib.bib26))将缓存状态适配到不同的位置或上下文前缀。我们的工作聚焦于逐出与复用,支持由智能体与 harness 进行高层逐出决策,同时提供一个实用的服务引擎以实现高效的跨请求复用与隔离。我们将在附录 A.5 (https://arxiv.org/html/2610.28577#A1.SS5) 中讨论同期面向智能体的逐出工作。

服务系统中的 KV 缓存管理。 除算法设计外,先前工作还探索了面向高效缓存存储、共享与请求调度的系统优化。现有系统使用前缀缓存在共享相同前缀的请求之间复用 KV 状态,同时保持与全量 prefill 的等价性(Zheng et al., 2024 (https://arxiv.org/html/2610.28577#bib.bib20);Ye et al., 2024 (https://arxiv.org/html/2610.28577#bib.bib21))。针对智能体工作负载,近期系统通过批量上下文编辑来减少缓存失效(Xu et al., 2026 (https://arxiv.org/html/2610.28577#bib.bib10)),或将重预填充与持续执行重叠以隐藏其延迟(Pan et al., 2026 (https://arxiv.org/html/2610.28577#bib.bib11))。对于 cache engineering,还额外需要跟踪缓存操作历史,因为相同的 token 前缀在不同操作下可能产生不同状态。

3 Cache Engineering

Cache engineering 让智能体在不重写轨迹、也不重预填充保留上下文的前提下直接控制其活跃 KV 缓存。我们在 3.1 节 (https://arxiv.org/html/2610.28577#S3.SS1) 介绍基本概念,在 3.2 节 (https://arxiv.org/html/2610.28577#S3.SS2) 阐述设计动机,然后在 3.3 节 (https://arxiv.org/html/2610.28577#S3.SS3) 与 3.4 节 (https://arxiv.org/html/2610.28577#S3.SS4) 中形式化缓存操作及其轨迹。

3.1 预备知识

自回归 LLM 在给定前序 token 序列 x_{1:t} 的条件下预测下一个 token:

p_{\theta}(x_{t+1}\mid x_{1:t})。(1)

现代 LLM 服务使用 KV 缓存来避免重新计算早期 token 的状态。于是下一个 token 的预测以当前 token x_t 以及前序 token 的缓存为条件:

p_{\theta}(x_{t+1}\mid x_{t},\mathcal{C}_{1:t-1}),(2)

其中 \mathcal{C}_{1:t-1} 表示由 token x_{1:t-1} 计算得到的 KV 状态。

智能体的轨迹(trajectory)是用于后续模型计算的有序文本历史,包括其提示词、助手消息与工具响应。形式上,轨迹是一个逻辑 token 序列 x_{1:t},t 是其逻辑 token 长度。

在 cache engineering 中,缓存规模不必等于逻辑 token 长度。因此我们定义活跃缓存 \mathcal{C} 为可参与后续注意力的 KV 缓存状态。与之对应的 token 序列称为活跃上下文,其长度等于 \mathcal{C} 中 token 条目的数量。注意,活跃指的是在算法层面参与注意力,而非在服务引擎中的物理缓存驻留。缓存条目的位置编码索引也可以独立于其 token 在轨迹中的逻辑索引进行调整。

相似文章

面向智能体的缓存工程

Hugging Face Daily Papers

提出 AKV 的缓存工程方案,让 LLM 智能体在不修改轨迹的前提下直接操作 KV 缓存(drop/repos),并配合协同设计的 serving 引擎,在降低成本与延迟的同时提升基准分数。

今天我享受了HF每日论文

Reddit r/LocalLLaMA

一条推文分享了三篇来自Hugging Face Daily Paper的有趣论文,内容涉及本地LLM的KV缓存压缩进展和代理框架优化。