代理服务中基于学习智能体执行的KV-Cache管理

# 面向智能体服务的KV缓存管理学习型智能体执行
来源：https://arxiv.org/html/2608.14624 研究全文  
Rui Zhang¹, Chaeeun Kim¹, Shaoting Feng², Kuntai Du³, Yuhan Liu³, Yi Zhong¹, Cheng-Wei Ching¹, Junchen Jiang³, Liting Hu¹  

## 摘要  
多智能体大型语言模型系统已成为AI服务的重要部署范式，每个用户请求被分解为一系列专门化的智能体。在这些工作流中，每个智能体反复执行包含系统提示、工具定义和少量示例的固定上下文，为KV缓存复用创造了巨大机会。然而，现有的LLM服务系统通过前缀缓存和基于最近访问的替换策略被动管理KV缓存，导致可复用的智能体上下文在下次调用前被驱逐，迫使重复计算。我们提出**CacheScout**——一个面向多智能体LLM服务的智能体感知KV缓存运行时层。核心见解是：未来KV缓存的复用不仅取决于访问时效性，更由智能体执行语义决定。CacheScout通过在线学习智能体执行转换过程捕获这些语义（无需预定义工作流图或离线训练），并利用学习到的执行模型指导缓存驱逐和主动预取，同时保持服务关键路径不变。我们在vLLM上实现了CacheScout。在代表性真实多智能体工作负载中，CacheScout将KV缓存命中率提升10-18个百分点，平均首Token延迟（TTFT）降低18-45%，平均单轮延迟降低29-38%，峰值吞吐量最高提升57%。这些优势可扩展至更大模型：在Qwen3-235B-A22B上，TTFT最高降低54%，同时保持吞吐量提升37%。  
**关键词**：LLM服务、多智能体系统、KV缓存、缓存管理、前缀缓存、机器学习系统  

## 1. 引言  
图1. 多智能体旅行规划用例。多智能体LLM系统迅速成为生产AI服务的主导部署范式，驱动着软件工程助手（Yang等，2024；Jimenez等，2024；Zhang等，2024）、企业知识助手（Lewis等，2020；Gao等，2023；Syarubany与Yoo，2025）以及深度研究智能体（Zhang等，2025；Huang等，2025；Du等，2025）等应用。这些应用不再依赖单一LLM调用，而是将每个用户请求分解为由一系列专门化智能体协作完成的子任务。规划器协调工作流，领域专用智能体执行特定推理或工具使用，最终结果整合为最终响应。如图1所示，考虑用户请求AI助手规划日本旅行：规划器首先调用旅行智能体搜索航班，接着酒店智能体推荐住宿，最后餐厅智能体查找当地餐馆，再将所有信息整合。每次调用旅行智能体时，它都以相同的固定上下文开始，包括诸如“您是旅行专家。根据用户预算和行程找出最佳航班选项”之类的系统提示，以及相同的航班搜索工具定义。酒店智能体同样以“您是酒店推荐专家...”开头，搭配相同的酒店搜索工具。特定任务的用户请求附加在此固定上下文之后。由于该固定上下文极少变化，其生成的KV缓存可在同一智能体被调用时复用，甚至跨不同用户会话。如图2所示，此重复出现的固定上下文在本文评估的四个多智能体工作负载中占所有提示令牌的53–62%，为KV缓存复用提供了巨大机会。  

然而，当今的LLM服务系统（如vLLM、SGLang和TensorRT-LLM）未能充分利用此机会，因为其缓存管理本质上是反应式的，依赖前缀缓存和基于最近访问的缓存替换策略。回到我们的例子：旅行智能体搜索航班后，规划器继续调用酒店智能体和餐厅智能体。随着它们的KV块逐渐填满GPU缓存，旅行智能体对应的固定上下文因未被最近访问而最终被驱逐。之后，用户审查酒店选项后，规划器决定比较另一航班行程，再次调用旅行智能体。由于其可复用的固定上下文已被驱逐，服务系统必须重新计算相同前缀。这种模式在多智能体工作流中反复出现。尽管可复用的智能体锚点可能在其他智能体执行期间保持空闲，但当同一智能体再次被调用时很可能被复用。基于最近访问的缓存策略无法区分这种临时空闲期与真正冷数据，导致它们恰恰驱逐了对未来执行最有价值的KV块。  

### 问题本质  
弥合差距需要缓存保留将被再次使用的KV块，而不仅仅是最近使用的块。这比表面看起来更困难。当今的服务引擎（如vLLM和SGLang）将KV缓存作为通过内容哈希索引的匿名块来管理。它们知道哪个块被访问过，但不知道谁使用了它。例如，引擎无法判断一个块属于旅行智能体、酒店智能体还是餐厅智能体。因此，它无法判断一个块是否可能在不久的将来被复用，或是否可以安全驱逐。  

即使缓存知道每个块由哪个智能体产生，决定下一步仍然困难。现代智能体框架（如AutoGen和LangGraph）不遵循固定工作流。相反，下一个智能体由LLM在运行时选择。规划器可能再次调用旅行智能体、切换到另一个智能体或直接结束任务。因此，未来复用无法从预定义工作流中确定。近期系统通过要求工作流预先已知（作为声明式执行图或开发者提供的注释）或固定当前会话的KV缓存跨工具调用来规避此难题。但当下一个智能体在运行时动态决定时，这两种方法都无效。  

最后，任何预测都必须极其快速。缓存驱逐发生在GPU内存满时，是服务热路径的一部分。存储领域的学习型缓存替换策略通过特征提取和模型推理提高预测质量，但花费毫秒做出更好的缓存决策很容易超过其节省的预填充计算成本。  

图2. 四个代表性多智能体工作负载（GSM8K、MT-Bench、GAIA、SWE-bench）中重复固定上下文（系统提示、工具定义、技能和示例）占提示令牌的比例。  

### 我们的解决方案  
我们通过引入**CacheScout**来解决此问题——一个轻量级的KV缓存运行时层，弥合智能体框架与服务引擎之间的鸿沟。CacheScout不基于过去访问管理KV块，而是观察智能体执行、学习运行时智能体调度模式、预测下一个可能执行的智能体，并利用此信息指导缓存驱逐和预取。通过这种方式，缓存管理从仅仅反应过去访问变为主动感知未来智能体复用。  

CacheScout通过三种技术实现此设计：  
1. **转换学习器**：将智能体执行建模为在线一阶马尔可夫链。对于每个请求，它通过提示前缀指纹识别智能体，并更新单个转换计数器。无需离线训练或预定义工作流图（第3.2节）。  
2. **生存概率评分器**：根据学习到的转换矩阵估计每个缓存锚点被复用的概率，并将此概率与最近访问度和重建成本结合，对驱逐候选者进行排序。结果可复用锚点被保留，同时执行保持可预测性；当不可预测时，策略自然回退至LRU（第3.3节）。  
3. **后台预取**：使用相同转换矩阵预测下一个智能体，并在请求间预热相应锚点，保持服务关键路径不变（第3.4节）。  

这些技术共同将KV缓存从被动的基于LRU的组件转变为主动的智能体感知运行时层。  

### 结果摘要  
我们在vLLM上实现了CacheScout（作为轻量级KV缓存运行时层），并与原生vLLM及Continuum进行比较。使用Llama-3.1-8B-Instruct在六智能体监督框架下，我们在四个代表性真实多智能体工作负载上评估了CacheScout。CacheScout将KV缓存命中率提升10–18个百分点（所有工作负载达81–85%），平均TTFT降低18–45%，平均单轮延迟降低29–38%，并实现19–57%的峰值吞吐量提升。在相同延迟预算下，它可承载原生vLLM的1.7–12倍负载。这些优势扩展至更大模型：在235B参数混合专家模型Qwen3-235B-A22B上，CacheScout在SWE-bench上将平均TTFT降低33–54%，吞吐量提升37%。我们还证明CacheScout在不同缓存容量和工作负载条件下保持鲁棒，且运行时开销可忽略不计。  

### 贡献  
本文做出以下贡献：  
- 识别多智能体LLM服务中的新挑战：现有前缀缓存是反应式的，无法利用未来智能体复用。  
- 提出**CacheScout**——一个轻量级KV缓存运行时层，弥合智能体框架与服务引擎，实现主动、智能体感知的缓存管理。  
- 设计并实现CacheScout，包含三项技术：在线转换学习、基于生存概率的驱逐和异步预测预取，同时保持运行时状态和开销低。  
- 在vLLM上实现CacheScout，在代表性多智能体工作负载中显著提升缓存命中率、TTFT和吞吐量。  

## 2. 动机与挑战  
### 2.1 背景  
#### 多智能体工作流  
现代LLM应用越来越多地将复杂任务组织为多智能体工作流。规划器不再依赖单一模型调用，而是将用户请求分解为一系列专门化智能体序列，每个智能体负责特定任务（如规划、检索、编码或工具使用）。这些智能体可遵循预定义执行图，或由LLM在运行时动态选择。AutoGen、LangGraph、CrewAI和OpenAI Swarm等框架使此执行模型在生产系统中日益普遍。  

#### 智能体锚点  
尽管不同智能体执行不同任务，但每次调用同一智能体都以几乎相同的提示前缀开始。这些前缀通常包括描述智能体角色的系统提示、指定可用API的工具定义、技能描述，以及可选的少量示例。本文中，我们将此可复用的提示前缀称为**智能体锚点**。由于智能体锚点在不同调用或用户会话间极少变化，其生成的KV缓存可在同一智能体再次执行时复用。  

#### 前缀缓存  
现代服务系统（包括vLLM、SGLang、TensorRT-LLM、LMCache和NanoFlow）通过前缀缓存减少冗余预填充计算。在预填充阶段，模型为每个提示令牌计算KV张量。如果后续请求共享相同提示前缀，这些KV张量可直接复用而非重新计算。现有系统主要在识别相同前缀的方式上有所不同。例如，vLLM将提示划分为固定大小的块（默认16个令牌），通过块哈希识别可复用KV块；而SGLang使用RadixAttention将提示前缀组织在基数树中，实现令牌级前缀匹配。尽管实现不同，所有现有系统仅根据提示内容识别可复用KV缓存。  

#### 反应式缓存管理  
现有前缀缓存本质上是反应式的。KV块仅在已请求并插入缓存后才成为可复用。同样，缓存替换策略（如LRU、LFU、ARC和LIRS）仅根据过去访问保留KV块。服务引擎仅处理内容寻址的KV块，既不知道缓存块由哪个智能体产生，也不知道该智能体是否可能再次被调用。随着多智能体工作流动态性日益增强，这种反应式设计错失了许多复用机会。  

图3. (a) 块复用计数 (b) 会话内延迟分布