OpenRouter 可靠性与自动故障转移：双层容灾配置、失败不计费规则与生产环境检查清单

一句话结论

直连单一供应商意味着单点故障：它宕机时用户看到报错，你在一小时后的支持工单里才知道。OpenRouter 的解法是用两层配置构建可靠性——供应商故障转移自动开启、同一模型内跨供应商恢复；模型回退按需开启、跨模型恢复。两层覆盖不同故障：主模型全部供应商同时失败时供应商层无处可去，模型层是第二道防线。本文按四类失败模式与恢复层的映射、计费规则、双机制原理、实时健康路由、故障转移边界与生产检查清单展开，配置可直接复制。

值得每个项目从这份配置起步，复制后按需调整：

from openrouter import OpenRouter

client = OpenRouter(api_key="sk-or-...")

completion = client.chat.send(
    model="anthropic/claude-sonnet-4.6",
    models=["openai/gpt-5.4-mini"],  # fallback if the primary fails
    messages=[{"role": "user", "content": "Summarize this incident report."}],
)

核心结论速览

• LLM 请求失败的原因可预测：供应商宕机、限流（429）、上下文超长错误、内容审核拒绝。
• 可靠性分两层：供应商层故障转移（默认开启，单一模型内恢复）与模型层回退（经 models 数组按需开启，跨模型恢复）。
• 路由层实时探测供应商健康并绕开故障路由，最坏情况的可用性优于任何直连的单个供应商。
• 故障转移按顺序走你的模型列表，列表耗尽后返回最后一个错误——把可靠的兜底模型排在最后。
• 最终失败的请求不收费，但有用户报告过例外路径（部分 429、部分输出仍扣点数），要盯活动日志并设消费上限。
• 用 only、ignore、order 收窄供应商集合是用可靠性换控制权：候选越少，回退选项越少。

LLM API 请求为什么失败

供应商宕机、限流（429）、上下文长度校验错误、内容审核拒绝，是 LLM 请求失败的四个可预测原因。直连单一供应商对其中任何一个都没有恢复路径，每个都变成用户可见的报错。

最简单的例子是限流。直连一家供应商、撞上它的每分钟上限后，选项只有退避、排队或失败——没有一个能帮到盯着加载图标转圈的用户。

社区把路由层称为”AI 的 DNS”是有道理的：它保持可用，因为它有不止一个可发送请求的去处。

这四类失败模式各自映射到 OpenRouter 的一个具体恢复层，知道哪层管什么，是正确配置可靠性的方法。

四类失败模式与恢复层对照

失败模式	表现	恢复层
供应商宕机或停机	5xx、超时、断连	供应商层故障转移（下一家供应商）
限流（429）	供应商返回”请求过多”	供应商层故障转移，再到模型回退
上下文超长错误	提示词超过模型窗口	模型层回退（换更大窗口模型）
审核拒绝	过滤版模型拒绝应答	模型层回退（换未过滤模型）

前两类是第二家供应商就能解决的基础设施问题，后两类是第二个模型才能解决的模型问题。

失败请求计费吗

简短回答：不计费。故障转移耗尽后最终失败的请求不入账，只为成功的运行付费（零补全保险）。

这让重试的设计成本很低：一条回退链烧掉三家供应商后成功，也只收一次成功补全的钱。可以放心激进地配置回退，不必盯着每次失败尝试的计量表。

需要规划的例外

现实中存在边界情况，官方宁愿读者在这里读到而不是从账单仪表盘发现。有用户报告过 429 错误消耗点数、或出错但部分输出仍被计数的情形。政策是”只为成功运行付费”，但少数 429 路径和部分输出漏了过去。

诚实的取舍：零补全保险真实存在但不滴水不漏。查活动日志确认实际扣费，设硬性消费上限，让边界情况跑不出账单。按消费上限设计，别假设每个失败请求都免费。

供应商故障转移与模型回退

OpenRouter 在两个不同层恢复故障。供应商层故障转移自动开启；模型层回退经 models 数组按需启用。一个让单一模型跨供应商存活，另一个整体换到不同模型。

供应商间故障转移自动发生，你用 ignore、only、order 塑造候选集合。常见场景无需手写重试逻辑。

ignore 按 slug 屏蔽特定供应商；only 限定白名单；order 设定”先试这个”的显式序列。三者都收窄候选集，使用要经深思熟虑——合格供应商越少，回退选项越少。

	供应商层故障转移	模型层回退
恢复什么	服务你模型的供应商宕机或 429	整个模型不可用，加上下文超长与审核拒绝
默认状态	开启（allow_fallbacks: true）	关闭，直到设置 models 数组
控制配置	allow_fallbacks、order、only、ignore	models 数组（优先级顺序）
恢复范围	同一模型，不同供应商	完全不同的模型

这是静态视角。下图展示运行时实际发生的事：单个请求如何穿过两层，在哪里以成功或最终错误退出。

供应商层：一个模型多家供应商

Claude Sonnet 4.6 这样的单个模型常由多家供应商服务。OpenRouter 选中的供应商返回 5xx 或限流时，自动改试同一模型的下一家。由 allow_fallbacks 治理，默认为 true（供应商选择文档）。零配置——发送请求的那一刻起就拥有这层保护。

模型层：整个模型不可用时

主模型的所有供应商全部失败时，供应商层已无处可去。models 数组在此接管：OpenRouter 移到列表中的下一个模型（模型回退文档）。这一层需要自选开启，因为它改变应答的模型——这是只有你能做的决策。

上下文超长错误或审核拒绝同样触发这层，因为换供应商解决不了这两类问题。

供应商层如何维持单一模型可用

对每个模型，OpenRouter 按发布的三步规则在供应商间负载均衡以最大化可用性：优先过去 30 秒无重大故障的供应商；在稳定候选中按价格平方倒数加权选最便宜者；其余留作回退（供应商选择文档）。这首先是可靠性机制，成本其次。

实践中，过去 30 秒内出过错的供应商自动排到队尾；稳定供应商中，最便宜的最先被选中，概率约为价格差的平方。可靠性优先、成本其次、全自动。

30 秒故障窗口是对可用性最关键的部分。过去半分钟打嗝过的供应商自动退出队首，无需你任何动作。

负载均衡算例

文档算例展示可靠性与成本如何协作。设供应商 A 每百万 token 1 美元、B 2 美元、C 3 美元，B 近期有过几次故障。

OpenRouter 先路由到 A；由于平方倒数加权，A 先于 C 被尝试的概率约 9 倍（1/3² = 1/9）。A 失败轮到 C。刚出故障的 B 最后被尝试：故障历史把不可靠供应商推向队尾但不排除它。

这是默认行为。但如果你已经知道某家供应商不行，不必等路由数学自己算出来。

控制候选集合

可以塑造哪些供应商合格，这就是屏蔽不可靠供应商的方法：

• order：按显式序列尝试供应商，如 order: ["anthropic", "together"]。
• only：本次请求的供应商 slug 白名单。
• ignore：黑名单，如 provider: { ignore: ["deepinfra"] } 跳过已知服务过度量化模型的端点。
• allow_fallbacks: false：硬停在所选供应商，无自动备份。

诚实的取舍：用 only、ignore、order 收窄”可能显著减少回退选项并限制请求恢复”（供应商选择文档原文）。排除的每家供应商都是少一个恢复去处。收窄候选池买到控制权、付出可靠性，修剪要 deliberate。

不损失候选池的前提下限制最坏延迟

需要可预测延迟时，设 preferred_max_latency 或 preferred_min_throughput 的百分位截断（滚动 5 分钟窗口，供应商选择文档）。没达标的端点被降权而非排除。与 ignore 组合的形态如下：

completion = client.chat.send(
    model="deepseek/deepseek-v4-flash",
    provider={
        "preferred_max_latency": {"p90": 3},   # prefer <3s for 90% of requests
        "ignore": ["deepinfra"],               # skip a known-bad endpoint
    },
    messages=[{"role": "user", "content": "Classify this ticket."}],
)

以上都是让一个模型跨供应商存活。但当该模型的全部供应商都倒下，供应商故障转移无处可去，模型回退接管并尝试列表中的下一个模型。两者是顺序协作的层，models 数组就是打开第二层的开关。

配置模型回退

按优先级顺序传入 models 数组，第一个模型的供应商全部出错时，OpenRouter 试下一个模型（模型回退文档）。一个数组，无需重试代码。OpenRouter SDK 把 models 作为一等字段；OpenAI SDK 经 extra_body 传递。

cURL 形态：

curl https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"models": ["anthropic/claude-sonnet-4.6", "openai/gpt-5.4-mini"],
"messages": [{"role": "user", "content": "Draft a release note."}]
}'

TypeScript 形态：

import { OpenRouter } from '@openrouter/sdk';

const openRouter = new OpenRouter({ apiKey: process.env.OPENROUTER_API_KEY });
const completion = await openRouter.chat.send({
  models: ['anthropic/claude-sonnet-4.6', 'openai/gpt-5.4-mini'],
  messages: [{ role: 'user', content: 'Draft a release note.' }],
});

完整触发条件表

理解什么触发回退比知道它存在更重要。四种条件任意一条都会触发（模型回退文档）：

触发条件	含义	恢复层
宕机	供应商不可达或持续 5xx	供应商层再到模型层
限流	供应商返回 429	供应商层再到模型层
上下文超长校验错误	提示词超过模型窗口	模型层（换更大窗口模型）
审核标记	过滤版模型拒绝应答	模型层（换未过滤模型）

计费跟随实际应答的模型，在响应的 model 字段返回。核对该字段确认谁服务了请求，尤其在回退触发过的情况下。

触发条件说明回退何时发生，没说的是何时停止。

只有撞上才知道的边界

回退在你列表的尽头停止。“如果回退模型宕机或返回错误，OpenRouter 会返回该错误”（模型回退文档）。它按顺序走一遍 models 数组，绝不是无限重试链。

失败不属于 OpenRouter 判定可回退的错误时，回退也不会触发（例如格式错误请求的 400 会直接返回）。

实用的修法是把 models 数组排序成：最后一项是你最可靠的兜底模型——前面全部失败时你最信任它能应答的那一个。

实时健康路由如何绕开故障

OpenRouter 持续监测全部供应商的响应时间、错误率和可用性，并按实时反馈路由（可用性优化文档）。无需自建监控即得自动供应商健康探测——这是企业评估者最先问的可靠性特性。实时数据喂给 30 秒故障窗口：正在劣化的供应商立刻被路由降权。

可验证的公开可用性

文档为 Claude Sonnet 4.6、GLM 5.1 等模型内嵌实时可用性挂件，供应商可用性是可以盯着看的，不用凭信念接受（可用性优化文档）。三个信号喂给路由决策：响应时间给慢端点降权；错误率让持续 5xx 的供应商退出队首；可用性驱动 30 秒故障窗口。

评估生产可用性时，答案就是这个：实时健康路由、30 秒故障窗口、可亲自验证的逐模型公开可用性，而不是幻灯片上的可用性百分比。

平台健康与路由健康

逐供应商的路由健康实时引导单个请求。平台级健康——网关本身——看 status.openrouter.ai。影响整个网关的事故看状态页；单个供应商不稳定交给实时路由自己处理。路由健康 OpenRouter 自动管，网关本身要你自己盯。

故障转移不覆盖什么

故障转移恢复供应商错误和模型错误，边界就在这里。它不会无限重试、不会捕获”非错误的坏响应”、不会在所有供应商上退还已取消流的费用、无法让网关自身对其宕机免疫。下表是确切边界与对策：

边界	含义	对策
列表边界	models 数组全部出错后返回最后的错误	把可靠的兜底模型排在最后
非错误拒绝	200 状态的”坏”响应不触发回退	正确性关键路径自己校验响应
流取消	部分供应商（Bedrock、Groq、Google、Mistral 等）取消流仍计费	路由到支持流取消的供应商，或为此做预算
网关依赖	路由层有自己的宕机（2025 年 8 月，约 50 分钟）	自己设计重试；盯 status.openrouter.ai

列表边界与错误分类

回退按顺序试 models 数组中的每个模型，最后一个也失败时错误返回给你（模型回退文档），列表之外没有重试链。更糟的是模型返回 200 状态的垃圾内容时回退根本不触发——OpenRouter 只对分类错误触发。把最可靠的兜底模型排在最后，正确性关键时自己校验响应。

流取消在部分供应商上继续计费

客户端停止渲染但全额费用照扣时，第一直觉通常是翻日志：以为提示词触发了审核标记，或浪费时间找从未发生的 5xx。实际原因是一部分供应商——含 Bedrock、Groq、Google、Mistral——不支持流取消（流式参考文档）。中断流式响应时，你这侧连接关了，模型在那侧继续生成（和计费）。对策：成本敏感的流式路径显式只路由到支持流取消的供应商，或为超额部分做预算。

网关也是依赖项

2025 年 8 月，一次约 50 分钟的数据库宕机带倒了整个路由层。路由层有自己的单点故障。Hacker News 讨论的结论公允：“可用性仍优于任何单一供应商”，但不是零风险。自己设计重试，盯 status.openrouter.ai 的网关级事故。

生产环境配置检查清单

合并两层加消费护栏。多数生产设置要的形态：带可靠兜底的模型链、默认供应商故障转移保持开启、排除已知劣质端点、面向用户路径的延迟截断。

步骤	动作
1	设 models 数组，可靠兜底模型排最后，最终回退是最信得过的那个
2	保持 allow_fallbacks: true（默认），除非合规或 BYOK 合同强制单一供应商
3	用 ignore 排除已发现服务劣质的供应商端点；模型页的供应商可用性标签页用来发现它们
4	面向用户的路径加 preferred_max_latency 百分位截断，限制尾部延迟
5	依赖零补全保险，但设消费上限并盯活动日志防 429 边界情况
6	监控 status.openrouter.ai 的网关级事故

这是每个项目推荐的起步配置，复制后调整：

from openrouter import OpenRouter

client = OpenRouter(api_key="sk-or-...")

completion = client.chat.send(
    model="anthropic/claude-sonnet-4.6",
    models=["openai/gpt-5.4-mini", "google/gemini-3.5-flash"],  # floor model last
    provider={
        "ignore": ["deepinfra"],               # exclude a known-bad endpoint
        "preferred_max_latency": {"p90": 3},   # bound worst-case latency
        # allow_fallbacks stays true by default
    },
    messages=[{"role": "user", "content": "Summarize this thread."}],
)

print(completion.model)  # confirm which model answered

拿到 API 密钥，故障转移默认项已经打开。官方建议第一天就加上 models 数组——这是能配置的最便宜的安全网。

常见问题

供应商宕机时 OpenRouter 如何故障转移？单一模型由多家供应商服务时，选中的供应商返回 5xx 或限流，OpenRouter 自动改试下一家。这层供应商故障转移默认开启（allow_fallbacks: true）且零配置（供应商选择文档）。

供应商故障转移和模型回退有什么区别？供应商层故障转移靠换供应商让单一模型存活，全自动；模型层回退经 models 数组整体换模型，按需开启。前者恢复供应商宕机与限流，后者还恢复上下文超长错误与审核拒绝。

什么触发自动回退？四种条件：宕机、限流、上下文长度校验错误、过滤模型的审核标记（模型回退文档）。宕机和限流先在供应商层处理再到模型层；上下文超长与审核在模型层处理。

OpenRouter 对失败请求收费吗？不收。只为成功的运行付费，故障转移耗尽后失败的请求不入账（零补全保险）。要规划一个已记录的例外：有用户报告部分 429 路径和部分输出仍消耗点数，设消费上限并查活动日志。

OpenRouter 生产环境可靠吗？它用 30 秒健康窗口实时绕开供应商宕机，并发布可核验的逐模型可用性（可用性优化文档），最坏情况的可用性优于直连任何单一供应商。但不是零风险：2025 年 8 月的网关宕机说明路由层有自己的依赖。自己设计重试并监控 status.openrouter.ai。

怎么在 OpenRouter 上配置回退模型？按优先级顺序传 models 数组。OpenRouter SDK 把 models 作为一等字段，如 models=["openai/gpt-5.4-mini"]；OpenAI SDK 经 extra_body 传递（模型回退文档）。把最可靠的模型排在最后，让最终回退是你的兜底。

原文信息

• 作者：OpenRouter
• 发布时间：2026-06-12
• 原文标题：OpenRouter Reliability & Automatic Failover: How Requests Keep Succeeding

原文地址：