我们盯着账单看了一周，才真正搞懂 token 缓存

这篇不讲概念，讲一次实测。我们拿一本 50 万字的修仙文，用 DeepSeek 连续续写 60 轮，把每一轮的账单字段抄下来。 起因很不光彩：有用户反馈「连续两次续写，第二次输入缓存突然骤减」，我们排查时被迫把缓存机制从头到尾搞了一遍。 排查完的结论值得单独写一篇，因为它改变了我们对「AI 到底贵在哪」的理解。

先看账单

第 3 轮续写，输入 21,400 token，其中缓存命中 18,900。第 20 轮，输入 33,700，命中 31,200。 第 41 轮，输入 47,800，命中 44,600——命中率 93%。DeepSeek 对命中部分收的钱大约是未命中的十分之一 （2024 年 8 月它率先把这层缓存做成全平台默认，行业才跟着卷起来）。 换算下来，第 41 轮那次请求，输入侧的实际花费不到全价的 15%。

为什么命中率这么高？因为续写这个场景，每一轮发给模型的东西几乎都是上一轮的原样重复：系统提示没变， 书的设定档案没变，已写好的章节没变。真正的新内容只有你那句「接下来写主角进城」和上一轮刚生成的段落。 模型处理输入时会为每个 token 算一组中间状态（就是 KV Cache），这个状态只依赖前文——所以供应商把它存下来， 下次遇到相同开头直接取用，跳过计算，也就敢只收零头。

然后我们把它搞坏了

实测中段出了个事故。某一版构建里，我们往系统提示加了一行「当前时间：21:47」，方便模型感知时间。 当天的账单立刻变脸：命中率从 91% 掉到 0%，连续 30 多轮全价。原因现在看很蠢——缓存按前缀逐字匹配， 时间戳每分钟都在变，等于每一轮都亲手把前缀改掉了。改成只注入日期之后，第二天命中率回到 90% 以上。

类似的坑我们后来又踩过两个：重摇时把采样参数拼进提示词开头（前缀变了）；世界书条目按相关性动态排序 （每轮顺序不同，前缀又变了）。三次事故指向同一条纪律：稳定的内容放前面，会变的东西尽量放最后。 这条纪律没有任何供应商会替你执行，它完全是应用层的活。

四家的规则，抄作业版

细则在各家文档里：OpenAI、Anthropic、Gemini。Anthropic 那个「写入加收 25%」 容易被忽略：缓存写多读少的场景（比如每次都换一本书）可能反而变贵。这点我们还没做系统实测，先存疑。

这件事改变了一个老结论

过去省钱的标准建议是把上下文裁短，于是很多应用拼命压缩历史、砍设定。缓存出现后这笔账反过来了： 重复的长上下文很便宜，贵的是每轮变动的部分和输出。把完整角色卡和世界书常驻条目稳定塞进每轮请求， 第一轮付全价，之后一直走一折——比起「为省钱让角色失忆」，这是好得多的交换。

验证方法也简单，不用信任何人的说法（包括这篇）。供应商响应里都带缓存字段：DeepSeek 叫 prompt_cache_hit_tokens，OpenAI 叫 cached_tokens。Foreverse 的「API 请求记录」 把这些字段直接摆出来了，连续续写两次，第二次的命中数应该接近输入总量。如果一直是 0， 你的应用里就藏着一个我们当年那样的时间戳。