不是所有活都需要最贵的那个模型。分层是最容易见效的一步，但降级必须配验收标准。
一句话结论：不是所有活都需要最贵的那个模型。
把任务按难度分层，让不同的活走不同价位的模型 —— 这是少数不需要改产品、也不需要改数据结构就能看见效果的一步。但它有一个前提，而且这个前提经常被跳过：降级必须带验收标准。
现象
很多系统的默认形态是「所有请求都走同一个模型」，而且通常是能力最强、单价也最高的那个。
原因可以理解：开发时用最好的那个最省事，也最不容易出错。但一段时间之后回头看，会发现请求里混着大量根本不需要那么强能力的活。
拆解：哪些活可以降级，哪些不要碰
可以降级的三类：
| 类型 | 为什么可以 | 典型场景 |
|---|---|---|
| 格式转换类 | 输入输出都被规则框死了，容错空间小，能力过剩 | 表格转字段、固定模板填空 |
| 分类与抽取类 | 判断维度是固定的，答案空间有限 | 归类、打标、从一段文本里抽值 |
| 短问答与重复性生成 | 答案不需要长链条推理 | 标准话术、模板化文案 |
不该降级的两类：
- 需要长链条推理的活 —— 步骤一多，弱模型会从中间某一步开始偏，而且偏得不明显。
- 结论会被直接用于对外交付的活 —— 一旦错，代价不在账单上，在客户那里。
结论
正确的做法不是「换个便宜模型试试」，而是给每一层配一个验收标准：
- 把这个任务的历史调用拿出来，形成一批固定的测试样本；
- 用便宜的模型重跑这批样本；
- 用事先定好的标准判对错，得到一个通过率；
- 通过率达标 → 这一层长期走便宜模型；不达标 → 维持原样，不要为了省成本放宽标准。
先定标准，再换模型 —— 顺序反了，就等于把风险从账单转移到了客户现场。
边界（什么情况下本文不成立）
- 如果同一批请求的能力需求本来就一致（例如全部都是长链条分析），那么分层没有意义，本文不适用。
- 降级省下的多少，取决于你的请求里各层占比，以你自己改后的账单为准；本文不给任何省幅估计。
- 本文不比较、也不点名任何厂商：哪个模型适合哪一层，应当由你自己的测试结果决定，而不是由别人的推荐决定。
你可以怎么自己验证
不用接系统，也不用改代码：从你自己导出的用量明细里挑一批真实调用，用另一档模型重跑同样的输入，人工比对通过率。
通过率是对比出来的，不是我说的。
来源与说明
- 分层方式属于通用做法，不涉及任何厂商的评测结论。
- 来源：元舵 Tunenomics 对外统一口径（对照复核日期：2026-09-18）。
- 本文不含客户原始数据，不含实测数字与省幅承诺。
本文为元舵「AI 成本观察」系列。文中方法说明与结论口径均可核对；数字均标注来源、口径与日期。示例数据不代表任何客户的真实结果。