OpenAI 如何为模型供应商设计故障转移

当业务依赖 AI 工作流时，即使供应商只是短暂中断，也可能延误决策或中断服务。我们一直在与金融服务客户合作，帮助他们使用 OpenAI 模型构建智能体应用和网络安全工作流。本文以支付工作流中的只读欺诈评估为例，说明我们如何为关键工作负载设计生产路由与恢复方案。

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

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

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

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

对于关键工作负载，我们还会考虑在 1P 与 3P 之间进行经过验证的故障转移。供应商故障转移是指当主供应商无法处理请求时，通过另一个已获批准的供应商重试该请求。只有当请求可以安全重复，且替代方案满足工作流要求时，这种做法才有帮助。

一家全球支付服务商可能会使用 Responses API 进行独立的只读欺诈评估。如果该调用在结果被使用前超时，应用可以在交易截止时间之前，通过经过验证的备用路由重试。

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

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

计划内路由与故障转移

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

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

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

路由器所处的位置

示例：OpenAI API 为主路由，已获批准的第三方供应商为备用路由。对于该工作负载，任意一条路由都可以作为主路由。AI 应用 工作流负责人 平台运营的路由器 工作流定义的策略 已批准且就绪的路由 容量与预算 完成时间与安全重试 OpenAI API（1P） 主路由：正常流量 已获批准的第三方供应商（3P） 已批准的备用路由 仅限符合条件的恢复 无可用路由 排队、降级、移交或拒绝 应用管理的恢复上下文与操作核对 已批准的检查点与重复操作防护

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

如果现有的模型路由器或 LLM 网关能够为每条路由执行单独的规则，就可以继续使用。将正常流量发送到主路由。只有在满足故障转移条件时，才使用经过测试的备用路由。

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

私有连接与路由选择

许多受监管行业的客户要求将私有连接作为其安全控制的一部分。对于这些客户而言，选择路由还意味着要检查其应用所在的云如何与各供应商建立私有连接。图中展示了客户私有网络中的应用和网关，以及通往各供应商的独立私有路径。

示例：OpenAI API 为主路由；已获批准的供应商为备用路由。连接性按路由分别验证。客户私有网络（VPC / VNet）AI 应用 LLM 网关 策略 + 重试 主路由：正常流量 私有连接 如有需要可跨云 OpenAI 运营的 OpenAI API（1P）API 服务与模型推理 备用路由：仅限恢复 供应商特定的私有连接 如有需要可跨云 独立供应商 已获批准的供应商（3P）选定模型 + API 仅限符合条件的恢复

公共 HTTPS 是另一个独立选项。本示例中不会自动切换。

实线：主路由流量。虚线：仅限符合条件的恢复。请分别验证每条私有路径。

图 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 状态码。

条件 路由决策

临时性服务或连接故障 对于可重试的供应商错误、连接重置或超时，考虑故障转移。

持续限流或响应缓慢 如果等待会违反请求或工作流截止时间，考虑故障转移。请区分临时性限流与需要修复的配额或计费问题。

无效请求、访问失败、拒绝或额度耗尽 对于格式错误的请求、401/403 错误、安全拒绝、配额耗尽、额度或支出上限，不要自动切换路由。请纠正或上报原因。未分类的错误不应触发故障转移。

部分输出或工具操作结果不确定 不要盲目重放，也不要假设部分响应可以在另一条路由上继续。在重启之前，请核对操作结果并防止重复写入。

特定模型不可用或容量受限 尝试另一个满足质量、功能和延迟要求的已获批准模型。如果供应商的共享服务路径受到影响，请考虑在上述前提条件下进行供应商故障转移。

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

限制故障转移流量，避免备用路由过载。在代表性请求于规定时段内持续满足错误率和响应时间限制后，逐步恢复主路由。若超出这些限制，则暂停增加流量。如果两条路由都受到限制，则遵循工作流约定的恢复策略。

使用 Codex 实现故障转移策略

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

在 Codex 中打开负责网关配置或应用路由的仓库，然后根据你的工作流和目标路由调整下面的提示词。

为 [仓库/网关] 中的 [工作流自包含、只读的推理步骤] 添加默认禁用的供应商故障转移。保留主路由，并复用现有网关、已获批准的平台路由和工作流策略。

检查网关、SDK 和适配器版本、部署配置、API 以及当前官方文档。按负责人和所需评审将应用更改与网关更改分开。为其他团队负责的依赖项提供配置和集成测试。标记不受支持的控件。不要猜测审批或限制；在验证完成之前，保持相关故障转移路径处于禁用状态。

使用经过测试的供应商特定错误映射。仅当重放安全，且已获批准、已启用、状态健康的备用路由具备所需功能、数据控制、经过测试的容量、剩余预算和完成时间时，才允许临时性服务/网络故障和已确认的临时限流。阻止无效请求、访问失败、拒绝、配额/额度/预算耗尽、未知错误和含义不明的 429。

在客户端、网关和 SDK 之间使用同一个重试控制器。禁用相互冲突的重试/故障转移链；强制执行单一的总尝试次数上限，以及请求截止时间和工作流截止时间。在总体截止时间内使用配置的每次尝试超时。每个逻辑请求只接受一个结果，忽略较早尝试的迟到响应。遵循有效的 Retry-After；否则使用带抖动的有界指数退避。切勿盲目重放部分输出或结果不确定的操作，也不要假设供应商状态可以转移。应用已获批准的排队、缩减结果或停止策略。包含手动禁用、熔断和逐步故障恢复。

在本地 HTTP 桩且外部网络被阻断的情况下测试实际请求路径。针对成功、符合条件的失败、每一类被阻止的错误、资格判定失败、部分输出、结果不确定的操作、预算耗尽、两条路由均失败以及恢复控制，断言路由顺序、调用次数和耗时。被阻止的情况不得发起任何备用路由调用。将合成限制保留在测试夹具中，并保护密钥。未经授权不得进行实际调用或部署。

返回最小补丁、映射到需求的测试、结果、回滚说明以及尚未完成的实机检查。将所有未经验证的故障转移路径保持禁用。

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

验证路由与恢复

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

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

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

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

要判断备用路由能否应对，请将其现有工作负载与预期的欺诈评估流量及重试一起进行负载测试。利用这些结果设定故障转移流量上限，并决定哪些请求可以等待、哪些可以使用缩减功能、哪些应当停止。仅靠配额并不能保证在截止时间前完成。

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

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

从服务恢复的速度、截止时间前完成的评估数量、结果质量、成本和重复操作等方面评估恢复情况。定期演练可使这些检查保持最新，以应对凭据过期、配置变更或容量变化。

谁负责恢复

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

在这种模式下，应用程序所有者定义哪些操作可以故障转移、服务和质量目标以及可接受的缩减功能。他们还负责业务成果、保存的恢复上下文、工具权限、响应检查以及防止重复操作，包括在状态或工具共享时。

你的团队可以合并这些角色或以不同方式划分。在启用故障转移之前，就要商定由谁批准控制措施、负责路由测试和运行手册，以及在事件期间拥有行动权限。

结论

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

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