Prompt 缓存悬崖：一次系统提示词修改如何重置你的整个集群成本

一切都没坏。这正是让人困惑的地方。没有部署失败，没有延迟报警，错误率也没有上升。有人合并了一个只有一行的 PR，在系统提示词（system prompt）末尾添加了一句话——一个新工具的描述、一条政策提醒，或者是“今天的日期是”的页眉——结果第二天早上，推理账单就高出了三到五倍。流量平稳，模型没变，代码也完全按照预期运行。

改变的是那一行代码放错了位置，导致你集群中所有的缓存前缀（cached prefix）瞬间失效。你的缓存命中率在一个请求周期内从 90% 降到了零，原本几乎免费的每个 token 开始按全价计费。这就是 Prompt 缓存悬崖（prompt-cache cliff），它是生产环境下 LLM 系统中最昂贵的故障模式，而且没人会对它进行威胁建模，因为它看起来根本不像故障。

它之所以难以察觉，是因为 Prompt 缓存是一种你从未显式开启的折扣。当供应商识别出重复的前缀时，会自动应用它，所以你的系统便宜地运行了几个月，而你从未在意过。接着，折扣悄无声息地消失了，“新”价格其实只是没有了你甚至不知道自己在依赖的折扣后的原价。如果你没有针对缓存命中率设置报警，你收到的第一个信号就是发票——而那时，你已经按悬崖价支付了一个完整的计费周期。

缓存即前缀匹配，这就是全部逻辑

每个主流供应商的 Prompt 缓存底层工作原理都一样：它是对你请求中渲染后的字节进行的精确前缀匹配。模型逐个 token 地处理你的提示词，而最昂贵的部分——构建键值（KV）注意状态——如果新请求的开头与已经计算过的内容字节完全一致，就可以复用。供应商会将你的提示词哈希处理到特定的检查点，如果命中，就加载预先计算好的状态，而不是重新计算。

结论显而易见：**前缀中任何位置的任何变动都会使之后的所有内容失效。**失效的不只是改变的那个 token，而是它下游的所有内容。缓存键（cache key）是根据每个检查点之前的精确字节生成的，因此在位置 N 处的一个字节差异就会使位置 ≥ N 的所有检查点失效。一个尾随空格、一个重新排序的 JSON 键、一个重新格式化的日期，或者系统提示词中多出的一句话：所有这些都会导致后续前缀的彻底失效。

这就是为什么提示词的顺序是一个成本决策，而不仅仅是风格问题。供应商按固定顺序渲染请求——在 Anthropic 上，顺序是工具（tools）、系统提示词（system prompt），然后是消息（messages）。你放在前面的任何内容都排在其他所有内容之前。插入到系统提示词页眉的时间戳不仅自身无法被缓存，还会导致其后的整个系统提示词和每个工具定义都无法缓存，因为它们现在位于一个随每个请求变化的值的下游。

由于这个原因，“不断增长的系统提示词”和 Prompt 缓存正处于冲突之中。系统提示词在不断增长。每一次事故都会产生一条新的“永远记住……”行，每一个功能都会增加一个工具，每一个边缘案例都会增加一条告警。这些修改都位于前缀的前部。你构建的稳定前缀越大，你押注在上面的筹码就越多——这意味着触碰它的波及范围（blast radius）随着时间的推移而扩大，而不是缩小。

写入的经济学：为什么悬崖如此致命

要理解为什么失效不仅是麻烦，而且极其昂贵，你必须查看价格结构。供应商对输入 token 收取三种不同的费率：

• 缓存读取（Cache reads） —— 从现有缓存项中提供的 token。在 Anthropic 上，其成本约为基础输入费率的 0.1 倍，即 9 折优惠。对于 Claude Opus 4.8，每百万 token 的读取费用为 0.50 美元，而未缓存时为 5.00 美元。
• 缓存写入（Cache writes） —— 缓存未命中时写入缓存的 token。在 Anthropic 上，这些费用比基础输入更高：默认 5 分钟 TTL 为 1.25 倍，1 小时 TTL 为 2 倍。
• 未缓存输入（Uncached input） —— 全价，不涉及缓存。

加载中…