前阵子某头部AI平台的API价格调整刷了不少人的屏。旗下轻量模型Haiku 5.5直接降价90%折算下来基本就是“打一折”。很多人第一反应是“哦便宜了好事”但紧接着就该问自己一句既然价格变成这样我现在手里的模型选型和调用方案还合理吗我把自己负责的几个线上项目重新做了一遍成本核算发现这次调整的影响范围比表面上看大得多。它改变的并不是“某个模型便宜了多少”这种简单数字而是直接把过去很多“因为贵而舍不得用”的场景重新拉回了讨论桌也顺带把一批“因为定价策略而勉强选择”的方案推翻了。原本觉得“轻量模型不够稳还是上标准模型吧”的任务在新的价格差面前账已经完全不同。这篇东西就用来记录我完整的核算过程和重新选型的方法论包括怎么拆解任务、怎么正确计算Token成本、怎么建对比模型以及迁移过程中踩过的坑和最后的兜底策略。如果你正在做API选型或者正在维护调用量比较大的线上应用这篇应该能直接用得上。就算你用的不是我说的这个平台成本核算和路由分层的思路也是通用的。1. 为什么Haiku 5.5降价90%会影响你的整个调用策略1.1 降价真正改变的不是单价而是路由策略价格下调90%最直接的理解是“同样的钱现在能调用10倍量”。但对我们这些实际在做系统维护的人来说意义远不止这么简单。以前很多团队会把请求一股脑发给标准模型理由是“贵但稳”。轻量模型虽然便宜可质量波动让人心里没底出了问题排查也麻烦于是宁愿多花点钱买个确定性。这个决策在轻量模型只比标准模型便宜30%的时候是成立的因为差价不够大到让人愿意承担质量波动带来的额外工作量。但差价到了90%以后逻辑完全颠倒过来。同样一笔预算原来够跑10万次标准模型现在能跑100万次轻量模型。就算轻量模型的准确率天生低那么三五个点也可以用更多的调用次数、更长的上下文、更精细的后处理逻辑来弥补整体ROI依然占优。换句话说成本差异已经大到可以覆盖大部分质量损失按“质量优先”做的一刀切路由策略必须重新设计。我在这次调价之后做了一件事把线上所有低频、批量、非实时的调用全部列出来逐个检查它们当初选择较贵模型的理由。结果发现大部分理由都是“当时轻量模型能力不够”而不是“这个任务真的需要旗舰级推理”。降级之后多项业务指标并没有明显滑坡预算倒是以肉眼可见的速度缓下来了。1.2 模型选型的本质是给每次请求找到性价比最优解模型选型从来不是一道“哪个模型最强”的单选题而是根据请求特征动态匹配。把线上所有流量都压给旗舰模型等于开着跑车去送外卖但把全部流量都切到轻量模型又可能在复杂推理场景里翻车。我习惯把请求先分成三层来拆第一层是机械性任务信息抽取、意图分类、实体识别、标题生成、格式化改写。这类任务边界明确答案模式固定轻量模型完全能覆盖。第二层是需要一点推理的任务多轮对话、内容改写、代码片段解释、文案润色。普通模型基本够用偶尔遇到复杂判断再临时升配。第三层是高难度任务复杂代码生成、长文本综合判断、数学推导、多条件约束求解。这层再省钱也不敢省质量旗舰模型依然是唯一选择。这次降价之后第一层几乎可以无脑用轻量模型第二层的性价比优先级也大幅提升。真正需要旗舰模型的只有第三层里面最尖的那一小撮请求。如果把线上流量分布画出来你会发现可能只有10%不到的高难请求需要留在最高档位其他都有降配空间。提示这里说的“降配”不是让你把整个应用一刀切换个便宜模型而是建立路由规则按请求复杂度分配合适的模型档位。只要路由逻辑够清晰用户几乎感知不到切换。2. 模型选型的核心决策逻辑2.1 先看任务复杂度而不是先看价格很多同学做选型时第一件事是打开价格表。但价格表的意义只有在“你已经明确要哪个档位”之后才存在。第一步永远是拆任务。我把拆任务的方法总结成一张检查清单拿到任何需求都按这个走输入内容是结构化信息还是自由文本结构化信息往往不需要强推理只是格式转换。输出结果是需要固定格式JSON、标签、分类结果还是开放文案固定格式对创造力的要求低。任务是否存在多轮依赖模型需要不需要记住很久之前的信息错误容忍度是多少答错了会造成什么后果影响越大档位越高。对延迟的硬性要求是多少实时交互和异步任务完全是两套选择标准。调用量级处于什么水平每天几千次和每天百万次对单价的敏感度完全不同。以内容分类任务为例输入通常是几十个字到一两百字的标题或描述输出是一个预设标签。这种任务几乎不吃长上下文也不吃复杂推理唯一需要的是稳定的判别能力和低的重复率。轻量模型完全能满足。可如果是做一个“帮用户生成三千字行业研究报告”的功能那完全是另一回事上下文的组织、逻辑的连贯、数据的取舍都对模型能力提出了更高要求。这里有个关键点任务的复杂度和输入的字符长度并不是正相关。有人觉得“输入内容那么多模型一定得是高级的”其实长文本里可能大部分都是模板化内容真正需要推理的核心只有一小段。反过来一句简短的“这句话是不是在阴阳怪气”反而需要很强的语义理解。按业务真实难点定档别按输入长度定档。2.2 输入输出比被很多人忽视的计费结构差异计费结构的第一条铁律是输入价格和输出价格不一样而且输出通常贵得多。这不是某家平台的独特设计几乎所有按Token计费的API都一样。原因也不难理解输入部分可以并行预计算输出部分必须一个字一个字生成计算资源占用完全不同。这个结构会推出一个很反直觉的结论哪怕输入Token数量是输出的两三倍输出费用往往还是占大头。所以做成本核算的时候一定要把输入和输出分开统计不能简单估算“每个请求大概多少Token”。尤其是对话场景。一次请求很可能带着之前十轮的历史记录累积几千个输入Token但模型输出只是一两百字的回复。如果只看到输入侧单价很便宜随便估个数就觉得“这次降价后成本不值得一提”最后出来账单一定超出预期。我在核算时会把线上日志里每个请求的输入输出Token分别统计算出平均数和P95分位数。因为平均Token数会把长尾稀释掉如果拿平均值做预算一旦出现几个超长上下文请求成本会瞬间被拉高。按P95或P99做预算才更接近真实账单的波动上限。2.3 延迟、速率限制和并发还拴着一道闸成本只是第一道闸延迟和速率限制是第二道闸。轻量模型降价90%但如果把它架在一个必须实时交互的产品上模型处理时间的每一毫秒差距都可能直接拖垮用户体验。不同档位的模型处理速度不一样而且“便宜模型更快”并不是一个普适结论。轻量模型因为参数量小单次推理的物理耗时通常更短但如果你把同一段长文本丢给它处理时间可能并没有想象中那么乐观。尤其当上下文达到几万Token时预填充阶段会消耗大量计算时间P95延迟可能直接暴涨。还有并发和速率限制。很多平台对轻量模型给的速率上限会比其他模型高因为轻量模型单次消耗的资源少平台也更愿意放开配额让你多调。但这不等于你可以无脑并发。我在一个批量处理任务里就遇到过明明报价更便宜结果因为速率限制卡住跑完同一批任务总时间反而比原来更长的情况。成本省了但业务时效没达标等于白省。所以做选型对比时至少要做三组测评单次延迟、P95延迟、在目标并发下的成功率。三个指标都过关再看成本才谈得上“省钱”。3. Token成本核算方法与实战公式3.1 Token的真实身份比“字数”更标准的计价单元Token并不等于中文字符也不等于英文单词。英文里一个Token大约覆盖4个字符中文一个Token大概能覆盖零点几个到几个汉字具体取决于分词器怎么切。所以永远别想当然地用“字数乘以某个系数”来估成本。最靠谱的做法是用平台提供的Token计数接口直接数把真实业务里的句子跑一遍统计平均输入、平均输出的Token数。我这个习惯坚持了很久因为只有统计出来的数是真正的“业务口径”你在纸上“感觉”的数字往往偏差很大偏差大了以后整个成本预算都是空中楼阁。3.2 自己建一套成本核算公式我把一次请求的成本拆成下面这个模型单次成本 输入Token数 × 输入单价 输出Token数 × 输出单价月度成本 单次成本 × 预估月请求数年度成本 月度成本 × 12以此为基础对比两个模型时计算差额差额成本 月度成本模型A - 月度成本模型B看上去很简单但至少有三个细节需要提醒。第一输入单价和输出单价必须用同一个价目表的口径不同档位、不同计费区间都要查清楚。第二如果有上下文缓存命中部分的价格要单独算通常缓存命中的输入Token会便宜很多。第三模型的max_tokens上限会卡住单个请求的输出Token数量如果max_tokens设置得太小模型输出会被截断但截断前的Token依然计入费用这一点下面会细说。3.3 用Python写一个轻量的批量估算脚本这个脚本我每次做选型对比都会用不依赖任何外部包核心就是把不同价目表模拟成参数跑一遍批量场景。建议把真实业务日志里的Token数据灌进去别拍脑袋填数字。def estimate_montly_cost( daily_requests, avg_input_tokens, avg_output_tokens, input_price_per_million, output_price_per_million, ): 估算单个模型一个月的成本。 价格单位为美元/百万Token。 per_request_cost ( avg_input_tokens * input_price_per_million avg_output_tokens * output_price_per_million ) / 1_000_000 return per_request_cost * daily_requests * 30 # 示例每日100万次请求平均输入1200 Token输出180 Token # 轻量模型降价前输入0.8美元/百万输出2.0美元/百万 # 轻量模型降价后输入0.08美元/百万输出0.20美元/百万 # 标准模型对比输入2.5美元/百万输出10.0美元/百万 scenes { 轻量模型_降价前: (1_000_000, 1200, 180, 0.8, 2.0), 轻量模型_降价后: (1_000_000, 1200, 180, 0.08, 0.20), 标准模型_对比: (1_000_000, 1200, 180, 2.5, 10.0), } for name, (req, in_tk, out_tk, in_price, out_price) in scenes.items(): cost estimate_montly_cost(req, in_tk, out_tk, in_price, out_price) print(f{name}: 月度成本约 {cost:,.2f} 美元)这段代码跑完之后你会得到一个非常直观的对比。我心里清楚这次降价影响大但真正看到三个数字并排摆在那里时还是沉默了一会儿。日常运营的成本优化有时候就是靠这种最笨的计算撬动的。注意价目表会更新上面代码里的价格只是用于演示的示例值。实际核算请以平台控制台展示的最新价格为准。算法本身是通用的替换成真实价格即可。4. 三种典型场景下的成本测算实例4.1 智能客服短输入、高频率智能客服是典型的短输入、高频次场景。假设一个客服系统每天处理100万次请求平均输入1200 Token平均输出180 Token。这类任务对准确率有要求但大多数问题都是常见FAQ不需要太长上下文。用前面的脚本算轻量模型降价前的月度成本大约是输入成本100万 × 1200 × 0.8 / 100万 × 30 2.88万美元输出成本100万 × 180 × 2.0 / 100万 × 30 1.08万美元合计3.96万美元降价后输入成本100万 × 1200 × 0.08 / 100万 × 30 2880美元输出成本100万 × 180 × 0.2 / 100万 × 30 1080美元合计3960美元一个月从接近4万美元降到不到4000美元幅度就是90%。如果拿标准模型对比标准模型可能光输出成本就要21.6万美元/月差距更悬殊。对于客服这种高频机械任务降级切换到轻量模型是毫无悬念的选择。实际执行时我也留了一手遇到用户情绪强烈、问题表述模糊、或者需要多轮纠缠的场景时机器人会自动把请求路由到标准模型。轻量模型覆盖80%的常规问题剩下20%交给高配兜底整体成本还是比原来低一大截。4.2 长文档总结高输入、低输出长文档总结是另一种典型场景。假设每天5000次请求平均输入30000 Token输出800 Token。这种场景的算例会给你一个完全不同的感受。轻量模型降价后的每请求成本输入成本30000 × 0.08 / 100万 2.4美元输出成本800 × 0.2 / 100万 0.16美元单次合计约2.56美元月度成本2.56 × 5000 × 30 38.4万美元看到这个数字你就会明白就算输入单价降了90%只要输入Token总量足够大成本依然非常可观。因为每次请求的输入Token数动辄几万单价再低也经不起量堆。这种情况下真正有效的降本手段不是换更便宜的模型而是从工程层面降低输入Token数。比如把长文档切成多段分别处理用轻量模型先做分段摘要再把摘要送入标准模型做综合或者利用上下文缓存让重复出现在不同请求里的公共部分命中缓存直接享受缓存折扣。单纯指望价格下调解决长文本成本是不现实的。4.3 代码生成与结构化输出输出占比高代码生成和结构化输出场景输出Token占比高成本压力主要在输出侧。假设每天2万次请求平均输入1500 Token平均输出1200 Token。用降价后的轻量模型算输入成本1500 × 0.08 / 100万 0.00012美元输出成本1200 × 0.2 / 100万 0.00024美元单次成本约0.00036美元月度成本0.00036 × 2万 × 30 216美元看起来不贵但你要警惕的是输出Token膨胀。代码生成任务里模型经常会输出多余的解释、重复的函数片段或者因为max_tokens设置过大而生成一长串无用内容。这些都会显著拉高输出Token直接打到账单里。我在生产环境的做法是能用JSON模式强制结构化输出就绝不用开放文本尽量把prompt里的输出格式限制到最短把max_tokens设为业务实际需求上限的1.2倍而不是设成模型最大窗口。多出来的余量是给特殊情况用的不是让模型自由发挥的。5. 踩坑清单与问题排查实录5.1 计费口径问题最容易踩的几个坑这些坑我基本都踩过列出来给你提个醒。第一个坑把输入单价和输出单价当成同一个价来估。很多人一看到“百万Token多少钱”就取一个整数随手乘上总Token数结果账单出来比预估高一截。输入输出分开算是成本核算的基本功。第二个坑没有考虑缓存命中。有些平台的上下文缓存是按自动命中的方式扣费也就是说你只要发送相同的前缀这部分输入就能以更便宜的价格计费。如果不提前了解缓存机制你算出来的成本会比真实账单偏高然后在做方案对比时错误地否掉某些优化方案。第三个坑忽略max_tokens被截断的计费。模型达到max_tokens后会强行停止生成但已经生成的Token是照常收费的。可能是你的max_tokens设小了也可能是指令写得不清晰导致模型废话太多两种情况都会让输出侧费用超出预期。第四个坑批量任务的自动重试也算钱。我之前差点漏掉这个好在做日志审计时发现某模块一直在短时间内重复提交同一个请求每次重试都是一次完整计费。价格再便宜架不住重试几十次成本一样飞起来。排查后把重试策略加了退避和次数上限费用立刻回落。5.2 用量审计把usage字段变成成本监控的核心数据每个API响应的返回体里都有一个usage字段包含输入Token数和输出Token数。很多人只在研究功能时看一次从不记录这其实是在浪费最便宜也最重要的数据。我的建议是把每次调用的usage字段打到结构化日志里按小时或当日做聚合再对照价目表计算成本。成本数据只有以用量为基础才能反映线上真实情况。当你看到某个功能模块的单用户成本异常飙升时你才能快速定位到是上下文过长、重试过多、还是prompt膨胀而不是等到月底账单出来才一头雾水。成本告警阈值也值得设。我在系统里给单日成本设了一条警戒线超过后直接推送通知。这样即使业务侧没有感知成本侧的异常也逃不过监控。5.3 迁移过程中的风险控制灰度切换与兜底策略别搞“一夜全切”。这可能是整篇内容里最重要的一条建议。即使降价幅度再大也不能把所有流量在一天之内全部切到新模型尤其是线上生产环境。我的做法是分四步第一步先拿10%的流量跑轻量模型观测准确率、延迟、异常比例三个指标。第二步如果三项指标都在可接受范围内把流量提升到50%。第三步再提升到80%并持续观察至少一个完整业务周期。第四步最后10%再切过去保留完整回滚能力。同时我在架构里保留了一个兜底逻辑当轻量模型返回低置信度结果或者触发限流、超时、异常时自动把请求升级到标准模型重试一次。这个双通道设计看似增加了一部分高配调用量但实际上它让系统在切换和运行过程中始终有一个安全垫整体成本还是比原来低得多。提示灰度切换不是只在第一次迁移时用。每次模型版本更新、价格变动、prompt模板改动都应该重新跑一轮小流量验证别让“历史结论”变成默认前提。6. 一些个人经验总结最后分享几个我自己的习惯。第一每次价格变动之后我都会在一个专门的项目里建一个成本对比任务从线上抽样一批真实请求重新算一遍成本。价格表变化往往意味着最优模型档位变化不重新算你就还在用老地图跑新路。第二任何模型迁移都必须以usage数据为准没有数据就别谈成本优化。我见过很多团队凭感觉说“这个模型好像便宜”结果上线后一算总账反而更贵了就是因为它把输入输出结构想反了。第三模型选型不是一锤子买卖而是跟随价目表和模型能力持续调整的动态过程。今天的最优解在下一次价格调整或版本更新后就可能变成次优解保持一个轻量的核算流程比记住某个固定答案重要得多。坦白讲这次Haiku 5.5降价之后我把手上大概七成的高频调用都切到了轻量模型整体成本下降非常明显业务指标并没有因此变差。这个结果也再次印证了一件事在AI API花销这件事上不会算账比不会调接口损失更大。希望这篇核算过程和选型思路能让你在下一次价格变动时少踩几个我踩过的坑。