1. 同一天两封降价邮件这不是巧合做AI应用开发的同行最近应该都有同感模型调用成本这件事已经从技术选型时顺手看一眼变成了每周都要盯的运营指标。尤其是当你的产品跑在千万级token量级上每百万token差几毛钱一个月下来就是几万块的真金白银。所以当Claude Opus 5.5和GPT-6 Sol/Luna在同一天宣布调价的时候我第一反应不是哦又降价了而是打开计费后台把过去三个月的账单拉出来重新算了一遍。这次调价的核心信息其实就几条Claude Opus 5.5下调了输入输出单价同时把**缓存读取cache read**的价格压到了一个相当激进的位置GPT-6的Sol和Luna两个档位也同步跟进Sol主打高吞吐推理Luna主打轻量低成本场景。两家选在同一天动手明眼人都看得出来模型价格战这次是真的正面开打了不再是隔空喊话式的我们更便宜而是直接改价目表。这篇文章不打算复述新闻稿那没意义。我想聊的是作为一个真正在跑生产环境的人这次降价对你意味着什么你的计费函数该怎么改缓存策略要不要重做以及那些藏在价目表小数点后面的坑。如果你正在做模型选型、成本优化或者单纯想知道自己的账单为什么下个月可能突然变便宜或者变贵这篇应该能帮到你。2. 拆开价目表这次降的到底是哪部分钱2.1 输入、输出、缓存三段计费的真实结构很多人看模型定价只看一个每百万token多少钱这是最容易踩坑的地方。实际上现在主流大模型的计费至少分三段输入tokeninput、输出tokenoutput、以及缓存读取tokencache read。有的还有缓存写入cache write单独计费。这三段的价格差异可以到十倍以上所以降价这两个字必须拆开看。以这次调价为例Claude Opus 5.5的调整重点明显在缓存读取上。为什么因为Opus系列一直是长上下文、复杂推理场景的主力这类场景的典型特征就是系统提示词system prompt特别长——可能几千甚至上万token的指令、few-shot示例、知识库片段。如果每次请求都重新计费这部分输入成本会非常吓人。缓存机制就是把这部分固定内容缓存起来后续请求只付缓存读取的钱通常比正常输入便宜一个数量级。GPT-6这边Sol和Luna的定位差异更明显。Sol面向的是需要高并发、高吞吐的推理任务Luna则是给那些对延迟和成本都敏感、但任务相对简单的场景准备的。两家同一天调价本质上是在抢同一批重度API用户。2.2 缓存读取为什么是这次的主角我拿一个真实场景算给你看。假设你做一个客服问答系统系统提示词加知识库上下文一共8000 token用户每次提问平均200 token模型输出平均500 token。一天1万次请求。不做缓存的情况下输入token (8000 200) × 10000 8200万token/天。做了缓存之后8000 token走缓存读取只有200 token走正常输入。假设正常输入价格是X缓存读取是0.1X那么输入成本从8200万×X降到8000×0.1 200×10000 1000万×X。直接砍掉将近88%的输入成本。这就是为什么这次降价把缓存读取作为重点。对于长系统提示词的应用来说缓存读取单价每降一点放大到生产量级就是巨大的数字。所以你在评估这次降价时第一件事不是看输入输出降了多少而是看你的缓存命中率有多高。命中率低的话再便宜的缓存价格也跟你没关系。2.3 Sol和Luna的分档逻辑别选错GPT-6把Sol和Luna分开定价这个设计思路值得说一下。Sol的定位是能力优先适合复杂推理、长链思考、代码生成这类任务Luna是成本优先适合分类、抽取、简单问答、格式化输出这类任务。两者的价差不是随便定的背后是模型规模、推理步数、显存占用的差异。我见过太多团队犯一个错误所有请求都走同一个模型。结果就是简单任务用了贵模型复杂任务又因为省钱用了便宜模型导致效果崩盘。正确的做法是按任务复杂度路由。这次降价之后Sol和Luna的价差可能进一步拉大路由的价值就更明显了。计费维度典型占比长提示词场景降价敏感度优化优先级缓存读取60%-80%极高最高正常输入10%-25%中中输出15%-30%中中缓存写入视策略而定低低这张表的意思是如果你的场景是长提示词那么缓存读取的价格变动对你的总成本影响最大优化优先级也最高。别把精力花在抠输出token上那是捡芝麻。3. 计费函数重写从能算到算得准3.1 一个能落地的计费函数长什么样很多团队的计费逻辑是拍脑袋写的上线之后发现账单和预估对不上差个百分之二三十是常事。问题出在计费函数没有把缓存、分档、阶梯这些因素考虑进去。我下面给一个结构清晰的计费函数你可以直接改成自己用的版本。def calculate_cost(usage, pricing): usage: dict, 包含 input_tokens, output_tokens, cache_read_tokens, cache_write_tokens pricing: dict, 各档位单价每百万token cost 0.0 cost usage.get(input_tokens, 0) / 1_000_000 * pricing[input] cost usage.get(output_tokens, 0) / 1_000_000 * pricing[output] cost usage.get(cache_read_tokens, 0) / 1_000_000 * pricing[cache_read] cost usage.get(cache_write_tokens, 0) / 1_000_000 * pricing[cache_write] return round(cost, 6)这个函数看起来简单但有几个关键点必须注意。第一单位换算。价目表通常写的是每百万token而API返回的usage是绝对token数除错一个数量级就是灾难。第二缓存写入和读取要分开。有些团队把两者混在一起算结果缓存写入那部分成本被严重低估。第三round的位数。单次请求成本可能小到0.000001如果你在聚合前就round误差会累积。建议单次不round聚合后再round。3.2 缓存命中率怎么统计别只看账单账单只告诉你花了多少钱不告诉你钱花得值不值。要优化你得知道缓存命中率。这个指标的定义是命中缓存的请求数 / 总请求数或者更精确地缓存读取token / (缓存读取token 正常输入token)。统计方法有两种。一种是从API返回的usage字段里直接读现在主流API都会返回cache_read_input_tokens这类字段。另一种是自己埋点在请求发出前记录是否命中了本地缓存。我建议两种都做因为API返回的是服务端认为命中的本地埋点能帮你发现你以为命中但实际没命中的情况。提示缓存命中率低于60%的话先别急着优化单价去查为什么没命中。常见原因是系统提示词里有动态内容比如时间戳、用户ID导致每次请求的缓存key都不一样。3.3 分档路由的成本模型如果你同时用Sol和Luna计费函数要支持按模型分档。我一般会做一个路由层根据任务类型决定走哪个模型然后分别累计成本。这样你能清楚看到如果全部走Luna能省多少和如果全部走Sol效果会好多少为决策提供依据。def route_and_cost(task, usage, pricing_table): model luna if task[complexity] low else sol pricing pricing_table[model] cost calculate_cost(usage, pricing) return {model: model, cost: cost}这个路由逻辑可以做得更细比如按输入长度、按是否需要多轮推理、按输出格式要求来分。核心原则是能用便宜模型解决的绝不走贵模型。但前提是你得有评估机制确认便宜模型的效果达标。4. 缓存策略重做省钱的真正战场4.1 缓存key的设计决定了你的命中率缓存能不能命中90%取决于缓存key怎么设计。我见过最离谱的写法是把整个请求体包括用户问题做hash当key那命中率基本为零因为每个用户问题都不一样。正确的做法是只把固定不变的部分纳入缓存key通常是系统提示词 工具定义 知识库版本号。具体来说缓存key应该包含系统提示词的hash、工具/函数定义的hash、知识库的版本标识。不应该包含用户问题、时间戳、请求ID、会话ID。如果你需要按用户做隔离那就在key里加用户ID但要接受命中率下降的代价。4.2 缓存写入的时机与成本权衡缓存不是免费的。第一次写入缓存要付缓存写入的钱通常比正常输入还贵一点。所以这里有个权衡如果某个系统提示词只用一次那缓存反而亏钱。只有当同一个提示词被复用足够多次缓存才划算。我一般会算一个盈亏平衡点缓存写入成本 / (正常输入单价 - 缓存读取单价) 需要复用的次数。假设写入是1.25X正常输入是X缓存读取是0.1X那么平衡点 1.25X / (X - 0.1X) ≈ 1.39次。也就是说同一个提示词用两次以上缓存就开始赚钱了。这个计算很简单但很多团队从来没算过。4.3 多轮对话里的缓存陷阱多轮对话是缓存最容易出问题的地方。因为对话历史是不断增长的如果你把整个对话历史都放进缓存key那每一轮key都不一样命中率极低。正确的做法是把对话历史分成两部分固定的系统提示词走缓存动态的对话历史走正常输入。还有一种做法是滚动缓存把前几轮对话也缓存起来只把最新一轮走正常输入。这个策略在长对话场景下能省不少钱但实现复杂度高需要你精确控制缓存的失效和更新。我的建议是先用简单策略只缓存系统提示词跑一段时间看数据再决定要不要上滚动缓存。注意缓存通常有TTL生存时间过期后需要重新写入。如果你的应用请求间隔很长比如超过缓存TTL那缓存基本没用。评估缓存收益时一定要把TTL考虑进去。5. 价格战背后的选型逻辑变化5.1 从选最强的到选最合适的价格战打起来之后模型选型的逻辑变了。以前大家倾向于选最强的那个反正差不了多少钱现在价差拉大选型变成了一个真正的优化问题。你需要同时考虑效果、延迟、成本、稳定性。这四个维度里成本这次被大幅拉低了权重但没到可以忽略的程度。我的经验是先按效果筛出一批够用的模型再在这批里按成本排序。不要一上来就按成本排那样容易选到效果不达标的模型最后返工的成本更高。效果达标是底线成本优化是在底线之上的事。5.2 多模型并行的成本分摊现在很多团队的做法是同时接多家模型按场景分流。这样做的好处是不被单一供应商绑定坏处是计费逻辑变复杂。你需要一个统一的计费层把不同供应商的usage字段归一化然后统一计算成本。归一化的关键是字段映射。不同API返回的usage字段名不一样有的叫input_tokens有的叫prompt_tokens有的把缓存单独列出来有的混在input里。你需要写一个适配层把它们统一成前面那个计费函数能吃的格式。这个适配层看起来是脏活但它是成本可视化的基础值得认真做。5.3 降价之后哪些场景值得重新评估降价不是所有场景都受益。我列几类最值得重新评估的长系统提示词场景缓存读取降价直接受益如果你的命中率高成本可能降30%以上。高并发简单任务Luna这类轻量模型降价后可能比你自己部署小模型还便宜。批量离线处理这类任务对延迟不敏感可以用最便宜的档位降价后成本优势更明显。实时交互场景这类场景对延迟敏感可能还是要用贵一点的档位降价受益有限。反过来如果你的场景是短提示词、低并发、对延迟极度敏感那这次降价对你的影响可能很小别抱太大期望。6. 实测中的几个坑我替你踩过了6.1 账单和预估对不上先查这三个地方我做过一次成本预估结果实际账单比预估高了40%。排查下来是三个问题叠加第一缓存命中率比预期低因为系统提示词里混进了一个动态的日期字段第二输出token比预期多因为模型在某些输入下会话痨第三有个批处理任务忘了走便宜档位全走了贵模型。这三个坑很典型。动态字段污染缓存key是最隐蔽的因为从代码上看不出来只有对比缓存key的hash值才能发现。输出token超预期需要你在prompt里加约束比如回答控制在X字以内。档位走错则需要路由层有明确的日志能追溯每个请求走了哪个模型。6.2 缓存命中率上不去试试这个排查顺序命中率低的时候按这个顺序查先看缓存key里有没有动态内容再看TTL是不是太短然后看请求间隔是不是太长最后看是不是缓存容量不够被挤掉了。这个顺序是从最常见到最罕见能帮你快速定位。我遇到过一次命中率只有20%的情况查了半天发现是缓存key里包含了请求的时间戳精确到秒。去掉时间戳之后命中率直接上到85%。这种问题不看代码根本发现不了因为时间戳是框架自动加的。6.3 别忽略隐性成本价目表上的价格只是显性成本。隐性成本包括重试带来的额外调用、失败请求的浪费、调试期间的反复调用、以及模型效果不达标导致的返工。这些加起来可能比显性成本还高。我的做法是给每个环境开发、测试、生产单独设预算和告警。开发环境随便调但要能看到花了多少生产环境设硬上限超了就降级到便宜模型。这样既能保证开发效率又不会让成本失控。7. 我自己的成本优化清单跑了一段时间之后我整理了一份成本优化清单每次调价或者上新模型都会过一遍。分享出来你可以对照自己的情况调整。第一先测命中率再谈单价。命中率不到70%的话优化命中率的收益远大于换模型。第二路由层要能灰度。新模型先小流量试确认效果和成本都达标再放量。第三计费函数要有单测。计费逻辑错了后面所有优化都是白搭。第四账单要按天看。按周看的话问题发现太晚损失已经造成了。第五别为了省钱牺牲效果。省下来的钱如果导致用户体验下降那是负收益。这次两家同日降价对重度用户来说是实打实的利好但利好能不能落到你头上取决于你的计费体系够不够细、缓存策略够不够好、路由逻辑够不够聪明。价格战是别人的事成本控制是自己的事。把上面这些做到位降价的红利你才接得住。