KV Cache如何重塑AI Agent成本结构

AI Agent 的运行成本远不止模型推理的 token 单价。在大规模多轮对话与工具调用场景中，KV Cache（键值缓存）的管理策略正在成为影响成本的关键变量。原始素材指出一个核心洞察：缩小缓存、复用前缀、就近存放，这三件事节省的是完全不同的资源。理解这条逻辑，才能把 Agent 成本优化做到位。

为什么 KV Cache 直接决定 Agent 成本

大模型在生成每个 token 时，需要对历史上下文做注意力计算。为避免重复计算，推理引擎会把每一层的 Key 和 Value 张量缓存下来，这就是 KV Cache。对于单次问答，这笔缓存开销可以忽略；但 Agent 的典型负载是长会话、多轮工具调用、反复重试——上下文越滚越长，缓存占用随序列长度线性增长，显存压力随之上升。

当缓存撑爆显存，系统只能把部分内容换出到更慢的存储层级，或者干脆重算。前者拉高延迟，后者浪费算力。两者最终都会反映为账单上的成本增加。因此，KV Cache 不是单纯的工程细节，而是 Agent 经济性的底层杠杆。

KV Cache 与注意力机制的关系

Transformer 解码器在自回归生成时，每产生一个新 token，都需要对全部历史 token 计算注意力。如果每次都从头计算，第 n 个 token 的生成需要 O(n²) 的注意力计算量，重复度极高。KV Cache 的做法是把每一层已计算过的 Key 和 Value 矩阵保存下来，新 token 只需与缓存的 K、V 做一次注意力，就把单步计算量降到 O(n)。代价是缓存本身占用显存：每个 token 的 KV Cache 大小为 2 × 层数 × 隐藏维度 × 精度字节数，以 70B 级模型、8K 上下文为例，单请求缓存就可达数 GB。这也解释了为什么长上下文与高并发在显存上是相互挤占的关系。

PagedAttention 与显存碎片

早期推理引擎为每个请求预留连续显存块，长度按最大可能序列分配，造成严重内部碎片。vLLM 提出的 PagedAttention 借鉴操作系统虚拟内存分页思想，把 KV Cache 切分成固定大小的 block 并按需分配，使显存利用率从约 20%-40% 提升到 90% 以上。这一机制是后文"缩小缓存""复用前缀""就近存放"三类优化能够落地的基础设施前提。

三种优化手段，三种不同的节省

原始素材最有价值的部分，是把常被混为一谈的三类优化拆开来看。

缩小缓存：省的是显存容量

压缩 KV Cache 的手段包括量化、低秩近似、按重要性淘汰旧 token 等。它的直接效果是让同样大小的显存装下更长的上下文，或者在同等上下文下容纳更多并发请求。换句话说，它买到的是容量——单位显存能承载的 token 数变多了。

复用前缀：省的是重复计算

Agent 系统提示词、工具定义、少样本示例往往在每次请求中重复出现。如果推理引擎能够识别并复用这段公共前缀的缓存，就无需为每个请求重新计算这些 token 的注意力。这节省的是算力与首 token 延迟，与显存容量是两回事。前缀缓存命中率越高，单位请求的有效计算成本越低。

前缀缓存的技术前提：前缀必须逐 token 完全一致

前缀复用（Prefix Caching）依赖一个严格条件：被复用的部分必须从序列第一个 token 开始就完全相同。系统提示词中间插入一个时间戳、工具列表顺序变动、甚至少样本示例的措辞调整，都会导致缓存失效、整段重算。工程上常见的应对是把动态内容（用户输入、当前时间、检索结果）统一后置到静态前缀之后，形成"稳定前缀 + 可变后缀"的请求结构。部分推理框架还支持多级前缀树匹配，能命中不同请求间的公共祖先节点，从而提高共享率。前缀缓存的收益可直接量化为：命中 token 数 × 单 token 预填充计算成本，在长系统提示词的 Agent 场景中，这部分往往占总预填充算力的一半以上。

就近存放：省的是传输与等待

缓存放在哪里，决定了访问它的代价。把 KV Cache 保留在 GPU 显存中访问最快但容量稀缺；下沉到 CPU 内存或远端存储可以扩大容量，却引入传输开销。就近存放策略的本质，是在容量与访问延迟之间做分层调度，节省的是数据搬运的时间和带宽。

分层存储与卸载的实际带宽约束

把 KV Cache 从 GPU 显存下沉到其他层级时，代价主要由互联带宽决定。NVLink 可达数百 GB/s 至 TB/s 级，PCIe 4.0 x16 约 32 GB/s，而跨节点以太网通常在 10-100 Gb/s 量级，相差一到两个数量级。以单 token KV Cache 约 1 MB 估算，通过 PCIe 搬运 8K token 的缓存需数百毫秒，足以让首 token 延迟翻倍。因此"就近"不只是物理距离，更是带宽与延迟的匹配问题：热缓存留在 HBM，温缓存放 CPU 内存或本地 NVMe，冷缓存才允许跨节点迁移。类似 Mooncake、LMCache 这类系统正是围绕"以 KV Cache 为中心"的调度来设计，把缓存复用与分层卸载做成独立服务。

对 Agent 架构设计的启示

把这三者区分清楚，能避免一个常见误区：以为做了缓存量化就等于解决了全部成本问题。实际上，如果一个 Agent 的瓶颈在于每轮都重算长系统提示词，那么压缩缓存容量并不能改善它的延迟和算力浪费；反之，如果瓶颈是并发数上不去，前缀复用也帮不上忙。

合理的做法是先做成本归因：用监控数据判断当前瓶颈落在显存、算力还是数据搬运上，再选择对应的优化手段。三者可以叠加，但优先级应当由瓶颈决定。

实践中的权衡

压缩缓存可能带来精度损失，需要在任务质量与容量之间校准；前缀复用要求请求结构足够稳定，提示词频繁变动会降低命中率；分层存放则要求调度策略能准确预测哪些缓存会被再次访问。这些都不是免费的午餐，而是工程团队需要持续调优的地方。

对构建 Agent 产品的团队而言，KV Cache 管理正在从底层细节上升为架构级决策。谁能在容量、算力、传输三者之间找到适合自身负载的平衡点，谁就能在同等模型能力下拿到更低的单位任务成本。