上下文压缩后 KV Cache 是否失效？

核心回答

**把历史对话替换成摘要后，原 KV Cache 不能直接整份沿用；但压缩位置之前、计算条件不变的公共前缀，仍可能复用。**不是“只要压缩就全部失效”，也不是“意思没变，缓存就还能用”。

普通因果 Transformer 的 KV Cache，保存的是各层历史 Token 已计算出的 K/V 中间状态。这些状态与前面的 Token、位置和模型配置有关。摘要改变了输入序列，替换位置及其后面的状态通常需要重新计算；即使近期对话的文字原样保留，它们看到的前文变了，也不能简单搬用旧缓存。

工程上可把稳定的系统规则和工具定义放在前部，把会变化的摘要及近期交互放在后部，尽量保住公共前缀。实际命中还取决于引擎的分块、缓存是否仍在、服务路由及模型配置。压缩后应同时看缓存命中 Token、输入长度、首 Token 延迟和任务质量，不能只追求命中率。

为什么保留原文，也不一定保得住后面的 KV

以普通多层因果注意力为例，追加新 Token 不会改变过去位置已经看到的前文，所以可以复用历史 K/V；但修改已有前文是另一回事。

某个位置在较深层的输入表示，已经包含前面多次注意力计算得到的信息。即使这个位置的 Token 字面相同，前文被摘要替换后，其隐藏状态及后续层的 K/V 仍可能改变；删除一段内容还可能改变后续位置编号。只修正位置编码，也不能普遍恢复原先依赖旧前文的深层状态。

因此，普通精确前缀缓存要求的是实际模型输入及计算条件兼容，不是两段文本在人看来语义接近。缓存保存的也不是模型参数，更不是上一次回答的文字。

哪一段可以复用：看第一个变化发生在哪里

把两次模型输入简写为：

压缩前：P（稳定规则） | H（较早历史） | R（近期交互）
压缩后：P（稳定规则） | S（历史摘要） | R（近期交互）

如果 P 的实际 Token、位置和相关配置都没变，因果注意力使它不受后续 H 或 S 的影响，因此 P 对应的缓存具备复用条件。到了 H 被替换成 S 的位置，两次输入开始不同；后面的 R 虽然文字相同，也不再具有相同的完整前缀，普通前缀缓存通常要重新处理 S 和 R。

这里有三种容易混淆的情况：

• 只在末尾追加新内容：旧输入仍是新输入的前缀，已有状态通常可以继续使用。
• 从末尾截掉一部分：保留下来的完整前缀在计算上可以沿用；具体缓存接口是否支持裁剪、位置如何维护，要按引擎处理。
• 删除或改写中间内容、重排工具描述、替换系统规则：从第一个变化处起，不能照搬后续旧状态。

“这次不能复用”不一定表示物理缓存已被立即删除。服务端可能仍为其他请求保留旧前缀，只是它不匹配这次输入。跨请求前缀缓存还可能只复用完整块，实际命中长度不一定正好到文本变化的边界。

压缩与缓存怎样配合

稳定部分保持稳定。 系统规则、确实固定的工具描述可以置于前部，避免每轮在开头插入时间戳、随机 ID 或反复重排。工具集合若随任务变化，就按实际需求更新，不必为了命中保留大量无关工具。

摘要按任务阶段更新。 可以在完成一个阶段、较早交互已不再需要直接参与下一步时，再生成摘要。保留目标、硬约束、未完成事项和证据位置；近期仍要继续的工具交互保持完整。摘要变化后，接受相应后缀重新计算，而不是把摘要写得“看起来相同”就认定缓存可用。

由引擎匹配缓存。 自建推理服务按实际 Token 和必要配置识别前缀。以 vLLM 的前缀缓存为例，块标识关联当前块内容与之前的前缀，不能因为两个后缀块文字相同，就绕过前文直接复用。模型权重或适配器、多模态输入等也可能影响缓存身份。

看整个任务的收益。 压缩会增加一次摘要调用，并可能产生一次新的预填充；后续调用则可以使用更短的输入。应比较完整任务的总耗时、总调用成本和结果质量，同时检查缓存命中情况。压缩后命中 Token 减少，并不能单独说明方案变差；继续携带大量无用历史，也不能因为命中率高就算更好。

常见追问

摘要放在固定位置，能保证命中吗？

不能。固定位置只是让边界更稳定，摘要的实际 Token 仍可能变化。公共前缀还要满足服务端的缓存粒度、保留时间、模型与路由等条件。云服务应以实际返回的缓存使用统计为准，不把相同请求视为必然命中。

语义缓存可以解决这个问题吗？

应用层语义缓存通常按相似问题复用答案或结果，KV Cache 复用的是模型中间状态，两者的正确性条件不同。问题语义相似不代表各层 K/V 可互换，语义缓存也不能让改写后的输入自动继续使用旧状态。

KV Cache 压缩和对话摘要是一回事吗？

不是。对话摘要改写的是发送给模型的文本序列；KV 量化、选择性保留或淘汰等方法则直接处理模型缓存，可能使用专门算法并引入精度或注意力范围的变化。它们的效果和适用架构要单独验证，不能把普通文本摘要说成无损压缩 K/V。

参考资料