最近账单上多了一条提示Prompt Cache Reads 的单价降了 50%。看到这条消息我第一反应不是开心而是想搞清楚这笔账到底怎么算。因为只要做过 API 集成的人都知道缓存读取降价不等于总成本降价它只影响输入 token 里“命中缓存的那部分”和普通输入、缓存创建、输出 token 都没关系。如果上来就把整份账单打个五折核算出来的“真实节省”基本就是自嗨。这篇文章就是来帮你把这笔账算明白的。我会把 Prompt Cache 的计价逻辑拆开给出一个可以直接套用的成本核算方法再用一个模拟客服项目的例子全程演算一遍。适合正在做批量调用、跑 Agent 应用、维护智能客服/知识库问答的开发者也适合刚入门、被账单搞晕的同学。1. 从“降价50%”说起Prompt Cache Reads 到底改了什么1.1 一次请求里的钱其实分四个口袋很多同学理解的 API 计费就是“输入多少钱、输出多少钱”但引入缓存机制后情况变成了四个口袋普通输入、缓存创建、缓存读取、输出。普通输入好理解就是你每次提交给模型的全新内容。缓存创建Cache Write是当系统识别到一段较长且稳定的前缀、决定把它存进缓存时产生的一次写入成本。缓存读取Cache Read则是后续请求命中这段缓存时按更低价格读取缓存内容的费用。输出就是模型生成的 token价格通常最贵。这里有个很容易忽略的点缓存并不是“免费的存储”。它需要维护前缀索引、存储中间状态所以平台才会把缓存读取单独列出来收费。只不过相比每次把前缀重新彻底计算一遍读取缓存的成本低得多所以单价才低于普通输入。1.2 明明开了缓存为什么命中率上不去我用一个生活类比解释缓存命中做饭时第一次要看完整食谱把所有原料和步骤读一遍第二次做同一道菜你只需要瞄一眼“土豆炖牛肉”就知道下一步该干嘛。API 的 Prompt Cache 就是这个道理——请求前缀完全一致时服务端直接复用之前的计算结果。但这里有个魔鬼细节前缀必须逐字节一致。只要你在系统提示词前面加了个时间戳、随机数、用户ID整条前缀就“脏”了缓存直接失效退回普通输入价格。我见过某个项目团队辛辛苦苦把系统提示词写到 6000 token结果每次请求都在开头动态拼接了一个 trace_id导致命中率长期低于 5%。这属于典型的“缓存设计事故”不是机制不好用是用法错了。表格列一下四类计费的相对倍数示意价格真实数值以官方价格页为准计费类型相对单价示意说明普通输入1x未命中缓存的新增输入缓存创建1.25x首次写入缓存时收取缓存读取0.1x降价前命中后读取缓存内容缓存读取0.05x降价后本次降价后的新单价输出3x模型生成内容的价格从表里能看出缓存读取原本就是“最便宜”的计费项。它降价 50%意味着原本就便宜的部分现在更便宜了但普通输入、缓存创建、输出这三个口袋纹丝不动。2. 这笔降价到底降在谁的账单上2.1 先算一笔“看起来很美”的账假设你每天跑 1 万次请求每条请求的系统提示词有 12000 token用户输入 3000 token输出 2000 token。如果没有缓存普通输入就是 12000 3000 15000 token按 1x 单价算。有了缓存且全部命中12000 token 的前缀走缓存读取3000 token 的用户输入走普通输入输出不变。降价前1 万次请求的缓存读取 token 数是 12000 x 10000 1.2 亿 token。按 0.1x 单价计费相当于 1200 万“普通输入等价值”降价后同样的读取量按 0.05x 计费等价 600 万普通输入。看着确实省了挺多。但这只是理想情况。这个例子里如果有一条请求前缀变了那它的 12000 token 就会从缓存读取直接跳回普通输入单价直接变 1x。一个 0.05x 和一个 1x 之间差了 20 倍。**所谓降价 50%省的钱可能被一次缓存未命中完全吞掉。**这也是我一直强调“先盘命中率再算节省”的原因。2.2 哪些业务能吃到红利哪些吃不到并不是所有应用都能从这次降价里受益。我总结了三种典型业务形态能吃到大头的系统提示词长、内容稳定、调用量大的应用。典型代表是智能客服、代码助手、知识库问答。这类应用的前缀可能有几千甚至上万 token而且所有请求共享同一套前缀命中率天然高。能吃到一点但有限的多轮对话应用。对话历史会不断变长但前几轮的内容相对稳定系统提示词也能命中缓存只是每次新增的对话轮次会产生新的普通输入和缓存创建费用。基本吃不到的以短输入、一次性任务为主的调用。比如单次翻译、单次改写。请求和请求之间几乎没有公共前缀缓存建了也用不上甚至可能因为缓存创建费用反而更贵。如果你的业务属于第三种这次降价对你的意义就是“看着别人省钱”不用硬凑缓存。3. 怎么核算你项目里的真实节省手把手实操3.1 第一步先把用量数据拆出来核算真实节省的前提是拿到拆细的 token 使用量。不要只看账单总额要去接口返回的 usage 字段里拉明细。大多数模型 API 会在响应里返回这几类字段input_tokens本次请求的普通输入 token 数cache_read_input_tokens本次请求命中的缓存读取 token 数cache_creation_input_tokens本次请求写入缓存的 token 数output_tokens输出 token 数如果你用的是网关或代理可以把这些字段透传到日志系统。如果你只是自己在脚本里调用建议在每次响应后把 usage 打点到本地文件或时序数据库后面做成本分析全靠这份数据。我自己的习惯是维护一张日表字段包括时间、请求 ID、普通输入、缓存创建、缓存读取、输出、命中率。每天跑一个汇总脚本产出当日单价和总成本。3.2 第二步套成本公式拿到明细后按下面的公式计算单次请求成本单次请求成本 (普通输入 token / 1M) x 普通输入单价 (缓存创建 token / 1M) x 缓存创建单价 (缓存读取 token / 1M) x 缓存读取单价 (输出 token / 1M) x 输出单价所有 token 数先除以 100 万因为价格页一般按“每百万 token”标价。然后把四个部分相加。这里要注意单位统一。有的平台价格按“千 token”标有的是“百万 token”写脚本之前先换算一致不然算出来的结果能差三个数量级。在降价前后各算一次两次总成本的差额才是这次降价带来的真实节省。3.3 第三步一个客服项目的完整演算我用一个更贴近实战的例子来说明。某模拟客服项目每天调用 1 万次每条请求的用量结构如下系统提示词8000 token内容固定基本都能命中缓存用户问题150 token属于普通输入模型回复500 token属于输出每天第一批 1000 次请求需要写缓存其余 9000 次直接命中读取价格按前面的示意倍数来算普通输入 1 元/百万 token缓存创建 1.25 元/百万缓存读取降价前 0.1 元/百万、降价后 0.05 元/百万输出 3 元/百万。先算降价前的日成本缓存创建1000 次 x 8000 token 800 万 token费用 800 x 1.25 10 元缓存读取9000 次 x 8000 token 7200 万 token费用 7200 x 0.1 7.2 元普通输入1 万次 x 150 token 150 万 token费用 150 x 1 1.5 元输出1 万次 x 500 token 500 万 token费用 500 x 3 15 元日均总成本 10 7.2 1.5 15 33.7 元。再算降价后的日成本变化的只有缓存读取单价缓存读取7200 x 0.05 3.6 元其余不变降价后日均总成本 10 3.6 1.5 15 30.1 元。真实节省 33.7 - 30.1 3.6 元/天占总成本的 10.7% 左右而不是“总价减半”。如果这个项目把系统提示词加长到 2 万 token命中率不变缓存读取 token 变成 1.8 亿那降价前读取费用 18 元降价后 9 元节省比例会明显提升。**系统提示词越长、命中率越高、调用量越大吃到这次降价的幅度就越大。**这也是为什么我一直建议做成本核算时不要看官方示例百分比要看自己的流量结构。4. 省钱之外这些成本角落容易被忽略4.1 缓存创建费用一个隐藏的“入场费”很多人只盯着缓存读取单价忽略了缓存创建。从计价表能看到缓存创建的单价甚至比普通输入还高它是 1.25x。这意味着每次重建缓存你是在用更高的价格买一次“后续读取折扣”。如果你的业务请求间隔太长超过缓存 TTL那每次请求都会变成“先花 1.25x 创建再花 0.05x 读取”的两次收费比完全不缓存还要贵。缓存创建费用才是决定“到底要不要开缓存”的核心变量。这次降价没有动缓存创建价格所以这个权衡逻辑没有根本变化。4.2 动态前缀污染比你想的更常见前缀污染是最不值得的浪费。本来一段 8000 token 的提示词可以做成缓存结果因为拼接了一个毫秒时间戳整段作废。系统提示词变成每次“重新创建”既被收了 1.25x 的创建费又享受不到 0.05x 的读取价。排查的方法很简单挑一小段时间全量打印请求的 system prompt对比前几十个字符是否有变化。如果有把动态内容移动到用户输入部分或者放到前缀后面保证公共前缀稳定。还要注意另一种污染模型接口会自动在 system prompt 后追加工具定义或历史消息如果你在代码里手动再插一段内容顺序一变整条前缀就不同了。4.3 延迟收益也是收益只是不体现在账单上这次降价对缓存命中的请求还有一个隐藏收益首 token 时间会明显下降。因为命中缓存的请求省略了重复前缀的计算过程服务端可以直接进入生成阶段。我实测下来长前缀请求未命中时首 token 延迟可能要到 2 到 3 秒命中后能降到 500 毫秒以下。对用户而言这是实打实的体验提升。如果做的是实时对话类产品这个收益甚至比省下的钱更重要。它没直接体现在账单里但体现在留存和转化里。4.4 降价之后缓存命中率没提升先别急着骂平台如果你的项目启动了 Prompt Cache、也确实看到了这次降价但账单一算“怎么才省这么点”多半是命中率没做到位。我建议做一个最低限度的成本监控每日缓存命中率cache_read_input_tokens 除以总输入 token缓存读 token 占比单位请求成本单价 x 总 token 数 / 请求数三个指标每周看一次趋势。命中率长期低于 50% 的优先查前缀稳定性而不是把精力花在找更便宜的价格上。5. 常见核算误区和排查清单5.1 四个高频误区我在群里看别人晒成本核算时常见这几种翻车姿势**误区一把输入 token 总额打五折。**输入 token 里包含大量普通输入和缓存创建这两部分不在降价范围。只有 cache_read_input_tokens 打五折。**误区二忘记缓存写入的存在。**有人把“缓存创建 token”也当成缓存读取 token 来算还以为是打五折结果实际费用比预期高。**误区三拿官方示例场景套自己的业务。**官方演示往往用超长、超高命中的极端场景抬头看一眼“最多可节省 90%”落到自己项目上可能只有 3%。要用自己的日志数据算。**误区四忽略 TTL。**缓存不是永久的。业务请求频率低、间隔超过有效期时命中率会断崖式下降理论计算就会失真。5.2 问题排查速查表症状可能原因排查方式命中率低前缀包含动态内容对比多请求的 system prompt 前段命中率正常但没省钱缓存创建费用占比高检查 cache_creation 与 cache_read 比例总费用反而上升请求间隔超过 TTL统计单用户请求间隔分布缓存读取量异常大把多轮历史全部塞进前缀检查请求体的实际前缀长度延迟没改善命中发生在无关紧要的尾部对比缓存 token 与首 token 延迟5.3 我建议的落地动作如果你在团队里负责这块成本建议做一个小工具解析每次调用的 usage 对象按天汇总输出成报表再自动对比降价前后的成本曲线。脚本不复杂关键是持续记录数据。我实际踩过几次坑之后现在的固定步骤是先看一周的缓存命中率再算缓存创建与缓读比例最后才套价格公式。没有前两步第三步算得再准也是空中楼阁。另外给系统提示词做版本管理也很重要每次改动提示词都意味着缓存重建改动越频繁缓存收益越低。尽量把稳定的公共指令和频繁调整的业务规则拆成两段公共段优先保证不变。这次降价对长前缀、高命中场景确实是实打实的利好但它的价值只有在“算清楚自己账单结构”的前提下才成立。我个人经验是与其花时间到处找哪里还能打折不如先把系统提示词做稳、把前缀结构理清让缓存命中率自然地提升上去。等命中率稳定在高位再回头看这 50% 的降价你才会真正感觉到“钱花在刀刃上”的快感。如果你也正在做类似的成本核算不妨按上面的方法跑一周数据看看你的真实节省是多少欢迎回来分享你的账单结构。