大模型 API 故障转移策略：供应商异常时怎么办

大模型 API 故障转移是指在主用模型提供方返回错误、超时或在流式输出中途停止生成时，将生成式 AI 请求自动路由到备用提供方的一种机制。生产级的故障转移策略并不是“一直重试直到成功”那么简单；它需要区分哪些错误可以安全重试、哪些应该快速失败，并且要把流式早期的失败与已经向用户输出部分内容后的失败区别对待。

为什么故障转移比看起来更难

大多数 API 网关都是围绕 HTTP 请求/响应语义构建的。5xx 状态码通常意味着“换一家再试试”。但 LLM 负载带来了两个会打破这一假设的复杂情况。

首先，大量请求采用流式传输。HTTP 状态码可能是 200，但提供方仍可能在助手已经开始输出后发出错误数据块。一旦 token 已经到达客户端，简单粗暴的重试会重复部分答案、让用户困惑，并对已经消耗的 token 重复计费。

其次，相同症状可能由截然相反的原因造成。429 Too Many Requests 通常在几秒内就会缓解，而 401 Unauthorized 或 403 Forbidden 则会一直持续，直到轮换凭据。对后者进行重试既浪费预算，也浪费延迟预算。

正因如此，OWASP LLM 应用 Top 10 2025 将过度代理和未加限制的重试视为架构风险：自动化循环可能放大成本、将数据泄露给备用提供方，或违反数据驻留要求。

重试之前先分类错误

保证故障转移安全最可靠的方法是先对错误分类。依据提供方的 HTTP 状态码、流式中的位置以及错误体的结构来判断。

流式早期失败

这类失败发生在尚未生成任何有意义的 token 之前。网关尚未向调用方提交输出，因此重试或切换提供方通常是安全的。

常见例子：

• 首个 token 前的 408 Request Timeout
• 速率限制触发的 429 Too Many Requests
• 502 Bad Gateway、503 Service Unavailable、504 Gateway Timeout
• 完成响应头之前的 TLS 握手失败或连接重置

对于这类错误，先采用指数退避重试，然后切换到下一个已配置的模型。将总延迟控制在应用可接受的范围内；一个 30 秒的重试循环会让聊天界面失去响应。

流式中途失败

这类失败发生在至少一个内容数据块已经下发之后。用户可能已经看到了部分答案，因此网关无法透明地重试同一请求，否则会产生重复或矛盾的输出。

推荐处理方式：

1. 干净地停止向客户端的流式输出。
2. 在使用日志中记录该失败，并标注已消耗的 token 数量。
3. 将错误暴露给调用方或 UI，而不是静默切换模型。
4. 允许用户显式重新生成；此时 UI 可以将下一次请求路由到备用提供方。

有些团队通过将部分助手消息作为上下文回传，让备用模型接着续写来实现“从截断处继续”。这只有在两个模型共享相同的 tokenizer 行为，并且应用能够容忍语气或格式变化时才可行。它不是默认安全的行为。

通常不应重试的状态码

状态码	典型含义	是否重试？
400 Bad Request	请求体格式错误、参数无效或安全过滤触发	否——修复请求
401 Unauthorized	API 密钥无效或已过期	否——先轮换凭据
403 Forbidden	账户被停用、区域封禁或策略违规	否——调查账户状态
404 Not Found	模型或端点不存在	否——更新模型映射
422 Unprocessable Entity	请求体存在语义错误	否——修正请求负载
429 Too Many Requests	速率限制或配额耗尽	是，指数退避后故障转移
5xx	提供方端错误	是，有限重试后故障转移

这张表是起点，而非保证。提供方有时会对不同的失败模式复用相同的状态码，因此当错误体可用时应解析其中的细节。

如何识别暂时性的响应体错误

仅看状态码是不够的。OpenAI 风格的流可能在数据块中抛出 error 字段，其中包含 code 字段，例如 rate_limit_exceeded、server_error 或 content_filter。Anthropic 和 Gemini 则返回带 reason 字符串的结构化错误对象。这些代码应当比单纯的 HTTP 状态码更能驱动重试策略。

例如：

• rate_limit_exceeded → 指数退避重试，随后故障转移。
• server_error → 快速故障转移；提供方已承认存在内部问题。
• content_filter 或 content_policy_violation → 除非治理策略明确允许，否则不要换一家提供方重试，因为相同提示可能在别处触发相同过滤，进而带来合规风险。
• insufficient_quota 或 billing_hard_limit_reached → 立即故障转移；该账户已无法服务此请求。

当响应体错误出现在流式中途时，即使 HTTP 状态为 200，也应按中途失败处理。最安全的策略是停止流式输出、记录事件，并让用户决定是否重新生成。

重试预算与提供方轮换

重试策略需要上限。没有上限时，一家提供方的级联故障可能会耗尽你在下一家提供方的速率配额。请为每次请求或每个会话定义：

• 每个提供方的最大尝试次数：通常在切换前重试 1–2 次。
• 最大尝试提供方数量：通常包括主用方在内共 2–3 家。
• 退避上限：限制指数退避的时间，确保在用户放弃前完成故障转移。聊天界面常见的上限是 2–4 秒。
• 总超时：包括连接时间、首个 token 时间和 token 间延迟。

轮换提供方也意味着轮换成本结构。从 GPT-4o 故障转移到 Claude 3.5 Sonnet 或 Gemini 1.5 Pro，可能同时改变价格和质量。将模型价格可视化纳入治理的团队可以设置成本护栏，避免故障转移在不知不觉中让推理账单翻三倍。

日志记录与可观测性

每一次故障转移事件都应留下审计轨迹。至少记录：

• 原始提供方与备用提供方
• 状态码和错误体中的错误代码
• 失败发生在流式早期还是中途
• 已消耗的 token 数量（如有）
• 每次尝试的延迟和总延迟
• 用户或项目归属

这些数据存在于使用日志中，也是控制台告警的输入。当某家提供方开始返回更高的 5xx 比例时，运维团队应在用户提交工单前就察觉到。

日志还能在计费争议中保护你。当提供方对中途错误前已经下发的 token 收费时，你需要精确记录流在何时中断、涉及多少 token。

何时不应故障转移

有时让请求失败，而不是把它路由到别处，反而是合理选择。

数据驻留与合规。 如果提示包含个人数据或受特定司法管辖区约束，故障转移到不同区域的提供方可能违反策略。应通过受限的渠道列表路由这类提示。

成本控制。 发送到高端模型的高复杂度提示可能没有成本对等的备用模型。故障转移到更便宜的模型可能输出质量更差，而且如果上下文窗口很大，费用仍可能超出预期。

内容安全。 被 A 提供方安全过滤器拒绝的提示，不应自动在 B 提供方重试以绕过过滤。这种模式可能带来法律责任，并违反大多数可接受使用政策。

确定性工作负载。 代码生成、法律文件起草或医疗辅助工作流可能需要特定模型版本。故障转移会改变输出分布，并可能使下游验证失效。

运营模式：一份简单的运行手册

设计或审查 大模型 API 故障转移策略时，请使用以下检查清单：

• 将每个支持的模型映射到一至多个上下文窗口和输出格式兼容的备用模型。
• 为每个提供方配置重试次数、退避策略和总超时。
• 在代码和日志中区分流式早期重试与流式中途失败。
• 解析提供方特定的错误代码，并在必要时覆盖基于 HTTP 状态的规则。
• 为每个项目或 API 密钥设置成本和速率限制预算。
• 对敏感数据所在司法管辖区限制故障转移路由。
• 通过运维控制台对故障转移率飙升设置告警。
• 文档化哪些错误触发自动重试、哪些触发故障转移、哪些需要人工审查。

综合运用

设计良好的故障转移策略将网关视为控制平面，而不仅仅是代理。它能区分瞬时抖动与硬故障，尊重用户看到一致输出的权利，并保持成本可预测。通过结合状态码规则、错误体解析、重试预算和清晰的日志记录，团队可以在不将提供方故障变成失控账单的前提下，保持 AI 功能可用。

如果你正在将多家提供方整合到统一接口背后，更宏观的上下文同样重要。故障转移只是弹性 AI 访问层的一部分，其他还包括一个 API 对接多种 AI 模型、AI 团队 API 密钥治理以及模型价格可视化。这些能力相互 reinforcement：治理定义了谁可以路由到哪里，价格可视化防止意外成本，故障转移则在单一提供方出问题时让系统继续运行。

上次核对：2026-06-22

AveMujica API 能帮你解决什么

当这个能力进入真实流量后，问题会从“能不能调用模型”变成“谁能使用、花了多少钱、失败时怎么处理”。AveMujica API 把模型访问、价格上下文、钱包变化和使用历史放在同一个控制台里，让产品、工程和财务用同一组数据判断是否继续扩大。

• 先选一个真实工作流试运行，不要一开始就迁移所有客户端。
• 在控制台同时查看模型访问、钱包变化和使用日志，减少跨供应商后台手工对账。
• 当成本、延迟和归属都清楚后，再扩大到更多分组或更高流量。

多一层网关不应该增加负担。它应该把原本分散在密钥、账单、供应商后台和事故记录里的工作集中起来，让团队更快发现问题、更快调整策略。

参考资料

这些一手资料用于核对供应商行为、价格和风险框架，帮助读者追溯文章里的关键判断。

• IETF HTTP Semantics RFC 9110
• OpenTelemetry documentation
• Amazon Bedrock model invocation logging

常见问题

团队做 大模型 API 故障转移策略：供应商异常时怎么办 时应先决定什么？

先决定责任归属和策略边界：哪个分组或密钥负责这条工作流，允许哪些模型，哪一个信号证明策略有效。

上线后应该看哪个指标？

看最接近用户影响的指标：单次成功任务成本、故障转移率、p95 延迟、被拦截请求或额度变化，并把指标关联到使用日志，而不是只看供应商后台。

多久复核一次？

供应商价格、模型能力和风险规则变化很快。涉及价格或能力的事实建议每月复核；发生事故、上线新功能或价格变动后应立即复核策略。

选型时看什么

维度	要确认的问题	在哪里查看
归属	谁负责这条工作流？	使用日志 和范围化 API key
成本	哪个计价单位最容易增长？	价格、模型目录 和 钱包
可靠性	哪类失败最影响体验？	控制台概览 和渠道历史
治理	下次应复核什么？	分组、额度、key 范围和使用历史

从一个工作流开始

先选一个真实工作流，在 AveMujica API 中确认模型访问、价格上下文、使用日志和预算归属彼此一致，再逐步扩大流量。