多提供商LLM路由不是问题，而是你的架构：生产环境推理系列

每个推理提供商的销售手册中都有关于为什么你应该与他们整合的内容。推销通常包括对竞争对手的锁定担忧、管理多个API密钥的运营复杂性，以及单一计费关系的便利性。

以下是手册没有说的：最精明的买家、大规模运行AI的团队、那些真正知道自己在做什么的人，几乎普遍在设计中采用多提供商。他们将批处理任务路由到最便宜的端点，实时查询到最快的端点，小众模型放到拥有它们的提供商，合规敏感的工作负载交给认证提供商。他们这样做是有意的，而非偶然。

对这一现实的正确回应不是与之对抗，而是在其中变得有用。

本文介绍当今生产中多提供商路由如何运作、团队用于实现它的工具，以及推理提供商的第一方路由在哪些方面改变了计算方式。所讨论的DigitalOcean产品包括Serverless Inference（位于inference.do-ai.run的按token计费、兼容OpenAI的端点）、Inference Router（第一方、基于策略的模型路由）和Dedicated Inference（按GPU小时部署）。

• 多提供商路由是严肃团队的默认架构：需要为此设计，而不是一个需要对抗的问题。
• 驱动因素具有结构性：没有提供商拥有所有模型，API可用性（约99.1–99.8%）低于传统基础设施规范，因此故障转移是必须的，而且同一模型在无服务器提供商之间的价差约为2倍（跨模型层级则达60倍以上）。
• 按约束路由：批处理→最便宜，实时聊天→最低TTFT，小众→最广泛的目录，合规→认证区域，外加一条后备路径。
• 优化有效吞吐（以正确答案满足SLO的请求），而不是原始token/秒或最便宜的token。
• OpenAI兼容API使切换变成更改base-URL，因此锁定效应很弱；第一方路由（DigitalOcean Inference Router：客户报告推理成本降低高达67%）在运营上实现差异化，而不是通过困住你。

“在单一推理提供商上全押”在运行严肃生产工作负载的团队中越来越罕见。驱动因素具有结构性：

1. 没有单一提供商拥有完整目录

模型格局已经碎片化。前沿闭源模型（Claude、GPT-5、Gemini）需要直接使用各自的提供商。开放权重模型运行在Together、Fireworks、Groq、Replicate或你自己的基础设施上。专业化模型（医疗编码、法律推理、代码专用）通常托管在精品提供商处。没有单一提供商能以最佳性能和价格提供所有这些。

2. 可用性差距证明故障转移的必要性

传统云基础设施的SLA为99.9%以上。LLM API的可用性达不到这个水平。一家第三方监控（TokenMix的30天滚动数据）报告主要提供商在约99.1–99.8%的范围内，表现最低的约97.2%（每月大约20小时停机）。将任何单个此类数字视为方向性而非权威性。大多数提供商发布自己的状态页面，而你的实测可用性取决于你的区域、模型和流量形态。但结构性观点在所有来源中都成立：生产级LLM API低于你期望从成熟云基础设施获得的99.9%以上。对于AI层处于关键路径上的应用，这要求制定故障转移策略；请对照每个候选提供商的状态页面核实其真实数字，而不是任何聚合器的表格。

这不是对任何特定提供商的批评，LLM推理比静态文件服务器更难做到可靠。这是该技术当前成熟度的结构特性。用小时来衡量：99.8%在30天的一个月内大约1.5小时停机，99.1%约6.5小时，97.2%约20小时。如果你的应用一个月内无法承受来自单一提供商的数小时不可用，你就需要不止一个。

3. 价格差异使路由在经济上合理

并非所有推理流量都有相同的要求。一个合理的路由架构会根据实际约束对流量进行分类并相应路由：

可以把这想象成物流运输作业。经验丰富的货运商不会只用一家承运商处理所有货物：他们用隔夜空运处理紧急包裹、用陆运处理大宗货物、用区域承运商处理最后一公里配送，并为跨境需求备用国际选项。智慧在于将货物需求与承运商的优势相匹配，而不是因为只用一家承运商更省事就那样做。

路由器就像一个调度员：它读取每个请求的约束（成本、延迟、模型可用性、认证），然后选择满足该约束的通道。这些通道就是上面的路由表。

那些对所有推理流量一视同仁、把所有内容都通过单一提供商的单一层级路由的团队，就相当于为所有货物支付隔夜空运的费用，包括非紧急货物。

LiteLLM和OpenRouter已经在做这件事：第一方路由带来了什么

在讨论第一方路由之前，有必要实事求是地看待生态系统中已有的东西。你可能已经知道这些工具，而且可能已经有一个在生产环境中运行。

LiteLLM是一个开源的Python库和可自托管的代理，通过OpenAI兼容接口暴露100多个LLM提供商。它处理提供商抽象、回退逻辑、成本跟踪和速率限制。代价是：它是自托管的（运维负担）并且会增加延迟开销。自托管还意味着你拥有整个依赖链：这样一个规模的代理会引入一棵庞大的传递依赖树，因此要像对待关键路径上的任何其他服务一样固定版本并跟踪安全公告。对于拥有Python基础设施且有能力自托管的团队，它是一个经过验证的选择，拥有庞大的社区。

OpenRouter是一项托管路由服务，在单一API和统一计费背后提供来自数十家提供商的300多个模型。它接受一个按优先级排序的模型数组，当主模型失败、触发速率限制或被拒绝时，会自动尝试下一个。它不可自托管，但完全消除了运维负担。代价是：你在关键路径上增加了另一个托管依赖，而且与自托管方案相比，你对路由决策的可见性更低。

Portkey、Bifrost等工具占据类似的位置：托管网关，在可观测性、成本跟踪和企业功能方面各有侧重。

重点在于：这些工具确实存在、确实能用，而且如果你认真评估过路由方案，你很可能已经看过它们了。如果 OpenRouter 已经接入你的技术栈，那么“你不需要它，只用一家供应商就行”并不是一个论点，而是在要求你拆掉已经能跑的代码。更有意义的问题更具体：第一方路由能给你带来哪些第三方网关给不了的东西？

DigitalOcean 的 推理路由器是内置于推理平台本身的第一方路由层，它不是连接多家供应商的第三方网关，而是一种原生能力。在托管推理平台中，这种第一方路由仍然不常见；目前大多数多供应商路由都是通过叠加在平台之上的第三方网关实现的。

这在实际中意味着：

• 无外部网络跳转：路由决策在平台内部完成，而不是通过增加一次网络往返的外部代理。不过，路由决策本身并非没有成本：DigitalOcean 的官方文档将路由器开销列为每个请求约 200ms，这仍然优于外部网关的代理跳转加上其自身的决策时间，但在严格的 TTFT 目标下需要纳入预算考量
• 集成计费：无需与网关供应商建立单独的计费关系；路由是同一个账户的一部分
• 无需自定义代码的跨模型路由：路由器自动在模型层级之间转移请求，将简单查询发送到较小的模型，并将复杂查询升级处理。这在真实工作负载上能省下多少，将在下一节中用数据衡量；DigitalOcean 的发布公告引用了一位客户（LawVo）的报告，称基于路由的模型选择使推理成本降低了 40% 以上；在你自己跑过流量验证之前，请把任何供应商发布的数字（包括这个）都只当作方向性参考。（DigitalOcean 发布的更大的“67%”数字属于另一种机制：专用 GPU 基础设施上基于 KV 感知的路由，而非跨模型的规模调整）
• 无需部署即可重新配置：路由策略存在于平台中，而不是你的应用中，因此更改由哪个模型服务你的流量只需一次 API 调用，而不需要发布版本
• 一站式可观测性：路由决策、延迟、成本和缓存命中率与你的其他基础设施显示在同一个仪表盘中

区别并不在于 DO 的路由在路由能力上优于 LiteLLM；两者都能路由请求。区别在于运维层面：第一方路由消除了一个依赖，减少了集成面，并将路由逻辑保留在推理实际运行的平台内部。

为路由辩护的理由基于一个测量指标：模型选择税。下面的对比按照每个模型公布的价格，对相同的分类请求进行定价，使用 2026 年 6 月文档化运行中测得的 token 形态（openai-gpt-oss-20b 上 94 个输入 / 80 个输出 token，来自 inference.do-ai.run）作为固定参考。请注意，真实的跨模型使用从来不会是逐字节相同的（每个模型对相同消息的分词方式不同，生成补全 token 的数量也不同），因此这是在固定形态下对价格的比较；你测得的单请求差异还会取决于每个模型在你工作负载上的输出冗长程度：

仅价格差异就达到了 36 倍。当一个小模型就能达到准确率门槛时，把所有分类调用都发送给 Sonnet 在 70 万次请求下每月成本为 1,037.40 美元，而只有 28.49 美元。在一次文档化的 成本治理测试中，在 70 万 / 25 万 / 5 万次的分类 / 问答 / 推理混合负载下，路由器调度使月度成本相对于仅使用 Sonnet 的基线降低了 39.6%，相对于仅使用 Opus 降低了 63.7%。你可以用自己的 API key 复现每请求的差异：

curl -s -X POST "https://inference.do-ai.run/v1/chat/completions" \
  -H "Authorization: Bearer $MODEL_ACCESS_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai-gpt-oss-20b",
    "temperature": 0,
    "messages": [
      {"role": "system", "content": "Classify the ticket. Reply with one word: billing, bug, how-to, or account."},
      {"role": "user", "content": "I was charged twice for my subscription last month."}
    ]
  }' | python3 -c "import sys,json; print(json.load(sys.stdin)['usage'])"

何时使用哪一层路由：

• 第一方（DigitalOcean Inference Router）：你的主要工作负载运行在 DigitalOcean 上，希望路由不需要外部网关跳转、没有独立账单、只有一个控制面板。当 DigitalOcean 是你的主要提供商时，这是最佳选择。
• 第三方网关（LiteLLM、OpenRouter）：你的服务跨越 DigitalOcean 未托管的多个提供商，或者你需要一个可完全控制路由逻辑的自托管代理。接受额外的跳转和依赖。
• 单一提供商，不使用路由器：低流量、单一工作负载类型、单一模型层级。在流量真正混合简单和复杂任务之前，路由开销并不值得。

到目前为止，关于路由的讨论一直围绕成本。还有一个属性，随着系统运行时间越长越重要：模型决策的存储位置。

如果模型名称只是应用程序中的一个字符串，那么采用新模型就意味着每次调用它的服务都要经历代码更改、代码审查、发布和回滚计划。如果模型决策位于路由策略中，那么它只是一个配置更改，应用程序甚至不会感知到这一变化。

我构建了一个演示来验证这一机制确实可行，而不是凭空假设。两条通道服务同一个请求流：一条硬编码模型，另一条调用路由器。在请求流进行中，通过 API 重新调整了路由器的模型排序：

PUT /v2/gen-ai/models/routers/{id}

此后的每个响应都由新排名的模型提供。观察到的传播时间约为两秒。切换期间零客户端更改、零部署、无失败请求。

让这一点可通过验证而非仅凭宣称的部分在于：响应中的model字段由服务器端写入，且每个响应都带有x-model-router-selected-route头，显示平台选择了哪条路由。你无需轻信客户端关于哪个模型回答的说法；你可以直接从响应中读取，并将其与你的质量指标关联起来。

这是每次新模型发布时都会出现的问题的实用答案：如何在不让实时流量中断的情况下采用新模型？如果模型是硬编码的，答案涉及一个发布列车。如果它位于路由器之后，答案就是一次排名变更和一个事后可验证的头字段。

这就是向你推销路由时无人提及的矛盾：你路由出去的每个请求，都是一个无法命中热缓存的请求。

提示缓存实践：命中率从 7% 到 74% 从另一侧衡量了这一点。前缀缓存将输入成本削减了约 90%，但这仅仅是因为稳定的前缀反复落在同一端点并在缓存 TTL 内。路由同时攻击了这两个前提：

• 不同目的地，冷缓存。每个提供商和每个模型都有各自的前缀缓存。将相同的系统提示发送给三个模型，你会填充三个独立的缓存，为 1.25–2× 的写入溢价支付三次，而不是一次。
• 流量分散，间隔拉长。将工作负载分成四份后，每个目的地现在只看到四分之一请求率，因此请求之间的间隔变为原来的四倍。第 3 篇文章的衡量结果直白地说明了接下来会发生什么：请求到达间隔超过 TTL 的端点根本不会累积任何命中。一个在满负载下运行良好的 5 分钟 TTL，在四分之一负载下可能完全失效。

算术决定了哪种效应占上风，而且当你将两组数字并排查看时，差距并不小：

跨层级路由；不要在提供商之间拆分同一层级。将分类任务发送给成本低 36 倍的模型，其价值远超你为此放弃的任何缓存，而且这本来也不会让你损失什么，因为不同任务拥有不同的前缀，本来就不会共享那条缓存条目。但为了追逐约 2 倍的费率差异而将一个工作负载类别拆分到多个提供商，可能会在输入侧损失约 10 倍的缓存收益。这笔交易通常是亏本的，而团队往往是在两个提供商之间配置轮询负载均衡“以求高可用”后，奇怪为什么输入账单上升时，意外犯下这种错误。

两个实际后果：让每条路由保持足够的流量密度，使其流量仍能刷新 TTL；并且按定义将故障转移路由视为冷路由：故障转移后的首批请求会为一个尚不存在的缓存支付全价，这在估算中断成本之前值得了解。

路由器厂商意识到了这一矛盾。DigitalOcean 的 Inference Router 支持一个 X-Model-Affinity 头：传入一个会话标识符后，路由器正常路由第一个请求，然后将该会话中的后续请求固定到同一个模型，从而在多轮循环中保持前缀缓存热度，而不是在每次路由决策时使其失效。如果你采用任何路由器，无论是第一方还是第三方，在假设路由与缓存无法共存之前，请先检查它是否提供了等效机制。

大多数团队从每秒 token 数或每秒请求数的角度来考虑推理性能。这些指标很重要，但都不完整。

正确的指标是有效吞吐（goodput）：在目标 SLO 内完成并返回正确、可用响应的请求。一个每秒处理 1,000 个请求，但其中 15% 超时、另有 10% 返回幻觉的系统，其有效吞吐是 750 个在 SLO 内正确的响应，而不是 1,000。

这种重构改变了你对路由的思考方式：

• 原始吞吐量（tokens/sec）是供应商指标，适用于容量规划
• TTFT 是用户体验指标，对同步应用至关重要
• 目标延迟下每正确响应的成本是业务指标

当你为有效吞吐路由时，决策矩阵看起来会不同。Groq 的 LPU 在 Llama 3.3 70B 上提供了业界最高的输出吞吐量之一；数字确实令人印象深刻。但如果你的 SLO 是 500ms 端到端延迟，而 Groq 的队列深度偶尔导致 800ms 响应，那么 Groq 的吞吐量数字就帮不了你。为有效吞吐路由，而不是为原始规格路由。

多提供商路由在 2026 年之所以结构上容易，一个原因是：几乎每个推理提供商都提供 OpenAI 兼容 API。在大多数情况下，切换提供商只需更改基础 URL 和 API 密钥。仅此而已。

这使得供应商锁定论点比三年前弱得多。一个说“如果你添加第二个提供商，你会遇到集成麻烦”的提供商，所描述的现实自 2023 年以来就不再成立。提供商之间的正面较量成本很低。迁移不是六个月的工程；而是一天的任务。

推论是：唯一可持续的差异化形式，是在你实际工作负载上可衡量地更优的性能，而不是让切换变得痛苦的摩擦。

EMEA：美国主要无服务器提供商目前并不从欧盟提供服务

在美国主要的纯推理服务提供商中，存在一个显著的地域缺口。Together AI、Fireworks AI 和 Groq 都在美国数据中心运行无服务器推理（Together 仅在面向企业层的专用端点上提供欧盟部署选项）。如果你有 GDPR 合规要求，这不是偏好问题，而是合规障碍。在许多情况下，个人数据依法不得在欧盟/欧洲经济区之外进行处理。

DigitalOcean 在阿姆斯特丹运营着欧盟 GPU 基础设施（NVIDIA 裸机 GPU），通过在该基础设施上进行专用/自托管部署，如今即可实现欧盟驻留推理。

如果你的可用性要求超过了任何单一推理提供商所能提供的水平（而 99.9%+ 高于大多数提供商生产 API 的实测性能），那么后备架构就不是可选项。

一个最小化的韧性架构如下：

1. 主提供商：为你的主要工作负载类别提供最佳性能的选项
2. 备用提供商：同一模型或同等质量，但来自不同提供商
3. 故障转移逻辑：在主提供商超时、错误率达到阈值或触发速率限制时，自动路由到备用提供商
4. 熔断器：防止重试风暴放大局部故障
5. 可观测性：在触发故障转移时发出告警，并跟踪你处于备用提供商的时间

前面的路由分类法仍然适用：使用主提供商处理标准流量，备用提供商作为故障转移，并将不同的工作负载类型路由到各自的适当层级。架构不需要很复杂：一个配置良好的 LiteLLM 或 Inference Router，搭配两个提供商端点，即可覆盖大多数情况。

这实际上所需的代码极少。在我为观察这一过程而构建的演示中，一个三步智能体（检索 → 总结 → 提取）在两条通道中处理相同的请求，而主端点持续返回 429 状态码。两个通道中的智能体代码逐字节完全相同。唯一区别是配置中的一个元组：

ENDPOINTS = (PRIMARY,)         # single-endpoint lane: burns its retries, then fails
ENDPOINTS = (PRIMARY, ALT)     # routed lane: fails over mid-run and finishes

单端点通道耗尽重试次数后停止运行。路由通道完成故障转移，该通道上的用户永远不会知道发生了故障转移；它只出现在决策日志中。（故障由本地代理注入，因此运行是确定性的；该练习演示了故障转移行为，并不反映任何提供商的真实错误率。它也不是延迟基准；路由通道在切换前通常会多支付一次失败的请求。）

上述清单未涵盖两种故障模式，而这两种模式在生产中都会造成影响：

你的备用系统是不同模型，因此你的评估必须在两者上都通过。 “相同模型或同等质量”在该清单中承担了大量工作。如果备用系统是不同模型（跨提供商时通常如此），那么故障转移就是一次静默的质量变化。针对回退路径运行你的评估集，而不仅仅是主路径，否则提供商事故就会变成未被发现的降级，只会在用户投诉中显现。

故障转移要付出代价，而不仅仅是时间。 如果备用系统高了一个层级，那么六小时的事故不仅是可用性问题，也是成本事件。根据上一节所述，回退路径按定义就是冷路径：切换后的第一批请求在尚未填充的前缀缓存上需支付全价。在需要之前就估算好这一点，这样事故复盘就不会是第一次有人做这笔计算。

关键原则：刻意设计回退路径，而不是假设你的主要提供商永远不会出问题。 一个构建了弹性多提供商架构，并让一个提供商作为其主要工作负载类别的主端点的团队，最终会比一个原则上只运行单一提供商、在首次事故中手忙脚乱的团队处于更有利的位置。

将任何提供商置于多提供商架构中的有用方法是问它应该主要用于什么，而不是它是否应该是你唯一的提供商。对于DigitalOcean，诚实的回答是：对于主要工作负载和路由控制平面来说，它是一个很好的默认选择。

它在哪里赢得主要地位：

• 全栈集成（推理 + 计算 + 向量数据库 + 存储），比多云替代方案的总拥有成本低20–40%，据DigitalOcean自己的Deploy 2026分析；由供应商发布，因此应视为方向性参考，并在依赖之前对你的自身堆栈进行建模
• 第一方路由层，可处理模型合理选型，无需第三方依赖
• 通过阿姆斯特丹GPU基础设施上的专用推理实现欧盟数据驻留。
• 单一VPC、单一计费关系、集成可观测性。

1. 跨多个提供商的路由会增加延迟吗？

这取决于路由发生的位置。第三方网关位于你的应用程序和模型之间，因此你需额外支付一次网络往返，通常为几十毫秒，这对于500毫秒的TTFT预算很重要，而对于批处理作业则无所谓。推理平台内部的第一方路由避免了外部跳转，但路由决策本身仍需要时间：DigitalOcean的文档将Inference Router的开销定为每请求约200毫秒。在做出任何假设之前，用你自己的流量进行测量，并在针对任何严格的TTFT目标时，将路由器的决策时间（而不仅仅是网络路径）纳入预算。

2. 我的流量很低。我真的需要路由器吗？

可能不需要。当你的流量确实混合了任务复杂度（廉价分类与昂贵推理共存）时，路由才会产生回报，因为节省来自不将简单工作发送到顶层。如果你在单一模型层级上以适度流量运行一种工作负载类别，路由器增加的操作面换来的节省也就以美元计。当流量组合多样化或月度账单开始令人痛苦时，再重新考虑。

3. 切换提供商实际上需要多长时间？

对于任何提供OpenAI兼容API的提供商（几乎都是如此），只需一个基础URL和一个API密钥。真正慢的部分不是代码：重新验证评估集上的输出质量，重新从你的区域进行延迟测量，以及重新运行你的组织要求的任何安全审查。为评估预留几天，而不是为集成预留几个月。

4. 当请求需要大模型时，路由器会不会将它们发送到小模型？

这是真正的故障模式，也是为什么可观测性比节省更重要。DigitalOcean的Inference Router在每个响应上返回一个x-model-router-selected-route头，因此你可以记录每个请求实际由哪个模型服务，并将其与你的质量指标关联。如果路由分类错误，你会从该数据中看到，而不是从用户投诉中看到。对于任何降级不可接受的情况，按模型名称显式路由，并让路由器处理那些降级可以接受的情况。

5. 我能直接将这些99.1–99.8%的数字放入我自己的SLA吗？

多提供商路由并非对推理提供商的威胁，而是成熟团队所构建的架构。原因是结构性的：没有哪家提供商拥有全部模型，可用性缺口决定了必须进行故障转移，而价格差异（同一模型在不同提供商间差异不大，但在不同模型层级间差异显著）使路由在经济上具有合理性。

在实践中行之有效的路由分类法：

• 批处理/离线 → 最便宜的提供商
• 实时聊天 → TTFT最低的提供商
• 小众模型 → 目录最全的提供商
• 合规敏感 → 在正确区域获得认证的提供商
• 回退 → 主提供商故障时使用备用提供商

你还可以参考以下本生产环境推理系列的其他文章：

1. 为什么你的LLM账单是你预期的3倍
2. 如何为推理用例选择合适的LLM模型
3. 提示缓存实践：命中率从7%提升到74%
4. 生产环境AI应用的实际成本

• 2026年最佳LLM API提供商 - TokenMix
• DigitalOcean推理定价 - DigitalOcean（模型层级价格阶梯的来源）
• Groq定价 / Fireworks定价 / Together定价 - Llama 3.3 70B对比的官方定价页面
• OpenRouter vs LiteLLM vs Portkey：2026年最佳LLM网关 - ToolHalla
• Groq对比Together AI与Fireworks AI - ToolHalla
• 托管开源LLM的API提供商对比 - Medium
• 使用推理路由器进行多模型API成本治理 - DigitalOcean（2026年6月实测运行）
• 如何使用推理路由器 - DigitalOcean文档
• KV缓存如何大幅降低大规模LLM推理成本 - DigitalOcean
• LLM推理三难困境 - DigitalOcean
• AI正常运行时间SLA：为什么你的业务需要多模型回退策略 - Universal.cloud