缓存命中率漂亮不代表账单一定更小。前缀写入本身可能收费短时间内没有复用几次缓存反而会多花钱。OpenAI 的 2026 年 10 月 20 日日志记录了 12 小时缓存选项。它适合重新检查重复上下文的使用方式但不能据此得出“所有模型缓存都打一折”或“每次推理能降到一分钱”。先把输入账拆开图中“完整成本”只指这四类 token 的小计搜索、硬件和人工不在其中。设某段共享前缀的普通输入成本为 P首次缓存写入倍率为 w后续读取倍率为 r期间共用 n 次。在“一次写入之后全部命中”的简化条件下不缓存nP。使用缓存wP (n−1)rP。缓存划算的条件n (w−r)/(1−r)且 r 小于 1。这个公式不含输出费用因为比较双方的输出量暂时相同。若缓存策略改变了请求内容或回答质量就得重新比较完整任务。用假设数据检查公式别假装这是账单下面的 P1 是一个成本单位不是一元钱也不是某个账号实际费率。倍率只用于演示计算应用到真实接口时应从对应模型当前价格表读取。from decimal import Decimal as D def cost(n, write, read): if n 1 or write 0 or not (D(0) read D(1)): raise ValueError(invalid inputs) return write D(n - 1) * read for n in (1, 2, 3, 10): cached cost(n, D(2.5), D(0.1)) ordinary D(n) print(fn{n:2} cached{cached} ordinary{ordinary} cheaper{cached ordinary}) assert cost(2, D(2.5), D(0.1)) D(2) assert cost(3, D(2.5), D(0.1)) D(3)保存为 cache_cost.py执行 python3 cache_cost.py。可以看到在这组假设下两次使用还不划算三次才跨过盈亏线。这是算术结果不是模型效果测试。实际系统还会遇到前缀变化、过期重写、不同请求落到不同机器以及最小可缓存长度。应从 usage 记录分别取普通输入、写入和读取量不要用“命中的请求占比”直接替代 token 命中比例。长寿命的价值在复用间隔里缓存文档区分寿命、写入与读取计费。比较长短寿命时不能只看谁写得便宜相隔数小时的工作是否会使短寿命缓存反复重建同样影响总成本。我会先看一周脱敏请求哪些前缀相同复用间隔多长工具目录改动多频繁。确实稳定、跨会话重复的材料才值得试长寿命用户订单和实时库存不该为了缓存而强行冻结。别把别家的折扣规则乘进来阿里云价格文档的千问 Max 栏明确说明Batch 与上下文缓存不能同时生效。这条规则不能推广到所有供应商但足以提醒我们半价乘一折不是一条通用结算公式。本地只验证 Decimal 成本公式没有调用付费模型。硬件、运维、人工、输出 token 和质量损失尚未纳入示例。价格与可用性需在实际接入当天再次核对。
