清华开源AKV：SGLang上的LLM智能体缓存工程服务器

从“删历史”到“调缓存”：LLM智能体的新思路

长上下文智能体面临一个尴尬的现实：对话历史越长，KV缓存越臃肿，推理成本和延迟同步上升。业界常见做法是让模型总结历史或直接截断，但这两种手段都会丢失关键信息。清华大学研究团队给出了另一条路径——把KV缓存本身当作可工程化的资源来管理，并基于SGLang实现了开源服务系统AKV。

据MarkTechPost报道，AKV允许智能体在推理过程中“丢弃”和“重新定位”KV缓存，而不是依赖总结来压缩历史。官方给出的数据显示，在4个智能体基准测试上，该方案将平均成本降低了27.7%。

AKV解决的是什么问题

缓存膨胀是智能体的隐性成本

多轮智能体任务中，每一步推理都需要携带此前积累的上下文。传统方案把整段历史作为不可分割的KV块随请求传递，导致显存占用和预填充计算量持续增长。当历史超出窗口上限时，系统只能丢弃早期内容或让模型生成摘要，前者可能丢失任务关键线索，后者则引入额外的生成开销和信息损耗。

AKV的思路是把缓存视为可编辑的数据结构：研究者可以标记哪些缓存片段应该保留、哪些可以丢弃、哪些需要移动到新的位置。这种“缓存工程”让智能体在保持任务相关上下文的同时，显著压缩无效历史。

KV缓存是Transformer架构在自回归生成时的一种关键优化：每生成一个新token，模型需要用到此前所有token的Key和Value向量，为了避免重复计算，推理引擎会将这些中间结果缓存起来。对于多轮智能体任务，整个对话历史对应的KV缓存会随轮次线性增长，不仅占用大量显存，还使得每次新请求的预填充（prefill）阶段需要处理更长的序列，直接推高延迟和算力成本。因此，缓存膨胀并非单纯存储问题，而是影响推理经济性的核心瓶颈。

与“总结历史”路线的对比

总结历史依赖模型生成能力，本质上是把长上下文压缩成短文本，代价是信息有损且每次压缩都需要一次额外的模型前向。AKV直接操作KV缓存，省去了生成摘要的步骤，也避免了摘要模型理解偏差带来的任务失败风险。从工程角度看，这更像数据库的索引管理，而非自然语言处理。

SGLang是一个面向大语言模型的高性能推理服务框架，其核心创新之一是RadixAttention：它利用基数树（radix tree）组织KV缓存，使得多个请求之间可以自动共享相同前缀的缓存，从而避免重复计算。这种机制天然适合多轮对话场景，因为后续轮次通常复用前序历史。AKV在SGLang的基础上扩展了缓存编辑能力，允许智能体不仅复用缓存，还能主动丢弃或重新定位缓存片段，将缓存管理从被动复用升级为主动工程化控制。

技术实现与开源形态

AKV构建在SGLang之上。SGLang本身是面向大模型推理的高性能服务框架，具备RadixAttention等缓存复用机制。AKV在此基础之上增加了面向智能体场景的缓存编辑接口，使开发者能够以编程方式控制KV缓存的生命周期。

对于智能体开发者而言，这意味着可以在任务编排层直接声明缓存策略，而不必修改模型本身或依赖外部摘要模块。开源发布也降低了复现门槛，研究社区可以基于同一套服务系统对比不同缓存策略的效果。

27.7%成本下降意味着什么

在多智能体或长程任务中，推理成本往往随轮次近似线性增长。27.7%的平均成本下降不是一个小数字——它意味着同样的预算可以支撑更多轮交互，或者在相同任务量下显著降低API与算力开销。

需要客观看待的是，这一数字来自4个智能体基准的平均值，具体到不同任务类型，收益可能有明显差异。缓存可丢弃程度取决于任务对历史信息的依赖强度：信息检索类任务可能受益更大，而需要严格追踪早期指令的任务则未必。

对智能体基础设施的启示

AKV代表了一种趋势：智能体的优化正在从提示词工程向推理系统层下沉。过去一年，围绕KV缓存压缩、分页管理和前缀复用的研究密集出现，说明长上下文成本已经成为智能体落地的核心瓶颈之一。

清华团队选择在SGLang上开源而非闭源商用，也有助于形成围绕缓存工程的工具生态。如果后续有更多框架接入类似的缓存编辑原语，智能体开发者或许能像配置数据库索引一样配置上下文策略，把“记住什么、忘记什么”变成可调参数而非玄学。

目前AKV的公开信息仍集中在方法层面，具体的接口设计、调度策略和不同模型上的适配效果，还需要社区在实际使用中检验。