Token 降本增效 · 11 / 13 架构层：KV Cache 的注意事项 在商业化产品的降本增效中，KV Cache 是最被低估的技术点之一。命中缓存和没命中，最高差 90% 的成本——但里面有几个隐形的坑，不说你可能不知道。 前缀匹配 空间换时间 tools 陷阱 章节缓存 一句话速览 前缀匹配最高省 90%；动态切换工具为什么把缓存全打穿，滑动窗口 vs 章节缓存 什么是 KV Cache：前缀匹配 大模型的本质是「Token 推 Token」：它不关心你问的是什么问题，只关心前文是什么。这意味着—— 如果两次请求的前缀相同，模型其实在重复计算同样的内容 。KV Cache 就是把算过的中间结果存下来，下次遇到相同前缀直接复用：用廉价的存储换昂贵的实时计算，「空间换时间」。 举个例子：你问「2 + 4 = ?」，它算出 6。再问「3 + 4 = ?」，前缀变了，只能从头算。但如果问的是「2 + 4 + 1 = ?」——前缀「2 + 4」没变，模型直接从 6 开始算出 7。 只要前缀不变，缓存就能命中。 DeepSeek、Qwen、智谱都支持这个能力（回看第 3 节报价表：缓存价只有标准价的 1/5），这是作者挑选大模型 API 时必看的一项。

交互演示 · 哪些 Token 命中了缓存 上一次请求已经缓存了完整前缀。点下面三种「这一次的请求」，看命中（绿）和重算（红）的部分。

上次请求（已缓存） 这次请求

坑一 · 用 tools 参数，就别动态切换工具

看起来省 Token，实际是大坑 有些产品为了极致省钱，根据用户意图动态挂载工具：问天气挂 WeatherTool，闲聊就不挂。问题出在大模型后端的模板逻辑——以 Qwen 3 为例， 只要请求带了 tools 参数，服务器就会在 System Prompt 后面插入一段工具说明 ；如果你没写 System Prompt，模板还会自动帮你加一个再插。工具状态一变（从有到无、从 A 换成 B）， Prompt 头部前缀就变了，之前缓存的几十万 Token 瞬间灰飞烟灭 。

切换 tools 参数的瞬间：已缓存的 200k Token 全部失效，整段重算。（图：作者分享原稿）

推荐操作： System Prompt 保持不变 + 不用 tools 字段 ；或者宁可浪费点 Token，把全量工具定义一直挂着，也要保住缓存命中。System Prompt 的稳定性，比省那点 Token 重要得多。

坑二 · 慎用滑动窗口，尽量采用归纳形式 多轮对话和长文本场景，很多产品用「滑动窗口」处理超长历史——只保留最近 N 轮，旧的直接丢。这是偷懒，而且会出问题。滑动窗口的本质是 FIFO 队列： 每滚动一次，前缀就变一次，缓存永远命不中。 作者的产品「伴写」（用前文生成后文）早期就是固定 800 字滚动窗口，又贵又容易「失忆」。后来改成 章节缓存 ：AI 生成时识别到话题转换（场景切换、新章节）就插入分隔标记，系统据此判断哪些内容压缩成摘要、哪些完整保留——与其让 AI 自己有损压缩，不如让前缀尽量稳定，命中缓存。

指标 旧方案（滑动窗口） 新方案（章节缓存） KV Cache 命中率 ~10%（前缀总在变） ~80%（前缀稳定） 逻辑连贯性 差（经常失忆） 好（摘要 + 完整章节） Token 成本 高（重复计算） 低（缓存复用）

上下文管理的四个设计决策

问题 设计决策 哪些信息必须「恒久保留」？ 放入 Stable 区 ，作为缓存前缀 哪些信息可以「压缩存档」？ 用 摘要替代原文 ，控制窗口大小 哪些信息需要「按需加载」？ 按 章节 / 话题切分 ，动态挂载 如何识别「可压缩边界」？ 设计 分隔符机制 ，让 AI 标记话题转换点

不要把上下文窗口当垃圾桶，也不要用简单粗暴的滑动窗口。上下文管理，本质上是在做 信息的分层存储与按需调度 ——这才是在质量、成本、速度之间找平衡的正确姿势。

本节要点

✓ 前缀不变，缓存命中，最高省 90%。 选 API 时「支不支持上下文缓存」是必看项。 ✓ 别动态切换 tools： 工具状态一变，模板重写 System Prompt，缓存全打穿。宁可全量挂着。 ✓ 滑动窗口是缓存杀手： 用「Stable 前缀 + 摘要存档 + 章节挂载」代替，命中率 10% → 80%。

内容来源： 整理自作者团队内部分享《AI Token 降本增效策略分享》实战篇「03｜架构层」。DeepSeek 的硬盘缓存定价见 官方公告 ；「Token 推 Token」的原理复习 大模型原理 · Base 模型 。