当你的Agent系统同时调用Claude Opus做复杂推理、GPT-5.4做函数调用、Gemini Flash做廉价分类时,谁来决定每个请求发给哪个模型?这个"决策层"就是LLM路由网关——2026年Agent基础设施中增速最快的赛道。Mavik Labs的研究指出,路由决策占Agent运营成本的70–80%,在代码执行之前就已经决定了你的账单。RouteLLM的实验证明,经过偏好训练的路由器可以在保持GPT-4级别95%质量的同时,将MT-Bench成本削减85%以上。本文横向评测六款生产级模型路由引擎,从架构原理、路由策略、成本控制、可观测性四个维度拆解它们的设计取舍。
2026年的Agent不再是单模型单任务的玩具。一个典型的多Agent系统可能包含:
Google DeepMind 2026年初的研究发现,无结构的Agent网络会将错误放大17.2倍。问题不在于Agent本身,而在于没有人仔细考虑如何分配工作。路由层正是解决这个问题的基础设施——它决定了每个子任务由哪个模型执行、失败后如何升级、以及如何在成本和质量之间取得平衡。
IDC的2026 AI FutureScape预测:到2028年,70%的顶级AI驱动企业将采用多模型路由架构。这不是可选项,而是基础设施演进的必然方向。
| 维度 | OpenRouter | LiteLLM | Portkey | RouteLLM | Semantic Router | Azure Foundry Router |
|---|---|---|---|---|---|---|
| 类型 | 托管市场 | 自托管代理(MIT) | 托管网关+可观测 | 学术→生产(学习型) | 嵌入路由(无LLM) | 云托管路由 |
| 模型覆盖 | 300+模型/60+供应商 | 100+供应商 | 250+模型 | 任意可配置 | 任意 | Azure生态 |
| 核心路由 | 基于规则+成本优先 | 负载均衡+Fallback | 条件路由+断路器 | RL偏好训练 | 语义嵌入分类 | 混合预测器 |
| 自托管 | 否 | 是(核心优势) | 否(开源Gateway) | 是 | 是 | 否 |
| 可观测性 | 基础统计 | 自建(Prometheus) | 内置(日志/追踪/分析) | 自建 | 自建 | Azure Monitor |
| Fallback | 供应商路由 | 可配置链 | 高级(断路器) | 学术原型 | 无内置 | 内置 |
| 成本模型 | 5.5%信用费 | 免费(开源) | 按日志量 | 免费(开源) | 免费(开源) | Azure定价 |
| 延迟开销 | <50ms | <20ms | <30ms | <100ms(推理) | <5ms | <40ms |
| 适合场景 | 快速原型/全模型接入 | 私有化/成本敏感 | 企业可观测/合规 | 学术研究/成本优化 | 高频分类/极低延迟 | Azure生态 |
架构原理
OpenRouter采用集中式网关架构,通过统一的OpenAI兼容API提供对300+模型、60+供应商的访问。其核心设计理念是"零基础设施、一个API Key搞定一切"。2026年新增的Agent SDK引入了"auto-resolve"工具类型,允许Agent自动处理路由决策并在需要时暂停等待人类审批。
# OpenRouter多模型路由示例
import openai
client = openai.OpenAI(
base_url="https://openrouter.ai/api/v1",
api_key="sk-or-...",
)
# 简单任务用廉价模型
response = client.chat.completions.create(
model="google/gemini-3.1-flash", # $0.10/M tokens
messages=[{"role": "user", "content": "格式化这段文本"}],
)
# 复杂推理用旗舰模型
response = client.chat.completions.create(
model="anthropic/claude-opus-4-6", # $15/M output tokens
messages=[{"role": "user", "content": "分析这个并购方案的风险"}],
)
核心优势:300+模型的即时接入,无需管理多个API Key;支持自动Fallback到备用供应商;提供免费的模型能力排行榜(基于真实用户偏好数据)。
核心劣势:5.5%的信用购买费在大规模使用时成本显著;无自托管选项,数据必须经过第三方;路由策略偏向静态规则,缺乏学习型路由能力。
变现评估:适合作为"AI模型超市"概念做训练营包装,快速展示多模型对比能力。但不宜作为生产级路由引擎的核心依赖。
架构原理
LiteLLM以MIT协议开源,将100+供应商的API统一为OpenAI兼容格式。核心是一个Python代理服务器,在本地或K8s集群中运行,所有流量通过本地网关转发,不经过任何第三方。2026年的版本支持虚拟Key、团队预算控制、RBAC和SSO。
# LiteLLM路由配置示例
from litellm import Router
router = Router(
model_list=[
{
"model_name": "agent-cheap",
"litellm_params": {
"model": "gemini/gemini-3.1-flash",
"api_key": "AIza...",
},
},
{
"model_name": "agent-medium",
"litellm_params": {
"model": "gpt-5.4",
"api_key": "sk-...",
},
},
{
"model_name": "agent-premium",
"litellm_params": {
"model": "claude-opus-4-6",
"api_key": "sk-ant-...",
},
},
],
fallbacks=[{"agent-cheap": ["agent-medium", "agent-premium"]}],
context_window_fallbacks=[{"agent-cheap": ["agent-medium"]}],
num_retries=2,
timeout=30,
routing_strategy="cost-based", # 按成本路由
)
# 自动路由到最便宜的可用模型
response = router.completion(
model="agent-cheap",
messages=[{"role": "user", "content": "总结这篇文章"}],
)
核心优势:完全自托管,零数据泄露风险;支持cost-based routing自动选择最便宜的可用模型;内置Fallback链和上下文窗口Fallback;可与Prometheus/Grafana集成做监控。
核心劣势:可观测性需要自建;路由策略偏向静态规则(轮询/成本优先/延迟优先),缺乏语义理解能力;需要自行管理基础设施和供应商API Key。
变现评估:极度适合企业内训和安全合规场景。自托管特性是金融、医疗等受监管行业的刚需。
架构原理
Portkey的设计哲学是"先看见,再优化"。作为AI网关,它统一了250+模型的API访问,但核心差异化在于内置的完整可观测性栈:日志、追踪、分析、缓存、guardrails全部开箱即用。2026年Gateway已完全开源,日均处理超过1万亿Token。
# Portkey条件路由配置
{
"strategy": {
"mode": "conditional",
"conditions": [
{
"query": {
"metadata.stakes": "high"
},
"then": "claude-opus-4-6"
},
{
"query": {
"metadata.stakes": "medium"
},
"then": "gpt-5.4"
},
{
"query": {
"metadata.stakes": "low"
},
"then": "gemini-3.1-flash"
}
],
"default": "gpt-5.4"
},
"fallbacks": [
{"claude-opus-4-6": ["gpt-5.4"]},
{"gpt-5.4": ["gemini-3.1-flash"]}
]
}
核心优势:内置断路器(Circuit Breaker)模式,当某个模型/供应商连续失败时自动切换;语义缓存(Semantic Cache)可减少30-50%的重复请求;完整的请求级追踪和成本归因。
核心劣势:高级功能需要付费计划(免费版仅10K日志/月);作为中间层增加网络跳数;非完全自托管,依赖Portkey的云基础设施。
变现评估:最适合作为"AI运维平台"概念包装。企业级的成本追踪和合规审计能力是直击痛点。
架构原理
RouteLLM源自UC Berkeley Sky Computing Lab的研究项目RouteLLM。其核心创新是使用偏好数据训练路由模型,而非依赖人工规则。路由器通过学习用户对不同模型响应的偏好分布,动态决定每个查询应该路由到哪个模型。最新研究(2026年2月的R2-Router)将成本再推低4-5倍,引入了"推理+长度"联合路由策略。
# RouteLLM核心路由逻辑(概念性)
from routellm import Router
router = Router(
routers=["mf"], # 矩阵分解路由器
strong_model="anthropic/claude-opus-4-6",
weak_model="google/gemini-3.1-flash",
# 关键:使用真实偏好数据训练
benchmark="mt-bench",
)
# 路由器自动判断查询复杂度
# 简单查询 → gemini-flash ($0.10/M)
# 复杂查询 → claude-opus ($15/M)
# 结果:85%+ 成本削减,95% 质量保持
response = router.chat.completions.create(
messages=[{"role": "user", "content": query}],
)
关键数据:
| 基准测试 | 成本削减 | 质量保持 |
|---|---|---|
| MT-Bench | >85% | 95% |
| MMLU | 45% | 95% |
| GSM8K | 35% | 95% |
核心优势:唯一基于学习型路由的开源方案,自动适应用户查询分布;学术验证充分,论文经过同行评审;路由决策可解释,可以追踪"为什么这个查询被路由到廉价模型"。
核心劣势:需要偏好数据做初始训练;路由推理本身有约100ms延迟;从学术原型到生产系统仍需工程化工作。
变现评估:适合作为"AI成本优化咨询"的技术底座。85%的成本削减数字是极佳的营销卖点。
架构原理
Semantic Router完全跳过了LLM调用,使用向量嵌入做语义分类。核心思路:将预定义的路由规则编码为向量,将用户查询也编码为向量,通过余弦相似度匹配最合适的路由。因为不需要调用任何LLM,路由决策延迟低至5ms以下。
# Semantic Router配置示例
from semantic_router import Route, RouteLayer
from semantic_router.encoders import OpenAIEncoder
encoder = OpenAIEncoder(name="text-embedding-3-small")
# 定义路由规则
coding_route = Route(
name="coding",
utterances=[
"Write a Python function",
"Debug this code",
"Refactor this class",
"Implement a REST API",
],
)
analysis_route = Route(
name="analysis",
utterances=[
"Analyze the risk factors",
"Compare these two approaches",
"What are the trade-offs",
"Evaluate the architecture",
],
)
simple_route = Route(
name="simple",
utterances=[
"What is the weather",
"Format this text",
"Summarize this email",
"Translate to English",
],
)
router = RouteLayer(
encoder=encoder,
routes=[coding_route, analysis_route, simple_route],
)
# 路由决策:< 5ms
result = router("Write a function to parse CSV files")
# → Route(name="coding", similarity=0.92)
# → 路由到 GPT-5.4 (最佳代码模型)
核心优势:路由延迟<5ms,是所有方案中最快的;完全确定性路由(相同输入总是相同输出);成本极低(仅需嵌入模型的几美分/天)。
核心劣势:只能做分类路由,无法理解查询的真实复杂度;需要为每个路由类别维护示例utterances;对于模糊查询的处理能力有限。
设计取舍:正如Raoul Coutard在"90%免费AI策略"文章中提出的——semantic router处理有把握的80%查询,LLM处理模糊的尾部20%。这本身就是一个完整的架构模式。
架构原理
Microsoft Azure AI Foundry的Model Router采用混合预测器架构:将意图分类、复杂度评估和成本预算优化整合到单一路由层中。关键创新是全局预算优化(Lagrangian双分解)——不再对每个查询做贪心决策,而是在整个查询流上做全局优化。
# Azure Foundry路由概念性配置
from azure.ai.inference import ModelRouter
router = ModelRouter(
endpoint="https://your-foundry.services.ai.azure.com",
# 全局成本预算
daily_budget_usd=1000,
# 质量要求
min_quality_score=0.95,
# 路由策略
strategy="cost-aware", # cost-aware | quality-first | latency-first
)
# 路由器自动做全局优化
# 不是每个查询独立决策,而是考虑今天的预算剩余
response = router.route(
messages=[{"role": "user", "content": "分析这份合同的风险"}],
metadata={"stakes": "high", "domain": "legal"},
)
# → 根据当日预算消耗情况动态选择模型
# 预算充裕 → Claude Opus ($15/M)
# 预算紧张 → GPT-5.4 ($8/M) + 严格验证
OmniRouter的研究表明,这种全局优化方法可以在保持质量的前提下实现至少10.15%的额外成本削减和6.30%的准确率提升。MixLLM研究进一步证明,上下文臂老虎机(Contextual Bandits)可以在时间约束下以24.18%的成本达到GPT-4质量97.25%的效果。
核心优势:唯一提供全局预算优化的方案;与Azure生态深度集成(Monitor、Key Vault、RBAC);企业级SLA和合规支持。
核心劣势:强绑定Azure生态,供应商锁定风险高;路由延迟约40ms(混合预测器推理开销);对于非Azure用户接入成本高。
graph TB
subgraph "第一层:意图分类 (Intent Classification)"
A[用户请求] --> B{Semantic Router<br/>嵌入匹配 < 5ms}
B -->|简单查询<br/>sim > 0.85| C[轻量级模型<br/>Gemini Flash / Llama]
B -->|复杂查询<br/>sim < 0.85| D{第二层:复杂度评估}
B -->|模糊查询<br/>无法分类| E[LLM路由器<br/>GPT-4o-mini分类]
end
subgraph "第二层:复杂度路由 (Complexity Routing)"
D --> F[RouteLLM<br/>偏好训练路由器]
F -->|低复杂度| G[中端模型<br/>GPT-4o / Claude Sonnet]
F -->|高复杂度| H[旗舰模型<br/>Claude Opus / GPT-5.4]
E -->|分类结果| F
end
subgraph "第三层:Fallback与预算控制 (Fallback & Budget)"
C -->|失败/超时| G
G -->|失败/低置信度| H
H -->|连续3次失败| I[断路器<br/>Portkey Circuit Breaker]
I --> J[人类接管]
H -->|成本超预算| K[降级到中端模型<br/>+ 严格验证]
end
subgraph "网关层 (Gateway)"
L[LiteLLM Proxy<br/>统一API格式]
M[Portkey Gateway<br/>可观测+缓存+Guardrails]
N[OpenRouter<br/>300+模型市场]
end
C --> L
G --> L
H --> L
L --> M
M --> N
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 个人开发者/初创 | OpenRouter + Semantic Router | 零基础设施成本,5ms极速路由处理80%流量 |
| 中型SaaS产品 | LiteLLM自托管 + RouteLLM | 完全自控,偏好路由削减85%成本 |
| 企业合规场景 | Portkey + LiteLLM双网关 | 可观测性+自托管双重保障 |
| Azure生态企业 | Azure Foundry Router | 全局预算优化,无需额外基础设施 |
| 高频低延迟场景 | Semantic Router独立部署 | <5ms路由延迟,确定性决策 |
| 研究/学术 | RouteLLM | 可复现的学术基准,开源可控 |
graph LR
A[100%请求] --> B["Level 1: 本地模型<br/>Ollama Llama 3<br/>$0/M tokens"]
B -->|60%成功| C[完成 ✅]
B -->|40%失败| D["Level 2: 廉价云模型<br/>Gemini Flash<br/>$0.10/M tokens"]
D -->|25%成功| C
D -->|15%失败| E["Level 3: 平衡旗舰<br/>Claude Sonnet<br/>$3/M output tokens"]
E -->|10%成功| C
E -->|5%失败| F["Level 4: 旗舰模型<br/>Claude Opus<br/>$25/M output tokens"]
F -->|5%成功| C
style B fill:#4CAF50,color:#fff
style D fill:#FFC107,color:#000
style E fill:#FF9800,color:#fff
style F fill:#F44336,color:#fff
按上述级联架构,加权平均成本约为$1.5/M tokens,相比全部使用Claude Opus的$15/M tokens削减90%。Raoul Coutard的实际部署报告证实了这一数据。
选择路由策略时,关键问题不是"哪个路由器最好",而是"你的查询分布长什么样":
graph TD
A[开始选型] --> B{日均请求量?}
B -->|< 1K| C[OpenRouter<br/>无需基础设施]
B -->|1K-100K| D{是否需要自托管?}
B -->|> 100K| E{合规要求?}
D -->|是| F[LiteLLM + RouteLLM]
D -->|否| G[Portkey托管网关]
E -->|金融/医疗/政府| F
E -->|一般商业| H{延迟敏感?}
H -->|< 50ms| I[Semantic Router<br/>+ LiteLLM Fallback]
H -->|> 50ms可接受| F
C --> J{是否需要<br/>可观测性?}
J -->|是| K[OpenRouter + Helicone]
J -->|否| C
教训一:路由器本身成为瓶颈。 Opper AI的2026路由器延迟基准测试显示,添加路由层通常增加30-100ms延迟。在高频场景下(如实时客服),这不可接受。解决方案是使用Semantic Router处理确定性的大部分流量,将不确定的尾部交给LLM路由器。
教训二:Fallback链的"隐性延迟"。 级联架构的最好情况是5ms(首次命中),最坏情况是300ms+(四级全部失败)。必须设置严格的超时和断路器,避免用户等待数秒。
教训三:路由准确率不等于系统准确率。 LLMRouterBench(arXiv 2601.07206)对20+模型集合的评测显示,路由器本身的准确率在60-85%之间。即使路由器85%正确,在15%的误路由中,将简单查询发给昂贵模型只是浪费钱,但将复杂查询发给廉价模型会导致质量下降。方向性错误的代价远大于浪费。
教训四:成本优化需要全局视角。 OmniRouter的全局预算优化比逐查询贪心决策额外节省10%+。当你有每日/每月预算上限时,全局优化是唯一可靠的方法。
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
