Prompt Cache 能省多少钱?原理、真实命中率与三个写法

很多用户第一次看账单都会问:为什么同样的模型,我的成本和别人差这么多?答案八成在 prompt cache(提示词缓存)。这篇讲清它的计费原理、真实世界的命中水平,以及怎么写提示词才能吃满折扣。

计费原理:缓存命中的输入按折扣价计

大模型 API 的输入计费分两种:首次处理的 token 按标准价;命中缓存的前缀部分按大幅折扣价(以 Claude 为例,缓存读取价是标准输入价的十分之一)。也就是说,你的会话前缀越稳定,重复部分越长,实际输入成本越低。

真实世界的命中率

从我们网关侧的观察看:Claude Code、AI Chat 这类会话式工具,由于每轮都携带系统提示与历史消息,健康会话的缓存命中比例普遍能到六成以上;而写法糟糕的集成——比如每次请求都往系统提示里塞时间戳——命中率可以直接归零,成本翻好几倍。

让命中率翻倍的三个写法

1. 把「不变的」放前面,「变化的」放后面。缓存按前缀匹配:系统提示、工具定义、few-shot 示例放最前;用户输入、检索结果放最后。前缀中间插一个动态字段,后面的缓存全部作废。
2. 别在提示里放会变的东西。时间戳、随机 ID、「今天是几号」这类内容是缓存杀手。真需要时间,放在消息末尾的用户轮里。
3. 会话要「续」不要「重开」。同一个任务的多轮交互保持在同一会话里累积;每轮都新起会话等于每轮都全价。

怎么验证自己吃到了折扣

控制台的用量明细里,每条请求都分开展示标准输入、缓存写入与缓存读取的 token 数。改完提示词组织后跑几轮,对比缓存读取占比的变化即可——优化是否生效,数据一眼可见。

缓存不是玄学,是前缀匹配。把提示词当「不可变前缀 + 可变后缀」来组织,账单会诚实地回报你。