多模型路由是基础设施决策，而非功能

让我们从最容易衡量也最容易被忽略的部分开始：时间。

每个语义路由器都会在提示词到达和模型开始处理之间插入一个步骤。必须有东西读取请求并决定它属于哪里，而这个决定并非瞬间完成。根据 DigitalOcean 的文档，“使用路由器比直接调用模型大约增加 200 毫秒的延迟开销”。这不是一个藏在细则中的数字，而是作为使用该产品的正常成本明确陈述的，这一点值得注意。负责该工作的模型是一个专门构建的分类器，名为Plano-Orchestrator，在其更大、更准确的规模下，大约同样需要 200 毫秒来解析意图，同时还有一个更小、更快的变体，在速度比精度更重要时使用。

200 毫秒听起来很小，直到你问它占多少比例。这才是这里真正唯一重要的问题，答案完全取决于你的应用程序需要多快的响应。例如，聊天界面通常将约 200 到 300 毫秒以内的首令牌时间（TTFT）视为即时响应，300 到 600 毫秒视为可容忍，超过一秒则明显缓慢；而代码补全工具需要在 100 毫秒以内，以避免打断用户的打字节奏。将 200 毫秒的额外开销与这些目标放在一起，你会得到一张截然不同的账单，具体取决于你属于哪条线：

将这个例子视为观察问题形态的一种方式，而不是一条定律。开销因路由器而异，DigitalOcean 自己早期的分类器Arch-Router在其已发布的基准测试中大约用 50 毫秒解析意图，路由选择准确率约为 93.17%，是取代它的系统所宣称的 200 毫秒的一小部分。（请注意，Arch-Router 的 93.17% 衡量的是它选择预期路线的频率，与下面 Plano-Orchestrator 的 87.84% 跨领域性能是不同的指标，因此这两个数字不能直接比较。）这两个数字下的模式才是你真正需要的：同样的固定成本在宽裕的预算（1,000 毫秒）下几乎不可见，在紧张的预算（100 毫秒）下则直接被淘汰，所以在判断路由开销是四舍五入的误差还是决定性因素之前，先了解你自己的预算。

DigitalOcean 自己的路由模型实际上正是因为这个原因而提供两种规格，两者之间的差距让这种权衡变得具体而非理论化。根据 DigitalOcean 自己的报告，较大版本的 Plano-Orchestrator 是一个拥有 300 亿参数的混合专家模型，每次决策仅激活约 30 亿参数，它在通用、编码和长上下文对话中的平均得分为 87.84%。较小的 40 亿参数版本得分 84.68%，但换来的是更轻量的部署体积和更低的延迟，适用于每一毫秒都至关重要的场景。这是一个值得注意的权衡，因为每个在紧张 TTFT 预算下运行的团队都在默默做出同样的取舍，无论他们是否意识到这一点。如果你的预算迫使你选择速度更快但准确率稍低的分类器，你实际上是在用一小部分可量化的准确率换取速度。这是一个可以接受的决策。而不可接受的是，仅仅因为没人想到去检查，就把同样的三四个百分点的准确率损失交给一个你从未基准测试过的路由器。

是否有人在盯着时钟也很重要。路由开销发生在第一个 token 之前，因此在流式聊天界面上，它表现为文本开始出现之前的停顿。在批处理任务中，同样的 200 毫秒会消失在总响应时间里，远不那么引人注意。如果一个人在应用流式响应时盯着闪烁的光标，200 毫秒的重要性远超在隔夜批处理管道中同样的 200 毫秒。

还有一个悄无声息变得更糟的方式：距离。如果分类器不靠近你的模型服务基础设施，开销会成倍增加。如果你的路由器在转发请求之前，必须先向外部分类端点单独发起一次网络调用，那么就把这次往返时间加到其他所有开销之上。同地部署不是锦上添花；它决定了你付出的是固定的、已知的税，还是随着分类器所在位置的距离而增长的税。

单一模型设置只有一种失效模式：模型宕机，或者没有宕机。你可以监控它，并在发生的那一刻收到警报。而路由设置有两种失效模式：模型可能失败，路由器也可能在报告成功的同时把你的请求发送到错误的模型。第二种失效更危险，因为它是无声的。没有任何错误，日志中也不会显示为失败，用户只是得到了一个比他们应得的更差的答案。

这是路由行业不喜欢谈论的失败，值得追问为什么。一个被错误路由的请求不会抛出错误，不会出现在仪表板上。它从一个不适合这个问题的模型那里生成了一个答案，一个听起来合理的答案，用户阅读了它，也许还根据它采取了行动，而下游没有人会发现系统猜错了。宕机是响亮的，通常几分钟内就能修复。错误路由恰恰相反：它一次一个未被注意的答案地侵蚀信任，而紧张的延迟预算永远无法保护你免受它的影响。

那么这种情况实际发生的频率有多高？没有一个出售路由器的供应商愿意公布这个数字，公平地说，这确实取决于你把任务描述写得多好。但研究结果并不令人安心。RouteLLM 背后的工作表明，基于偏好数据进行路由可以以一小部分成本达到强模型的质量，而单独的微调实验甚至更加惊人。在Anyscale 的 LLM 路由器工作中，一个基于现成嵌入模型构建的路由器开箱即用准确率约为 80.4%，而仅仅在 805 个样本上微调同一个嵌入模型，就将其推到了 98.5%。这不是一个小的差距。这是五分之一请求出错与百分之一请求出错之间的区别，而且在你花一分钱之前就告诉你一件事：这里的大多数错误路由风险并非路由本身固有的，而是对你愿意投入多少调优努力的征税。

然而，即使是调优后的版本也不是终点。一项名为“路由高原”的最新研究在五个基准上测试了 21 种不同的路由方法，发现了一些令人不安的现象：它们都收敛到大致相同的、平庸的准确率，远未达到完美路由器可以实现的水平。研究人员称之为“可预测性瓶颈”。路由器学会了哪个模型在平均情况下往往更好，因此它们能处理简单、明显的案例，却在困难、模糊的案例上悄然出错，而恰恰是在这些案例上出错影响最大。这不是一个可以用更好的提示词修补的 bug。这是一个结构性限制，制约了当今方法能达到的路由决策质量，这意味着上面的调优努力能为你买到真实的准确率，但永远买不到确定性。

DigitalOcean 自己的架构博客报告了其生产路由器背后分类器的强劲数据：在通用、编码和长上下文对话中的平均性能为 87.84%，超过了作为分类器测试的GPT-5.1（86.93%）和Claude Sonnet 4.5（86.11%）。对于专门构建的路由器来说，这确实是一个非常强劲的结果。但按定义，它不是 100%。即使在这个比较中最好的路由器有时也会出错，而且它不会告诉你。

差距在编码方面最大，Plano-Orchestrator 得分 83.51%，而 GPT-5.1 为 77.54%，Claude Sonnet 4.5 为 74.39%。DigitalOcean 报告的这些数据来自一项跨越 605 个对话中 1,958 条消息和 130 多个代理的评估，这是在相信任何路由器的头条数字之前值得寻找的方法论细节。

就在这时数字变得具体起来，DigitalOcean 发布了真实的每请求成本，让你可以诚实地计算而不是猜测。一篇关于推理路由器成本治理的 DigitalOcean 教程展示了一个三层设置：一个用于短分流式请求的廉价分类模型，一个用于客户问答的中档模型，以及一个用于复杂分析的昂贵推理模型。使用 DigitalOcean 自己的实时定价和确认测试运行中的 token 数量，每个请求的成本为：

（来源：使用推理路由器实现多模型 API 成本治理，基于已发布的每 token 定价。）

现在想象一下，每月有700,000个请求本应由廉价模型分类，却被错误路由。如果其中3%（即21,000个请求）落到了客户问答模型而不是分类器上，单单这一项就要花费约93.49美元，而不是本应花费的0.85美元，每月大约多出93美元的差额。这是一个微小且容易被忽视的漏洞。但同样的3%错误路由的分类流量如果落到推理模型上，成本就会跃升到约717.70美元而不是0.85美元，仅因错误路由每月就增加超过716美元，而这还是一个本该是系统中最便宜的任务类别。

一个每月本应花费0.85美元的任务变成了93美元或718美元，却没有任何报错，仪表盘上也没有任何标记。

为了更直观地说明问题，DigitalOcean自己的实操示例表明，如果正确路由这组每月700,000个分类、250,000个问答、50,000个推理的混合流量，总成本约为2,850美元；而如果你将每个请求硬编码到Claude Sonnet 4.5，则大约需要4,717美元，节省约39.6%。如果错误路由率高到足以将分类流量送入推理层，那么在你注意到之前，就可能已经消耗掉这些节省中的相当一部分，因为典型配置中没有任何东西会在发生这种情况时提醒你。

让分类器失效的提示词，以及如何捕捉

某些提示词会让这种情况变得更糟，在将工作负载交给路由器之前，有必要了解它们：

• 非常简短的提示词让分类器无从下手。
• 在单条消息中混合多个任务的提示词，会混淆一个旨在选择单一路由的系统。
• 领域术语可能会让提示词的含义偏离分类器训练所用的数据。

模糊或重叠的任务描述会让这一切雪上加霜，因为路由器的精确度取决于你交给它的类别。其中一些风险需要你自己管理，而另一些则不是，无论你写得多么仔细。

事后发现问题在整个行业中仍然主要是一个人工问题，无论你使用哪种具体路由器，这一模式都值得理解。DigitalOcean的Analyze仪表板会报告总请求数、Token使用量、与配置任务匹配的请求比例以及回退率，文档建议低于90%的匹配率通常意味着任务描述过于笼统（使用推理路由器进行多模型API成本治理）。大多数路由器都会提供某种版本的匹配率和回退率，告诉你某个请求何时完全无法匹配任何任务。这是一个有用的信号，但请注意它实际衡量的内容：未能匹配任何任务的请求。它不会说明某个请求自信地匹配了错误的任务，而这是更危险的情况，也是默认情况下没有仪表盘会标记的情况。要弥合这一差距，通常需要两件事：

• 针对一组带有已知正确答案的保留提示词进行离线评估，通常由LLM充当裁判打分，每当修改任务描述或添加模型时运行。
• 另有一个持续进行的在线路由响应样本，以同样的方式检查。

DigitalOcean自己的Router Evaluation工具就是离线评估部分的一个示例，它会根据预期输出对正确性和完整性进行评分，但模式比具体工具更重要。除了你自己构建并定期运行的评估工作之外，没有什么能够捕捉到高置信度的错误路由，无论哪个路由器位于你的模型之前。

回退听起来很简单：如果你想要的模型不可用，就用另一个。这一句话实际上隐藏了两个问题，而大多数路由文档却把它们混为一谈，好像是一个问题：

• 第一个是模型不可用，即你选择的模型宕机、过载或受到速率限制。
• 第二个是分类器不匹配，即请求根本不符合你定义的任何任务。

DigitalOcean的系统实际上将这两者区分开来：一个名为x-model-router-selected-route的响应头会报告哪个任务匹配了，并且在没有任何匹配时专门返回“fallback”值，这与匹配了模型但模型不可达的情况不同。这种区分很重要，因为这两种失败需要不同的修复措施，而将它们视为同一问题是团队最终解决错误问题的原因。

回退的延迟成本容易说明，也容易被低估：你在主模型上设置的任何超时时间，都会在回退模型开始之前加到总响应时间上。如果你为了安全起见在主模型上配置了30秒的宽裕超时，那么每个需要回退的请求现在至少要慢30秒，这对用户来说往往比快速、诚实的失败更糟糕。这个问题没有干净的解决办法：超时短了，可能会放弃一个只是短暂变慢的模型；超时长了，则可能把小问题变成糟糕的体验。你是在选择愿意承受哪种失败，而不是消除失败。

跨提供商的故障转移，即从一家公司的API回退到另一家公司的API，会进一步提高风险，因为现在你不仅仅是切换模型，而是在切换模型之下的所有东西。LiteLLM的路由器（一个广泛使用的开源工具，正是为此而构建）为一般回退、内容政策拒绝和上下文窗口错误记录了不同的处理方式，每种都单独配置，因为每种都需要不同的响应。它将失败的部署置于冷却期，以便重试不会一直命中刚刚对你进行速率限制的提供商，并按顺序升级到备用层级，最后落入最终的回退列表。OpenRouter（一种托管替代方案）允许你为每个请求指定一个小的有序回退模型列表，并指出了四个不同的触发条件：提供商停机、速率限制、提示词超过模型的上下文长度，以及内容审核标记。请注意这两个工具的共同模式：工具越成熟，就越坚持将失败视为几个不同的问题，而不是一个笼统的“试试别的”选项。这并非偶然；这是因为人们长期构建这些系统后，因将它们视为可互换而吃过亏。

下面是LiteLLM代理配置中这种分离的大致情况：三个不同的回退键对应三类不同的失败，加上重试、短超时和冷却期，这样故障中的部署会被暂停，而不是被反复击打。

model_list:
  - model_name: primary-gpt-5
    litellm_params:
      model: openai/gpt-5
      api_key: os.environ/OPENAI_API_KEY
  - model_name: backup-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-5
      api_key: os.environ/ANTHROPIC_API_KEY

litellm_settings:
  num_retries: 2          # retry the primary before failing over
  request_timeout: 10     # keep this short so a slow model fails fast
  fallbacks: [{"primary-gpt-5": ["backup-sonnet"]}]                 # generic errors (429, 500)
  content_policy_fallbacks: [{"primary-gpt-5": ["backup-sonnet"]}]  # moderation rejections
  context_window_fallbacks: [{"primary-gpt-5": ["backup-sonnet"]}]  # prompt too long
  allowed_fails: 3        # trip the cooldown after 3 failures per minute
  cooldown_time: 30       # park a failing deployment for 30 seconds

三个独立的*_fallbacks键正是关键所在：内容策略拒绝和提示词过长与速率限制不是同一类问题，而反射性地将三者全部路由到同一个备用模型，最终只会掩盖缺陷，而非在故障中幸存。

除了触发条件本身，跨提供商设置还会带来与路由逻辑无关的额外工作：每个提供商需要独立的凭据，响应格式也需要规范化，因为各提供商的API响应结构各不相同。这正是DigitalOcean自家的Plano引擎在自身基础设施之外使用时，会为OpenAI、Anthropic、Gemini及其他提供商格式配备专门翻译层的原因之一。这个翻译层总得有人来构建，要么是他们，要么是你，而这一点在宣传跨提供商故障转移为何值得做的时候很少被提及。

还有第三种值得了解的模式，它与上述两种回退类型截然不同：级联路由器，它使用相同的机制却服务于完全不同的目的。级联路由器并非仅在失败时才回退，而是每次请求都先尝试一个廉价的模型，检查响应是否达到质量门槛，只有在未达标时才升级到能力更强的模型。Martian与加州大学伯克利分校的研究人员合作构建了RouterBench基准测试，部分目的正是为这种模式提供一种标准化的方法来衡量其取舍。这与我们主要关注的任务分类方法是一个截然不同的赌注：不再是仅凭提示词就预先猜测正确的模型，而是让廉价模型自身的输出告诉你它是否是合适的选择，只有在答案否定时才付出第二次调用的代价。这相当于用分类器准确性的风险换取另一种成本：每次需要升级的请求都会增加额外延迟和额外花费，所以它并非语义路由的无成本升级。这是同一取舍的不同形态，在你假定基于任务的分类是唯一可行方案之前，值得先了解这一点。

鉴于以上种种，有一条规则值得直接采纳，而不是逐案重新评估。当问题属于结构性问题时——例如主模型真正的容量或故障问题——应回退到另一个模型。对于瞬时错误，如短暂的速率限制或网络波动，应使用带短退避的客户端重试。如果每次瞬时故障都路由到一个不同的、通常能力更弱的模型，你实际上是用暂时的速度下降换取了永久性的更差回答。这很少是你真正想做的交易。

所有这些都不是反对路由的理由，而是主张明确了解哪些条件能让路由真正值得，因为这些条件是具体且可检验的，而非凭感觉。一项被频繁引用的多模型路由学术研究（TensorOpera Router：面向高效LLM推理的多模型路由器）发现，与单个专家模型处理一切相比，路由使查询效率提升了高达40%，成本降低了高达30%，并保持或提升了高达10%的输出质量。这样的数字是真实的，但它们完全取决于工作负载构成，而这正是DigitalOcean自己公布的数据所展示的——这种依赖性到底是什么样，而不只是口头断言。

值得退一步思考一个最简单的反对意见：为什么不总是使用前沿模型，跳过这一切？这并非一个幼稚的问题。绕开路由器不仅仅是为了省去小额成本，而是关于你的系统中到底需要多少可靠性机制。前沿模型的价格一直在下降；少一个活动部件就意味着少一个可能悄然失效的环节，而一个硬编码的模型比本文描述的任何方案都更容易推理、监控和调试。如果你的流量足够低，绝对金额的节省无关紧要，或者一次错误回答的代价高到误路由风险超过任何可能的节省，那么这个论点就完全成立，再聪明的任务描述编写技巧也无法改变这一点。对“为什么不总是使用前沿模型”的诚实回答是：对于相当一部分工作负载，你可能确实应该如此。路由的理由从来不是它在总体上更优，而在于随着你的流量增长和任务类型分化，两种方案之间的差距会越来越大，而不是越来越小。

流量构成比其他任何单一因素都重要。在DigitalOcean上述成本计算示例中，在每月70万次分类、25万次问答、5万次推理的混合流量下，分级路由相比将所有请求硬编码到Claude Sonnet 4.5节省了约39.6%的成本。如果以更便宜的始终在线基线——所有请求都用GPT-5——进行同样的计算，节省幅度就缩小到仅7.7%，因为GPT-5自身的定价已经接近路由系统支付的平均水平。这里的教训不是一个固定的百分比阈值，而是路由的回报取决于你的替代方案本会花费多少，以及你的流量中有多少是真正廉价的服务。如果你的大部分流量本来就需要一个能力强的模型，那么路由能为你节省的空间就很小，而引入的风险却更大，换来的节省本来就不会很大。

你可以把这个转化为一个实际的盈亏平衡数字。复现DigitalOcean自己的成本模型（其每token价格，以及非廉价部分中问答与推理流量5比1的同样比例），阈值完全取决于你本来会硬编码什么。相对于昂贵的Claude Sonnet 4.5基线，路由在整个现实区间内都占优，无论你的廉价流量有多低，至少都能节省23%，因为Sonnet无论对琐碎请求还是推理密集型请求都同样昂贵。相对于便宜的GPT-5全包基线，存在一个真实的盈亏平衡点，大约在59%廉价任务流量处：低于这个比例，将问答层级发送给Sonnet的成本会超过分类节省所回收的金额，因此硬编码GPT-5就是纯粹更便宜的选择。DigitalOcean的70%廉价流量示例确实超过了这个阈值，但也只超出了7.7%。关键不在于具体百分比——它会随价格和你的任务比例而变化——而在于你可以在假设路由划算之前，计算并且应该计算你自己的交叉点。

具有清晰可分离任务类型的工作负载是最适合的，这有一个相关但不同的原因：它们为分类器提供了真正可用的信息。一个将简短分类问题与散文式回答及深度技术故障排查分开处理的客服系统，给路由器提供的是在结构和长度上真正不同的任务，而不仅仅是主题不同。

固定步骤的Agent流水线也是一个强有力的候选方案，因为任务类型部分取决于你在流水线中所处的位置，而不是纯粹依靠从提示词的措辞中猜测。以一个编码Agent为例：在一次会话中，Agent可能会进行深度代码库分析、编写新函数、根据测试输出修复Bug以及搜索文档——这些任务的差异足够大，将每个任务路由到规模合适的模型在架构上是合理的，而不是因为硬编码的默认值恰好是前沿模型，就为所有任务都支付前沿模型的费用。

多轮会话还能获得一项路由很少被认可的收益：只需支付一次分类器的成本，而不是在每一轮都支付。大多数支持这一功能的路由器允许你将会话固定到第一轮选定的模型，从而在对话的其余部分跳过重新分类。这种固定还顺带保住了另一项不相关的收益：基于前缀的缓存。在会话中途切换模型会使提供商的缓存前缀完全失效，因为缓存与特定模型绑定，丢失它的代价很高。在一个15轮的Agent循环中，如果90%的输入是重复的缓存前缀，DigitalOcean记录的数据显示，保持缓存热状态可以在输入token成本上节省45%到80%。这是对一项收益的具体量化——在会话固定和前缀缓存同时可用的任何地方，这种收益都应当以某种形式成立。这是路由较为持久、低风险的胜利之一；它之所以持久，恰恰是因为它的运作方式是减少路由器需要做决策的频率——这正是本文一直在论证你应该减少的那件事。

围绕“智能路由”的营销语言将解决截然不同问题的产品混为一谈，而这种混淆对那些受益于你不仔细审视的人来说，确实在发挥实际作用。值得根据真正重要的维度来区分它们：它们是按任务内容分类，还是主要按可用性和价格分类；分类器是位于你的请求路径之内，还是需要额外的网络跳转；以及在此之后你实际能看到什么。

根据底层实际执行工作的分类器类型来区分它们也很有帮助，因为“路由器”在不同产品中所做的事情截然不同。其中一些方法，如前面讨论的RouteLLM方法，依赖于嵌入相似度：它们将提示词的嵌入与一组带标签的示例进行比较，并基于最近邻进行路由。这种方法部署成本低，而且通过微调能显著提高准确性，正如准确率从80.4%跃升至98.5%所显示的那样。另一些方法则使用小型的、专门训练的分类器模型，而不是相似度搜索——例如vLLM Semantic Router采用基于BERT的mmBERT分类器的做法，或者DigitalOcean采用Arch-Router和Plano-Orchestrator的做法。后者是专门训练来阅读对话并输出路由决策的生成模型，而不是被临时征用为分类器的通用模型。还有第三类方法完全跳过了固定的任务类别：Martian和Unify都试图预测给定模型在特定提示词上的表现，然后基于该预测进行选择或级联，而不是将提示词匹配到预定义的类别。在抽象意义上，这些方法中没有一种严格优于其他方法。固定任务类别更容易推理和审计；基于预测的方法能更好地适应无法干净地归入任何类别的提示词；而哪种方法胜出，则取决于你自己的流量能多好地映射到离散的任务类型上——这正是本文反复回到的同一个问题。

让我们来看一些常见的提供商：

• DigitalOcean Inference Router使用一个专门构建的分类器——要么是40亿参数的模型，要么是名为Plano-Orchestrator的300亿参数专家混合模型（约30亿活跃参数）——该分类器与DigitalOcean自身的服务基础设施共置部署，因此分类过程不会产生额外的网络调用。它提供OpenAI兼容的API，通过x-model-router-selected-route头报告匹配到的任务，通过X-Model-Affinity头支持会话固定，并通过Analyze仪表板报告聚合指标。它目前只在DigitalOcean自己的模型目录内进行路由，并且处于公开预览阶段。
• vLLM Semantic Router是由vLLM项目在Red Hat的支持下构建的开源、自托管替代方案。它作为Envoy外部处理器运行，调用基于Rust的BERT分类器；该分类器构建在名为mmBERT、拥有约3.07亿参数的模型之上，用于处理意图分类以及越狱和PII（个人身份信息）检测。一篇相关的研究论文（何时推理：面向vLLM的语义路由器）报告称，与始终使用完整推理模式相比，该方法在MMLU-Pro基准上的准确率提升了10.2个百分点，响应延迟降低了47.1%，token使用量减少了48.5%。这种控制权的代价要由你自己承担：没有托管的仪表板，没有可以致电的供应商，你需要自己运行和监控它。
• LiteLLM Router最好将其理解为一个负载均衡和可靠性层，只不过它恰好也做了一些路由。它凭借强大的凭据和速率限制管理，处理超过一百个提供商的的重试、冷却和回退，并区分通用回退与内容策略回退和上下文窗口回退。它在跨提供商、以可用性为核心的故障转移方面非常强大。语义任务分类不是它的重点，如果你需要的是这个，你必须在它之上自行构建那一层。
• OpenRouter为你提供跨多个提供商的统一托管API，每个请求都带有一个有序的回退模型列表。回退会在停机、速率限制、上下文长度错误和审核标记等情况下触发；如果所有回退选项都用尽后运行仍然失败，它不会向你计费。与LiteLLM一样，它的逻辑主要关注跨提供商的可用性和成本，而不是将提示词匹配到任务类型。

以下是同一比较的速览：

这里提供一种基于你自身工作负载而非供应商演示的决策方法，这也是唯一真正具有普适性的决策方式。

以下情况适合使用路由：

• 你的任务类型会产生结构上不同的输出，而不仅仅是主题不同，这样分类器才有真正可以处理的内容。
• 你的响应时间预算足够宽裕，100 到 200 毫秒的分类器开销不会占去很大一部分。
• 你能够持续监控回退率和任务匹配率，而不是只在启动时检查一次就不再理会。
• 你的模型阵容足够稳定，不需要每周重写任务描述。
• 你运行的是多轮、智能体式工作负载，其中会话固定（session pinning）让你只需为每个会话支付一次分类器成本，而不是每一轮都支付，这大约是整篇文章中最接近“稳赚不赔”的事情。

以下情况不适合使用路由：

• 你的几乎所有流量都需要相同水平的模型能力，因此路由器几乎没有可区分之处。
• 你的响应时间预算非常紧张，几百毫秒的分类器开销已经占其中相当大的一部分。
• 你的提示词很短，分类器几乎没有可处理的信息。
• 你尚未测量自己的错误路由率及其成本，而是依赖营销宣传的说法。

同时，也要对自己诚实：路由的真正目的是什么？路由到更便宜的模型只有在以下情况下才有帮助：你已经另行确认过，该更便宜的模型在你自己具体任务上能产生可接受的答案。路由并不能取代“检查更便宜模型是否足够好”的评估工作；它只是在你已经知道答案之后，自动决定请求的去向。

特别针对跨提供商故障转移：保持主超时时间较短，这样缓慢的故障不会叠加成更慢的回退。提前规划响应格式的差异，而不是在生产环境中才发现。同时，将跨提供商回退视为一种可用性策略，而非主要的成本节省机制，因为涉及的凭证、速率限制和格式规范化工作所耗费的工程时间，往往比在中等等流量下节省的成本还要多。

1. 什么是多模型路由？它与直接选择一个模型有何不同？

多模型路由在多个模型之前放置一个决策层，并将每个请求发送给它判定最合适的模型，通常基于提示词的内容（语义或基于任务的路由）或实时的可用性和价格。与“直接选择一个模型”的区别在于，这个选择是由你并不直接控制的基础设施，在每次请求时自动做出的。当你的流量多样时，这会非常强大，但也意味着任何请求上都可能悄无声息地发生路由错误。

2. 路由器实际上会增加多少延迟？

这取决于路由器，但DigitalOcean的文档引用其Inference Router大约有200毫秒的开销，而其早期的Arch-Router分类器在大约50毫秒内解析意图。重要的数字不是绝对开销，而是开销在你首令牌时间预算中所占的比例。200毫秒对于1000毫秒的批处理任务来说接近背景噪声，而对于低于100毫秒的代码补全功能来说则完全不合格。

3. 为什么错误路由被认为比宕机更危险？

宕机是明显的：某些东西出错，监控触发，通常几分钟内就能修复。错误路由是无声的：请求成功，一个看似合理的答案从错误的模型返回，而你的日志中没有任何东西标记它。标准仪表板报告的是匹配率和回退率，它们只告诉你请求何时没有匹配到任何任务。它们对请求自信地匹配到错误任务的情况只字不提，而这正是随着时间的推移侵蚀质量的故障。

4. 路由真的能省钱吗？

有时候能，而且这几乎完全取决于你的流量混合。在DigitalOcean的实例中，分层路由相较于将所有内容硬编码到Claude Sonnet 4.5节省了约39.6%的成本，但相较于已经便宜的GPT-5基线仅节省了约7.7%，因为该基线的价格已经接近路由系统平均支付的水平。相对于GPT-5基线，在约59%的廉价任务流量处存在一个真正的盈亏平衡点，低于该点，路由的成本超过其节省的费用。错误路由也可能抹掉节省：将3%的廉价分类流量发送到推理层，可能会将一个约0.85美元/月的任务变成约718美元/月。

5. 什么时候我应该直接使用单一前沿模型而不是路由？

当你的流量量低到绝对金额节省无所谓时，当你几乎所有流量都需要相同的高能力水平时，当你的延迟预算无法吸收分类器开销时，或者当一个错误答案的代价高到错误路由的风险超过任何可能的节省时。单一硬编码模型更容易推理、监控和调试。对于相当一部分工作负载来说，这种简单性是正确的选择。

围绕多模型路由的讨论大多只讲述了一个双面故事中的一面。它能省钱。它能提高质量。它能让你保持在线。这些都可能成立，但这从来都不是全部。路由还会在每个响应之前增加可测量的延迟，引入一种新的、无声的出错方式，并使回退逻辑比推介材料所展示的复杂得多，尤其是当涉及多个提供商时。这些都不意味着路由是个坏主意。它使路由恰好成为标题所说的那样：一个基础设施决策，账本两边都有实际成本，而不是一个因为演示看起来不错就开启的功能。

所以在决定任何事情之前，先衡量你自己的流量。对照你自己的SLA检查你自己的延迟预算，而不是基准表。上线后持续关注你的回退率和匹配率，而不是只在启动时看一次。对数学上明显有利的工作负载进行路由，而不是默认假设它处处有帮助，因为整篇文章的论点就是它并非如此，而那些以艰难方式学到这一点的团队通常是最初从未计算过数据的团队。

• 如何使用Inference Router
• 我们如何构建DigitalOcean Inference Router
• 使用Inference Router进行多模型API成本治理
• 推理路由：将模型与任务匹配，而不仅仅是请求
• Hugging Face，katanemo/Plano-Orchestrator-4B
• Arch-Router：将LLM路由与人类偏好对齐
• RouteLLM：使用偏好数据学习路由LLM
• 构建高质量且成本高效的LLM路由器
• 路由平台期：理解并打破LLM路由器的准确率极限
• 何时推理：vLLM的语义路由器
• TensorOpera Router：用于高效LLM推理的多模型路由器（EMNLP 2024）
• vLLM语义路由器：LLM推理的下一阶段
• vLLM语义路由器：提高AI推理效率
• LiteLLM文档：路由与负载均衡
• LiteLLM文档：回退
• OpenRouter文档：模型回退
• Martian：介绍RouterBench
• BentoML：LLM推理的关键指标
• LLM推理速度详解：TTFT、吞吐量与延迟