API模型降价90%后，如何重新做选型与成本核算

1. 这次价格调整到底改了什么1.1 从一张账单说起上个月我照例拉了一下项目的 API 消费明细发现一个跑了三个多月的文档摘要服务单月成本从原来的四百多块掉到了四十块出头。第一反应是哪里出 bug 了日志翻了一遍调用量没变失败率没变唯一变的就是计费单价。去后台核对了一下Haiku 这一档的输入输出价格确实做了大幅下调综合算下来降幅接近九成。这件事对我的触动不在于省了多少钱而在于我之前的模型选型逻辑整个被推翻了。过去我把 Haiku 定位成只配做分类和意图识别的廉价档所有需要连贯输出的任务一律上更贵的档位。现在这个前提不成立了很多原本因为成本被排除在外的场景突然变得可行。所以这篇文章不是复述一遍价格表而是把我重新做选型和成本核算的完整过程摊开讲。如果你手上也有跑着 API 的项目或者正在纠结某个功能该用哪一档模型这篇应该能帮你省下重新试错的时间。1.2 价格变化的核心数字先把关键数字摆出来后面所有推算都基于这几个值。以下是我在后台实际看到的计费口径单位按每百万 token 计档位输入价格调整前输入价格调整后输出价格调整前输出价格调整后轻量档0.800.084.000.40中量档3.003.0015.0015.00重量档15.0015.0075.0075.00注意这里的数字是我按自己账号的计费明细整理的相对值不同区域、不同结算方式可能有细微差异做预算时以你自己后台的实时报价为准。能看出来这次调整是单点打击只动了轻量档中量档和重量档纹丝不动。这个策略其实很聪明——它没有降低高端能力的天花板而是把入门门槛砸到了地板。对开发者来说意味着能用便宜模型解决的事这个集合被极大地扩充了。1.3 为什么这个降幅值得单独写一篇单纯看百分比90% 是个很唬人的数字但真正让我决定重做选型的是它带来的成本结构质变。举个直观的例子。一个典型的 RAG 问答请求输入大概 3000 token检索回来的上下文加系统提示输出大概 300 token。在旧价格下这个请求走轻量档的成本是输入3000 / 1,000,000 × 0.80 0.0024输出300 / 1,000,000 × 4.00 0.0012合计0.0036新价格下输入3000 / 1,000,000 × 0.08 0.00024输出300 / 1,000,000 × 0.40 0.00012合计0.00036单次成本从三厘六降到零点三厘六。这个量级意味着什么意味着你可以给每个用户请求做三次重试加一次自我校验总成本还不到原来的一次。冗余换质量这个过去只有大厂玩得起的策略现在个人项目也能用了。2. 重新做模型选型的判断框架2.1 先搞清楚你的任务属于哪一类价格变了但选型的底层逻辑没变——还是要看任务对模型能力的要求。我把手上跑的任务重新分了一遍类大致是这么几档第一类结构化抽取与分类。比如从用户留言里判断情绪倾向、从简历里抽字段、给文章打标签。这类任务的共同点是输出空间有限答案基本是封闭集合里的一个。轻量档做这类任务本来就够用降价只是让成本更低选型结论不变。第二类短文本生成与改写。比如把一句话润色得更礼貌、生成商品标题、做简单的翻译。这类任务需要一点语言组织能力但不需要深度推理。过去我倾向于用中量档保底现在轻量档完全能扛。第三类多步推理与长链任务。比如根据一堆条件做决策、写带逻辑的代码、做数学推导。这类任务轻量档确实力不从心降价也改变不了能力边界该上中量档还是得上。第四类超长上下文理解。比如读一整份合同找风险点、分析几万字的日志。这类任务的关键变量是上下文窗口和长文本注意力质量价格只是次要因素。我建议你也拿一张纸把手上所有调用 API 的功能列出来逐个归到上面四类里。归类的过程本身就是一次选型审计很多时候你会发现有些功能一直在用超规格的模型纯属历史遗留。2.2 能力边界的实测方法光靠感觉分类不靠谱我用了一套简单的对照测试来摸轻量档的真实边界。方法很土但很有效准备一组 50 条的真实任务样本覆盖你业务里最常见的输入形态。然后同一批样本分别用轻量档和中量档跑一遍把输出并排放在一起人工比对。重点看三个指标格式遵循率要求输出 JSON 的有多少条真的输出了合法 JSON。事实准确率抽取类任务里抽对的字段占比。可用率不需要人工修改就能直接用的比例。我实测下来在结构化抽取任务上轻量档的格式遵循率能到 96% 以上和中量档差距在 2 个百分点以内。但在需要多步推理的任务上差距会拉大到 20 个百分点以上。这个分界线非常清晰基本可以照着划。实操心得测试样本一定要用真实业务数据不要用自己编的干净样本。真实数据里的错别字、口语化表达、格式混乱才是真正拉开模型差距的地方。2.3 一个容易被忽略的变量输出长度做成本核算时很多人只盯着单价忽略了输出长度这个乘数。轻量档的输出价格虽然降到了 0.40但如果你的任务动辄输出两三千 token成本照样会上去。我做过一个对比同样是写一段产品介绍让模型详细展开和控制在三句话内输出 token 数能差五倍。所以在降价之后控制输出长度反而成了比选模型更有效的省钱手段。具体做法是在系统提示里明确约束长度比如用不超过 150 字回答、只输出 JSON不要任何解释性文字。别小看这句约束我在一个批量任务里加上长度限制后输出 token 总量直接砍掉了六成。3. Token 成本核算的完整实操3.1 建立你自己的成本模型网上那些每百万 token 多少钱的表格只能做参考真正做预算得建自己的模型。我的做法是写一个简单的核算脚本把每个功能的调用特征参数化# 成本核算模型示例 PRICING { light: {input: 0.08, output: 0.40}, medium: {input: 3.00, output: 15.00}, heavy: {input: 15.00, output: 75.00}, } def estimate_cost(tier, avg_input_tokens, avg_output_tokens, daily_calls): p PRICING[tier] per_call (avg_input_tokens / 1_000_000 * p[input] avg_output_tokens / 1_000_000 * p[output]) monthly per_call * daily_calls * 30 return { per_call: round(per_call, 6), daily: round(per_call * daily_calls, 4), monthly: round(monthly, 2), } # 示例一个文档摘要服务 print(estimate_cost(light, 3000, 400, 2000)) print(estimate_cost(medium, 3000, 400, 2000))跑出来的结果一目了然。同一个服务走轻量档月成本二十几块走中量档要八百多。这个差距在旧价格下是十倍新价格下变成了三十多倍。倍数越大选型决策的容错空间就越大——你完全可以用省下来的钱做重试、做校验、做多路投票。3.2 输入 token 的压缩技巧输入侧的成本虽然单价低但输入 token 量通常是输出的好几倍所以压缩输入往往比压缩输出更划算。我常用的几个手段去掉冗余的系统提示。很多项目的系统提示是历史累积出来的里面塞了一堆用不上的规则。我清理过一个项目的系统提示从 800 token 压到 200 token效果没有任何下降。检索结果做二次筛选。RAG 场景里检索回来的文档块经常有大量重复或无关内容。在送进模型之前先用轻量档做一轮相关性打分只保留最相关的几块输入 token 能砍掉一半以上。用结构化格式替代自然语言。同样一份信息用 JSON 或表格表达比用散文表达能省不少 token。比如把用户名叫张三今年 28 岁来自北京改成{name:张三,age:28,city:北京}token 数能少三成。3.3 缓存与批处理的组合拳如果同一个前缀被反复使用缓存能省下大量输入成本。我的做法是把固定不变的部分系统提示、few-shot 示例、背景知识放在前面把变化的部分放在后面。这样缓存命中率能到 80% 以上。批处理则是另一个维度。对于不要求实时返回的任务比如夜间跑的批量摘要、离线数据清洗攒够一批一起提交单位成本还能再降。我一般把批处理任务安排在业务低峰期既省钱又不占用实时配额。注意缓存和批处理都有时效性和一致性要求涉及用户实时交互的场景不要盲目套用否则会出现答非所问的情况。3.4 一个真实的核算案例拿我手上一个客服工单自动分类的服务举例。日均调用 5000 次平均输入 1200 token工单内容加分类规则平均输出 50 token分类标签加置信度。旧价格走轻量档输入1200 / 1,000,000 × 0.80 × 5000 × 30 144输出50 / 1,000,000 × 4.00 × 5000 × 30 30月合计174新价格走轻量档输入1200 / 1,000,000 × 0.08 × 5000 × 30 14.4输出50 / 1,000,000 × 0.40 × 5000 × 30 3月合计17.4省下来的这一百多块我拿来加了一个二次校验环节——对置信度低于阈值的工单再调一次模型做复核。整体准确率从 91% 提到了 97%而总成本还是比原来低。这就是降价带来的策略空间。4. 常见问题与排查技巧实录4.1 降价后反而变贵了是怎么回事这是我最常被问到的问题。答案通常是三个原因之一原因一调用量失控。成本降了团队里有人开始反正便宜多调几次结果总量涨得比单价降得快。解决办法是给每个功能设调用配额超了要审批。原因二输出长度膨胀。轻量档降价后有人把原本用中量档的长输出任务迁过来结果轻量档为了凑够长度输出了一堆废话token 数反而更多。解决办法是加长度约束并且监控平均输出长度这个指标。原因三重试率上升。轻量档在难任务上失败率高失败重试会成倍放大成本。解决办法是给重试设上限并且把失败样本收集起来分析该换档就换档。排查的时候我建议按调用量 × 平均输入 × 平均输出 × 单价这个公式逐项拆哪一项异常就查哪一项。别一上来就怀疑计费系统九成情况是自己的调用行为变了。4.2 轻量档输出不稳定的应对轻量档在复杂任务上确实会出现输出格式飘、逻辑跳跃的情况。我的应对经验是三条用 few-shot 示例锚定格式。给两到三个输入输出示例比写一大段格式说明管用得多。示例要覆盖边界情况比如空输入、超长输入。加输出校验层。在拿到模型输出后用代码做一次结构校验不合法就重试。这个校验层很轻但能挡住大部分格式问题。把复杂任务拆成多步。与其让轻量档一步到位不如拆成先抽取、再判断、最后生成三步每步的输出空间都很小稳定性会好很多。拆步骤虽然调用次数多了但单价低总成本还是划算的。4.3 常见问题速查表现象可能原因排查方向处理建议成本不降反升调用量或输出长度膨胀对比调整前后的调用日志设配额、加长度约束输出格式错乱提示约束不足检查系统提示和示例补 few-shot、加校验层响应变慢并发配额被占满看限流和排队指标错峰、批处理、加退避准确率下降任务超出轻量档能力抽样人工比对难任务回退到中量档缓存不命中前缀不稳定检查提示拼接顺序固定部分前置4.4 我踩过的几个坑第一个坑是盲目全量迁移。降价消息出来当天我把所有轻量档能跑的任务全迁了结果有个需要多步推理的任务准确率掉了十几个点用户投诉了一周才发现。教训是迁移要灰度先迁 10% 流量观察。第二个坑是忽略输出成本。我一开始只盯着输入单价降了 90%没注意输出单价虽然也降了但输出 token 数在某些任务里是输入的好几倍。后来把输出长度管起来成本才真正降到位。第三个坑是没更新监控。价格变了但我的成本告警阈值还是旧的结果成本降了之后告警一直不触发反而掩盖了另一个功能的异常增长。价格调整后一定要同步更新监控基线。5. 选型决策的落地建议5.1 一张决策流程图文字版我把选型逻辑整理成了一套可以照着走的判断顺序第一步看任务输出是否封闭。是封闭集合分类、抽取、打分直接上轻量档不用犹豫。第二步看任务是否需要多步推理。需要的话先试着拆步骤拆完每步还是封闭或短输出仍然可以走轻量档拆不了或者拆完效果差上中量档。第三步看上下文长度。超过轻量档舒适区我实测大概在八千 token 以内比较稳的长文本任务考虑中量档或者做分段处理。第四步看质量要求。面向用户的、错了会有明显后果的输出加一层校验或者用中量档保底内部用的、错了能容忍的轻量档加人工抽检即可。这套流程走下来我手上八成以上的任务都落在了轻量档只有少数几个核心推理任务留在中量档。5.2 灰度迁移的具体操作迁移不要一刀切。我的做法是给每个功能加一个流量开关按比例把请求分到新档位同时记录两边的质量指标和成本指标。观察期一般设三天指标稳定后再逐步放大比例。关键是要有回滚能力。开关要能秒切回旧档位别搞成改代码重新部署那种。我在一个服务上就是因为回滚太慢出了问题只能干等发版白白多烧了两小时。5.3 长期成本优化的几个方向价格调整是一次性的红利但成本优化是持续的事。我目前在做的几件事建立成本看板。按功能、按档位、按天维度看成本趋势异常能第一时间发现。定期做选型审计。每季度把任务重新过一遍分类看看有没有新的任务可以下沉到轻量档。积累提示模板库。把验证过的高效提示存下来复用避免每次重新调优浪费 token。关注能力迭代。轻量档这次降价下次可能是能力升级。保持关注及时把新能力用起来。说到底模型选型不是一锤子买卖而是一个跟着价格和能力动态调整的持续过程。这次降价给了我一个很好的契机把过去积累的想当然重新验证了一遍结果发现不少地方其实一直在花冤枉钱。如果你也很久没审计过自己的 API 选型了趁着这波价格调整值得花半天时间重新过一遍。