多模型路由：把大部分请求交给便宜模型的正确姿势

同一套业务里请求难度差别极大：有「改一下措辞」，也有「分析这份合同的风险条款」。全用旗舰模型是浪费，全用便宜模型会翻车。

但大多数路由实现写成了关键词 if-else，效果不稳、维护成本高。

一、路由的三个层次

规则分流：长度、有无附件、任务类型。能解决 30% 的场景，零成本、可解释，先做没错。

难度打分：用小模型或 embedding + 分类头给请求打分，超过阈值走大模型。这是路由主体。

置信度回退：便宜模型输出后，用廉价验证器判断「靠不靠谱」，不靠谱再升级。性价比最高，最常被漏掉。

二、四步实现

1. 定义质量可判定标准。 路由的前提是能判断好坏，做不到就别做。可行方式：结构化输出能否 parse、是否引用了不存在的字段、轻量打分模型给 1–5 分、有标准答案时直接比对。

2. 离线建难度分布。 拿 500~1000 条真实请求，两个模型都跑，记录「便宜模型失败、贵模型成功」的比例并按特征分桶。这是唯一值得花大钱做全量对比的环节。

3. 先做回退，再做预测。 顺序很重要。回退策略的错误代价是延迟，预测策略的错误代价是质量，先保质量。

4. 常驻评估。 供应商升级小模型后，你的阈值可能就过时了。每周跑固定评测集，盯「便宜模型成功率」和「升级率」。

三、两个容易翻车的设计

路由不可观测。 线上出问题，你得能回答「这条请求为什么走了便宜模型」。每次请求必须记录分流原因、难度分、置信度、最终模型。没有这几个字段，路由就是黑盒。

级联放大延迟。 便宜模型超时 → 升级 → 贵模型也慢，用户等了三倍时间。必须设总超时预算，且对已升级过一次的请求不再升级，直接降级返回。

四、收益估算

在难度分布正常的业务里（如客服 + 数据分析混合），路由通常能做到：6075% 请求走便宜模型，综合成本下降 4060%，质量损失 < 2%（用固定评测集衡量）。

若算出来收益低于 20%，说明请求难度太集中，直接用中端模型更划算，别为架构而架构。

五、什么时候不该做

请求量小（每天 < 几千）、质量要求极高且难以判定（医疗、法律意见）、团队没有评测体系——三条任一成立，都不建议上路由。没有评测就没有路由，这是硬前提。

路由本质是用工程复杂度换成本。先量出成本痛点在哪，再决定要不要换。