Microsoft 刚曝光的 Project Perception 在三家模型间按任务路由;RouteLLM 实测省 85% 成本保 95% 质量。「用哪个模型」正在从人工选择变成一个工程系统——这就是路由层。
你的应用每天发出成千上万次 LLM 请求,其中大部分是「帮我改个措辞」这种简单活,少部分是「重构这个模块」这种硬活。全部用旗舰模型,是拿大炮打蚊子,账单爆炸;全部用便宜模型,硬活答不好,质量崩盘。
模型路由器(Model Router)就是解决这个两难的中间层:它先看一眼每个请求,判断难度和类型,再把它转发给「能答好的模型里最便宜的那个」。应用只管调一个统一入口,后面用了谁由路由器决定。
数据来源:RouteLLM 官方 README(lm-sys)、AWS Bedrock 官方产品页、Braintrust / Digital Applied 2026 综述(第三方,见文末来源清单)。
两年前做 LLM 应用,标准做法是选定一个模型,把 API key 写进配置,完事。那时模型选择少、价差小,「选型」是上线前做一次的决定。
现在的局面完全不同。同一件事可用的模型太多了,而且价差拉到了几十倍:GPT-5.6 一家就分 Sol($5/$30 每百万输入/输出 token)、Terra($2.5/$15)、Luna($1/$6)三档;Kimi K3 这样的开源前沿模型 API 定价 $3/$15,还能自己部署;Thinking Machines 的 Inkling 干脆 Apache 2.0 放出权重。模型能力此消彼长,上个月的最优选这个月就可能被超越。
面对这个局面,如果还靠工程师拍脑袋定「我们全用旗舰」,会遇到三个具体的痛:
一句话动机:当「可选模型 × 价格档位 × 能力差异」的组合复杂到人脑管不过来,「用哪个模型」就必须从配置项变成系统的运行时决策——这个决策系统就是路由层。
这两个词经常混用,但 OpenRouter 官方博客给了清晰的区分:
OpenRouter 官方把路由拆成两个相互独立的决策,这个拆分对理解一切路由产品都适用:
models 数组,供应商级回退默认开启。「看一眼请求就知道该给谁」听起来玄,拆开看其实是四代技术,一代比一代聪明:
code 标签的走编码强的模型、超长上下文走 1M 窗口模型、内部工具走便宜档。零训练成本、完全可控、可审计,但规则粒度粗,覆盖不了「同类任务难度不同」的情况。绝大多数团队的第一步。mf(官方推荐)、加权 Elo 的 sw_ranking、BERT 分类器、LLM 分类器 causal_llm。官方强调:虽然它们在 GPT-4/Mixtral 这对模型上训练,但换成别的强弱模型对也能泛化,无需重训。以最经典的第 2 代为例,一条请求进来后发生了什么:
阈值不是拍脑袋定的,是「校准」出来的:你告诉工具「我希望大约 50% 的请求走强模型」,它在数据集上反推出对应阈值(官方示例:50% 对应 0.11593)。官方同时提醒——默认用 Chatbot Arena 数据校准,你的真实流量分布和 Arena 不同,所以应该用贴近自己业务的查询样本重新校准,否则实际分流比例会跑偏。
适合:想把路由逻辑握在自己手里、有工程能力自己部署的团队。RouteLLM 是 LMSYS(Chatbot Arena 团队)出品,Apache 2.0,GitHub 约 5k star。以下步骤和代码全部来自官方 README:
pip install "routellm[serve,eval]"import os
from routellm.controller import Controller
os.environ["OPENAI_API_KEY"] = "sk-XXXXXX"
# 弱模型走 Anyscale 的 Mixtral(官方示例,可换任意供应商)
os.environ["ANYSCALE_API_KEY"] = "esecret_XXXXXX"
client = Controller(
routers=["mf"], # 官方推荐的矩阵分解路由器
strong_model="gpt-4-1106-preview", # 强模型
weak_model="anyscale/mistralai/Mixtral-8x7B-Instruct-v0.1", # 弱模型
)> python -m routellm.calibrate_threshold --routers mf \
--strong-model-pct 0.5 --config config.example.yaml
For 50.0% strong model calls for mf, threshold = 0.11593response = client.chat.completions.create(
model="router-mf-0.11593", # 用 mf 路由器、阈值 0.11593 路由本请求
messages=[{"role": "user", "content": "Hello!"}]
)不想改代码?它还能起一个 OpenAI 兼容服务器(python -m routellm.openai_server ...),任何现有 OpenAI 客户端把 base URL 指过来就接上了路由。模型接入靠 LiteLLM 打底,支持大量开源/闭源供应商,也支持 Ollama 本地模型。
两个官方注明的细节:① 无论用哪对模型,mf 和 sw_ranking 路由器目前都需要 OPENAI_API_KEY 来算嵌入;② 仓库研究底座是 2024 年论文(arXiv:2406.18665),工程上活跃但理念偏「双模型对」,要在 3 个以上模型间路由需自行扩展 Router 抽象类(只需实现 calculate_strong_win_rate 一个方法)。
适合:不想自己运维路由层,希望一个 API key 接入所有模型的团队。OpenRouter 是「你直接调用的路由器」:一个 OpenAI 兼容端点,前面 400+ 模型、60+ 供应商,月处理 100 万亿 token(官方数字)。以下机制与代码均来自其官方博客(2026-06-12)与文档:
from openrouter import OpenRouter
client = OpenRouter(api_key="<OPENROUTER_API_KEY>")
resp = client.chat.send(
model="anthropic/claude-sonnet-4.6", # 改这个字符串就是换模型
messages=[{"role": "user", "content": "Summarize this changelog."}],
)
# 已在用 OpenAI SDK?把 base URL 指到 https://openrouter.ai/api/v1 即可同一个模型有多家供应商时,你不配置任何东西的话,OpenRouter 按三步走:① 近 30 秒内出过故障的供应商排到队尾;② 在稳定供应商里按「价格的平方反比」加权抽选;③ 其余作为回退。官方算例:A($1/M)、B($2/M,刚出过故障)、C($3/M)三家,A 被优先尝试的概率约是 C 的 9 倍(1/1² 对 1/3²),B 垫底。平方的意义是把流量狠狠推向最便宜的健康供应商,而不是均匀摊。
| 需求 | 写法 | 效果 |
|---|---|---|
| 合规要求只走指定供应商 | provider.order + allow_fallbacks: false | 按序尝试,失败即止,绝不静默回退到第三方 |
| 用户对话,时延敏感 | 模型名后加 :nitro | 等价 sort:"throughput",按吞吐路由 |
| 批处理,成本封顶 | 模型名后加 :floor,配 max_price | 等价 sort:"price",按最低价路由 |
| 跨模型容灾 | models: ["主模型","备模型"] 数组 | 整个模型不可用时按序降级;失败请求不计费 |
| 嫌某供应商量化版本质量差 | provider.ignore / quantizations | 拉黑或限定精度等级 |
| 不知道用户会发什么 | model: "openrouter/auto" | 交给 Auto Router 逐条选模型(NotDiamond 驱动) |
{
"model": "openrouter/auto",
"plugins": [{
"id": "auto-router",
"cost_quality_tradeoff": 3, // 0-10 旋钮:0 最重质量,10 最重省钱,默认 7
"allowed_models": ["anthropic/*", "openai/*"] // 限定候选池
}]
}响应里的 model 字段会告诉你实际是谁答的。官方明确:Auto Router 不额外收费,按被选中模型的标准价计费。另一个容易忽略的默认行为:带工具调用的请求默认走 Auto Exacto——一个「质量优先」的路由步骤,按工具调用质量给供应商分层(层内保持价格排序);想让工具请求回到纯价格路由,需显式加 :floor 或 sort:"price"。
适合:已经在某朵云上、想要「打开开关就有」的托管路由。以 AWS Bedrock 智能提示词路由为例(以下来自 AWS 官方文档):
aws bedrock create-prompt-router \
--prompt-router-name my-router \
--models '[{"modelArn": "arn:aws:bedrock:<region>::foundation-model/<modelA>"}]' \
--fallback-model '[{"modelArn": "arn:aws:bedrock:<region>::foundation-model/<modelB>"}]' \
--routing-criteria '{"responseQualityDifference": 0.5}'官方自己列出的三条限制:只对英文提示词做过优化;不能根据你应用的实际表现数据调整路由决策;对特殊/垂直场景未必给出最优路由(效果取决于其训练数据)。这三条基本框定了「云内置路由」的适用边界:通用负载好用,深度定制乏力。
微软侧对应产品是 Azure AI Foundry 的 model router:用训练过的小模型逐条实时选择 Azure 托管模型,提供平衡/成本/质量三种模式和自动故障转移(此段来自多家第三方转述,具体能力以微软官方文档为准)。
谁:Microsoft(内部代号 Project Perception,据 The Information 报道,尚未正式发布)。问题:安全工作负载差异极大——漏洞分析、代码审查、威胁检测、事件响应对模型能力的要求各不相同,且单一供应商锁定既贵又有风险。做法:产品同时接入 Microsoft、OpenAI、Anthropic 三家模型,路由层按任务把请求发给「性能、速度、成本平衡最优」的那个。意义:被广泛解读为「把模型竞争变成平台机会」——不论哪家模型在单项跑分领先,平台靠路由层都能吃到红利。
谁:任何客服机器人、编码助手、文档处理类应用。问题:流量里「查订单状态」和「分析合同风险」混在一起,全走旗舰模型账单失控。做法:规则路由打底(按功能分档)+ 学习型路由器处理灰色地带。效果参考:RouteLLM 在 MT Bench 上实测最多省 85% 成本、保住 95% 的 GPT-4 质量,且比商业路由方案便宜 40% 以上(官方 README);2026 年多家综述给出的实践区间是 40-85%(第三方数字,你的里程可能不同)。
谁:对可用性有 SLA 的生产应用。问题:供应商限流/宕机直接打穿服务。做法:供应商级自动回退(OpenRouter 默认开启,故障供应商 30 秒降权)+ 模型级回退数组兜底(触发条件包括上下文超限、审核拦截、限流、宕机);失败请求不计费(zero-completion insurance)。
为什么说它是 2026 的「推理层显学」:本周 Fireworks AI 以 $175 亿估值融资 $15 亿(据 Axios),其核心叙事正是「企业会多模型并用,推理层是持续大头」;MCP Gateway 也在向统一控制面演化(2026 综述)。路由不再是省钱小技巧,而是多模型时代的默认架构层。
| 方案 | 形态 | 路由智能 | 适合谁 |
|---|---|---|---|
| RouteLLM(lm-sys) | 自托管框架,Apache 2.0 | 学习型胜率路由(4 种路由器)+ 阈值校准 + 评测框架 | 想拥有路由逻辑、能自己部署调优、以双模型对为主的团队 |
| OpenRouter | 托管网关+路由器,直接调用 | 供应商价格加权 + 故障降权 + 双层回退 + Auto Router 逐条选模型 | 想一个 key 用遍 400+ 模型、把运维交出去的团队 |
| LiteLLM | 自托管网关(开源 SDK/代理) | 统一 100+ 模型接口,路由规则自己写 | 需要自托管控制面、审计、per-team RBAC 的团队(OpenRouter 官方也承认这类需求该找 LiteLLM/Portkey) |
| AWS Bedrock 提示词路由 | 云内置,serverless 端点 | 响应质量预测 + 质量差判据 + 回退模型;同家族二选一 | 已在 AWS、负载以英文为主、想零运维起步的团队 |
| Azure model router | 云内置(AI Foundry) | 小模型实时选路,平衡/成本/质量三模式(第三方转述) | 已在 Azure 生态的团队 |
普遍的务实路径:规则打底 → 网关统一接入 → 灰色地带上学习型路由 → 有真实反馈后考虑在线学习,每一步都能独立产生收益。
ignore/quantizations 控制,或固定供应商。