多模型级联实战横评：贵模型先用还是便宜模型先用？我们跑了2000条请求

“用便宜模型先试，不行再升级到贵模型”——这个说法听起来天经地义，但在我们的实测里，它是三种级联策略中性价比最差的一种。

测试设计

• 任务集：2000条真实业务请求，混合客服问答（55%）、结构化抽取（30%）、多步推理（15%）
• 模型档位：L（旗舰，约 $15/百万输出token）、M（中端，约 $3）、S（小模型，约 $0.5）
• 三种策略：
  • A 上行级联：S → M → L
  • B 下行级联：L 先答，用置信度决定是否重答
  • C 路由优先：先用分类器判断难度，直接派给某一档
• 评判：人工标注的黄金答案，二值正确/错误

结果

策略	准确率	相对成本	单条成本	P95延迟
全用 L	94.1%	100%	3.00x	4.2s
全用 M	88.6%	20%	0.60x	2.1s
A 上行级联	91.8%	48%	1.44x	7.9s
B 下行级联	93.5%	67%	2.01x	5.1s
C 路由优先	93.2%	31%	0.93x	2.4s

（成本已归一化，全用 L = 1.00）

结论有三个，都很反直觉：

1. 上行级联的延迟是灾难

A 策略的 P95 延迟达到 7.9 秒，接近全用 L 的两倍。原因是串行：失败才升级意味着一部分请求要跑完两到三轮。而延迟在客服场景里直接等于流失。

2. 上行级联还会“带偏”

更隐蔽的问题：小模型给出的错误答案，有大比例看起来很像对的。你的判据如果只看“格式是否合规”，根本拦不住。实测中 A 策略的漏检率达到 18%——这些请求永远不会被升级，用户直接吃到错答案。

3. 路由的成本优势来自“大部分请求其实很简单”

C 策略之所以便宜又准，是因为任务分布严重偏斜：约 70% 的请求属于 S 档就能做好的简单问题。用一个轻量分类器前置分流，比串联试错高效得多——它不产生额外延迟（分类器用10ms级别的小模型），也不产生重复推理。

那上行级联什么时候是对的

只有一个场景：错误代价极高，且判据可靠。

比如代码生成后要跑测试，测试结果就是100%可靠的判据，这时“不行就升级重试”完全合理。同理适用于SQL执行失败、JSON schema校验失败。

换句话说，上行级联的前提是有一个客观裁判。如果裁判本身是模型打分，那你只是在用两个模型的不确定性互相抵消。

路由分类器怎么建：别训，直接标注

大多数人第一反应是训练一个难度分类器。实测中更省事的做法是：

1. 从历史日志里抽 300~500 条请求；
2. 人工标三档：S够用 / 需要M / 必须L；
3. 用这300条作为 few-shot 示例，交给一个便宜的小模型做在线分类；
4. 每周复盘误派样本，把错判的典型案例补进 few-shot。

这套流程不需要任何训练基础设施，两周内就能上线。我们把它从300例扩到500例后，路由准确率从 81% 提到 89%，超出部分主要来自长尾专业术语。

阈值标定：用“后悔率”而不是准确率

上线后别只看准确率，看两个运营指标：

• 升级后悔率：升级到高档后，正确率提升是否值得增量成本？我们设定的红线是“每1%准确率提升不超过5%成本增量”；
• 降级后悔率：派给小模型但用户重问/投诉的比例，红线 5%。

两个后悔率同时达标，才说明路由真的稳了。

给一个务实的起步配置

如果你现在就想动手，建议是：先做二档路由（S vs L），不要一上来搞三档。

S vs L 的分界最容易标定，收益也最大——通常能直接省掉 55%~65% 的成本，准确率损失不到 2 个点。等这条链路跑稳三个月、积攒了足够的误派样本，再考虑插入 M 档。

级联的本质是把不确定性显式化。方向搞反了，不确定性没减少，只是被藏进了延迟和重复调用里。