统一模型路由，开发者不买账了

Manifest 近日宣布弃用自家的 LLM 路由器，理由不是模型不够多，而是统一路由带来的复杂度已经超过它创造的价值。就在大量团队仍把“自动选择最佳模型”包装成 AI 应用的下一层基础设施时，一家真正把路由器交给用户的公司选择了后退。

这不是 LLM 路由器已经死亡的证据，却是一个值得开发者警惕的信号。论文里的路由器通常面对固定基准、明确成本和可重复评分，生产环境里的路由器却要同时处理模型更新、工具调用、结构化输出、限流、数据合规与故障恢复；前者解决的是选择题，后者更像一个持续变化的分布式系统。

**LLM 路由器是根据请求内容、成本预算、延迟目标或服务状态，在多个大语言模型之间自动选择执行路径的调度层。**它最诱人的承诺很简单：简单问题交给便宜模型，复杂问题交给强模型，最终获得接近旗舰模型的质量，同时减少推理成本。

退潮的不是路由，而是“万能路由器”

统一模型路由的核心假设正在失效：不同模型可以被当成能力有高低、价格有差异但接口基本等价的计算单元。这个假设在纯文本问答时代勉强成立，但在 2026 年的 Agent、工具调用和长任务环境里，模型之间的差异已经不只是“谁更聪明”。

一个模型可能拥有更稳定的 JSON 输出，另一个模型更擅长函数调用；一个模型支持原生图像理解，另一个模型能处理更长上下文；即使两者都能完成任务，它们对系统提示词、工具描述和推理预算的敏感度也可能完全不同。路由器如果只看用户问题，就像只看乘客目的地来派车，却不看车辆是否能装货、司机有没有通行证，以及道路是否限高。

Manifest 的弃用决定因此更像一次产品现实校正。开发者真正需要的往往不是“帮我猜一个模型”，而是“这次调用必须可预测、可复现，出了问题还能定位”。当路由层隐藏模型选择后，同一类请求可能在不同时间落到不同模型上，输出风格、工具参数乃至安全拒答策略都会随之改变。

这也是为什么“大家都在造路由器”和“用户愿意把生产流量交给路由器”是两回事。前者说明模型选择是一个真实问题，后者要求路由器对业务结果负责，而不仅是给出一次看似合理的模型名称。

统一抽象最终会漏出模型差异

统一接口只能抹平请求格式，不能抹平模型行为。文本消息、温度、最大输出长度等字段相对容易统一，但推理强度、提示缓存、工具并行调用、结构化输出约束、多模态输入和服务端状态等能力并没有稳定的共同语义。

| 路由维度 | 统一路由的理想状态 | 生产环境的实际问题 | 可能后果 | | --- | --- | --- | --- | | 模型能力 | 能力可以按统一分数排序 | 编程、检索、工具调用和写作能力并非单调关系 | 选到综合分高但不适合当前任务的模型 | | 成本 | 按输入、输出 token 单价比较 | 缓存、推理 token、工具重试和长输出都会改变总成本 | 单次调用便宜，完整任务反而更贵 | | 延迟 | 小模型一定更快 | 排队时间、区域、限流和冷启动可能高于生成时间 | 路由决策正确，用户体验仍然更差 | | 上下文 | 窗口越长越适合长任务 | 可接受长度不等于能稳定利用全部上下文 | 长文档进入模型后仍出现遗漏 | | 工具调用 | 所有模型都能遵守同一工具描述 | 参数格式、并行策略和纠错能力存在明显差异 | Agent 循环重试甚至执行错误操作 | | 安全策略 | 拒答规则可以统一配置 | 不同模型的内置策略和版本更新并不一致 | 同一产品出现前后矛盾的回答 |

最低公分母接口还会产生一种反直觉结果：接入的模型越多，平台越难发挥每个模型的独特能力。为了保持可替换性，开发者只能少用厂商专属功能；一旦业务依赖某项专属能力，所谓“一键切换模型”就只剩下形式上的兼容。

模型数量还会放大测试成本。假设系统接入 8 个模型，仅做两两行为比较就存在 8×7÷2，也就是 28 组模型组合；如果再乘以 5 类任务、3 个延迟区间和2种工具配置，就会得到 840 个评测切片。新模型上线、旧模型升级或价格调整后，这些结论都可能需要重跑。

路由器很容易把省下的钱花回去

路由器的成本不能只计算最终被选中模型的账单。分类模型本身要消耗计算资源，路由决策会增加一次网络或本地推理延迟，错误选择还会触发重试、升级模型和结果校验。

一次失败后升级到旗舰模型的请求，通常不是“便宜模型成本加一点”，而是同时支付便宜模型、旗舰模型以及额外延迟。如果便宜模型完成一次任务花费 1 个成本单位，旗舰模型花费 10 个单位，那么失败升级后的总成本是 11 个单位，比一开始直接使用旗舰模型高 10%；若还需要裁判模型检查结果，总成本会继续上升。

隐性成本往往比 token 单价更难控制。团队需要维护路由规则、离线评测集、在线反馈、供应商健康检查、回退链路和版本记录，还要解释为什么某次请求被送进某个模型。对请求量不大的产品而言，这套基础设施节省的推理费用，可能还不够覆盖一名工程师维护它的时间。

学术结果也不能直接等价为生产收益。RouteLLM 等研究证明，偏好数据和成对比较可以训练出有价值的强弱模型路由器，但论文中的“质量”通常由特定基准或裁判模型定义；企业真正关心的可能是合同字段有没有遗漏、工具参数是否可执行，以及用户会不会因为回答风格突变而流失。

最大的问题是无法稳定定义“最佳模型”

“最佳模型”不是一个固定标签，而是质量、价格、延迟和风险共同作用的结果。对批量摘要任务，便宜和稳定可能比推理上限重要；对代码迁移任务，一次正确完成通常比节省几分钱更有价值；对涉及资金操作的 Agent，可验证性又比语言自然度更重要。

路由器如果没有业务结果反馈，就只能优化代理指标。提示词长度、关键词、分类标签和基准难度都只是间接信号，它们无法确认模型最终是否完成了用户任务。一个问题看上去简单，不代表回答它所需的隐含知识简单；一个提示词很长，也可能只是让模型从文档中提取一个日期。

在线反馈同样存在延迟和偏差。点赞率容易受表达风格影响，任务成功率可能几个小时后才能确定，人工评分则昂贵且难以覆盖长尾场景。没有稳定反馈，自动路由就会逐渐退化成一组看起来智能、实质上难以审计的启发式规则。

模型更新速度让路由策略迅速过期

动态模型池是统一路由面临的另一项结构性难题。模型会持续上线、下线和静默更新，供应商也会调整价格、限额和默认行为；一个季度前训练出的路由器，可能仍在根据已经不存在的能力差异分配请求。

UniRoute 一类研究试图解决这一问题。**通用模型路由是把每个模型表示为能力特征向量，使路由器可以根据模型画像选择训练阶段未见过的新模型。**相关实验尝试把新模型在小型验证集上的表现映射到推理、编程、对话等任务簇，据此让它加入候选池，并在超过 30 个未见模型的范围内检验泛化能力。

这种思路解决了“每加一个模型就完整重训”的部分成本，却没有消除生产环境中的校准问题。小验证集只能描述模型在已定义任务上的能力，无法提前覆盖企业私有数据、复杂工具链和新型失败模式；模型画像越简洁，更新越容易，但它丢失的行为信息也越多。

真正留下来的路由，会更窄也更硬

LLM 路由并没有消失，而是在从开放式模型竞猜转向边界明确的策略执行。vLLM Semantic Router 使用轻量级分类器识别请求意图和复杂度，并把语义缓存、安全检测、推理模式选择与基础设施调度结合起来；这种路由知道候选模型、部署环境和任务类型，目标也比“全网选出最佳模型”具体得多。

| 路由方式 | 是否值得采用 | 适用场景 | 主要限制 | | --- | --- | --- | --- | | 跨厂商自动选择任意模型 | 谨慎采用 | 探索性产品、模型评测平台 | 行为不可预测，评测与维护成本高 | | 固定大小模型二选一 | 通常可行 | 客服、摘要、批处理生成 | 必须有可靠的复杂度分类和升级机制 | | 按业务类型显式分流 | 推荐 | 编程、翻译、检索、内容生成 | 需要维护清晰的任务边界 | | 按合规与数据区域分流 | 必要 | 金融、医疗、政企系统 | 规则优先，不能单纯交给学习模型 | | 同一模型切换推理预算 | 优先考虑 | 能力需求相近但难度不同的任务 | 依赖模型自身提供可控推理模式 | | 按集群负载调度同一模型 | 推荐 | 自托管推理、大规模批处理 | 主要解决基础设施问题，不提升模型质量 |

规则路由看起来不够“智能”，却往往更适合生产系统。例如，包含图像的请求固定进入多模态模型，涉及代码仓库的任务进入代码模型，低风险闲聊进入快速模型，执行写操作的 Agent 固定进入经过工具调用评测的模型。每条规则都能解释，也能单独监控。

模型内部路由也正在替代一部分外部路由需求。统一系统可以在快速回答与深度推理路径之间分配计算预算，而应用层只面对一个相对稳定的产品接口。厂商掌握模型训练、推理负载和能力边界，通常比外部路由器更容易完成校准，但代价是开发者获得的控制权和供应商可替换性进一步下降。

开发者应该先做评测，再决定是否路由

评测集是模型路由真正的起点。团队至少需要收集 200 至 500 条来自真实业务的代表性任务，并为每条任务记录成功条件、可接受延迟、失败代价和是否允许升级；如果连“回答得好”都无法被稳定定义，增加一个路由器只会让问题更难定位。

上线时也不应该立刻让路由器控制全部流量。更稳妥的方式是先运行影子路由：路由器只记录它会选择哪个模型，但真实请求继续走固定模型。开发者随后比较候选选择与真实结果，测算错误路由率、升级率、端到端成本和 P95 延迟，而不是只看分类准确率。

路由收益应该按完整任务计算。一个可操作的指标是“每个成功任务成本”，即总推理费用、重试费用和校验费用之和，除以最终成功的任务数；另一个关键指标是“不可恢复失败率”，它比平均模型得分更能反映路由是否伤害用户。

退出机制必须在路由上线前准备好。生产系统应允许按租户、任务和模型版本关闭自动选择，并保留明确的默认模型；当模型行为变化或路由器置信度不足时，系统应该迅速退回确定性路径，而不是继续尝试更多模型。

路由器退潮，说明 AI 工程开始去魅

Manifest 的决定并不意味着多模型架构没有价值，而是提醒行业区分“统一接入”“故障切换”和“智能选模”这三个不同问题。统一接入解决工程接口，故障切换解决可用性，智能选模才需要判断任务与模型能力；把三者都塞进一个黑盒路由器，通常会得到难以测试、难以解释的系统。

真正有价值的路由器不会承诺理解所有模型和所有任务。它会拥有有限候选池、清晰目标、持续评测和强制回退机制，并且只在节省的成本显著高于错误代价时介入。对多数团队来说，三条透明规则加一个可靠默认模型，可能比一个会学习但无法解释的万能路由器更有用。

这轮退潮本质上不是开发者放弃调度，而是开发者不再愿意为“自动选择最佳模型”这句模糊承诺买单。路由最终会留下，但它更可能藏在模型内部、推理集群和具体业务流程里，而不是作为一个能够无差别替换所有模型的独立魔法层。

参考来源

• RouteLLM GitHub 仓库：LMSYS 开源的成本与质量感知模型路由框架，包含训练、评测和路由方法。
• RouteLLM 论文页面：介绍如何利用偏好数据在强模型与弱模型之间学习路由策略。
• vLLM Semantic Router：面向自托管推理的语义路由项目，覆盖任务分类、缓存、安全与推理调度。
• LLMRouter GitHub 仓库：用于研究和比较多种模型路由及训练策略的统一框架。