1. 这次降价到底改变了什么1.1 从“用不起”到“用得起”的临界点我第一次认真评估轻量级模型做生产环境主力是在一个日均调用量大概三十万次的内容审核项目上。当时团队算过一笔账如果用旗舰级模型跑全量一个月光推理成本就能吃掉整个项目预算的大半如果全量走最便宜的那档准确率又撑不住业务方的验收标准。卡在中间那种感觉做过成本核算的人都懂——不是技术做不到是账算不过来。这次 Haiku 系列新版本的价格调整本质上就是把这条“算不过来”的线往下压了一大截。输入侧和输出侧同时降价对于以输出为主的任务比如内容生成、摘要、结构化抽取来说边际成本的下降幅度比表面数字看起来更明显。我拿手头一个真实跑着的任务做了对比同样的 prompt 结构、同样的输出长度约束单次调用成本降到了原来的一个零头。这不是“省一点”的概念而是让原本只能跑抽样检测的场景直接可以升级成全量处理。先把结论摆前面如果你的业务里有大量“判断类”“抽取类”“改写类”任务之前因为成本被压着只能用规则或者小模型凑合现在值得重新做一轮选型评估。但“值得评估”不等于“无脑切”后面我会把核算方法和踩过的坑都摊开讲。1.2 谁最该关注这次价格变动我把可能受益的场景按优先级排了一下你可以对号入座高频低复杂度任务内容分类、意图识别、敏感词二次判定、工单自动打标。这类任务单次 token 消耗小、调用量大价格敏感度最高。批量离线处理历史数据清洗、存量文档结构化、批量翻译或摘要。这类任务对延迟不敏感但对总成本极其敏感降价后很多原本“不值得跑”的存量数据变得值得跑一遍。Agent 链路中的轻量节点在一个多步流程里不是每一步都需要旗舰模型。路由判断、参数提取、结果校验这些节点换成轻量模型整条链路的成本结构会好看很多。个人开发者和小团队预算有限之前只能靠免费额度或者极低配额试水现在可以用很低的成本跑通完整的产品验证。反过来如果你的任务本身就需要强推理、长链条规划、复杂代码生成那这次降价跟你关系不大——该用旗舰还是用旗舰省下的那点钱换不来准确率的损失。选型的第一原则永远是“任务匹配”成本是第二位的约束条件不是第一位的目标。2. 模型选型不能只看单价2.1 单价是表象单位任务成本才是真相很多人比价的方式是直接看“每百万 token 多少钱”然后挑最便宜的那个。这个做法在早期粗筛阶段没问题但真正做决策的时候会误导人。原因很简单不同模型完成同一个任务消耗的 token 数量是不一样的。我举个自己踩过的例子。同样一个“从合同文本里抽取甲乙方、金额、签署日期”的任务旗舰模型可能用 200 个输出 token 就干净利落地给出结构化结果而一个能力弱一些的轻量模型可能会啰嗦一大段解释或者格式不稳定需要重试实际输出 token 跑到 500 甚至更多还伴随 10% 的失败重试率。算下来单价便宜了一半单位任务成本反而更高。所以正确的核算公式应该是这样的单位任务成本 单次平均输入 token × 输入单价 单次平均输出 token × 输出单价 × (1 重试率)这里的“重试率”是最容易被忽略、又最影响结论的变量。我的做法是拿 200 到 500 条真实样本分别用候选模型跑一遍统计三个数——平均输入 token、平均输出 token、需要重试的比例。这三个数一出来单位任务成本基本就锁定了比看官方价目表靠谱得多。2.2 一张表看懂选型维度我把选型时要权衡的维度整理成了一张对照表实际评估时逐项打分避免拍脑袋评估维度为什么重要怎么测单位任务成本决定能不能规模化真实样本跑批算含重试的综合成本输出格式稳定性影响解析代码复杂度同一 prompt 跑 100 次看格式合规率指令遵循度决定 prompt 要不要写很长用精简 prompt 测试看是否跑偏延迟表现影响在线场景体验测 P50 和 P95别只看平均值长上下文能力决定能否塞下完整文档用接近上限的输入测召回质量并发承载影响高峰期稳定性压测观察限流和错误率这张表里“输出格式稳定性”和“指令遵循度”是我最看重的两项因为它们直接决定了你要写多少兜底代码。一个模型如果格式稳定你的解析层可以写得很薄如果格式飘忽你就得写一堆正则和异常处理这些隐性工程成本往往比 token 费用还高。2.3 分层选型不要用一个模型打天下我现在的默认架构是分层的而不是全量押注某一个模型入口层用最轻量的模型做意图识别和路由判断这个请求该走哪条链路。这一层追求的是快和便宜准确率要求不高因为判断错了后面还有兜底。处理层用中等能力的模型做主体任务比如抽取、改写、摘要。这是成本大头也是这次降价受益最明显的部分。兜底层只有处理层置信度低、或者任务本身复杂度高的时候才升级到旗舰模型。这一层的调用比例通常能压到 5% 到 15%。这套结构的好处是整体成本由处理层决定而处理层正好是降价幅度最大的那一档。我实测下来同样的业务量分层架构比全量旗舰方案成本降了一个数量级而端到端的准确率只掉了不到两个百分点——这两个百分点还能靠兜底层补回来一部分。3. 成本核算的完整实操流程3.1 第一步把业务拆成可计量的任务单元成本核算最容易翻车的地方是一上来就统计“总调用量”而不是“任务单元”。总调用量是个模糊的数字没法指导优化。我习惯先把业务拆成一个个原子任务每个任务有明确的输入输出定义。比如一个客服辅助系统我会拆成用户消息意图分类输入单条消息输出一个标签历史对话摘要输入最近 N 轮对话输出一段摘要知识库检索改写输入用户问题输出检索用的 query回复草稿生成输入意图 摘要 知识片段输出回复文本拆完之后每个任务的调用频率、平均输入长度、平均输出长度都能单独统计。只有拆到这个粒度你才能判断哪些任务该换模型、哪些任务换了也没意义。我见过太多团队笼统地说“我们一个月调用一百万次”结果一拆发现 80% 的调用集中在两个简单任务上优化这两个任务就够了根本不用动全局。3.2 第二步采样跑批拿到真实 token 数据拆完任务接下来是采样。我的经验是每个任务至少采 200 条覆盖典型场景和边界场景。边界场景特别重要因为长尾输入往往是 token 消耗的元凶——一条超长文本能把平均值拉高一大截。跑批的时候我会记录每个样本的这几个字段# 跑批记录结构示例伪代码字段说明用 record { task_id: intent_classify, # 任务标识 input_tokens: 0, # 实际输入 token output_tokens: 0, # 实际输出 token latency_ms: 0, # 单次延迟 success: True, # 是否一次成功 retry_count: 0, # 重试次数 format_valid: True, # 输出格式是否合规 }跑完之后用这些数据算出每个任务的平均输入 token、平均输出 token、重试率、格式合规率。这四个数就是后面所有核算的基础。我强烈建议把这个跑批脚本固化下来每次换模型或者改 prompt 都重跑一遍形成可对比的历史数据。3.3 第三步代入公式算单位成本有了真实数据代入前面那个公式就能算出单位任务成本。我拿一个虚构的抽取任务举例说明计算过程假设某抽取任务采样 300 条统计结果如下平均输入 token1200平均输出 token180重试率8%即 8% 的请求需要重跑一次再假设当前候选模型的定价是输入每百万 token 若干、输出每百万 token 若干具体数字随官方调整这里用相对值演示。那么单次成本 1200 × 输入单价 180 × 输出单价 × 1.08把重试率乘在输出侧是因为重试通常意味着重新生成输入也要重发但为了简化我习惯把重试的额外开销统一折算到输出侧误差在可接受范围内。如果你要更精确可以把重试的输入也单独算进去。算完单次成本乘以月调用量就是月成本。这个数字才是你做决策的依据而不是价目表上的单价。我见过单价降了一半但月成本反而上升的案例原因就是新模型输出啰嗦、重试率高把省下的单价又吐回去了。3.4 第四步做敏感性分析成本核算不是算一个数就完事还要看这个数对哪些变量最敏感。我通常会做三组敏感性测试调用量翻倍如果业务增长成本曲线怎么走有没有规模效应输出长度增加 50%如果业务方要求更详细的输出成本会涨多少重试率上升 5 个百分点如果模型稳定性下降成本会恶化到什么程度这三组测试能帮你识别出成本结构里最脆弱的一环。我的经验是大多数任务的成本对“输出长度”和“重试率”的敏感度远高于对“输入长度”的敏感度。所以优化成本时优先去压缩输出、提升一次成功率比去精简输入划算得多。4. 把成本真正降下来的几个实操手段4.1 Prompt 瘦身省下的都是纯利润输入 token 是成本里最容易被忽视的部分因为它单价低但架不住量大。我做过一次统计一个跑了半年的系统prompt 里积累了大量的“历史遗留”——过时的示例、重复的说明、没人敢删的兜底指令。清理一遍之后平均输入 token 降了将近四成。具体怎么瘦身我的做法是示例从“多而全”改成“少而精”三个高质量示例往往比十个平庸示例效果好还省 token。把固定说明移到系统提示里如果平台支持系统提示和用户消息分开计费或有缓存机制把不变的指令放系统侧能省不少。删掉“以防万一”的冗余指令很多指令是早期调试时加的后来模型能力上来了根本用不到但一直留着。用结构化格式替代自然语言描述同样一个输出要求用 JSON schema 描述比用一段话描述更省 token也更稳定。提示每次改 prompt 都要重跑采样确认准确率没有下降。瘦身不能以牺牲效果为代价否则省下的 token 钱还不够赔业务损失。4.2 输出约束让模型少说废话输出 token 单价通常比输入高所以控制输出长度的收益更直接。我常用的手段有这么几个在 prompt 里明确长度上限比如“摘要不超过 80 字”“只输出 JSON不要任何解释”。用停止序列如果平台支持设置停止标记模型生成到标记就停避免多余的收尾话术。结构化输出要求模型输出固定字段的 JSON比让它自由发挥更可控。后处理截断对于确实会超长的场景在应用层做截断但这是兜底不能当主要手段。我实测过一个改写任务加了“只输出改写后的文本不要任何前后缀”这一句之后平均输出 token 从 220 降到了 130效果完全没受影响。这一句话的改动带来的成本下降比换模型还明显。4.3 缓存与去重别为重复的问题付两次钱很多业务场景里请求是高度重复的。比如电商场景下的商品咨询同一个问题一天可能被问几百遍。这种场景下在应用层做一层语义缓存能省掉大量重复调用。我的做法是对输入做归一化去空格、统一大小写、去掉无意义的语气词然后算一个哈希或者语义指纹命中缓存就直接返回。缓存的有效期根据业务特点设置时效性强的场景设短一点知识类场景可以设长一点。除了语义缓存还有一类是前缀缓存。如果平台支持对相同的 prompt 前缀做缓存计费那么把不变的部分系统指令、示例、背景知识放在前面把变化的部分放在后面能显著降低成本。这个技巧在长系统提示的场景下效果尤其明显。4.4 批处理把能合并的请求合并对于离线任务批处理是降本利器。很多平台对批量接口有单独的优惠即使没有优惠把多个小请求合并成一个大请求也能减少请求开销和重复的系统提示消耗。我做过一个文档分类的离线任务原本是每篇文档单独调用一次后来改成每批 20 篇一起送进去让模型输出一个数组。结果总 token 消耗降了大概三成因为系统提示和任务说明只发了一次而不是二十次。批处理的代价是单次延迟变高、错误影响面变大所以只适合离线场景在线场景慎用。5. 常见问题与排查实录5.1 换了便宜模型之后效果变差怎么办这是最常见的问题。我的排查顺序是这样的先看是不是 prompt 不匹配不同模型对 prompt 风格的敏感度不一样。旗舰模型能理解的模糊指令轻量模型可能理解不了。先试着把指令写得更明确、更结构化。再看是不是任务本身超纲有些任务就是需要强推理轻量模型做不了。这时候别硬撑把这类任务单独拎出来走旗舰模型。然后看输出格式如果只是格式不稳定加一个 few-shot 示例或者用结构化输出约束往往能解决。最后才考虑换回旗舰如果前三步都试过还是不行那说明这个任务确实不适合轻量模型老老实实换回去别为了省钱牺牲业务。我踩过的一个坑是一开始以为是模型能力不够折腾了半天 prompt最后发现是采样时用的测试集和实际业务分布不一致测试集偏简单实际业务里有大量长尾输入。所以采样一定要贴近真实分布否则所有评估都是自欺欺人。5.2 成本降了但账单没降问题出在哪这种情况我遇到过两次原因分别是第一次是重试率上升新模型格式不稳定应用层疯狂重试把省下的钱又花出去了。解决办法是加格式约束把重试率压下来。第二次是调用量涨了成本降了之后业务方觉得便宜把原本抽样处理的任务改成了全量处理总调用量翻了好几倍。这不是坏事但做预算时要提前跟业务方对齐预期。所以看成本不能只看单价要看月度总账单和单位业务量成本两个指标。前者看绝对值后者看效率。两个都健康才算真的降本。5.3 一张速查表应对高频问题现象可能原因排查动作输出格式不稳定prompt 约束不足加结构化输出要求 few-shot重试率高模型对任务理解偏差简化任务、拆分子任务延迟波动大并发或输入长度不均测 P95做请求分级成本不降反升调用量或输出长度增加对比单位任务成本而非单价准确率下降任务超出模型能力该任务单独走旗舰模型长文本效果差超出有效上下文分段处理或先摘要再处理注意这张表是排查起点不是万能药。每个业务的具体原因可能不同关键是养成“先量化、再定位、后优化”的习惯别凭感觉调参。5.4 几个容易被忽略的隐性成本除了 token 费用还有几项成本经常被漏算工程维护成本格式不稳定的模型需要更多兜底代码这些代码要维护、要测试都是人力成本。调试成本换模型意味着重新调 prompt、重新跑评估这部分时间成本不小。迁移成本如果深度绑定了某个模型的特性比如特定的函数调用格式迁移时改动量可能很大。机会成本为了省钱选了一个效果差的模型导致业务指标上不去这个损失往往远超省下的 token 钱。我的建议是把 token 费用和工程成本放在一起算总账。有时候多花点 token 钱换一个稳定的模型整体反而更划算。6. 一套可复用的选型决策框架6.1 决策流程从任务到模型把前面所有内容串起来我实际用的决策流程是这样的拆任务把业务拆成原子任务明确每个任务的输入输出。定标准为每个任务定义可量化的验收标准比如准确率下限、格式合规率下限。采样跑批用真实样本跑候选模型记录 token、延迟、成功率、格式合规率。算成本代入公式算单位任务成本做敏感性分析。分层设计根据任务难度分配模型层级简单的走轻量复杂的走旗舰中间加兜底。小流量验证先放 5% 到 10% 的流量跑一周观察真实指标。全量切换验证通过后逐步放量同时保留回滚能力。这个流程看起来繁琐但跑一遍之后你会对成本结构有非常清晰的认识后面再调整就有据可依了。最怕的是一拍脑袋全量切换出了问题再手忙脚乱地回滚。6.2 什么情况下不该换模型降价很诱人但有些情况下我建议你按兵不动任务本身对准确率极其敏感比如涉及金额计算、合规判断错一次的代价远超省下的钱。当前系统运行稳定且成本可接受如果成本占比本来就不高折腾的收益有限不如把精力放在别处。团队没有评估能力如果没有采样跑批和指标监控的基础设施换模型就是盲盒风险太大。迁移成本高于预期收益算一下迁移需要多少人天对比一年能省多少钱不划算就别动。我个人的原则是降本的前提是不降质如果两者冲突优先保质量。成本优化是个持续过程不是一次性的运动没必要为了短期数字好看去冒业务风险。6.3 后续可以怎么继续优化模型选型和成本核算不是一劳永逸的事。价格会变、模型会更新、业务会演化所以这套评估机制要能持续运转。我的做法是每月跑一次成本复盘看单位任务成本的变化趋势及时发现异常。每季度做一次选型重评估把当前用的模型和市面上的新选项放一起重新比一遍。把评估脚本工具化让跑批、统计、出报告变成一键操作降低重复劳动。建立 prompt 版本管理每次改 prompt 都记录版本和对应的效果数据方便回溯。这套机制跑顺之后你会发现选型决策越来越快因为数据都是现成的不用每次从零开始。我在实际项目里最大的体会就是成本优化的核心不是找到最便宜的模型而是建立一套能持续找到“性价比最优解”的方法。模型会过时方法不会。最后分享一个我一直在用的小技巧每次评估新模型时除了跑标准测试集我还会专门挑一批“历史上让旧模型翻过车”的难样本单独测一遍。这批难样本往往最能暴露模型的真实短板比标准测试集有参考价值得多。这批样本我会一直留着随着项目积累越来越丰富成了选型时最宝贵的资产。