模型路由是系统设计问题，而非配置选项

大多数团队选择 LLM 的方式就像选择数据库引擎一样：在架构评审时选一次，然后再也不改。你选了 GPT-4o 或 Claude 3.5 Sonnet，把它写进配置文件，然后上线。这个选择感觉无法逆转，因为更改它需要重新部署、跨服务协调，以及针对本周 eval 的回归测试。

这种思维方式是错误的。你的流量并不是同质的。"总结这篇文档"和"调试这个神秘堆栈跟踪"两个请求同时打到同一个接口，对能力的需求天差地别——但从静态模型选择的基础设施视角来看，两者毫无区别。你要么对其中一个过度供给，要么对另一个供给不足，而且每一个请求都是如此。

模型路由将 LLM 的选择视为运行时分发决策。每个进入的查询都会根据能预测该请求最合适模型的信号进行评估，并据此进行分发。路由层不存在于配置文件中——它运行在你的请求路径上。

真正驱动良好路由的信号

简单性的诱惑会把团队推向单信号路由："按 token 数量路由"，或"检测提示词中是否包含'代码'这个词就路由"。这些方法在实践中效果很差，因为单个信号是你真正关心的事情的弱代理：这个请求是否需要一个高能力的模型，还是一个更便宜的模型就够了？

有效的路由器会结合多种信号类型：

输入复杂度，而非仅仅是输入长度。 Token 数量是一个快速信号，也是成本的代理指标，但两个 200 token 的提示词可能有完全不同的推理需求。关于常识地理的问题 50 个 token 就很简单。一个细致的法律解释问题 500 个 token 也很难。复杂度分类器——训练用于预测查询难度的轻量级模型——作为路由信号始终优于原始长度。

任务分类。 不同任务类型对模型能力的敏感度曲线各异。代码生成、数学推理和结构化提取对模型能力高度敏感：小模型的失败方式是即时可见且难以恢复的。文档摘要、翻译和分类的敏感度则低得多——7B 和 70B 模型之间的质量差异对终端用户来说往往难以察觉。了解请求属于哪个类别，比任何其他单一信号都更有价值。

按用户层级设定延迟 SLA。 交互式聊天会话与通宵运行的批处理作业，对首个 token 时间（time-to-first-token）的可接受值截然不同。用户层级（免费 vs. 付费、交互式 vs. 后台）是一级路由输入，而非事后补充。在路由器中构建层级感知能力，让你为付费用户提供大模型容量——他们会注意到差异，并愿意为此承担相应成本。

置信度升级。 一些路由器先运行廉价模型，然后检查自我报告的置信度分数，再决定是否升级。当置信度高时，廉价答案直接发出；当置信度低时，请求路由到更强的模型。这要求你的廉价模型具有良好的校准性——过度自信的小模型会让这种方法不可靠——但当它奏效时，能实现两全其美。

关于多信号路由的研究结论是一致的：结合任务分类、复杂度估计和成本信号，比任何单信号方法都好得多。RouteLLM 是最广泛基准测试的开源框架，通过同时从人类比较数据中学习两类信号的路由偏好，在对话基准测试上实现了 85% 的成本降低。

为什么朴素的故障转移逻辑在流量下会崩溃

路由最简单的心智模型是："先尝试廉价模型，如果失败就回退到昂贵的模型。"团队首先实现这个方案，因为它显而易见且不需要训练数据。但它在生产中崩溃的原因并不明显，直到你陷入故障时才会察觉。

可重试和不可重试的错误并不相同。 400 Bad Request 意味着你的提示词格式有问题——在不同模型上重试会同样失败。503 意味着提供商过载——在不同提供商上重试是正确做法。429 速率限制需要指数退避，而不是立即回退到会在几秒内触及同样限制的备用提供商。朴素的故障转移逻辑把这些归为一个代码路径，在负载最大时放大问题。

流式传输失败不可组合。 如果提供商开始流式传输响应后在中途失败，你的客户端已经收到了部分输出。如果没有客户端缓冲，你无法在流式传输中途透明地切换提供商——而缓冲会消除流式传输的延迟优势。静态故障转移链没有考虑到这一点；它们假设请求是原子的。

成本分布呈重尾分布。 大多数请求消耗适度的 token。一小部分——长文档摄取、累积了大量上下文的多轮对话、复杂推理链——消耗了大部分 token 预算。把每个请求都路由到"先用小模型"优化的是中位数情况，而几乎不触及尾部——而那才是你大部分钱花去的地方。有效的路由器优先处理高成本请求的路由决策，并廉价地路由低成本请求。

质量-成本权衡会产生反馈循环。 过度激进地路由到廉价模型会降低输出质量。降低的质量会增加重试率、用户困惑和支持量。支持量和用户流失也是成本，只是在不同的预算中。那些报告路由"节省了 60%"的团队，往往没有核算转移到客服和增长数字上的代价。

影子路由：在不影响用户的情况下验证路由器

直接将新的路由策略部署到生产环境风险很高：如果路由器出错，你在衡量到降级之前就已经影响了真实用户的质量。影子路由是在提交之前验证路由器的标准技术。

基本设置：新的路由策略与生产策略并行运行在相同流量上，但其决策只被记录，不被执行。每个请求由生产路由器分发，而影子路由器记录它会做出什么不同的决策。收集足够的流量后——通常需要 5-7 天达到统计置信度——你将影子路由器的决策与观察到的质量结果进行比较。

这在部署前给你提供了几个可测量的量：

• 路由分歧率：新策略与生产的分歧频率
• 预测成本差值：如果影子路由器更激进地路由到廉价模型，基于实际 token 消耗，预计能节省多少
• 质量信号分布：对于影子路由器会使用廉价模型的请求，实际（昂贵）响应的质量信号如何？如果质量始终很高，那么用廉价模型大概没问题

影子路由不能告诉你廉价模型实际上会产生什么——那需要运行它并评估输出。但它将实验范围缩小到高分歧案例，并在触及实时流量之前，给你一个优先运行离线评估的列表。

同样的原则适用于路由策略更新，而不仅仅是新策略。以与代码部署相同的严格程度对待提示词路由规则变更是正确的直觉。路由变更的风险与其影响的流量成正比。

大多数团队忽略的成本核算

实施路由的组织经常报告大幅节省：" 40% 的削减"、"便宜了 85%"。这些数字是真实的，但往往是不完整的，报告的节省与实际损益表影响之间的差距很有启发性。

路由开销有实际成本。 路由决策需要计算——无论是轻量级分类器、相似度查找，还是在某些实现中，一个单独的 LLM 调用。在高请求量下，路由器开销是一个不可忽视的成本项。快速的基于相似度的路由器（毫秒级，廉价）适合常见路径。通过 API 调用来做路由决策的基于 LLM 的路由器，对于短小廉价的请求，可能比它们节省的路由费用还要贵。

升级率是一个乘数。 每个路由器误判的请求——选择了廉价模型，质量不够，升级到昂贵模型——要付出双倍代价：廉价模型调用加上昂贵模型调用。高升级率会把路由从成本削减策略变成成本放大策略。升级率，而非每次请求的成本，才是需要密切监控的数字。

以理论节省的 70-80% 为目标是正确的。 在生产路由部署中存在一个一致的模式：理论成本节省的前 70% 可以用适度的路由复杂度实现。接下来的 15% 需要越来越激进的路由阈值，把质量推向不可接受的边缘。最后 15% 需要解决工程时间成本超过推理成本节省的问题。追逐 95% 的理论节省是个陷阱。目标 70-80%，然后继续前进。

总体拥有成本包括下游。 大规模的低质量输出会增加重试率（用户再次尝试）、支持量（他们升级投诉）和流失（他们离开）。一个每月减少 2 万美元推理账单却增加 2.5 万美元支持成本的路由策略是净亏损。你需要跨职能可见性才能准确衡量这一点。

设计一个能在生产中存活的路由器

综合以上内容，一个生产就绪的路由架构具有以下几个特性：

多级故障转移链，而非二元故障转移。 不是廉价 → 昂贵，而是构建主要 → 次要 → 三级，每个级别有不同的成本/能力配置。这在提供商之间分配负载，减少单点故障，并让你在某个级别不可用时能够优雅地调整降级。

按层级设置预算和熔断器。 交互层级有硬性延迟预算——如果模型在 N 秒内没有响应，就升级而不是等待。后台层级有硬性成本预算——如果每个请求的 token 消耗超过阈值，就截断或拒绝。这些预算防止批处理队列饱和导致交互请求超时等待容量的故障模式。

反馈循环来重新训练路由器。 在静态基准数据（如 Chatbot Arena 偏好对）上训练的路由器可以泛化到生产环境，但随着流量分布变化而漂移。实施用户接受信号的轻量级收集——点赞/踩、重试率、会话放弃——并定期重新训练路由分类器。启动时校准良好的路由器如果没有维护，会在几个月内退化。

每次请求的成本归因，而非每个计费周期。 你需要知道每个请求的路由决策、使用的模型、token 数量和成本。聚合计费仪表板告诉你花了多少；每次请求的归因告诉你为什么以及哪些路由需要调整。在调整阈值之前构建这个监控，而不是之后。

避免热路径中的路由延迟。 最快的路由器每次请求增加 5-20ms；较慢的分类器或基于 LLM 的路由器增加 100ms+。对于首个 token 时间是主要 UX 指标的交互式用例，100ms 的路由税往往比廉价和昂贵模型之间的延迟差异还大。对常见情况使用快速分类器（BERT 规模，而非 GPT 规模），将更重的路由逻辑保留给风险值得的请求。

路由在哪里赚回其复杂性成本

模型路由是真实的基础设施，有真实的运营负担。配置面很大，失败模式不明显，成本核算需要大多数团队天然不具备的跨职能协调。它在以下情况下赚回其复杂性：

• 你的流量多样：在广泛的任务分布中混合了简单和复杂的查询
• 你的规模有意义：在低流量下，路由开销往往超过节省
• 你的用户层级结构映射到质量要求：并非每个请求都需要相同的模型
• 你有评估基础设施：路由决策需要针对质量信号进行验证，你需要在部署前进行测量

如果你所有的查询在复杂度上都相似，或者你的流量很低，或者你没有验证路由质量的评估基础设施——静态模型选择可能就够了。路由是优化，不是默认值。过早构建它的团队最终会维护复杂的基础设施，却无法推动他们关心的数字。

但如果这些条件得到满足——在有意义的规模下，通常如此——把模型选择当作静态配置就是每个请求、持续地把真金白银留在桌上。路由层会为自己买单。