架构层：KV Cache 的注意事项
在商业化产品的降本增效中，KV Cache 是最被低估的技术点之一。命中缓存和没命中，最高差 90% 的成本——但里面有几个隐形的坑，不说你可能不知道。
大模型的本质是「Token 推 Token」：它不关心你问的是什么问题，只关心前文是什么。这意味着——如果两次请求的前缀相同，模型其实在重复计算同样的内容。KV Cache 就是把算过的中间结果存下来，下次遇到相同前缀直接复用：用廉价的存储换昂贵的实时计算，「空间换时间」。
举个例子：你问「2 + 4 = ?」，它算出 6。再问「3 + 4 = ?」，前缀变了，只能从头算。但如果问的是「2 + 4 + 1 = ?」——前缀「2 + 4」没变，模型直接从 6 开始算出 7。只要前缀不变，缓存就能命中。DeepSeek、Qwen、智谱都支持这个能力（回看第 3 节报价表：缓存价只有标准价的 1/5），这是作者挑选大模型 API 时必看的一项。
上一次请求已经缓存了完整前缀。点下面三种「这一次的请求」，看命中（绿）和重算（红）的部分。
看起来省 Token，实际是大坑
有些产品为了极致省钱，根据用户意图动态挂载工具：问天气挂 WeatherTool，闲聊就不挂。问题出在大模型后端的模板逻辑——以 Qwen 3 为例，只要请求带了 tools 参数，服务器就会在 System Prompt 后面插入一段工具说明；如果你没写 System Prompt，模板还会自动帮你加一个再插。工具状态一变（从有到无、从 A 换成 B），Prompt 头部前缀就变了，之前缓存的几十万 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 模型。