智能模型路由：把“选模型”从采购决策变成运行时决策

原创

H
H

AI安全推进计划

2026年11月6日 08:30
北京

去阅读

结论先行：路由的收益上限由“可路由比例”决定，不由算法决定；现有路由器都撞在同一堵墙前；而路由层的长期价值，正在从“省钱”转向“治理”。

开篇：三个数字，先把话说清楚

85%。伯克利与 LMSYS 的 RouteLLM 在 MT-Bench 上把成本砍掉 85%，同时保留 GPT-4 95% 的质量，只有 14% 的请求需要走强模型。这篇论文发在 ICLR 2025，是这个领域被引用最多的“招牌数字”。

0.23 个百分点。2026 年，莱斯大学团队把 21 种路由方法放到 5 个统一基准上重跑，发现 RouterBench 上排名前 15 的方法，准确率差距只有 0.23 个百分点；而最好的路由器，仍落后“每次都选对模型”的 Oracle 10 到 30 个百分点。

第 12 名。独立评测平台 RouterArena 给 12 个路由器排名，某家融资最多的商业路由器排在第 12 位，理由是“过度选择昂贵模型”——你买它就是为了少花冤枉钱，它在中立评测里恰恰在花冤枉钱。

三个数字放在一起，构成了这份报告的全部张力：路由是真金白银的技术，但市面上大部分关于它的说法，都把“某个基准上的上限”当成了“你的预期收益”。

这篇报告不讲“什么是路由”。我们直接进入四个问题：它到底怎么工作、钱在哪里、哪些场景真的成立、以及它在 2026 年变成了什么样的攻击面。

一、先给五个判断

如果你只读一段，读这段。

判断一：路由的天花板由“可路由比例”决定，不由算法决定。 一个请求能不能交给便宜模型，取决于你的业务能容忍多少质量损失——这是业务问题，不是模型问题。这个比例我们记作 r。r 低于 30% 时，任何路由器、任何算法、任何商业方案都不会有实质收益，你只是在给每次请求多加几十毫秒延迟。先测 r，再谈方案。这是唯一正确的顺序。

判断二：所有路由器都撞在同一堵墙上。 “路由高原”（Routing Plateau）不是某家产品的问题，是整个方法族的共性：现有路由器学到的是“模型的全局平均能力”（哪个模型总分高），而不是“这道题哪个模型会做”（实例级正确性）。前者是粗粒度信号，后者才是钱。这就是为什么 kNN 这种 2010 年代的简单方法，在 5 个基准上都能挤进前二——它能捕捉的粗粒度信号，和复杂模型能捕捉的差不多。

判断三：商业路由器不必然更好，选错比不选更贵。 RouterArena 的榜单里，成本跨度从每千次查询 0.04 美元到 10.02 美元，250 倍；准确率跨度 32% 到 80%。这两个数字不是同一个维度的军备竞赛，而是同一个榜单上的真实分布。一个选错的路由器，会同时让你更贵和更差。

判断四：级联优于预分类，因为决策时掌握的信息量不同。 预分类是“看着题目猜难度”，级联是“看着答案判对错”。前者便宜但盲目，后者多花一次调用但严格更知情。在可机器验证的任务上（结构化抽取、代码、必须引用文献的问答），级联几乎总是更优解。这条判断在工程上的含义是：先问“我能不能验证答案”，再问“我该用哪个模型”。

判断五：路由层的长期价值不在省钱，在治理。 模型单价每年在跌，省下来的钱会被降价自然抹平；但“这个请求的数据能不能出境”“这次调用用的是哪个模型、谁批的、依据哪条策略”——这些需求不会因为降价而消失。2026 年企业采购路由器，真正的采购标的正在从“成本优化”转向“策略执行点 + 审计证据源”。

二、被混淆最严重的一件事：路由有三种粒度

大部分关于路由的讨论，把三件不同的事装进了同一个词。

粒度	决策对象	决策频率	典型实现	适用条件
请求级	一次 API 调用用哪个模型	每请求一次	分类器、相似检索、规则	请求之间难度差异大，请求内部同质
会话级	一段对话锁定哪个模型	每会话一次	首轮判定 + 粘性	多轮上下文强相关，切换会破坏一致性
步骤级	Agent 工作流中每一步用哪个模型	每步一次	步骤类型映射 + 失败升级	单任务内步骤异质性高

请求级路由的隐藏假设是：一个请求 = 一个难度。这个假设在 Chat 场景成立，在 Agent 场景失效。一个“帮我分析这份财报并生成 PPT”的任务里，同时存在“从 PDF 提取表格”（小模型足够）、“计算同比并交叉验证”（需要推理模型）、“写结论段落”（需要写作强的模型）三种截然不同的子任务。用请求级路由处理它，等于用一把尺子量三种东西。

步骤级路由的收益，来自“步骤异质性”，不是“请求异质性”。这是 2025 年之后 Agent 大规模落地带来的结构变化：路由的价值从“省一次调用”变成“省一条链路”。一条 12 步的 Agent 任务，如果每步都走旗舰模型，成本是“按步骤最优分配”的 3 到 5 倍；但收益也不是白拿的——步骤级路由需要工作流引擎暴露“当前步骤类型”，这要求架构上把“编排”和“推理”分开，很多团队在这一步就卡住了。

会话级路由则是最容易被忽略、也最容易翻车的一档。它省下的钱不多，但能避免“同一个对话里前后两个模型说法不一致”这种致命体验问题。经验规则：涉及多轮引用、代词消解、状态累积的会话，宁可不路由，也不要中途换模型。

三、六种范式：原理、代价与失效条件

图 2 给出了六种范式的相对定位。需要说明的是，这张表是定性评估，用于范式选型，不是产品横评。

3.1 静态规则与分层（Tiering）

定义：按显式条件把请求映射到固定档位。条件可以是模型名、请求头、租户、token 长度、是否含工具调用。

这是最被低估的范式。它零推理开销、完全可解释、可审计、不会漂移。企业里 60% 以上的路由需求，用规则就能满足——“内部管理后台的请求走便宜模型”“含身份证号的请求走私有化部署”“VIP 租户走旗舰”。这些是策略，不是预测，用分类器去做反而错。

失效条件：流量结构不稳定、任务类型无法用规则表达、需要按“难度”而非“属性”分流。

工程建议：把规则当作地基，而不是过渡方案。任何学习型路由器都应该叠加在规则之上——规则负责“不许去哪里”（合规、地域、能力边界），学习负责“去哪里更好”。

3.2 语义意图分类

定义：用一个小编码器（BERT 类）把 prompt 映射到意图/领域/复杂度标签，再按标签选模型。

2025 年最有代表性的工程实现是 vLLM Semantic Router：用微调后的 ModernBERT 做意图分类，Rust 实现分类核心，通过 Envoy 的 ext\_proc 过滤器接入 Kubernetes。它在 MMLU-Pro 上配合 Qwen3-30B-A3B 的实测结果是：准确率提升 10.24 个百分点，平均延迟下降 47.1%，token 消耗下降 48.5%（arXiv:2510.08731，MLForSys@NeurIPS 2025）。

注意这个结果的真正含义：它验证的不是“路由能省钱”，而是“不是所有问题都需要推理”。同一篇论文的出发点是：对简单事实性问题也套 chain-of-thought，是当前推理系统最大的浪费源。所以它路由的不是模型，是“推理模式”——这一点在第 6.10 节会展开，它往往比换模型更划算。

失效条件：意图体系与真实流量不匹配（最常见）、跨语言时编码器失真、长文档被截断导致分类错误。

3.3 相似度检索（kNN）

定义：把历史请求向量化，对新请求找最近邻，用邻居的“最优模型”投票。

这是被严重低估的一类。在 Routing Plateau 的统一评测里，kNN 在全部 5 个基准上都排进前二。原因很朴素：路由真正能捕捉的信号本来就是粗粒度的“这类问题该用什么档位”，而 kNN 恰好擅长这个，还不需要训练、不会过拟合、新模型加入时只需补数据。

失效条件：冷启动（没有历史数据）、长尾任务（邻居不相似）、流量分布突变。

工程建议：如果团队没有标注数据和训练能力，kNN 是性价比最高的起点，比买一个黑盒分类器更可控。

3.4 级联与验证器（Cascade）

定义：先走便宜模型，用验证器判断答案是否可接受，不行再升级。

这套方法的全部价值在验证器上。没有可靠验证器的级联，等于随机重试。可用的验证器按可靠性排序：

1.形式验证：代码能编译、单测通过、JSON schema 校验、SQL 能执行 —— 最可靠，二元结果

2.证据验证：答案中的每个论断能否在检索到的文档里找到支撑 —— 较可靠，可自动化

3.一致性验证：多次采样答案是否收敛 —— 中等，成本翻倍

4.判官模型：用另一个模型打分 —— 最弱，但最通用

失效条件：验证器本身失效且无人监控。这是生产事故的高发点：供应商悄悄改了输出格式，schema 校验开始 90% 失败，路由器静默地把所有请求升级到旗舰模型，你为每次请求付了两遍钱，而账单要月底才看见。升级率必须当作 SLO 监控，不是当作配置项。

3.5 偏好与正确性预测

定义：用人类偏好数据或正确性标签训练一个路由器，直接预测“这个请求给弱模型，用户会不会满意”。

RouteLLM 是这个路线的标杆：用 Chatbot Arena 的 8 万条人类偏好对战数据训练四种路由器架构，其中矩阵分解路由器表现最好。它的三组数字值得记住，因为它们暴露了“收益高度依赖任务类型”：

基准	成本降幅	质量保留	走强模型比例
MT-Bench（通用对话）	85%	GPT-4 的 95%	14%
MMLU（知识）	45%	GPT-4 的 92%	54%
GSM8K（数学）	35%	GPT-4 的 87%	＞50%

（来源：Ong et al., RouteLLM, ICLR 2025）

这张表比“85%”这个数字重要得多。它说明：通用对话里 86% 的请求确实不需要旗舰模型；而数学题里超过一半必须走强模型——因为数学题没有“差不多对”。

失效条件：偏好数据与业务目标错位（用户“喜欢”的答案不等于“正确”的答案）、分布漂移、新模型加入后未重训。

3.6 平台内置路由

这是 2025 到 2026 年最重要的产业变化：路由从“你自己搭的一层”变成了“模型/平台自带的属性”。

OpenAI GPT-5 的系统卡写得很直白：GPT-5 是一个统一系统，包含一个快速模型、一个深度推理模型，以及一个实时路由器，根据“对话类型、复杂度、工具需求和显式意图”决定用哪个；路由器持续用真实信号训练，包括“用户何时切换模型、回复的偏好率、实测正确性”（OpenAI, GPT-5 System Card, 2025-08-07）。

这句话的信息量很大：最懂模型能力边界的，是训练它的人。厂商内置路由拥有外部路由器拿不到的信号（用户切换行为、内部评测）。这也是外部路由器在通用场景上很难赢的结构性原因。

Microsoft Foundry Model Router 走的是平台路线：单个部署端点，背后最多 18 个模型，提供 Balanced / Quality / Cost 三档路由模式，内置自动故障转移和提示缓存透传。微软在 Ignite 2025 给出的口径是“最高 40% 更快响应、50% 更低成本，无需改代码”。它文档里有两个细节值得架构师注意：

l三档模式的性能带：Balanced 模式大约落在最强模型性能的 1–2% 以内，Cost 模式 5–6% 以内（Microsoft Foundry 文档）。这等于把“质量损失”做成了可选的 SLO。

l模型子集就是治理面：子集决定合规边界（哪些厂商/地域可触达）、有效上下文窗口（等于子集里最小的那个）、成本上限、故障转移池。新模型不会自动进入子集——这是刻意的护栏。

AWS Bedrock Intelligent Prompt Routing 保守得多：只在同一模型家族内路由（Claude Sonnet ↔ Haiku、Llama 70B ↔ 8B、Nova Pro ↔ Lite），官方口径是“最高 30% 成本降低，不影响准确性”，按每千次请求 1 美元计费。

火山方舟的智能模型路由提供了国内语境下更典型的两代形态：旧版是“多模型自主路由”（效果优先/成本优先/平衡三种策略 + 全自动或指定模型集），新版是“基线模型智能降本/增效”——先指定主力模型，再判断是否值得切走。这个演进方向值得注意：从“帮你选模型”退到“帮你判断要不要换”，因为前者太难，后者已经够用。

共同的天花板：平台内置路由只能在其自有模型池内优化。跨厂商的价格差、合规差、能力差，它看不见也用不了。这就是外部路由器和 AI 网关仍然有存在空间的原因——但空间在收窄，且越来越集中在“跨厂商 + 治理”这两件事上。

3.7 横切能力：在线学习

多臂老虎机（bandit）类方法把路由当作“探索-利用”问题：一部分流量用于探索次优模型，一部分用于利用当前最优。它的价值不在准确率，在自适应——模型降价、新模型上线、流量结构变化时，策略能自己移动。

代价是：探索本身要花钱，且探索期的质量波动难以向业务方解释。生产环境里更常见的折中是“影子流量”：真实流量只走当前策略，同时把请求复制给候选模型做离线评估，用影子结果驱动策略更新。这是我认为最值得推广的工程模式——它把“学习”的成本和“决策”的风险分离开了。

四、算一笔账：路由经济学只有三个变量

4.1 公式

在不考虑缓存和批量的简化模型下：

节省率 = r × (1 − 1/k) − overhead

lr：可路由到便宜模型且质量可接受的比例

lk：强弱模型的单价倍数

loverhead：路由自身开销，含分类器调用、延迟、误路由重跑

这个公式的残酷之处在于：它对 r 是线性的，对 k 是边际递减的。k 从 10 倍涨到 100 倍，节省率只从 90% 涨到 99%；而 r 从 0.4 涨到 0.8，节省率直接翻倍。这解释了为什么很多团队换了更贵的路由器却没用——他们的问题是 r 太低，不是 k 不够大。

4.2 一个算例（假设值，仅用于演示结构）

假设月请求 1000 万次，平均每次 6000 输入 token + 400 输出 token。设强模型综合单价为 1.0（归一化），弱模型为 0.08（k≈12.5）。

方案	相对成本	说明
全走强模型	100	基线
全走弱模型	8	质量不可接受
路由，r=60%	44.8	理论值
路由 + 分类器开销	46.2	分类器约为总成本的 1.5%
路由 + 5% 误路由重跑	48.6	重跑按强模型计价

结论：r=60%、k=12.5 时，实际节省约 51%，而不是公式算出的 55%。差掉的 4 个点，就是路由税。

4.3 路由税的四个来源

大部分成本模型漏掉了后两项，而它们经常是净收益为负的真正原因。

（1）分类器调用。便宜，通常可忽略（一次小模型调用约为强模型调用的千分之一）。但在高频短请求场景（如代码补全），它可能比被路由的请求本身还贵。

（2）延迟。分类器通常增加 10–100 毫秒；商业路由器按调用计费的预测步骤，实测有报告在 100–200 毫秒量级。对交互式场景，这直接吃掉体验预算。

（3）误路由的双付。该走强模型的走了弱模型，用户重问或系统重跑，等于付了两次，还多了一次糟糕体验。误路由的代价不是线性的——它集中在长尾，而长尾恰恰是用户最在意的那部分。

（4）缓存失效。这是最隐蔽、也最容易被忽略的一项。

现代推理栈的成本结构里，前缀缓存（prompt caching）是最大的杠杆之一：AWS 宣称其对支持的模型可降低最高 90% 的成本、85% 的延迟。但缓存是按模型实例存的。一旦路由器把带相同系统提示的请求分散到 3 个模型上，每个模型看到的缓存命中率就降到 1/3。

一个反直觉的结论：路由省下的输入 token 钱，可能小于它破坏缓存造成的损失。在有 10 万 token 系统提示、缓存折扣 90% 的场景里，把请求分散到 4 个模型，缓存收益从 90% 掉到约 22.5%，净损失远大于路由带来的单价节省。

这不是理论推演。Microsoft Foundry 的文档明确写了这个耦合：“由于路由决策可能会变化，缓存优势仅当同一模型处理具有重叠提示前缀的连续请求时才适用。”——平台自己在提示你这个反模式。

工程上的对策是“路由亲和性”：在会话/租户维度做粘性哈希，让同一前缀尽量落在同一模型上；或者把“是否值得为省单价而破坏缓存”作为路由决策的一个显式特征。

五、现实检验：为什么大多数路由器省不到宣传的数字

5.1 路由高原

2026 年 5 月，莱斯大学团队发布《The Routing Plateau》。他们做了一件这个领域一直缺的事：把 21 种路由方法（kNN、矩阵分解、BERT 分类器、成对排序、聚类、置信度方法……）放到 5 个基准、统一模型池、统一评测协议下重跑。

三个发现：

1.顶端收敛：RouterBench 上前 15 名方法的准确率差距只有 0.23 个百分点。

2.kNN 常青：简单相似度方法在全部 5 个基准上都进前二。

3.Oracle Gap 顽固：最好的路由器仍落后 Oracle 10–30 个百分点。

他们的解释是“正确性预测瓶颈”：路由器学到的是“模型的全局平均能力排序”，而真实世界里，“哪个模型能答对这道题”与“哪个模型总分高”并不一致。所以所有路由器都在同一批简单题上表现良好，在同一批难题上一起失败。

更值得注意的是他们的“突破尝试”：把训练集从 3 万扩到 30 万条、编码器从 ModernBERT-base 换到 large、端到端微调，三项加起来的提升是 2.13 个百分点，只补上了 14.6% 的 Oracle Gap。

这条结论对采购决策的含义很直接：不要为“我们的路由器准确率更高”支付溢价，因为可测量的差异在噪声量级；要为“可解释、可审计、能在你的流量上校准”支付溢价。

5.2 独立榜单里的商业路由器

RouterArena 是第一个把学术与商业路由器放在同一活榜单上评测的平台，覆盖 9 个领域 44 个类别，指标包括准确率、成本、路由最优性（是否选中了“最便宜但够用”的模型）、鲁棒性（改写/加错别字后决策是否稳定）、延迟。

它的两个结论被广泛引用：

l商业路由器不必然优于开源：榜首是 Azure-Router，但 GPT-5 排第 7（受限于其模型池），NotDiamond 排第 12，原因是“频繁选择昂贵模型”。

l没有路由器在所有指标上排第一：这就是权衡本身。

榜单的成本跨度是每千次查询 0.04 到 10.02 美元（250 倍），准确率 32% 到 80%。这两个数字放在一起说明：这个品类还没有收敛到“标准答案”，选型必须基于自己的流量，而不是榜单。

5.3 LLMRouterBench 的“反直觉”发现

这个基准对比了 10 种路由方法与三个参照点：随机路由、Oracle、以及“Best Single”（事后挑出的、跨数据集平均准确率最高的单模型）。

两个发现值得记住：

l表现最好的方法之一是一个不需要神经网络训练的聚类方法（Avengers-Pro），成本降低最高 31.7%，准确率与 Best Single 持平。

l论文的结论是：embedding 模型的选择对路由性能影响很小，大部分收益来自捕捉“粗粒度的领域结构”。

翻译成人话：路由的收益主要来自“这是代码问题还是合同问题”，而不是“这道题有多难”。这直接指导了工程选择——先做领域/任务类型分流（便宜、可靠、可解释），再考虑复杂度预测（贵、脆弱、收益边际）。

5.4 该信什么，不该信什么

常见说法	该怎么读
“最高节省 85%”	单一基准（MT-Bench）、单一模型对、特定质量容忍度下的上限。不是你的预期值
“不影响准确性”	通常指“在厂商自选评测集上平均分不变”，不代表你的长尾不变
“支持 400+ 模型”	支持不等于校准。未在你的流量上校准的模型，加入候选池只会增加方差
“准确率 98%”	问清楚：在什么意图体系、什么数据集、什么阈值下
“节省 20–97%”	区间宽度本身就说明它不是一个可预测的量

唯一可信的数字，是你自己回放出来的 r。方法在第 7 节给出。

六、十类场景：粒度、信号与失效模式

下面每一节的结构是：流量画像 → 粒度选择 → 关键信号 → 策略组合 → 失效模式。收益区间是经验值，仅用于排序，不可作为承诺。

S1 高并发客服与坐席辅助

流量画像：典型的“二八分布”——60–80% 的请求集中在 3 到 5 类意图（查订单、改地址、政策问答、退款进度），剩余长尾才是真正需要判断力的部分（投诉、协商、例外处理）。

粒度：请求级足够。不要上步骤级，客服对话的步骤结构太弱，收益不抵复杂度。

关键信号：意图分类结果、是否需要调用业务系统、是否含情绪词、是否是重复追问（同一会话第三次问同一件事，说明前两次没解决，直接升级）。

策略组合： 1. 规则兜底：含订单号/手机号 → 直接进工具链，模型只负责措辞，用小模型 2. 分类器分级：政策问答 → 中档；协商/投诉 → 旗舰 3. 级联验证：答案必须命中知识库片段（引用校验），否则升级 4. 会话粘性：同一会话锁定模型，避免前后矛盾

失效模式：把“情绪”误当作“难度”。真实情况更微妙——愤怒的客户需要的是更强的措辞能力（共情、安抚、给台阶），而不是更强的事实查询能力。正确做法是把“情绪”路由到“写作能力强”的模型，而不是“参数大”的模型。这两个维度在很多模型上并不重合。

收益区间：40%–65%。这是 r 最高、验证器最成熟的场景，也是绝大多数企业应该第一个做的场景。

S2 代码生成与 Code Agent

流量画像：四类子任务的经济学完全不同——行内补全（延迟 ＜300ms，单价极低，不能路由到远端）、函数生成（质量敏感，可用级联）、重构/迁移（长上下文，验证器最强）、调试（需要推理，几乎不能降级）。

粒度：补全用请求级（其实是“不路由”）；重构和调试用步骤级。

关键信号：是否有测试、是否有编译错误、上下文长度、是否涉及跨文件依赖。

策略组合： - 补全：本地小模型或专用补全模型，不要路由。延迟预算决定了这里没有决策空间。 - 函数生成：中档模型 + 单测级联。代码是这个世界上验证器最好的领域——编译和测试给出的是二元真值，不是概率判断。这让级联的可靠性远高于其他场景。 - 重构：长上下文模型 + 分块，路由维度是“上下文窗口”而非“难度”。 - 调试：不降级。

失效模式：用 benchmark 分数（如 SWE-bench）代替仓库内评测。一个模型在公开基准上强 3 个点，在你的代码库上可能因为不熟悉内部框架而弱 10 个点。代码场景的评测必须用你自己的仓库、你自己的测试。

收益区间：25%–45%。低于客服场景，因为数学和代码“没有差不多对”——这是 RouteLLM 的 GSM8K 数据（仅省 35%）已经预言过的。

S3 Agent / 工具调用工作流

流量画像：一条任务 5 到 15 步，每步的 token 消耗极不均匀。经验分布是：规划 5%、工具选择 10%、参数填充 15%、结果综合 40%、上下文重放 30%。

粒度：步骤级。这是步骤级路由唯一真正必要的场景。

关键信号：步骤类型（而非任务难度）、当前上下文长度、上一步是否失败、剩余预算。

策略组合： 1. 按步骤类型硬分配，不用分类器：规划→旗舰；工具选择→中档；参数填充→小模型（结构化输出，小模型足够）；结果综合→旗舰（这一步决定用户感知质量）；自我批判→中档。 2. 失败升级：任一步返回错误/超时/校验失败，重试时升一档，且限制升级次数（防止成本螺旋）。 3. 上下文压缩前置：在进入“结果综合”前先摘要，否则长上下文会把旗舰模型的成本放大 3 倍。

关键洞察：Agent 场景的成本大头不是“难度”，是“上下文长度”。一个 12 步的任务，如果每步都携带完整历史，token 消耗是线性增长的；路由能省的是单价，压缩能省的是数量级。先做上下文工程，再做路由——顺序反了，收益会被稀释。

失效模式：按“任务”路由而不是按“步骤”路由。一个“查天气并写邮件”的任务，如果整体判为“简单”而全部走小模型，最终邮件质量会崩——因为“写邮件”这一步需要的是写作能力，与“查天气”的难度无关。

收益区间：50%–70%（相对“全走旗舰”），但绝对收益取决于上下文治理做得好不好。

S4 企业 RAG 知识问答

流量画像：质量方差极大，且方差的主要来源是检索，不是生成。

粒度：请求级。

关键信号：检索置信度，而不是问题难度。这是 RAG 场景最重要的一条工程经验。

策略组合： 1. 检索分数高（top-k 相似度高、多路召回一致）→ 小模型足够，甚至可以用抽取式方法 2. 检索分数低 → 不是换更强的模型，而是触发拒答或澄清。用旗舰模型去生成一个“检索没找到依据”的答案，只会让它更自信地编 3. 引用校验：答案中每个论断必须能定位到检索片段，否则降级为“未找到依据”

失效模式：把 RAG 当成“模型能力问题”。检索召回率 60% 时，换任何模型都不会提升答案正确率——只会提升答案的流畅度，从而降低用户发现错误的概率。

收益区间：30%–50%。但这个数字的前提是检索已经治理好；否则路由是在优化一个错误的环节。

S5 内容生产与营销文案

流量画像：质量主观、评价滞后、单次价值高、调用频次低。

粒度：请求级（按体裁，而非难度）。

关键信号：体裁（公众号/小红书/邮件/公文）、品牌调性、是否需要事实核查。

策略组合：不要用级联。这个场景的验证器不可靠（“这段文案好不好”没有二元真值），级联会退化成“随机重试 + 双重计费”。正确做法是：按体裁硬路由 + A/B 测试 + 人工评分回流，用离线人评驱动策略更新，而不是在线自动判定。

失效模式：用 LLM-as-judge 做在线质量门禁。判官模型对“文风”的判断与人类相关性很低，且存在明显的“偏爱长文本、偏爱排比”偏差，会导致系统持续选择“话多”的模型。

收益区间：15%–30%。这是十个场景里最不该优先做的——收益低、风险高、评测贵。

S6 多语言与出海

流量画像：语种分布极度长尾。前 3 个语种占 90% 流量，剩余 20 多个语种共占 10%，但投诉集中在这 10% 里。

粒度：请求级，按语种，不按难度。

关键信号：语种 ID（可靠的语言识别比难度识别重要得多）、该语种的历史质量分。

策略组合：维护一张“语种 × 模型”的能力矩阵，硬路由。小语种不要用“最强的通用模型”兜底——很多旗舰模型在小语种上的表现断崖式下跌，反而不如专门的区域模型。

失效模式：依赖跨语言 embedding 做相似度路由。多语言 embedding 在低资源语种上的语义对齐质量差，导致“看似相似、实则无关”的邻居，路由结果比随机还差。

收益区间：35%–55%，且风险不对称——路由错了，英语用户会重问，小语种用户会直接流失。

S7 端云协同与隐私路由

流量画像：请求按数据敏感度分层，而非按难度分层。

粒度：请求级，按数据分级。

关键信号：数据分类标签（来自可信中间件，绝不能来自 prompt 文本或客户端 header）、网络状态、设备算力。

策略组合：三级路由——端侧模型（可离线、零数据外发）→ 私有云模型（数据不出域）→ 第三方 API（仅限公开数据）。默认 fail-closed：分级缺失或不确定时，走最保守的一档，而不是最便宜的一档。

失效模式：把“数据分类”交给模型自己判断。这是把安全边界交给一个可被提示词操纵的组件。Apple 的 Private Cloud Compute 之所以强调“可验证的隐私承诺”，正是因为这条链路上任何一环的自证都不够。

收益区间：这个场景的收益主要不是钱，是“能不能上线”。把它当成本项目评估会得出错误结论。

S8 金融、医疗、政务等强合规行业

流量画像：请求价值高、错误代价高、监管约束硬。

粒度：请求级，按数据域 + 业务线。

关键信号：数据域（客户信息/交易/征信/医疗记录）、业务线审批状态、监管地域。

策略组合：候选池是白名单，不是排序列表。先用合规约束把候选池砍到 2–3 个模型（同地域、同数据留存政策、有 DPA/BAA），再在池内做成本优化。任何“为了省钱临时调用池外模型”的路径都必须被物理阻断，而不是靠配置约定。

失效模式：把路由器当成治理系统。路由器简化了访问和选择，但它不能替代身份鉴权、数据分级、合规验证。安全团队最常见的误判，就是把“所有流量都经过网关”当成“所有流量都受控”——实际上你只是有了一个观测点，不是有了一个控制点。

收益区间：20%–40%，且优先级应让位于合规。

S9 离线批处理

流量画像：延迟不敏感（小时级 SLA）、量大、可重排、可重试。

粒度：任务级。

关键信号：截止时间、队列深度、当前各模型的配额余量。

策略组合：这是唯一可以“全力优化成本”的场景。手段包括：批处理 API（通常有 50% 折扣）、低谷时段调度、开源模型自建、多轮验证后重试、失败样本降级处理。在这个场景里，路由的收益可以叠加折扣，达到 60%–85%，但前提是业务能接受“结果晚到”。

失效模式：把在线场景的策略直接搬到批处理。在线场景追求“单次决策正确”，批处理追求“整体吞吐最优”——后者需要队列视角，而不是请求视角。

S10 推理密集任务：路由“思考预算”而非“模型”

流量画像：数学、复杂分析、多步规划。这类任务的特点是：同一个模型，开不开推理模式，成本和质量的差异比换模型还大。

粒度：token 预算级（即“给多少思考 token”）。

关键信号：任务类型（事实查询 vs 需要推导）、是否需要多步验证、历史同类任务的通过率。

策略组合：这是 vLLM Semantic Router 那篇论文的核心贡献——判断“这个问题需不需要 reasoning”，而不是“需不需要更大的模型”。实测在 MMLU-Pro 上准确率 +10.24pp、延迟 −47.1%、token −48.5%。

为什么这个方向被低估：因为大家习惯把“路由”理解为“选模型”，而“选推理模式”是同一个决策空间里更便宜的一维。对固定模型做 thinking budget 路由，不需要处理跨模型的输出格式差异、缓存失效、供应商锁定——工程复杂度低一个数量级。

失效模式：在技术/推理密集领域（工程、计算机科学、数学、生物）效果明显变差，论文自己也承认了这一点。越是需要推理的领域，“判断需不需要推理”这件事本身越难。

七、工程落地：路由层该放在哪里

先把路由拆成五个可独立交付的部分。这张图的价值不在“层”，而在它标出了三件必须分开的事：信号提取（看什么）、决策（怎么选）、执行（怎么保证）。三者耦合在一个函数里，是大多数自建路由最后无法维护的根本原因。

7.1 五种位置

位置	形态	优点	代价	适用
SDK 内	应用代码里调库	最灵活，可用业务上下文	每个应用各写一遍，策略不统一	单团队、快速验证
Sidecar	每 Pod 一个代理	语言无关，就近拦截	运维复杂度高，配置漂移	K8s 原生团队
AI 网关	集中式流量面	统一鉴权/限流/审计/计费	单点，需自己做高可用	多团队、多供应商
推理引擎内	vLLM/Envoy ext\_proc	零额外网络跳，延迟最低	绑定引擎，改造成本高	自建推理集群
平台内置	云厂商 router	开箱即用，免运维	只能在其模型池内优化	单云、快速上线

判断规则很简单：如果你的诉求是“省钱”，SDK 或平台内置最快；如果诉求是“治理 + 跨供应商”，网关是唯一解；如果诉求是“极致延迟”，只能进推理引擎。

7.2 网关与路由器不是一回事

这是采购时最常见的概念混淆，也是最容易多花钱的地方。

l网关是流量面：终结一个 API、持有密钥、计量、重试、故障转移。它是确定性的，行为可测试。

l路由器是决策函数：决定这次请求给哪个模型。它是预测性的，误差要到几周后才在质量指标里显现。

买网关，把路由策略当自己的应用代码来管。这个分工的好处是：故障转移这种“确定性管道”可以按 SLA 采购，而“预测”这部分的风险留在自己手里，可回退、可审计、可解释。

7.3 必须监控的八个指标

没有这八个指标，路由就是不可运维的。

指标	为什么关键	告警阈值（起点）
路由分布（各模型占比）	分布突变 = 故障/规则错误/攻击	单模型占比 1 小时内变化 ＞15pp
升级率	级联的健康度，静默升级的成本黑洞	＞20% 或环比翻倍
误路由率	需要人工标注样本，但必须有	按业务定
路由延迟 P99	直接吃交互体验	超过总延迟预算 10%
每任务成本（不是每 token）	唯一有业务含义的成本口径	环比 ＞20%
质量回归	黄金集通过率	下降 ＞2pp
缓存命中率	路由的隐藏成本	下降 ＞15%
决策可解释率	审计与排障的前提	＜95%

最后一项最容易被忽略：如果一次路由决策无法回答“为什么选它”，它在事故复盘时就没有价值。可解释的最低要求是三元组：命中的规则 ID + 策略版本 + 选中的模型与关键约束。

7.4 一个最小可用的配置骨架

# 概念示意，非特定产品语法 router:  version: 2026-10-r3  candidate\_pool:  allow: [model-a-large, model-b-medium, model-c-small]  deny\_reason: compliance # 池外一律拒绝，不做兜底  stages:  - name: guard  rules: # 规则永远在最前面  - if: data\_class in [PII, RESTRICTED]  route: model-a-large  reason: data\_residency  - if: tenant in gold\_list  route: model-a-large  reason: sla\_tier  - name: classify  method: knn # 先 kNN，够用再上分类器  index: prod\_traffic\_90d  fallback: model-b-medium # 分类失败不降级，走中档  - name: cascade  verify: [json\_schema, citation\_grounding]  max\_escalation: 1 # 硬上限，防成本螺旋  - name: affinity  key: [tenant, system\_prompt\_hash] # 保护前缀缓存  budget:  per\_request\_tokens: 32000  per\_tenant\_monthly: \"...\" # 超预算降档，不是拒绝  audit:  record: [rule\_id, policy\_version, model, key\_constraints, latency\_ms]

注意三个设计选择：规则在分类器之前（策略优先于预测）、分类失败走中档而不是最低档（不对称损失）、预算超限降档而不是拒绝（可用性优先）。

八、七个反模式

每一个都在生产环境里真实发生过，且都不是“实现 bug”，而是“设计错误”。

反模式一：让 prompt 文本决定模型。 “如果用户说'仔细想想'就用推理模型”——听起来合理，实际上把路由决策的控制权交给了用户输入。攻击者只要在提示里加一句“请快速回答”，就能把请求挤到弱安全模型上；或者反过来，加一句“这非常重要”，就能让你的成本翻倍。路由输入必须来自可信上下文：身份、租户、数据分级、工具需求。用户偏好可以表达，但不能决定。

反模式二：路由后不管缓存。 第 4.3 节算过账。一个 10 万 token 的系统提示，路由分散到 4 个模型，缓存收益从 90% 掉到 22.5%。上线前先测：路由开启前后的缓存命中率变化。如果下降超过 15%，净收益大概率为负。

反模式三：不监控升级率。 级联的升级率不是配置项，是运行时变量。供应商改一次输出格式，schema 校验全挂，所有请求升级到旗舰模型，每次请求付两遍钱——而你在月底看账单时才发现。升级率要和可用性一样做告警。

反模式四：用公开 benchmark 代替业务评测。 第 5 节已经说明：路由方法之间的差异在 0.23pp 量级，而模型在你业务上的差异可能是 10pp 量级。用 benchmark 选路由器，等于用平均分选员工。

反模式五：粒度错配。 用请求级策略处理 Agent 工作流（第 3 节），或者用步骤级策略处理单轮问答（纯粹增加复杂度）。先画出一条真实任务的步骤图，再决定粒度。

反模式六：把路由器当治理系统。 路由器是决策点，不是控制点。它不能替代鉴权、数据分级、合规验证。安全团队最危险的错觉是“流量都过网关，所以都受控”。

反模式七：决策逻辑不在自己手里。 如果你的路由策略只存在于某家 SaaS 的黑盒里，你既无法在事故时解释它，也无法在业务变化时修正它，更无法在供应商涨价时迁移它。可以租用校准，不要租用决策权。

九、被忽略的一章：路由层自身就是攻击面

这一章在大多数路由报告里没有，但它是 2026 年最该补的一课。

9.1 结构性矛盾：它必须看见明文

一个 LLM 路由器要在 L7 上做决策，就必须读到 prompt、工具调用参数、响应体。这些内容在它这里必然是明文——端到端加密会破坏路由本身。这不是实现缺陷，是架构属性。

于是路由器天然成为一个“应用层中间人”：它持有你的上游密钥，看见你的全部业务数据，并且有能力改写模型返回的 tool\_call 参数，而客户端无从校验——因为没有任何机制能证明“客户端收到的工具调用”与“模型原始生成的”一致。

9.2 实测数据

2026 年的一项测量研究抽测了 28 个商用路由/中转服务和 400 个免费服务，结果：

l9 个主动向 tool\_call 中注入恶意代码（1 个商用、8 个免费）

l17 个在植入的 AWS 金丝雀凭据流经后使用了这些凭据

l1 个从植入的监控私钥中盗走了资金

l注入行为具有条件性：有的在第 50 次请求后才开始改写，有的只针对“自动执行、无需人工确认”的会话——短测试完全正常

同期的 LiteLLM 供应链事件提供了另一个样本：攻击者污染其 CI 中的 Trivy 扫描器，窃取 PyPI 发布令牌，发布带恶意 .pth 载荷的 1.82.7/1.82.8 版本，Python 启动即执行。恶意版本存活约 40 分钟，下载量超过 11.9 万次。

9.3 四类攻击

类别	手法	为什么客户端防御失效
载荷注入	改写 tool\_call 参数：把 pip install 的包名换成同形异义域名、在命令后追加外联	响应格式完全合法，无签名可比对
凭据窃取	被动留存全部 prompt 与上游密钥，事后复用	传输加密到路由器为止，路由器就是终点
路由决策注入	用“快点回答”等提示把请求挤到弱安全模型，绕过原模型的过滤	决策依据来自不可信的 prompt 文本
成本操纵	制造超长上下文、反复触发升级，放大账单	升级逻辑通常只看“是否失败”，不看“是否被诱导失败”

9.4 五条防御

1.策略与路由分离：允许哪些模型、哪些地域、哪些数据级别，由路由之外的组件（策略引擎/网关前置）决定，路由器只能在允许集内排序。

2.fail-closed：候选池耗尽时拒绝，不降级到池外。故障不构成“可以发到未授权厂商”的授权。

3.决策审计三元组：规则 ID + 策略版本 + 选中模型与约束。不存全量输入也能解释决策。

4.模型等价性测试：两个模型不等价，即使同一个端点。工具调用格式、schema 解释、拒绝策略、注入抵抗力都要逐一对比，作为入池门槛。

5.把路由器当特权组件：它的供应链（构建、依赖、发布）与它的运行时同等重要；密钥短周期轮换、按租户隔离、按可恢复泄露来设计。

十、选型与路线：先测量，再决策，最后自动化

10.1 三十天，只做一件事：测出 r

方法：抽 2–4 周真实流量（不少于 5 万条），用候选的便宜模型全量回放，用你的业务口径（不是 benchmark）判定“这个答案可接受吗”。

这个比例就是你的天花板。它决定了后面所有投入的上限，也决定了这个项目该不该做。

10.2 一条决策路径

测出 r ├─ r ＜ 30% → 停止。这不是路由问题：要么场景选错，要么该做的是 │ 上下文工程 / 检索治理 / 提示优化 / 微调 ├─ 30% ≤ r ＜ 50% → 只做规则分层 + 硬边界。不要买路由器。 │ 收益 15–25%，投入最小，风险最低 ├─ 50% ≤ r ＜ 70% → 规则 + kNN + 单场景级联。可考虑网关承载。 │ 收益 35–55%，需要 1 名工程师 + 评测集 └─ r ≥ 70% → 值得上学习型策略与多场景推广。  收益 55–75%，但必须同步建漂移监控与影子流量

10.3 采购时该问的十个问题

1.你的路由器在我这类流量上的 r 是多少？请用我的样本回放，不要用你的 benchmark。

2.决策用了哪些信号？其中哪些来自我不可控的输入（如 prompt 文本）？

3.候选池能否按合规/地域白名单收窄？收窄后新模型会不会自动进入？

4.决策是否可解释？能否输出“规则 ID + 策略版本 + 约束”三元组？

5.升级率如何监控？供应商侧模型更新会不会导致静默升级？

6.路由是否保护前缀缓存？有没有亲和性机制？

7.故障时的行为是 fail-open 还是 fail-closed？能否配置？

8.我的 prompt 和响应在你的系统里留存多久？谁能访问？密钥如何隔离？

9.策略能否导出？迁移到自建或其他网关的成本是多少？

10.你的定价是按请求、按 token 还是按节省额分成？分别在我的量级下折算成多少钱？

第 1 题会筛掉大部分供应商。第 9 题会筛掉剩下的。

结语：三个预测

一、路由会从“一层”变成“一个属性”。 GPT-5 的系统卡已经写明“未来计划把这些能力整合进单一模型”。当模型自己知道自己会不会做，外部路由器的价值就退回到“跨厂商比价”和“治理执行”两件事上。这不是坏事——它逼着这个品类去解决真问题。

二、竞争焦点会从“准确率”转向“可运维性”。 既然 21 种方法的准确率差距在 0.23pp 量级，那么决定成败的就不是算法，而是：能不能解释、能不能回滚、能不能在你的流量上校准、能不能在供应商变更时不出事。这是一个从“研究问题”变成“运维问题”的转变。

三、路由层会成为 AI 安全的新边界，而大多数团队还没意识到。 它是唯一同时看见“用户意图、业务数据、模型行为、工具调用”的组件。这意味着它既是最高价值的观测点，也是最高价值的目标。第 9 节那些数字不是危言耸听——它们来自对 428 个真实服务的抽测。

附录 A：数据溯源表

结论 / 数字	来源	时间
MT-Bench 省 85%、保留 95% 质量、14% 走强模型；MMLU 45%；GSM8K 35%	Ong et al., RouteLLM, ICLR 2025	2025
21 种方法收敛；RouterBench 前 15 名差 0.23pp；Oracle Gap 10–30pp；扩数据+换编码器仅补 14.6%	Lu et al., The Routing Plateau, arXiv:2606.07587	2026-05
商业路由器不必然更优；NotDiamond 第 12（过度选贵模型）；GPT-5 第 7；成本跨度 250 倍	RouterArena, arXiv:2510.00202	2025-10
embedding 选择影响小；聚类方法 31.7% 降本	LLMRouterBench（转引自独立评测综述）	2026
语义路由：MMLU-Pro 准确率 +10.24pp、延迟 −47.1%、token −48.5%	When to Reason: Semantic Router for vLLM, arXiv:2510.08731, MLForSys@NeurIPS 2025	2025
GPT-5 实时路由器依据对话类型/复杂度/工具需求/显式意图；用切换行为与偏好率持续训练	OpenAI, GPT-5 System Card	2025-08-07
Model Router：最多 18 个模型；Balanced 1–2%、Cost 5–6% 性能带；最高 40% 更快、50% 更低成本	Microsoft Foundry 文档 / Ignite 2025 Book of News	2025-11
Bedrock IPR 同族路由，最高 30% 降本，$1/千次请求	AWS Bedrock 定价页与产品页	2025–2026
前缀缓存最高降本 90%、降延迟 85%	AWS Bedrock 产品页	2025–2026
428 个路由器抽测：9 个注入代码、17 个使用金丝雀凭据、1 个盗走资金	Wang et al., 路由器测量研究（经 Help Net Security 报道）	2026-04
LiteLLM 供应链事件：1.82.7/1.82.8 恶意版本，存活约 40 分钟，11.9 万+ 下载	Snyk / PyPI / Trend Micro 事件分析	2026-03
400+ 模型、60+ 供应商、月处理 token 量级 100T	OpenRouter 官网	2026-10

说明：本报告中的“收益区间”“可路由比例”若无特别标注，均为基于上述公开数据的经验映射，不是本报告的实测结果。图表 5 的数值用于场景排序，不可作为采购承诺依据。

附录 B：术语

术语	含义
r（可路由比例）	可交给便宜模型且质量可接受（按业务口径）的请求占比
k（价格倍数）	强模型与弱模型的单价比值
路由税	路由自身引入的成本：分类器、延迟、误路由重跑、缓存失效
Oracle Gap	最优路由器与“每次都对”的理论上限之间的准确率差
路由高原	不同方法收敛到同一准确率窄带、且远低于 Oracle 的现象
静默升级	验证器失效导致所有请求被动升级到强模型，成本隐性上涨
路由亲和性	让同前缀请求落在同一模型上，以保护前缀缓存
fail-closed	决策失败时拒绝，而非降级到未授权选项
---