模型路由：为什么 AI 应用不该每个问题都调用最强模型

为什么 AI 应用不该每个问题都调用最强模型

一个产品通常同时面对三类请求：简单的分类和改写、中等难度的知识问答，以及需要长链路推理或复杂工具调用的任务。如果所有请求都交给最贵、最强的模型，质量可能不错，但成本和延迟会一起上升；如果全部交给小模型，简单任务很划算，难题却容易失败。

模型路由（Model Routing）就是在请求进入主模型之前，先判断它适合哪一个模型。简单问题走便宜、快速的模型，困难问题才升级到更强的模型。它把“选哪个模型”从开发者写死的配置，变成了一个可以测量、调优和持续学习的系统决策。

RouteLLM 项目概念图

RouteLLM 的论文把问题表述成质量与成本之间的权衡，并提供了一个开源框架来训练和评估路由器。它的核心思想并不是“永远选小模型”，而是让小模型处理它擅长的请求，把强模型预算留给真正需要的地方。

路由和负载均衡不是一回事

负载均衡只关心“把请求平均分到哪台机器”，例如两台相同模型服务器各处理一半流量。

模型路由关心的是“这个请求需要什么能力”：

翻译、摘要、格式转换可以走轻量模型。
复杂代码修复、数学推理和多步骤规划可能需要强模型。
企业内部某类术语，可能应该路由到专门微调过的模型。

所以路由器评估的不只是流量，还包括任务类型、复杂度、领域、上下文长度、用户等级和失败代价。

三种常见路由方式

规则路由：最容易上线

可以先用明确规则：包含代码块就走代码模型，超过某个上下文长度就走长上下文模型，涉及付款就走经过安全评估的模型。

规则简单、可解释、容易审计，但它通常只能看到表面特征。一个短问题也可能很难，一个很长的请求也可能只是重复文本。

分类器路由：学习“谁更适合回答”

分类器可以根据历史请求、人工偏好或评测结果，预测不同模型在当前问题上的胜率。RouteLLM 的思路就是用偏好数据训练路由器，在强模型和弱模型之间做选择。

这里最重要的不是预测“这个问题难不难”，而是预测“强模型相对于弱模型能带来多少额外收益”。如果两个模型都能答对，就没有必要为了保险升级。

级联路由：先便宜，失败再升级

级联先调用小模型，再用规则、校验器或评审模型判断是否需要升级。例如结构化输出校验失败、答案缺少引用、置信度不足时，再把原问题交给强模型。

它比单次路由更稳，但最坏情况下会付出两次调用的成本。对于不可接受错误的场景，级联通常比一次性押注路由器更容易解释。

路由器到底应该看哪些信号

最容易想到的信号是输入长度，但它只能说明上下文大，不代表任务难。更有用的信号通常来自四个方向：

任务能力：是否需要代码、数学、翻译、视觉或长文档理解。
任务风险：回答错了是“改写不自然”，还是会触发付款、删数据或对外发信。
结构约束：是否要求严格 JSON、引用证据、固定字段或可执行工具参数。
业务预算：用户等级、实时性要求、剩余配额和当前模型可用性。

这些信号应当组合使用。例如，一个 100 字的“帮我修改退款金额并提交”并不长，却有明显副作用；一个 50 页的会议纪要摘要可能很长，但只需要稳定的长上下文模型，不一定需要最强推理模型。

可以把决策结果理解成一个“质量—成本前沿”：在满足任务质量门槛的前提下，选择成本最低的模型；只有当便宜模型无法达到门槛时，才升级。这个原则比追求一个固定的“最强模型胜率”更适合生产系统。

级联中的质量门槛怎么做

质量门槛不能只依赖模型自己说“我有信心”。更可靠的是组合多个可验证信号：

JSON 能否通过 Schema 校验。
答案是否覆盖问题里的必答字段。
引用是否真的支持对应结论。
工具参数是否通过类型、权限和业务规则检查。
轻量评审器是否发现明显矛盾或遗漏。

例如客服 Agent 先用小模型生成答案，再检查引用和退款金额。如果引用缺失，就升级到强模型；如果金额与订单 API 不一致，则直接停止自动回复。这种设计把“升级”从模糊的主观判断变成了可测试的状态机。

注意质量门槛也会制造额外调用。一个评审器如果和强模型一样昂贵，路由系统就可能变成“先调用路由器，再调用评审器，再调用主模型”。因此第一层优先使用确定性校验，只有无法用规则判断的质量问题才调用评审模型。

一个可落地的路由策略

假设你在做一个企业知识助手，可以先定义四个等级：

L0：改写、分类、提取字段，使用小模型。
L1：单文档问答，使用成本较低的通用模型。
L2：跨文档比较、需要引用的问答，使用更强模型或检索级联。
L3：涉及审批、代码修改或高风险判断，使用强模型，并要求人工确认。

路由器先根据请求类型和风险选择候选级别，再由质量门槛决定是否升级。这样“模型强弱”不是唯一维度，权限和失败代价也进入了决策。

可以把升级条件写得很具体：

JSON Schema 校验失败。
必须引用资料但没有找到证据。
工具参数缺字段或类型错误。
评测器判断答案没有覆盖问题中的关键约束。
用户请求涉及不可逆副作用。

这些条件比“感觉模型答得不自信”更容易测试。

路由器本身也有成本

如果每次请求都先调用一个昂贵的路由模型，节省下来的钱可能被路由器吃掉。路由器应该足够快、足够便宜，最好能复用已有输入特征，或使用规则与轻量分类器做第一层筛选。

此外，模型能力会变化。今天的小模型可能在摘要上很好，下一次版本升级后却改变了格式习惯；供应商价格、限流和延迟也可能调整。因此路由策略不能只在上线前评估一次。

上线要像发布一个模型一样谨慎

路由器本身也会产生回归。一个新路由器可能把更多请求送进便宜模型，账单下降了，但复杂问题成功率也下降；或者路由判断准确，却因为额外网络往返让 P95 延迟变差。

比较稳的发布方式是分阶段进行：

离线回放：用脱敏后的真实请求和人工质量标签比较不同策略。
影子模式：新路由器参与判断，但不改变真实模型，只记录它会怎么选。
小流量灰度：按租户或请求类型逐步放量，监控升级率、质量和尾延迟。
自动回滚：当高风险任务错误率、结构化失败率或人工投诉超过阈值时，切回固定模型。

路由日志至少要记录最终选择、候选模型、路由理由类别、是否升级和结果质量。不要记录一段让模型自由生成的“解释”作为唯一审计依据；真正可审计的是输入特征、规则版本、阈值和最终决策。

模型更换时还要重新校准。旧模型上的“0.5 阈值”没有理由在新模型上继续成立，尤其当价格、上下文能力、工具遵循能力和输出格式发生变化时。

如何正确评估路由效果

不要只看平均成本。至少要维护一个包含真实流量分布的评测集，并同时比较：

质量：任务成功率、人工偏好、结构化校验、引用正确率。
成本：平均输入输出 Token、模型调用次数、升级比例。
延迟：P50、P95，以及升级请求的尾延迟。
安全：高风险任务是否被正确升级，是否出现越权调用。
稳定性：路由器换模型、换领域、换用户群后是否退化。

RouteLLM 官方仓库也强调，路由阈值应使用与真实请求相近的数据进行校准，而不能直接照搬公开数据集上的阈值。因为同一个阈值，在客服、代码助手和内容审核场景里的含义完全不同。可以参考其开源实现和评测说明。

常见误区

误区一：按 Token 长度判断难度。 长文本不一定难，短问题也可能需要复杂推理。

误区二：只追求最省钱。 如果升级率很低但错误率明显上升，节省的是账单，损失的是用户信任。

误区三：用模型评模型却不做人工抽样。 自动评审可以扩展覆盖面，但自身也会有偏差，关键业务仍需要人工复核。

误区四：把路由器当成永久真理。 模型、价格、流量和用户目标都会变，路由策略必须和评测、观测、回滚一起建设。

误区五：忽略失败后的用户体验。 路由升级失败时，不能只返回“模型错误”。应该告诉用户正在重试、请求人工处理，或明确哪些部分已经完成。路由系统是产品流程的一部分，不是藏在 API 网关后面的黑盒。

什么时候值得采用

当你只有一个低流量原型时，固定使用一个模型更简单。模型路由真正有价值的信号通常是：调用量已经上升、不同任务能力差异明显、模型账单开始影响业务，或者你需要把小模型与领域模型组合起来。

推荐的最小落地顺序是：先记录真实请求与质量结果，再用规则做第一版路由；确认成本和质量边界后，再训练或接入分类器；最后为高风险流程加入级联、人工确认和自动回滚。

结语：把模型选择变成产品策略

模型路由不是简单的“省钱开关”，而是一套质量、成本、延迟和风险之间的决策系统。最好的路由器不会让所有请求都走小模型，而是让每个请求得到“足够完成任务”的能力。

落地清单：

是否知道不同任务分别需要什么能力？
是否有真实请求组成的路由评测集？
是否定义了升级条件和高风险任务的硬规则？
是否把路由延迟和调用成本纳入总账？
是否能在质量退化时快速切回固定模型？