LLM 路由：如何停止为简单查询支付顶级模型的昂贵价格
大多数团队都会遇到同样的拐点：LLM API 成本的增长速度超过了使用量的增长，而且每一个查询——无论是“总结这句话”还是“审计这个 2,000 行的代码库以查找安全漏洞”——都指向同一个昂贵的模型。解决方法不是挤压 prompt，而是路由。
LLM 路由意味着将每个请求引导至最适合该特定任务的模型。不是能力最强的模型，而是正确的模型——在成本、延迟和质量之间平衡，以满足查询的实际需求。如果做得好，路由可以在质量几乎不下降的情况下将 LLM 成本降低 50–85%。如果做得不好，它会产生隐性的质量倒退，直到用户流失你才会察觉。
这篇文章涵盖了其机制、权衡以及在生产环境中实际会出问题的地方。
为什么成本差距是可以利用的
顶级模型与小型模型 之间的价格差异是巨大的，且仍在增长。GPT-4o 的成本约为每 1,000 个 token 0.02 美元。GPT-4o-mini 的成本为 0.00075 美元。这是 27 倍的价格差异。Claude 3.5 Sonnet 的运行费用约为每 1,000 个 token 0.018 美元；Claude 3 Haiku 是 0.0015 美元。比例类似。
关键洞察是：模型能力并不随价格线性增长，且大多数查询不需要顶级模型的能力。事实查询、JSON 提取、简短总结——这些任务由便宜两到三个量级的模型就能胜任。关于“混合 LLM”（Hybrid LLM）方法的研究（ICLR 2024）从形式上证明了实践者们已经怀疑的事实：分配最大的推理资源并不总是能产生更好的输出。对于很大一类查询，7B 参数模型就足够了。
规模化后的计算变得非常有趣。如果你每天处理 100,000 个查询，并将其中甚至 50% 的查询从 GPT-4o 转向 GPT-4o-mini，你在这部分业务上的成本大约能削减 14 倍。在每天 100 万次查询的规模下，这种节省的复利效应证明了投入重大工程力量是值得的。
三种路由策略（以及何时使用它们）
基于规则的路由
最简单的方法：基于显性信号的条件逻辑。
def route_query(query: str, context: dict) -> str:
# 高优先级用户始终获得最佳模型
if context.get("plan") == "enterprise":
return "gpt-4o"
# 较短的查询可能是简单的
if len(query.split()) < 20:
return "gpt-4o-mini"
# 与代码相关的查询需要能力强的模型
code_keywords = ["function", "debug", "implement", "refactor", "sql", "api"]
if any(kw in query.lower() for kw in code_keywords):
return "gpt-4o"
# 默认：较便宜的模型
return "gpt-4o-mini"
基于规则的路由是确定性的、快速的（亚毫秒级）且可审计的。它涵盖了 80% 的用例，应该始终是你的起点。局限性在于：它很脆弱。像“这个算法的时间复杂度是多少？”这样的查询不包含代码关键字，但需要一个强大的模型。边缘情况的积累速度比你编写规则的速度快。
基于分类器的路由
训练一个轻量级模型——通常是 BERT 规模（约 1.1 亿参数）——来预测对于给定的查询，哪个 LLM 会产生最佳响应。RouteLLM (UC Berkeley / LMSYS) 是开源的参考实现。它在 Chatbot Arena 偏好数据上训练了四种路由架构：相似度加权排名、矩阵分解、BERT 分类器和因果 LLM 分类器。
基准测试数据令人印象深刻：最好的 RouteLLM 路由器在 MT Bench 上削减了 85% 的成本，同时保持了 GPT-4 质量的 95%。在 MMLU 和 GSM8K 等更结构化的任务上，节省额为 35–46%——这仍然非常有意义。路由器增加了 10–30 毫秒的延迟，这对于大多数应用程序来说是可以接受的。
一个容易被忽视的发现是：RouteLLM 路由器可以跨模型对进行迁移。在 GPT-4 / Mixtral 偏好数据上训练的路由器，无需重新训练即可泛化到 Claude 3 Opus / Llama 3。分类器学到了一些关于查询难度的知识，而这些知识并不受限于特定模型。
训练所需的数据比预期的要少。有效的路由器仅使用不到 1,500 个标记样本进行训练——不到完整 Chatbot Arena 数据集的 2%。如果你拥有带有质量标注或用户反馈信号的生产日志，你可能已经拥有足够的训练自定义路由器的数据了。
级联/瀑布式路由
级联路由不是进行一次性的路由决策，而是先尝试便宜的模型，如果质量不足则升级：
- 将查询发送给便宜的模型（例如 Claude Haiku）
- 评估响应的置信度
- 如果高于阈值 → 返回答案
- 如果低于阈值 → 升级到更强大的模型（例如 Claude Sonnet）
这是最复杂的策略，但提供了一个真正的优势：你不需要预先预测查询难度。便宜模型自身的确定性信号驱动了升级。将质量、成本和不确定性评分结合起来的研究实现了 97% 的 GPT-4 准确率，而成本仅为 GPT-4 的 24%——在几乎相同的输出质量下实现了 4 倍的成本降低。
缺点是：级联在触发升级时会增加延迟。如果你调用了便宜的模型，对响应进行评分，然后再调用昂贵的模型，对于困难案例，你实际上将延迟加倍了。对于 300 毫秒以下的实时聊天，这通常与用户体验 (UX) 要求不相符。
构建生产级路由栈
一个最小化的生产环境设置通常分为三个层面：
基础设施 (Infrastructure)：健康监控、供应商故障转移、熔断器。在进行任何智能路由之前，你必须具备将流量从性能下降的供应商处重定向的能力。LiteLLM 作为代理服务器在这方面表现出色 —— 它支持基于延迟的路由、基于成本的路由，并能通过跨 100 多个供应商的统一 API 接口实现自动回退链。
预过滤 (Pre-filtering)：领域标签、内容安全检查、PII（个人隐私信息）检测。这些通常是运行在路由决策之前的低成本规则检查，可以将特定查询强制分配给特定模型（例如，所有包含 PII 的查询都路由到你的本地部署模型）。
路由逻辑 (Routing logic)：实际的模型选择 —— 根据你的需求和流量规模，采用规 则、分类器或级联方案。
一个可以清晰映射到成本的实用模型分层：
| 层级 | 模型 | 使用场景 |
|---|---|---|
| 简单 | GPT-4o-mini, Claude Haiku | 格式化、翻译、事实问答、摘要 |
| 中等 | GPT-4o, Claude Sonnet | 多步推理、代码生成、分析 |
| 复杂 | o1, Claude Sonnet (extended thinking) | 规划、安全审查、研究综合 |
生产环境中究竟会出什么问题
隐性质量退化
这是最危险的故障模式。你激进地将流量路由到廉价模型，成本下降了，一切看起来都很正常 —— 直到留存指标发生变动。遇到响应质量下降的用户并不总是会明确投诉；他们只会重复提交相同的查询、点踩，或者干脆停止使用该 feature。
从第一天起就要将质量与成本同步监控。跟踪重试率、明确的反馈信号以及按模型层级细分的任务完成率。如果你无法衡量质量，就无法安全地进行路由。
对话中的一致性
在单个对话线程中混合使用模型会产生微妙的不一致性：不同的默 认格式、不同的响应长度、对边缘情况的不同处理。用户会对助手的行为建立心理模型；违背这一模型会让用户感到违和，即使他们无法准确表达原因。
解决方法：针对每个模型层级使用一致的系统提示词工程 (System Prompt Engineering) 来规范输出格式，并避免在对话中途未经重新评估就切换模型。增加一个强制执行格式标准的响应规范化层会有所帮助，但不能完全解决问题。
级联中的阈值校准偏差
为级联升级设置置信度阈值比看起来要难。阈值太高：你会频繁升级路由，导致成本比从一开始就使用昂贵模型还要高。阈值太低：廉价模型会处理它无法回答的查询，导致质量下降。
对阈值进行网格搜索速度慢且计算成本高。更好的方法是：对模型序列的联合性能分布进行概率建模，然后通过连续梯度下降来优化阈值。这种方法收敛速度明显更快，并且能更优雅地处理分布边界的边缘情况。
根据具有代表性的生产查询样本进行校准 —— 1,000 到 5,000 个通常就足够了。每月重新校准一次，因为随着产品的演进，流量分布会发生偏移。
路由器分布偏移
基于历史数据训练的分类器在以下情况会发生性能退化：
- 新的产品功能产生了训练数据中不存在的查询类型
- 模型供应商发布了能力发生变化的新版本
- 流量分布随季节性或业务增长发生偏移
请将你的路由器视为生产环境中的模型：监控其性能，对其进行版本管理，并定期重新训练。六个月前合理的路由分类器可能已经无法适应今天的流量。
路由器自身的延迟预算
路由并不是免费的。基于规则的路由增加约 1ms（微乎其微）。基于嵌入 (Embedding) 的语义路由会因为调用嵌入生成而增加 20–50ms。BERT 规模的分类器会增加 10–30ms 的推理时间。如果你运行多重检查，这些数字会累加。
对于有严格延迟要求的应用，预决策路由（在调用任何 LLM 之前由分类器决定）是必须的。级联路由 —— 在可能调用第二个模型之前增加了一次完整的模型推理加上评估过程 —— 仅在应用能够容忍升级查询带来的额外延迟时才可行。
什么时候路由不值得
路由在以下情况是有意义的：
- LLM 成本的增长速度超过了收入
- 你能识别出对质量要求有显著差异的不同使用场景集群
- 你每天处理的请求量超过约 10,000 次（低于此水平，工程成本通常会超过节省的费用）
- 你拥有可以监控并据此采取行动的质量信号
在以下情况不值得：
- 你处于早期阶段，流量较小
- 每个使用场景都需要最顶尖的 (Frontier-level) 质量
- 增加路由延迟会破坏你的用户体验 SLA (UX SLA)
- 你没有按模型层级监控质量的基础设施
元经验：路由是一种优化，而不是基础。先完善产品。只有当成本压力真实存在且你能衡量优化目标时，再进行优化。
新兴前沿：语义路由与基于能力的路由
对于已经在运行基础路由的团队，有两种较新的方法值得关注。
语义路由 (Semantic routing) 将查询编码为稠密向量嵌入 (dense vector embeddings)，并根据与特定模型相关的参考提示词之间的余弦相似度进行路由。这能自然地处理同义改写——例如，“天气怎么样？”和“告诉我今天的预报”会被路由到同一个地方——并且当查询不匹配任何已知类别时，它能优雅地降级。aurelio-labs/semantic-router 库是轻量级的 Python 参考实现；vLLM 的 Semantic Router（v0.1 "Iris"，2026 年 1 月）将其扩展到了生产级推理集群。
基于能力的路由 (Capability-based routing) 侧重于查询难度而非主题领域。IRT-Router (ACL 2025) 应用了借鉴自心理测量学的项目反应理论 (Item Response Theory)，将 LLM 的能力建模为潜在能力得分，并将查询建模为潜在难度得分。路由器根据这些得分预测哪个模型将正确回答，并提供可解释的输出。一个显著的发现是：通过在查询分布中进行最优选择，高性能的路由器能让弱模型池的整体表现超越该池中表现最好的单个模型。
对于多步 Agent 工作流，路由不仅限于入口点——每一个工具调用、子任务和推理步骤都可以分发给合适的专家。一个轻量级的编排器模型充当调度器，将任务路由给专门的 Agent（编码、搜索、分析），每个 Agent 背后都由针对该能力成本最优的模型支持。这就是路由从成本优化演变为架构模式的地方。
实践起点
如果你正在生产环境中运行 LLM 负载且尚未实现路由：
- 审计你的查询组合。将最近的 500 条查询按复杂度分类，看看有多大比例是真正简单的。你可能会发现 40–60% 的请求并不需要前沿模型 (frontier model)。
- 首先实现基于规则的路由。定义 3–4 个复杂度分层并制定明确规则。上线运行，衡量成本和质量，建立基准。
- 如果基于规则的路由显示出差距，则训练一个分类器。从生产日志中抽取带标签的查询样本，训练一个小型 BERT 分类器，在留出集上进行评估，并将其与规则层一起部署。
- 选择性地添加级联路由。将其保留在延迟容忍度高且质量要求足以证明复杂度合理的使用场景中。
85% 的成本降低基准是真实的——但前提是你已经配置了质量监控，并且可以根据实际流量调整阈值。这项工程投入是值得的。风险在于只优化成本而不跟踪质量，这会导致仪表盘上的数字看起来很漂亮，而用户却在悄然流失。
路由并非万灵药 (silver bullet)，但它是生产环境中 LLM 成本管理最可行的杠杆之一。工具链已经显著成熟：RouteLLM、LiteLLM 和 vLLM 的 Semantic Router 覆盖了具有生产就绪实现的核心用例。这种模式已被充分理解。将获得节省的团队与引入质量退化的团队区别开来的，是监控基础设施，而非路由逻辑本身。
