设计跨 OpenAI 模型提供商的故障转移

当业务依赖 AI 工作流时，即使供应商短暂中断，也可能导致决策延迟或服务中断。我们一直在与金融服务客户合作，使用 OpenAI 模型构建智能体应用和网络安全工作流。本文介绍了我们如何处理关键工作负载的生产路由和恢复，并以支付工作流中的只读欺诈评估作为贯穿示例。

在这里，第一方 (1P) 指直接的 OpenAI API；第三方 (3P) 指通过云提供商访问的 OpenAI 模型，无论应用运行在何处。我们将介绍直接访问预览模型和功能的价值、工作负载需求和私有连接如何影响路由选择，以及哪些操作可以安全地进行故障转移。随后，我们将提供一个 Codex 提示词，用于在现有网关中实施该策略，并说明在启用故障转移之前需要验证哪些内容。

为什么同时使用两种路由？

即使生产环境通过云提供商运行，直接访问 OpenAI 也很有价值。一个核心原因是能够访问预览模型和功能：当这些能力通过直接 API 提供时，符合条件的团队可以在其选定的云提供商支持之前，先针对自己的工作流对其进行评估。

工作流的运行位置通常决定了生产路由。第三方云服务可能更契合应用现有的基础设施和运营控制，而直接访问 OpenAI 可能更适合另一个工作流的需求。请在选定的路由上验证所需的模型、功能和行为，并使用直接访问 OpenAI 进行持续试验。可用内容取决于提供商、端点、区域和您的账户。

对于关键工作负载，我们还会考虑 1P 和 3P 之间经过验证的故障转移。供应商故障转移是指当主要供应商无法服务请求时，通过另一个已获批准的供应商重试该请求。只有当请求可以安全地重复执行，且备选方案满足工作流需求时，它才有效。

全球支付提供商可能会使用 Responses API 进行自包含的只读欺诈评估。如果调用在结果被使用之前超时，应用可以在交易期限内通过经过验证的备用路由重试。

持续的 Agents API 会话需要不同的恢复方法。切换供应商本身并不能恢复其对话和已保存的工作，也无法协调先前的操作。这种恢复要困难得多，且不在本文的讨论范围内。

正是这种区别，使得我们将多供应商支持视为平台能力，而将故障转移视为工作流决策。

规划路由与故障转移

选择生产路由和批准故障转移是两个独立的决策。规划路由可能包括在供应商之间分配流量，或将超额需求发送到另一条路由。这些模式需要各自的容量、成本、质量和恢复测试。

我们看到一些客户使用 Decisions API 作为路由的可选输入。为了保持工作流的弹性，请定义当该服务不可用时路由的行为方式。

图中以 1P 为主路由，以已获批准的 3P 路由为备用。根据工作负载的不同，两者都可以作为主路由。

路由器的位置

图 1. OpenAI API 为主；已获批准的第三方为备用。平台运行路由器；应用定义策略。模型、功能、容量、控制和可用性可能存在差异。

如果现有的模型路由器或 LLM 网关能够为每条路由分别执行规则，你可以直接使用它。将正常流量发送到主路由。仅在满足故障切换条件时才使用经过测试的备用路由。

定义谁可以使用每条路由、在哪些区域使用，以及使用哪些模型和 API。记录已批准的法律实体、团队、提供商账户或项目以及数据处理规则。批准仅适用于商定的工作负载和区域。

私有连接与路由选择

受监管行业的许多客户将私有连接作为其安全控制的一部分。对于这些客户，选择路由还意味着要检查其应用所在的云如何与每个提供商建立私有连接。该图显示了位于客户私有网络中的应用和网关，它们分别通过独立的私有路径连接到每个提供商。

图 2. OpenAI API (1P) 为主路由；已批准的提供商 (3P) 为备用路由，例如 Amazon Bedrock 或 Azure OpenAI。只有符合条件的恢复流量才使用备用路由。

在发布时，1P 和 3P 的私有连接选项有所不同。对于直接 OpenAI 访问 (1P)，OpenAI Private Link 使用 Azure 专用终结点。AWS 和 Google Cloud 中的工作负载需要客户管理的连接接入 Azure，才能使用这条通往直接 OpenAI API 的私有路径。

对于第三方访问 (3P)，Amazon Bedrock 通过 AWS PrivateLink 使用特定于 API 的接口 VPC 终结点，而 Azure OpenAI 使用 Azure 专用终结点。在启用故障切换之前，请验证两条路由上的 DNS、访问权限以及区域模型和 API 支持情况。OpenAI Private Link 不会自动在区域终结点之间切换，因此区域恢复需要单独的配置和测试。任何恢复到公共 HTTPS 的操作也需要明确批准。

提供商支持情况可能会发生变化。在选择或启用路由之前，请查阅官方文档。

哪些操作可以故障切换？

并非每个操作都有合适的备用路由。例如：

• 能力缺失：某个工作流可能会通过直接 OpenAI API 使用网络搜索来查询最新信息。如果备用路由不支持该功能，请不要静默跳过搜索。请验证替代实现，或为该操作禁用故障切换。
• 行为未经验证：模型名称匹配或 API 兼容是不够的。在启用备用路由之前，请使用该工作流现有的测试框架和评估针对备用路由运行测试。
• 驻留或状态约束：不要切换到违反已批准的数据位置要求，或无法访问安全完成操作所需状态的目标。

当没有备用路由符合条件时，可在商定的截止时间内排队处理任务、使用已批准的降级功能或人工路径，或安全停止。即使完整工作流不符合条件，可重试的推理步骤也可能符合条件。

一个只读的欺诈评估如果超时，只要其结果尚未被使用且仍有足够时间，就可能符合再次尝试的条件。一旦输出到达其他系统，恢复就需要一条经过测试的重启路径。如果某个操作可能已经完成，请先确认其结果并防止重复操作，然后再重启。

何时以及如何故障切换

在支付示例中，繁忙或不可用的模型可以被另一个已批准的模型替换：这就是模型回退。通过另一个提供商重试评估则是提供商故障切换。有时两者都会改变。

我们首先考虑是否更换供应商会有帮助。共享网关、检索服务或身份系统可能同时影响两条路由。测试备用路由的连接性、访问权限和容量，并检查针对你的模型、托管工具和数据位置要求的区域恢复支持。

如果故障或响应缓慢持续存在，熔断器可以暂停向受影响路由发送新请求。按供应商、模型、区域和工作流设置错误和响应时间限制。每个请求仍需符合故障转移条件。

在重试请求之前，检查其是否可以安全重复执行，以及能否在工作流的截止时间内完成。备用路由必须经过批准、启用、健康，并针对额外负载进行了测试，且预算尚有余额。请参阅 OpenAI 的 错误代码 和 速率限制文档；同时也要查看其他供应商的错误、重试、配额和计费规则。

下表为自动故障转移提供了一个保守的起点。请使用每个供应商的错误详情，而不仅仅是 HTTP 状态码。

应由一个层来统一控制应用、SDK 和网关中的重试，以避免重试次数倍增。使用共享的重试预算，并遵循有效的 Retry-After 指引。否则，使用带抖动的有界指数退避：延长尝试之间的等待时间，加入随机性，并限制尝试次数。仅重试安全的推理调用，且必须同时满足请求和工作流的截止时间。

限制故障转移流量，以免备用路由不堪重负。当具有代表性的请求在一段规定时间内满足错误和响应时间限制后，逐步恢复主路由。如果超过这些限制，则暂停恢复。如果两条路由都受限，请遵循工作流中约定的恢复策略。

使用 Codex 实现故障转移策略

我们现在可以使用 Codex 将这些恢复规则转化为对现有 LLM 网关的更改。以支付示例为例，我们将工作范围限定在独立的、只读的欺诈评估步骤。主路由保持不变，在备用路由获得批准和验证之前，故障转移保持禁用状态。

在 Codex 中打开拥有网关配置或应用路由的仓库，然后根据你的工作流程和预期路由调整下面的提示词。

Add disabled-by-default provider failover for [workflow’s self-contained, read-only inference step] in [repository/gateway]. Preserve the primary route and reuse the existing gateway, approved platform routes, and workflow policy.

Inspect gateway, SDK, and adapter versions, deployment configuration, APIs, and current official documentation. Separate app and gateway changes by owner and required review. Provide configuration and integration tests for dependencies owned elsewhere. Flag unsupported controls. Do not guess approvals or limits; keep dependent failover paths disabled until verified.

Use tested provider-specific error mappings. Allow transient service/network failures and confirmed temporary throttling only when replay is safe and the approved, enabled, healthy secondary has required features, data controls, tested capacity, remaining budget, and time to finish. Block invalid requests, access failures, refusals, exhausted quota/credits/budget, unknown errors, and ambiguous 429s.

Use one retry controller across client, gateway, and SDK. Disable conflicting retry/failover chains; enforce one total attempt limit and both request and workflow deadlines. Use configured per-attempt timeouts within the overall deadline. Accept only one result per logical request and ignore late responses from earlier attempts. Respect valid Retry-After; otherwise use bounded exponential backoff with jitter. Never blindly replay partial output or uncertain actions, or assume provider state transfers. Apply the approved queue, reduced-result, or stop policy. Include manual disable, circuit breaking, and gradual failback.

Test the actual request path with local HTTP stubs and external networking blocked. Assert route order, call counts, and elapsed time for success, eligible failures, each blocked error class, failed eligibility, partial output, uncertain actions, exhausted budgets, both routes failing, and recovery controls. Blocked cases must make no secondary call. Keep synthetic limits in test fixtures and protect secrets. Make no live calls or deployments without authorization.

Return minimal patches, tests mapped to requirements, results, rollback instructions, and outstanding live checks. Leave all unverified failover paths disabled.

该提示词要求 Codex 进行一次有针对性的网关变更，提供测试以表明何时应该调用备用模型、何时不应该调用，并列出在真实路由上仍需进行的检查项。请先审查补丁和本地测试结果。然后在启用故障转移之前，验证模型行为、数据控制、容量以及负载下的恢复能力。

验证路由与恢复

支付示例说明了同样适用于其他关键工作负载的检查项。请针对 工作流程的验收标准 测试两条路由的质量、安全性、输出格式、工具使用和上下文限制。记录已测试的配置、可用性和访问要求——包括处理层级和托管功能——并定义何时重新测试。

评估中的数据限制（包括提示词和输出日志记录限制）在正常运行和恢复期间均适用。在启用任一路由之前，请与法务、隐私、安全和数据治理负责人一起审查凭据、网络路径、检索、工具、存储状态和日志。

该审查需要服务文档和合同来确认数据的处理和存储位置、保留时长、加密方式，以及谁控制密钥和访问权限。仅凭端点的位置或私有连接是不够的。控制措施、资格和责任因端点而异——参见 OpenAI 的数据控制。

合适的路由仍需为恢复流量留出空间。提供商级别的仪表盘可能会掩盖欺诈评估模型上的限流情况，因此请跟踪每条路由的模型、账户或项目以及区域的请求速率和令牌速率、并发请求数、限流情况、响应时间以及剩余的已批准预算。

为了了解备用模型能否应对，请对其现有工作负载与预期的欺诈评估流量及重试进行负载测试。利用这些结果设定故障转移流量限制，并决定哪些请求可以等待、使用降级功能或直接停止。仅有配额并不能保证在截止时间前完成。

迁移评估任务还可能改变其成本和响应时间。请比较每次成功评估的成本，包括缓存未命中、数据传输费用和连接成本。同时测量缓存未命中或请求跨云产生的额外延迟。

最后，在负载下测试表中的故障场景，以及功能缺失和备用模型繁忙或不可用的情况。检查恢复策略是否按预期工作，包括流量限制、手动停止以及逐步返回主路由。

通过服务恢复速度、在截止时间前完成的评估数量、结果质量、成本和重复操作来评估恢复能力。定期演练可确保在凭据过期、配置变更或容量变化时，这些检查项保持最新。

谁负责恢复

一种实用的模式是将路由服务的所有权与应用的所有权分开。平台团队可以运行提供商集成、路由器、监控和审计日志。它将负责路由服务的生产就绪状态，并执行目标、身份、数据、流量和支出控制，同时指定待命负责人以禁用路由并管理返回主路由的过程。

在此模型中，应用所有者定义哪些操作可以故障转移、服务与质量目标，以及可接受的降级功能。他们还负责业务成果、保存的恢复上下文、工具权限、响应检查，以及防止重复操作的保护措施，包括在状态或工具共享的情况下。

您的团队可能会合并这些角色或以不同方式划分。在启用故障转移之前，请就谁批准控制措施、谁负责路由测试和运行手册，以及谁有权在事件期间采取行动达成一致。

结论

即使生产环境通过云提供商运行，也应将直接 OpenAI 访问视为工具箱的一部分。它为符合条件的团队提供了一种评估预览模型和功能的方式，也是关键工作负载的潜在恢复路径。根据工作流的能力、托管环境和控制措施（包括需要时的私有连接）选择 1P 或 3P 用于生产。

对于关键工作负载，从一个自包含的只读推理步骤开始。Codex 可以帮助实施其网关策略和本地测试，而在实际路由上进行验证则可确定辅助路由是否满足工作流的要求。这为团队提供了一个具体的恢复计划：何时切换、何时停止，以及谁负责决策。