RAG很好，但有个毛病：每次查询都去打向量数据库。哪怕文档几个月没变，也要重新检索一遍。Akshay在《Your KV Caching Is Broken》里拆解了这个问题。斯坦福的研究发现，AI agent每次调用，大约62%的内容是重复的——相同的系统提示词、相同的工具定义、相同的文档，一遍遍送进去。你刚处理完同一份信息，下一秒又从头再来。

这个问题在真实世界已经炸了。Uber在工程团队全面铺开Claude Code，四个月烧光了2026年全年的AI预算。token单价确实在降，2023到2026年，GPT-4级别模型从每百万token 30美元降到0.4美元。但agent工作流每个任务要消耗5到30倍的token，因为每一步都在重新发送全部上下文。总账单反而涨了。

RAG的问题就在这里：每次查询都访问向量库，即使静态信息几个月没变。这昂贵、缓慢、而且完全没必要。

CAG（Cache-Augmented Generation）就是来解决这个的。它让模型把静态信息留在自己的KV缓存里。KV缓存是模型在读取每个token时内部构建的Key和Value向量，本质上是模型对上下文的“理解”。既然理解没变，为什么每次都要重新理解一遍？

RAG和CAG可以组合，把知识拆成两层：

- 静态数据（政策、文档）在KV缓存里缓存一次

- 动态数据（最新更新、实时文档）走检索

你得到的是更快的推理、更低的成本、更少的重复劳动。关键在于有选择地缓存：只缓存那些稳定、高价值的静态知识。什么都缓存，上下文窗口会爆。

但缓存有硬性天花板。前缀缓存要求精确的字节级前缀匹配。只要缓存区域里改一个字符，整个缓存就失效。三个常见场景直接踩坑：

1. RAG多文档查询：文档A和B分别缓存，新查询需要两者，B的缓存状态失效，因为它计算时不知道A的存在。

2. 文档顺序变化：同样的三份文档，不同请求里顺序一变，每个排列都是缓存未命中。

3. 对话历史增长：每一轮新对话都改变了前缀之后的内容，更早的缓存状态变得没用。

阿里云的生产数据证实了这个局限：10%的KV缓存块贡献了77%的命中。大部分缓存内容从未被重用。

还有一个隐藏的性能税。当前所有KV缓存库都运行在推理引擎的进程内。缓存操作（存储、加载、移动张量）和推理计算共享同一套资源。引擎在管理缓存时就停止推理，在推理时缓存操作就得等着。就像厨师做每道菜都要跑去储物间拿食材，炒菜和取东西没法同时进行。Google的TurboQuant，一种KV缓存量化技术，把缓存压缩到每值3bit、零精度损失，但在推理引擎内运行导致20%以上的推理变慢。压缩本身没问题，问题在于它和推理在同一个进程里抢资源。

LMCache的解法是彻底分开。它把缓存管理从推理引擎中拆出来，作为独立进程运行。推理引擎只发一条消息“我需要这些块ID”，剩下的重活——在GPU、CPU、存储之间搬运KV张量——全在LMCache进程内完成。这带来三个实打实的收益：

- **无资源争用**：缓存I/O和推理互不阻塞。

- **跨GPU零拷贝共享**：多个GPU直接读写同一内存区域，省掉多次内存拷贝。

- **多层级并行加载**：缓存分布在GPU内存、CPU RAM、本地SSD、远端存储，LMCache同时查找所有层级，而不是顺序等待最慢的那层。

在H200 GPU上跑Qwen3-235B、50并发用户，LMCache比进程内缓存快14倍的TTFT、4倍解码速度。启动时间从3分钟降到30秒。

多文档查询的问题，LMCache团队的CacheBlend论文（EuroSys 2025最佳论文）直接解决。核心观察是：现代transformer里，大多数token主要关注自己的局部上下文，只有少数token跨文档边界有强连接。CacheBlend找出那几个token，只重算它们，其余全部复用独立缓存。多文档RAG查询快2到4倍，质量无损。

生产环境该有的它都有：Prometheus和OpenTelemetry集成、Kubernetes operator、CLI调试工具。容错设计：推理引擎崩溃，缓存数据在CPU和存储上保留；LMCache崩溃，引擎降级为无缓存模式继续跑，缓存进程恢复后自动重连。两边都不会全挂。

当然，不是所有人都买账。有网友指出，CAG把上下文窗口塞满静态知识，推理成本未必比向量库便宜。也有网友说，这个方案只在重复流量高的场景（支持机器人、FAQ）才划算，低频查询可能回不了本。还有人在本地做RAG时，选择缓存每个文档的嵌入，静态PDF不用每个会话重新embedding——手机端省算力。

最终，KV缓存管理不是未来的优化，而是今天的成本结构决策。你此刻就在做这个决策，不管你意识到没有。LMCache完全开源，项目在GitHub上。

[LMCache GitHub →](https://github.com/LMCache/LMCache)