提示缓存到底值多少钱

提示缓存是少见的那种优化：接入成本几乎为零，收益持续产生。如果你提示里很大一块每次调用都完全相同——对多数生产应用来说确实如此——那你现在就是在按全价，一天几千次地重复发送同一段内容。

这是成本总指南里的一个杠杆，单独拎出来是因为细节直接决定你能不能拿到这个折扣。

它是怎么计费的

两家厂商的规律一致：一次缓存读取大约按正常输入 token 的十分之一定价。corouter 以同样的比例在我们的奥莱价上承兑这些缓存倍率，所以折扣是叠加在更低的基础价之上的，而不是被抹平。

什么样的提示能命中

缓存作用在前缀上。被缓存的那部分必须位于提示开头、与上一次调用逐字节一致、并且长度达到厂商的最小门槛。由此引出三个后果，也正是多数实现丢掉折扣的地方：

• 顺序很重要。稳定内容在前——系统提示、工具定义、少样本示例、政策文档——然后才是可变的用户输入。系统提示顶部放一个时间戳，就会让每次调用的整个缓存全部失效。
• 逐字节一致就是逐字节一致。JSON 键顺序变了、空白字符变了、前缀里插了个用户名，都算未命中。
• 缓存会过期。它是为短窗口内的重复流量设计的，不是存储。一小时被调两次的路由，拿不到一秒被调两次那样的收益。

它值多少

取一个每月 5000 万输入 token 的负载，其中每条提示有 80% 是稳定前缀。不做缓存时，5000 万全按输入全价；做了缓存后，1000 万按全价、4000 万按缓存读取价。由于缓存读取大约是输入价的十分之一，账单的输入侧会降到原来的四分之一多一点。

这个幅度比多数换模型的决策都大，而且与换模型不同，它完全不改变你拿到的输出。把你自己的比例放进成本计算器跑一下——它把缓存输入单列一个字段，正是为了这件事。

为缓存而组织提示

1. 把所有固定指令、工具 schema 和示例放进顶部一个连续的块里，并且永远不要往里做字符串插值。
2. 把一切动态内容——用户消息、检索到的文档、当前时间——严格放在这个块之下。
3. 确定性地序列化。固定 JSON 键顺序，让相同内容产出相同字节。
4. 用 API 返回的用量数字验证。如果缓存 token 计数一直是零，说明前缀没匹配上；提示顶部会变的话，再怎么配置也救不回来。

然后给其余部分重新定价

缓存削减的是重复输入的花费，其余的杠杆负责削减别的：选对模型档位、直接对照两个候选，以及先度量再优化。我们承运的每一款模型的当前费率都在价格页上。