你的 KV 缓存已损坏

一份面向实践者的 KV 缓存管理指南。现代缓存架构如何将输入令牌成本削减 90%，并让 LLM 推理提速高达 14 倍。

斯坦福大学的研究人员研究了 AI Agent 实际使用推理预算的情况。最突出的发现是：每次调用发送给 Agent 的内容中，约有 62% 是重复的。相同的系统提示、相同的工具定义、相同的文档，一遍又一遍地喂进去。

所以每当 Agent 执行一个步骤时，你都要从头开始把所有内容交给它。所有指令、所有上下文、所有背景。即使它在上一秒刚刚处理过完全相同的信息。

昂贵的部分不是思考或推理，而是 AI 一遍又一遍地重读相同的笔记。

Agent 循环在每个步骤中重新发送相同的提示负载（系统提示、工具定义、文档），

Agent 循环在每个步骤中重新发送相同的提示负载（系统提示、工具定义、文档），

2023 年到 2026 年间，每 token 价格下降了 80%，GPT-4 级别模型从每百万 token 30 美元降至 0.40 美元。但 Agent 工作流每个任务消耗的 token 数是标准聊天机器人查询的 5 到 30 倍，因为每个步骤都会重新发送所有上下文。所以尽管每个 token 变便宜了，总账单却上升了，因为用量超过了价格下降的速度。

优步（Uber）深有体会。在他们整个工程组织推广 Claude Code，结果在四个月内就烧光了 2026 年全年的 AI 预算。高德纳（Gartner）现在预测，到 2027 年将有 40% 的 AI Agent 项目仅仅因为成本超支而被取消。

整个行业正在优化错误的变量。如果大多数 token 本来就不应该存在，那么让每个 token 更便宜是没用的。

所以，在这篇文章中，我们将学习一种新的开源架构，它将缓存管理完全移出推理引擎。采用该架构的团队看到首令牌延迟（time-to-first-token）快了 14 倍，而大多数从业者还没有跟上这个步伐，所以现在理解它，会让你领先于目前几乎所有运行推理的人。

显示 LMCache 工作原理的示意图

显示 LMCache 工作原理的示意图

当你发送提示时发生了什么

每次你向模型发送提示，模型都会让每个 token 通过注意力机制。对于每个 token，模型会在每一层注意力层计算一个 Key 向量和一个 Value 向量。这些 K 和 V 向量捕捉了模型如何“理解”每个 token 与上下文中其他每个 token 之间的关系。

这些 K 和 V 向量的集合称为 KV 缓存。

注意力机制如何产生 KV 缓存

注意力机制如何产生 KV 缓存

计算量随输入长度呈二次方增长。上下文长度翻倍，注意力计算量大约翻四倍。4K token（一个简单的聊天机器人回合）时，这是便宜的。128K token（一个包含工具、文档和历史的 Agent 循环）时，就变得昂贵了。

4K、32K 和 128K 上下文长度下的二次方计算成本曲线：上下文翻倍，成本翻四倍

4K、32K 和 128K 上下文长度下的二次方计算成本曲线：上下文翻倍，成本翻四倍

一块 MI300X GPU 每天大约产生 15 TB 的 KV 缓存。其中大部分在每个请求之后就被抛弃了。

你的系统提示的 KV 缓存每次发送时都是相同的。你上传的文档的 KV 缓存每次用户询问时都是相同的。但模型每次都重新从头计算这种相同的理解。

这就像是每次有人问关于第 7 章的后续问题时，你都从第 1 页开始重读教科书。你已经理解了第 1 章到第 6 章，但你没有办法保存和重用这种理解。所以你只能重新开始。

前缀缓存解决什么、止步于哪

业界注意到了这种浪费，并构建了一个名为提示缓存（prompt caching）的功能来解决它。

它的工作原理是这样的。如果两个连续的请求共享相同的开头 token（即“前缀”），提供商会存储第一个请求的 KV 缓存，并在第二个请求中重用。模型跳过重新计算那些 token，只处理新的部分。

节省是实实在在的。Anthropic 的实现对缓存输入 token 实现了 90% 的成本降低。对于稳定的工作负载，命中率可以达到 60% 到 85%。对于具有稳定系统提示和工具定义的团队来说，这是目前可用的最高杠杆优化之一。

但是前缀缓存有一个硬天花板。

缓存的部分必须与新请求的准确前缀完全一致（逐字节）。更改缓存区域中的任何内容（即使是一个字符），都会导致完全的缓存未命中。

这在三种常见场景中会失效：

三种前缀缓存场景：何时有效、何时无效

三种前缀缓存场景：何时有效、何时无效

• 带多个文档的 RAG：你单独缓存了文档 A 和文档 B。一个新查询需要两者。第二个文档的缓存 KV 状态是无效的，因为它是在没有意识到第一个文档的情况下计算的。

• 文档顺序变化：相同三个文档以不同顺序出现在不同请求中。每个排列都是缓存未命中，即使文档本身完全相同。

• 增长的对话历史：每一轮新的对话都会改变前缀之后的整个上下文。稳定前缀之后的早期缓存状态变得无用。

阿里云的生产数据证实了这一限制。10% 的 KV 缓存块服务了 77% 的命中。大多数缓存内容从未被重用，因为严格的前缀匹配规则阻止了它。

前缀缓存是一项有意义的优化，但它仅在上下文有较长且不变的开头时才有效。许多真实工作负载并非如此。

缓存性能税

当前缓存方式还有第二个问题，它影响所有可用的 KV 缓存工具。

每个 KV 缓存库都在推理引擎的进程内运行。这意味着缓存操作（存储、加载、移动 KV 张量）和实际的推理计算共享相同的资源。它们不能同时运行。

当引擎忙于管理缓存时，它会停止推理。当它进行推理时，缓存操作需要等待。

推理和缓存 I/O 在单个进程内轮流进行

推理和缓存 I/O 在单个进程内轮流进行

想象一下，一家餐厅的厨师每做一道菜还得跑到储藏室去拿食材。烹饪和取食材不能同时进行，所以厨房变慢了，尽管厨师完全有能力。

影响是可衡量的。Google 的 TurboQuant 是一种最新的 KV 缓存量化技术，将缓存压缩到每值 3 位，且零精度损失。但当它在推理引擎内部运行时，会导致 20% 以上的推理减速。

压缩本身工作完美，但它在与推理相同的进程内运行这一事实抵消了收益。

缓存管理和推理服务本质上是不同的工作负载。一个是 I/O 密集型（在 GPU、CPU 和存储之间移动大型张量）。另一个是计算密集型（GPU 上的矩阵乘法）。

将两者强制塞入同一个进程，就像在同一个线程中运行数据库和 Web 服务器。它在负载到来之前还能工作，但一旦负载上来，一切都在争夺相同的资源。

LMCache 与解耦架构

LMCache 是一个开源项目，它采用了一种根本不同的方法。它不是将缓存管理放在推理引擎内部运行，而是作为一个完全独立的进程与推理引擎并行运行。

回到餐厅的类比，这就像是专门给储藏室雇了一个跑堂。厨师永远不离开厨房。跑堂独立处理所有取货和存储。两者都全速工作，无需等待对方。

传统的单进程设计 vs LMCache 的解耦架构

传统的单进程设计 vs LMCache 的解耦架构

在实践中，LMCache 通过共享 GPU 内存连接到推理引擎。引擎只需要告诉 LMCache “我需要这些块 ID”（很小的消息，几乎没有数据）。

所有实际移动 KV 张量（在 GPU、CPU 和存储之间）的重活都在 LMCache 自己的进程中完成。推理引擎甚至没有注意到它在发生。

这种分离带来了三个具体优势。

• 无资源争用：缓存 I/O 从不阻塞推理，推理也从不阻塞缓存 I/O。在引擎内部运行优化技术导致的 20% 吞吐量损失消失了。

• 跨 GPU 的零拷贝共享：在传统设置中，在两个 GPU 之间共享缓存数据需要多次内存拷贝。LMCache 允许两个 GPU 直接读写同一内存区域，完全跳过这些拷贝。

• 多层级并行加载：缓存数据可以驻留在 GPU 内存、CPU RAM、本地 SSD 和远程存储中。传统方法逐个检查这些层级，在最慢的层级上形成瓶颈。LMCache 同时检查所有层级，并从找到匹配的任何位置并行流式传输数据。

四个存储层级（GPU 内存、CPU RAM、本地 SSD、云存储）的串行检查 vs LMCache 跨所有层级的并行查找

四个存储层级（GPU 内存、CPU RAM、本地 SSD、云存储）的串行检查 vs LMCache 跨所有层级的并行查找

性能差异显著。在配备 H200 GPU 和 Qwen3-235B 模型、50 个并发用户的情况下，与进程内缓存相比，LMCache 的首令牌延迟快了 14 倍，解码速度快了 4 倍。启动时间从 3 分多钟缩短到大约 30 秒。

经济账即使在非常低的缓存命中率下也是成立的。一个缓存的提示每周只需被重用两到三次（约 1% 命中率），系统就能收回成本。在 1000 节点部署中，10% 的命中率在三年内可节省约 2900 万美元。

LMCache 与所有主流推理引擎（vLLM、SGLang、TensorRT-LLM）集成，并支持 NVIDIA 和 AMD GPU。

用 CacheBlend 解决前缀问题

LMCache 的架构解决了缓存性能方面的问题。但还记得之前的前缀缓存天花板吗？你分别缓存了文档 A 和文档 B，现在一个查询需要两者。第二个文档的缓存是无效的，因为它是在隔离状态下计算的。

LMCache 团队的研究论文 CacheBlend（荣获 EuroSys 2025 最佳论文奖）直接解决了这一限制。

问题归结为一点。当你独立缓存两个文档时，它们谁也不知道对方的存在。所以当你把它们的缓存状态拼接在一起时，模型无法联合理解它们。两个文档之间的连接从未被计算过。

但事实证明，在现代 Transformer 模型中，大多数 token 主要关注自己的局部上下文。只有一小部分 token 在文档边界之间有强连接。

CacheBlend 通过识别这些少数 token 并仅选择性重新计算它们来利用这一点。其他所有内容都从独立缓存中原样重用。

前缀缓存重新计算第一个文档之后的所有内容 vs CacheBlend 重用所有缓存的文档

前缀缓存重新计算第一个文档之后的所有内容 vs CacheBlend 重用所有缓存的文档

结果是，对于多文档查询（你在 RAG 应用中看到的那种），处理速度提高了 2 到 4 倍，且没有任何质量损失。CacheBlend 不是从头重新计算所有内容，而是以极低的成本恢复缺失的跨文档理解。

对于构建 RAG 系统、多文档问答或从多个来源积累上下文的 Agent 的团队来说，这会将知识库中的每个文档都变成一个可重用的缓存资产，无论它以什么顺序出现，也无论旁边有什么其他文档。

为生产环境而构建

LMCache 不是一个研究原型。它提供了生产团队所期望的基础设施。

• 集成 Prometheus 和 OpenTelemetry，用于跟踪缓存命中率和 I/O 性能。

• 用于部署的 Kubernetes Operator。

• 用于调试和基准测试的 CLI。

其容错设计值得注意。

如果推理引擎崩溃，LMCache 会保留 CPU 和存储上的所有缓存数据，因此恢复不会从冷启动开始。

如果 LMCache 本身崩溃，推理引擎会进入降级模式，缓存被禁用，但推理继续正常进行，并在缓存进程恢复时自动重新连接。

无论哪种故障，都不会导致整个系统宕机。

更广阔的图景

AI 应用现在每块 GPU 每天大约产生 15 TB 的 KV 缓存，而且大部分被丢弃。管理、存储和重用这些数据的基础设施正在被构建。

对于在自托管模型上运行 Agent 工作负载的从业者来说，KV 缓存管理不是未来的优化。它是你今天正在做出的成本结构决策，无论你是否意识到。

LMCache 处于最前沿。它是 100% 开源的。

**LMCache GitHub →
**（别忘了点星🌟）

喜欢通过视频学习的朋友，我很快就会做一个关于这个架构的深度视频。

今天就到这里，感谢阅读。

干杯！:)