12 小时缓存值不值？先算写入费，再谈每次推理多少钱

缓存命中率漂亮，不代表账单一定更小。前缀写入本身可能收费，短时间内没有复用几次，缓存反而会多花钱。

OpenAI 的 2026 年 10 月 20 日日志记录了 12 小时缓存选项。它适合重新检查重复上下文的使用方式，但不能据此得出“所有模型缓存都打一折”或“每次推理能降到一分钱”。

先把输入账拆开

图中“完整成本”只指这四类 token 的小计，搜索、硬件和人工不在其中。

设某段共享前缀的普通输入成本为 P，首次缓存写入倍率为 w，后续读取倍率为 r，期间共用 n 次。在“一次写入，之后全部命中”的简化条件下：

• 不缓存：nP。
• 使用缓存：wP + (n−1)rP。
• 缓存划算的条件：n > (w−r)/(1−r)，且 r 小于 1。

这个公式不含输出费用，因为比较双方的输出量暂时相同。若缓存策略改变了请求内容或回答质量，就得重新比较完整任务。

用假设数据检查公式，别假装这是账单

下面的 P=1 是一个成本单位，不是一元钱，也不是某个账号实际费率。倍率只用于演示计算；应用到真实接口时，应从对应模型当前价格表读取。

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(f"n={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 和质量损失尚未纳入示例。价格与可用性需在实际接入当天再次核对。