模型分级的成本策略：怎么定义 Tier、怎么落地
很多团队第一次讨论”要不要分级用模型”时，讨论的其实是路由算法——怎么写一段代码自动判断该调哪个模型。但路由是执行层的事，往上还有一层没人讲清楚的东西：分级策略本身怎么定。也就是，你的 Tier 应该分几档、每档对应什么模型、谁有权限用哪一档、以及什么时候该把整套策略推倒重来。
这篇文章不讲路由引擎怎么写（这部分可以看多模型成本智能路由方案），而是讲分级这件事本身——一个更偏组织和治理的问题。
一、为什么”分几档”比”怎么路由”更容易出错
大部分团队分级失败不是因为路由代码写错了，而是分级设计本身有问题。常见的三种坑：
档位太多，维护不动。 见过团队按”极简单/简单/中等/复杂/极复杂”分五档，每档绑定不同模型和参数组合。三个月后没人记得住第三档和第四档的区别是什么，新人接手直接懵。档位数量应该反比于团队规模——五人以下团队，三档封顶。
档位定义用”感觉”而不是用指标。 “复杂任务用高档模型”这种描述没法落地，因为”复杂”是主观词。分级依据必须能用可测量的信号表达：输入 token 数、是否需要多步工具调用、下游是否有人工复核、失败重试成本。
没有逃生舱。 只设计了”选哪一档”，没设计”这一档不够用怎么办”。用户问题超出预期复杂度，模型在低档上循环重试三次都没解决，此时应该自动升级到高档还是直接返回错误？没提前想清楚，线上就会看到同一个请求被低档模型反复消耗 token 却拿不到结果。
二、三档模型分级的参考框架
给一个可以直接套用的起点，具体模型按你能拿到的价格表替换：
| 档位 | 定位 | 适用场景 | 典型延迟预算 | 单次成本量级 |
|---|---|---|---|---|
| Economy | 高频、低风险、可批量重试 | 分类、标签提取、格式转换、摘要 | 宽松（可异步） | 最低 |
| Standard | 默认档，覆盖大多数业务逻辑 | 问答、文档生成、代码补全 | 中等（同步交互） | 中等 |
| Premium | 低频、高风险、错误代价高 | 复杂推理、多步规划、生产代码审查 | 可以放宽换质量 | 最高，但占比应控制在个位数百分比 |
关键不是这张表本身，而是每一档都要写清楚”进入条件”和”退出条件”——什么样的请求默认落在这一档，什么信号会触发跨档流转。没有退出条件的分级迟早会退化成”一律用 Standard”，分级形同虚设。
三、分级依据：用信号说话，不用直觉
推荐按优先级组合以下几类信号，而不是单靠一个维度判断：
- 输入复杂度：token 数、是否包含结构化 schema、是否需要长上下文。
- 任务类型标签：在业务代码里显式声明”这是分类任务”还是”这是生成任务”，不要指望模型自己判断自己该被分到哪一档。
- 失败历史：如果某类请求在 Economy 档的历史失败率超过阈值（比如 15%），把它整体上调一档，而不是逐条重试。
- 下游影响面：面向付费客户的输出 vs 内部工具的输出，容错空间完全不同，应该分开定级，不能因为”任务类型相似”就合并处理。
这四类信号里，失败历史是最容易被忽视但最有效的一条——它是唯一一个能自我纠偏的信号，其余三类都依赖人工预设，容易过时。
四、团队配额：分级策略离不开权限设计
技术团队讨论分级时容易漏掉一个维度：谁能用 Premium 档，谁不能。没有配额设计的分级策略，实际效果往往是”人人都默认申请最高档，因为没人告诉他们不该这样”。
一个可落地的配额结构：
- 按团队/项目设定 Premium 档的月度调用上限，而不是按人头限制（按人头容易被拆分账号绕过）。
- 超限后不是硬断，而是自动降级到 Standard 档 + 告警通知负责人，避免功能直接中断。
- 配额用量周报发给团队负责人而不是只有工程侧看到——成本责任需要业务侧共同承担，纯技术团队自己扛成本压力容易导致”能跑就行”的短视决策。
具体的预算硬上限设计和告警阈值，参考AI API 预算上限设计，那篇文章讲的是配额之上的兜底红线；这里讲的是配额本身怎么分。
五、新模型发布时，分级策略要不要重做
每次头部厂商发新模型，都会有人问”是不是该把 Tier 表整个换一遍”。答案通常是不需要，但要做一次校准，流程如下：
- 用现有的分级评测集（如果没有，先补一个，覆盖每档的典型任务各 20~30 条），跑一遍新模型。
- 对比新模型在”低一档”位置的表现，而不是默认它能顶替同价位的旧模型——新模型的性价比曲线经常和旧模型不在同一个位置。
- 只替换单一档位，不要因为新模型全面更强就重新设计整个分级框架。分级框架的稳定性本身有价值，频繁重构会让团队失去对分级规则的信任，最后又变成”该用哪个自己拍脑袋”。
换句话说：模型可以经常换，分级框架不应该经常换。框架变动的触发条件应该是”现有档位数量或依据信号本身出了问题”，而不是”出了个更强的模型”。
六、常见反模式速查
| 反模式 | 后果 | 修正方式 |
|---|---|---|
| 分级依据写在代码注释里，没有文档 | 新人不知道规则，随手改路由逻辑破坏分级 | 分级规则和”进入/退出条件”单独成文档，代码只是实现 |
| 只设计升级路径，没设计降级路径 | 高峰期全员挤在 Premium 档，成本失控 | 降级路径同等优先级设计，且要有告警 |
| 分级评测集从来不更新 | 新任务类型出现后分级判断持续失真 | 每次模型迭代或业务改版后同步复核评测集 |
| 把”路由算法”和”分级策略”混为一谈 | 换路由框架时连带把业务分级规则也推翻了 | 分级策略独立于具体路由实现，写成配置而不是代码逻辑 |
七、相关阅读
分级策略定好之后，剩下的执行细节——多提供商切换、故障转移、统一计费——可以交给基础设施层解决，YoTradeApi 提供统一 API 入口对接 Claude、GPT 等主流模型，省去你自己维护多套 SDK 和账单对账的麻烦。