@akshay_pachaar：你的 KV 缓存中 90% 从未被重用。（提示缓存从未旨在解决此问题）如果你的系统提示和工具定义…

90% 的 KV 缓存从未被重用。 （提示缓存从未旨在解决此问题） 如果你的系统提示和工具定义是稳定的，那么提示缓存是目前可用最高杠杆的优化手段。缓存的输入令牌最多可便宜 90%，命中率可达 60% 到 85%。 但它有一条硬性规则：缓存的部分必须与新请求的精确字节前缀完全匹配。只要在该区域更改一个字符，就会导致完全缓存未命中。 这条规则在你经常遇到的三种情况下会失效： → RAG 涉及多个文档。你分别缓存了文档 A 和文档 B。现在某个查询同时需要两者。文档 B 的缓存状态是在不知道 A 的情况下计算的，因此它失效了，需要从头重新计算。 → 文档顺序变化。相同的三个文档在不同请求中顺序不同。每种排列都是缓存未命中，即使内容完全相同。 → 对话历史不断增长。每一轮新对话都会改变稳定前缀之后的所有内容，因此超出前缀的早期缓存状态变得毫无用处。 阿里云的生产数据展示了问题的严重性：10% 的 KV 缓存块服务了 77% 的命中。其余部分存放在存储中，从未被重用，因为前缀匹配不允许它们被复用。 CacheBlend，来自 LMCache 团队的研究论文（EuroSys 2025 最佳论文奖），正是针对这一问题。其核心洞察是：在现代 Transformer 中，令牌绝大多数关注自己的局部上下文。只有一小部分令牌携带跨文档边界的真正连接。 因此，CacheBlend 不会重新计算第一个缓存文档之后的所有内容，而是重用每个文档的缓存，仅选择性地重新计算那些少量的边界令牌。这些就是图中文档之间的小橙色修正，也是全部的开销。结果是在多文档查询上实现 2 到 4 倍的加速，且无质量损失。 顺序问题也随之消失。随意打乱相同文档的排列，每种排列都保持缓存状态，而前缀缓存则每次都会重新计算所有排列。图的底部并排展示了这一点。 这才是真正的转变：从缓存前缀转向缓存知识。知识库中的每个文档都成为可重用的缓存资产，无论它以什么顺序出现，或者旁边是什么文档。 CacheBlend 集成在 LMCache 中，这是一个开源的缓存管理层，运行在推理引擎之外，并与 vLLM、SGLang 和 TensorRT-LLM 集成，支持 NVIDIA 和 AMD GPU。 在 GitHub 上查看：https://github.com/LMCache/LMCache （别忘了点星 ⭐） 我写了完整的架构解析，包括为什么缓存管理永远不应该放在推理引擎内部。文章引用如下。 敬请关注更多内容！