缓存命中率为何影响模型账单?

聊到 AI 模型的账单，很多人第一反应是看单价：输入多少钱、输出多少钱，乘一下 token 量，成本不就出来了？但真正把 API 用起来之后才发现，账单上有一项不太起眼的费用，波动起来比想象中猛得多——缓存输入。它便宜得惊人，却也是账单失控最容易被忽略的源头。

先理解缓存是怎么回事。模型厂商为了降低重复计算的成本，会把常见的输入前缀存下来。同一个 prompt 反复用，命中了缓存，价格就按缓存输入算，往往只有正常输入价的十分之一甚至更低。比如 Qwen 系列里，缓存输入的折扣就能做到 90%。听起来是好事，对吧？问题在于，命中率是个很不稳定的变量。

有用户拿四款 AI 命令行工具跑同一个代码审查任务，结果某款模型在单次任务里就烧掉了 30 美元月度配额中的 23%。原因就是缓存命中不稳定，同样的输入反复计费，账单波动比预期大得多。这不是个别现象，社区里类似的抱怨不少。厂商给的标价都是理想状态下的数字，实际跑起来，缓存策略、请求格式的微小差异、并发方式，都会影响命中率，进而直接影响最终账单。

这里有个容易踩的认知误区：以为缓存是自动的、白送的。其实缓存命中率取决于你的使用模式。如果你的请求高度相似、前缀稳定，命中率就高，成本自然低；但如果每次请求的上下文都在变，或者工具内部对 prompt 做了动态拼接，缓存基本形同虚设，费用就按全额算。更要命的是，这种差异在采购评估阶段几乎看不出来，因为你拿到的报价单上不会写“缓存命中率可能只有 30%”。

对中小企业来说，这提醒了一件事：评估模型成本，不能只看标价，得把缓存命中率的不确定性当成一个独立变量。比较稳妥的做法是，按标价的 1.2 到 1.5 倍做预算缓冲，给波动留出空间。同时，在真正切换供应商之前，最好拿自己真实的任务负载跑一段时间，观察缓存命中的实际表现，而不是靠厂商给的理想数字做决策。

说到底，缓存定价本身是个好设计，它让高频重复任务的成本大幅下降。但它的收益不是自动到手的，取决于使用习惯和工具链的配合。下次看到某家模型缓存价格低得诱人时，不妨多问一句：我的使用方式，到底能命中多少次缓存？这个问题的答案，可能比单价更能决定月底账单的厚度。