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 条，统计结果如下：
- 平均输入 token：1200
- 平均输出 token：180
- 重试率：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 都记录版本和对应的效果数据，方便回溯。
这套机制跑顺之后，你会发现选型决策越来越快，因为数据都是现成的，不用每次从零开始。我在实际项目里最大的体会就是：成本优化的核心不是找到最便宜的模型，而是建立一套能持续找到“性价比最优解”的方法。模型会过时，方法不会。
最后分享一个我一直在用的小技巧：每次评估新模型时，除了跑标准测试集，我还会专门挑一批“历史上让旧模型翻过车”的难样本单独测一遍。这批难样本往往最能暴露模型的真实短板，比标准测试集有参考价值得多。这批样本我会一直留着，随着项目积累越来越丰富，成了选型时最宝贵的资产。
