缓存命中，为什么必须从第一个token开始？
用 AI 的人都见过"缓存命中便宜 10 倍"的账单，但很少有人注意到它的铁律：必须从第一个 token 开始一字不差地命中。系统提示词改一个字，缓存全废；RAG 把资料插在 prompt 中间？缓存直接装瞎。

今天拆一篇 EuroSys 2025 的论文 CacheBlend（LMCache 团队），它把这条铁律破了，代价只是 15% 的重算。这一篇是 KV 缓存系列第 1 篇，先讲清最核心的破局点。

🧩 问题有多结构化？
RAG 的 prompt 是 [系统提示]+[文档A]+[文档B]+[问题]。中间的文档来自静态知识库，被千万个请求反复取用--按理算一次就该到处复用，现实却是每个请求都在重算。4000 token 的输入，70B 模型单卡要让用户干等 6 秒才见到第一个字。

⚠️ 为什么不能直接搬缓存？
因为 KV（注意力中间结果）不是 token 自带的属性，是"它+它前面所有内容"的函数。提前算好的文档 KV，搬进新上下文严格说是"错的"。论文里最形象的翻车现场：问"梅西世界杯比 C 罗多进几个球"，前面挂两段数据，硬拼缓存的结果是模型开始胡言乱语--两段数据之间的跨块注意力从来没被算过。

🔑 破局观察：偏差长在个别 token 身上
把文档"裸算"和"带前缀算"各来一遍对比：绝大多数 token（比如数字、专有名词）几乎不动，只有一小撮锚定词（"它""该塔""如前文所述"）面目全非。就像抽出一章单独翻译：99% 的句子不变，只有"如前文所述"要重译。
更妙的是这些敏感 token 当场就能认出来：请求到了，前几层把现算的和缓存的 KV 一比，逐层收窄锁定名单，后面几十层只算这一撮。

💰 效果
85% 直接复用 + 15% 重算：前缀差多少都能用（没有相似度门槛）、一段一段跳着拼也行、顺序随便换。TTFT 快 2.2-3.3 倍，吞吐 2.8-5 倍，精度和全量重算持平。

💡一句话总结
KV 缓存从"前缀匹配器"升级成了"乐高积木"，任意位置、任意段数、任意顺序，随便拼

AI推理KVCacheRAG大模型LLMvLLM