大模型路由怎么做：选型、成本核算与效果评测

最强的模型，应该用在真正需要它的任务上。核验身份后的订单状态查询，与记录相互矛盾的退款争议，不该默认走同一条处理路径。难点在于：要在低价回答造成高昂返工之前，识别出两者的差别。

下文涉及的产品行为已于 2026 年 10 月 21 日依据当时的在线文档核实。客服工作负载与计算均为示例，不代表生产环境实测结果，也不是厂商宣称的节省幅度。

大模型路由到底在做什么？

大模型路由器是一套规则，或一个经过训练的分类器，用来为每个请求选择负责回答的大语言模型，也就是 LLM。分类器的作用是将输入归入某个类别。路由器可以根据应用中的任务类型、对话内容、所需工具、输入长度或预估难度来选择模型。

可以把它想成客服团队的派单员：常规查询交给能高效处理的人，争议案件交给专员。如果某项工作超出了所有人的权限，派单员还需要知道该如何升级处理。

落实到应用中，就是先检查模型是否符合条件，再谈优化：它能否处理这份输入、调用所需工具，并通过获准的服务提供方运行？只有满足这些条件的模型，才有资格进一步比较成本和预期质量。

**模型路由、服务提供方路由和失败回退，解决的是不同的问题。**模型路由决定由哪个模型回答；服务提供方路由决定选定模型在哪里运行，例如选择哪家托管服务商；失败回退决定一次尝试失败后接下来试什么。网关是应用与模型 API 之间的接入层，可以实现上述所有机制。但接入网关，本身并不意味着系统就能按质量要求选择模型。

本文所说的前沿模型，是候选范围中通用能力最强的模型。它仍然可能答错。路由分配的是模型能力，并不能保证答案正确。

模型路由的三种实现方式

**先用能解释清楚的规则。**当自动选择能够处理规则遗漏的变化，同时仍通过验收检查时，它才有价值。下面三种实现方式并非互斥：网关也可以承载经过训练的路由器。

在应用中编写路由规则

应用根据已知任务类型和约束，将请求分配给模型。例如，一个来自订单状态接口、携带已核验订单数据和获准回复模板的请求，比一条仅仅因为篇幅短就被判为“简单”的消息，更适合交给小模型。

应用已经掌握工作流程时，规则很有用。局限在于模糊情况：同一个接口，既可能收到直接查询，也可能收到涉及矛盾记录的投诉。遇到不确定的请求，应保留明确的处理路径，而不是不断堆叠脆弱的关键词规则。

使用网关的自动路由

将请求发给一个路由别名，由网关选择模型。具体选择方式因产品而异，可能采用分类器、预设档位或其他信号。这样可以集中管理行为，但也意味着你接受了该路由器对“合适模型”的定义。

如果输入任务变化较大，而自行维护选择器又不划算，可以考虑这种方式。要限定获准使用的候选模型，并记录实际作答的模型。别名不能作为稳定的模型身份标识。

训练路由器，并持续校准

经过训练的路由器会从样例和结果标签中学习：哪个候选模型更可能表现得好。训练时真正有用的问题是“更强的模型能否为这个请求带来价值”，而不只是“这段文字看起来是否复杂”。

RouteLLM 是用于部署和评估路由器的开源框架，其文档介绍了基于偏好数据训练的强弱模型选择，以及阈值校准。阈值控制较强模型被选中的频率。它公布的结果，不能证明它在你的工单上也有同样表现。参见 RouteLLM 文档。

维护中的难点是数据分布变化：新增任务类型或更换模型，都可能让原本有效的阈值失效。应在开发样例上训练或校准，再用从未参与调优的独立案例评测。

用客服应用走一遍路由策略

**有据可依、边界清晰的回复交给小模型；尚未解决的推理问题交给前沿模型。**授权仍由应用策略决定。模型能解释退款，并不意味着它就有权执行退款，无论它是哪一种模型。

假设一家采用订阅制的零售商，其应用会在起草回复前，检索客户订单、相关政策和对话历史。下表是一套拟议策略，并不表示某个特定小模型已经能通过这些要求。

缺少必要证据时，小模型这条路径应停止作答。应用可以检查订单字段缺失、输出结构无效，或请求的操作超出获准流程等情况。事实矛盾可能需要独立验证器或人工审核。格式合法的答案，内容仍然可能是错的。

把困难的那部分请求交给前沿模型；小模型失败后，只有在失败能够被检测出来时，才谈得上升级处理。缺失记录需要补充检索或澄清。把同样缺失证据的输入转发给更大的模型，并不能补上证据。

别漏算升级后的额外调用

假设一个示例批次包含 1,000 个请求。策略将其中 700 个发给小模型，300 个直接发给前沿模型。最初交给小模型的请求中，有 70 个未通过检查，需要由前沿模型重新处理。

此时要支付的是 700 次小模型调用和 370 次前沿模型调用，再加上路由与验证费用。负责作答的模型一共调用了 1,070 次，而不是 1,000 次。即使用户只看到最终回复，重试仍然是额外的工作。

设 r 为每个原始请求的平均路由成本，s 为每次小模型调用的平均成本，f 为每次前沿模型调用的平均成本，g 为整个批次额外产生的网关或验证费用。为简化示例，假设基线、直接调用和升级调用中的前沿模型平均成本相同：

路由方案成本 = 1,000r + 700s + 370f + g

全部使用前沿模型的基线成本 = 1,000f

只有满足 700(f − s) > 70f + 1,000r + g，路由方案才更便宜。左边是初次作答时，通过小模型路径省下的费用；右边是额外调用前沿模型重试的费用及其他开销。

根据所选模型及费率填写调用成本。若费率按每百万 token 报价，则 单次调用成本 =（未缓存输入 token 数 × 输入费率 + 已缓存输入 token 数 × 缓存费率 + 计费输出 token 数 × 输出费率）/ 1,000,000；另行计费的工具和请求费用还需加上。

在生产环境中，应按任务和路由路径的实际用量计算，取代上述简化平均值。困难工单可能生成更长的回答，重试可能携带更多上下文，切换模型也可能影响缓存复用。适用时，要计入路由分类器消耗的 token 和需要计费的推理 token，同时避免重复计费。比较两套系统时，应使用相同的重试策略。

真正有价值的结果，是在守住质量底线的前提下，降低每个通过验收的解决结果所对应的成本。如果账单降了，却多出了没有依据的退款承诺，这个方案就没有过关。

各家路由方案，文档里究竟承诺了什么？

**接入路由端点前，先看清它如何做选择。**这些产品开放的决策机制不同，名称里都有“路由”，不代表默认行为就一样。

OpenRouter：按任务选择模型的 Auto Router

OpenRouter 是连接多家模型服务提供方的托管网关，通过 openrouter/auto 提供 Auto Router。其现行文档描述的流程是：先对任务分类，再根据社区在过去 7 天窗口内针对该类任务的消费情况，为模型排序，之后按成本档位和适用条件筛选。这是汇总后的使用信号，并不是你的客服质量评分标准。参见 Auto Router 文档。

cost_tier 可选 low、medium、high、xhigh 和 max；默认行为大致相当于 low。档位代表一个区间，并非硬性支出上限。可以用 allowed_models 和 excluded_models 限定候选范围，并记录响应中的 model 字段。会话粘性可以让一次选择延续下去，但不保证模型始终固定。

在环境变量中设置 API 密钥后，可以用下面的最小示例发送路由请求：

curl --fail-with-body https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/auto",
    "messages": [{"role": "user", "content": "Rewrite this status politely: Your parcel is in transit."}],
    "plugins": [{"id": "auto-router", "cost_tier": "low"}]
  }'

评测时应限定候选模型。否则，模型池一旦变化，昨天的质量结果就更难解释。

LiteLLM：部署路由与 Auto Router 要分开看

LiteLLM 是可配置的 LLM 网关。其文档列出的部署路由策略包括加权选择、选择最空闲部署、按延迟路由和按成本路由。默认的 simple-shuffle 策略并不是用来判断客服工单难度的分类器。参见路由器文档。

它另有一套 Auto Router，文档介绍了启发式、LLM、关键词规则和自定义插件等分类器。SIMPLE、MEDIUM、COMPLEX 和 REASONING 档位映射到已配置的模型或模型池。文档中的控制台设置路径为 Models + Endpoints → Add Model → Auto Router，完成配置后运行 Test Routing。参见 Auto Router 文档。

如果开发者需要掌控候选模型和分类行为，这种方案比较合适。难点在于运维责任由自己承担：配置了档位映射，并不等于它已经通过你的验收规则。LiteLLM 与 OpenRouter 对比进一步讨论了这项基础设施选择。

Vercel AI Gateway：服务提供方选择与显式路由控制

Vercel AI Gateway 是模型 API 的托管接入层，会根据近期可用率和延迟选择默认服务提供方。它的服务提供方选项可以控制顺序和筛选条件；以字符串指定的模型回退配置，会在主模型失败或不可用时尝试备用模型。这些都是有用的可靠性机制，但仅凭这些机制，无法判断一张客服工单是否需要前沿模型。参见服务提供方路由与回退文档。

网关的路由规则还支持将请求中的模型改写为另一个模型，或拒绝该请求。改写可以集中迁移流量，但把发给某个模型的所有请求统一替换，与逐条判断请求难度，是两回事。参见路由规则文档。

需要明确控制行为时，可以在应用层选择策略之下使用这些功能。容易踩的坑，是误以为自动选择服务提供方也包含了按任务质量自动选模型。若要比较更广泛的接入层方案，可参阅多模型应用的 AI 网关选择。

Microsoft Foundry：由服务提供方托管的训练型路由器

Microsoft Foundry model router 是经过训练的模型选择器，以部署的形式提供。Microsoft 表示，它依据复杂度、推理要求、任务类型等属性进行选择，提供 Balanced、Quality 和 Cost 模式，也支持模型子集。参见模型路由器概念文档。

对于已经使用 Foundry、希望在符合条件的模型之间实现托管选择的应用，这种方式比较合适。关键限制是候选范围：地区和访问权限影响模型可用性；Microsoft 文档还提醒，底层模型中最小的上下文窗口，会限制路由器能够可靠接收的输入。应将子集限定为满足输入要求的模型。

模式名叫 Quality，也不能代替任务评测。要用实际的对话长度、工具和验收规则，测试所选模型子集。

AI 模型路由该怎么选？

如果能可靠识别简单任务，就保留应用规则。当任务变化让规则变得脆弱时，再考虑托管自动路由。有了足够多具备代表性、带结果标签的样本，且值得投入持续维护时，才考虑训练选择器。

如果还需要比较这些机制之外的基础设施方案，可以接着看 OpenRouter 替代方案指南。首要决策始终是路由策略及其依据，而不是把服务商名单列得更长。

如何用评测集检验路由效果？

**要评估路由最终产出的答案，而不是看它是否认同“简单”“困难”之类的标签。**选择器即使能准确区分任务类别，也可能把本该交给强模型的案例发给小模型。

评测集是一组可以重复运行的请求、上下文和验收标准。对于客服应用，每个案例都应包含对话、订单数据快照、适用政策、预期事实、禁止出现的说法或操作，以及规定的升级处理方式。

评测表应让代价高昂的错误显现出来：

如果某项指标的分母没有符合条件的案例，应标为“未定义”，不能记为零。有害的小模型分配率，应根据对两个模型输出的独立评测来估算，同时报告升级处理后的最终错误。两个模型都失败的案例要单独标记：选择器无法让这些候选模型凭空产出合格答案。

测试前就要确定可接受的非关键质量差异，并调查每一项新增的严重退步。应采用适合配对样本的置信区间；如果不确定性范围仍包含不可接受的质量损失，就继续收集证据，而不是宣布两者效果相当。

最后，在限定范围的真实流量上运行影子测试，由路由器并行处理，而客户仍由现有模型服务。影子调用会产生额外费用。审查结果后，再进行小范围上线，并确保能够立即切回现有模型策略。按请求类型持续监控；提示词、工具、模型或路由行为变化时，重新运行评测。

关于模型路由，哪些说法被夸大了？

**“质量不变、成本更低”是特定工作负载下才能得出的结论，不是路由器自带的属性。**它取决于收到什么请求、有哪些候选模型，以及怎样才算合格。别人业务中的节省百分比，不能代替你自己的测量。

API 成功返回，也说明不了多少答案质量问题。错误回退可以应对端点不可用，却无法识别一段流畅回答中编造的政策。要因质量问题触发升级，必须有独立检查；而检查本身也有错误率和成本。

难度评分同样需要审视。分类器的置信度，并不天然等于所选模型答对的概率。任何阈值都应根据观察到的任务结果校准。不能让用户输入“这很简单”之类的文字，覆盖应用权限或候选模型限制。

此外，即使应用代码没有变化，自动选择也可能发生变化。OpenRouter 基于消费数据形成的候选范围会变；Microsoft 当前的 model-router 版本也可能新增底层模型。这些文档已说明的行为，意味着记录候选模型、更新评测，都是路由器运行维护的一部分，不能当作可有可无的收尾工作。

谁适合现在做，谁应该再等等？

**能筛出可重复识别、且通过条件清晰的任务，开发者就可以动手。**为有依据的状态回复增加小模型路径，对不确定的情况保留保守处理方式，并为策略做版本管理，以便复现失败。

**运营负责人应要求看到整个工作流程的证据。**如果工单重开、人工审核或解决耗时增加，仅仅降低推理账单并不够。除了离线评测，还要跟踪这些结果。

**采购方应要求用自己的案例回放验证。**所选模型和回退行为必须可见。通用基准测试无法证明路由器理解你的退款政策。

如果还无法定义正确结果、无法约束候选模型池，或流量不足以收回运维投入，就先等等。如果应用已在固定而狭窄的任务上使用通过验证的小模型，再增加一个选择器，收益可能很有限。

下周一就能做的事：导出一组有代表性的客服案例，固定其中的证据，让当前模型和一个更小的候选模型并排接受评测。针对小模型能够通过的那部分任务，写一条范围明确的路由规则。只有自动路由器在满足相同质量要求的同时，成本还能低于这条规则时，才把流量交给它。

模型路由常见问题

订阅通讯，获取 AI 应用构建与评测的实用指南。