Reliability and Routing2026年6月22日Big Y

AI API 重试策略：何时重试、切换模型、排队或安全失败

使用 AI API 重试策略来判断何时重试、切换模型、排队处理或安全失败，同时不掩盖配额、身份验证或路由故障。

AI API 重试策略是一个策略，用于决定当模型请求失败、变慢或返回部分结果后，应用程序应该怎么做。错误的策略代价很高：对每个错误都重试会成倍增加配额压力；过早切换模型会改变答案质量；把交互式工作放入队列会让用户等待；在安全或认证失败时“fail open”会掩盖真实事故。

本指南为使用 AI 网关、多供应商路由器或 OpenAI 兼容 base URL 的生产团队提供一套实用的决策阶梯。它涵盖何时重试同一供应商、何时切换模型、何时排队处理，以及何时“fail closed”。AI API 重试策略的目标不是不惜一切代价让每个请求都成功；其目标是在不掩盖错误请求、认证问题、配额耗尽、不安全回退或路由事故的前提下，从临时性故障中恢复。

Flatkey 之所以适合这个问题，是因为其公开产品文案围绕一个 API key、一个 OpenAI 兼容的 base URL https://router.flatkey.ai/v1、清晰的定价、统一计费，以及用于密钥、用量和路由的单一仪表板展开。Flatkey 也描述了自动切换和负载均衡。这些功能仍然需要明确的重试策略，这样团队才能解释为什么一次请求会重试、切换模型、排队或 fail closed。

快速回答：AI API 重试策略阶梯

将这个决策阶梯作为你的 AI API 重试策略 的核心资产。它让重试行为与故障责任方、用户工作流和影响范围挂钩，而不是采用一个笼统的“再试一次”规则。

故障信号	默认动作	何时升级	停止条件
请求在服务商接收前发生网络超时	如果操作是幂等的，或使用了客户端请求 ID，则带抖动退避重试一次。	当重试预算用尽且备用目标已获批准用于相同工作流时，切换路由。	在路由预算耗尽后停止；返回受控的稍后重试响应。
带有重试指引的 HTTP 429 速率限制	遵守返回的等待信号，降低调用速度，并减少并发。	将后台工作排队，或切换到具有独立配额的已批准路由。	如果配额已耗尽、预算已封顶，或不再存在允许的路由，则关闭式失败。
HTTP 500、502、503、504，或服务商过载	使用指数退避和抖动进行少量重试。	仅在确认备用方案满足质量和策略规则后，才切换模型或服务商。	当请求将超过延迟、token、成本或尝试次数限制时停止。
400 无效请求、模式错误、不支持的参数或上下文溢出	不要在请求不变时重试。修正请求、缩减上下文，或返回可由用户修正的错误。	仅当产品接受这种行为和成本变化时，才路由到具有更大上下文的模型。	对重复出现的请求结构错误关闭式失败。
401、403、密钥已禁用、IP 未授权，或权限失败	关闭式失败并告警密钥所有者。	通过运维工作流轮换密钥或修复账户访问。	除非你的安全策略明确允许，否则绝不要静默回退到另一个账户。
安全阻断、策略阻断、工具授权失败，或数据边界问题	以安全消息关闭式失败，并记录策略原因。	如果该阻断看起来不正确或会影响客户，则升级审查。	不要只为了得到答案而在限制更少的模型上重试。
流式输出开始后卡住或断开	仅当操作可以安全重放且用户体验支持全新响应时才重试。	当日志显示重复的流级失败后，为后续请求切换路由。	除非 UI 专门为此设计，否则不要将第二个模型答案追加到部分已交付的答案后。

为什么盲目的重试循环会破坏 AI 产品

大多数 Web 服务都可以对短暂性故障使用标准的重试模式。AI API 则需要更谨慎，因为请求可能成本高、具有状态、支持流式传输、会使用工具，而且对模型敏感。盲目的 LLM API 重试 循环会引发四种自身故障：

配额放大： 过于激进地重试 429 可能会消耗本就受限的请求或令牌容量。
质量漂移： 备用模型可能给出不同答案、忽略工具模式，或改变输出格式。
成本意外： 成功的回退路径可能比主路径更昂贵，尤其是在长上下文、推理、图像或视频任务中。
事故遮蔽： 最终成功可能掩盖五次失败尝试，除非日志保留了重试链路。

因此，一个好的 AI API 重试策略 本质上是一种路由策略、可观测性策略和产品策略。它应明确允许哪些恢复方式、必须记录哪些证据，以及当恢复失败时，用户体验应当接受到什么程度。

在重试之前先对失败进行分类

每个 AI API 重试策略都应从一个标准化的失败分类法开始。不同提供商的文档各不相同，但这些运行时类别足够稳定，可以转化为策略：

类别	示例	负责人	重试策略
调用方缺陷	JSON 格式错误、无效参数、不受支持的工具模式、上下文过长。	应用程序或提示词流水线。	不要在不变更的情况下重试。
身份验证或权限	无效密钥、已禁用密钥、项目成员资格、IP 白名单、账号权限。	凭据负责人或安全负责人。	关闭失败并告警。
速率限制	每分钟请求数、每分钟 token 数、加速限制、并发限制。	流量负责人和配额负责人。	退避、排队、降低并发，或切换到已批准的配额池。
配额或预算耗尽	积分耗尽、月度支出上限、团队配额、客户配额、预付余额限制。	财务、计划负责人或客户负责人。	关闭失败或在审批后排队；不要在不知情的情况下透支其他预算。
临时性提供方故障	内部服务器错误、服务过载、临时网关错误、超时。	提供方或网络路径。	用较小的预算重试，然后在已批准的情况下路由到备用方案。
策略或安全拦截	审核拦截、受限输出、数据边界、工具授权失败。	安全、安保或产品策略。	关闭失败，除非存在人工批准的补救路径。

OpenAI 的错误代码指南将 429 速率限制与配额耗尽区分开来，将 500 和 503 情况记载为等待后重试的场景，并将身份验证问题视为密钥或组织层面的修复，而不是重试候选。Anthropic 的错误文档也类似地区分了无效请求、身份验证、权限、速率限制、API 错误和过载类别。正是这些区分说明了仅看状态码是不够的；你的网关应在日志中保留提供方错误类型和安全错误代码。

何时重试同一模型

当故障看起来是暂时性的、请求可以安全重放，并且重试不会让事故更严重时，再重试同一模型。这是 AI API 重试策略 中最狭窄但最有用的一部分。

适合同路径重试的场景包括：

在提供方接受请求之前发生的连接超时。
临时性的 500、502、503 或 504 响应。
带有较短等待窗口且剩余用户延迟预算足够的限流响应。
在向用户可见的任何 token 交付之前发生的流式设置失败。

请使用带抖动的指数退避，而不是同步睡眠。Google Cloud 的重试指南将带抖动的截断指数退避描述为标准的重试模式，因为它可以避免惊群式重试。对于 AI API，还应按工作流设置一个较小的重试预算。交互式聊天请求可能只给一到两次尝试。夜间摘要批处理可以等待更久，并更谨慎地重试。支付、安全或客户操作类工作流则应更加严格。

每次同路径重试都应记录尝试索引、路由、可用时的提供方请求 ID、状态码、错误类别、等待时间以及最终结果。将其与 AI API 可观测性日志清单配合使用，这样最终成功也不会掩盖之前的失败尝试。

何时切换模型或提供商

模型回退重试不只是另一种重试。它会改变模型、提供商、账户、成本项、行为，有时还会改变合规边界。只有当回退已针对该特定工作流预先批准时，才进行切换。

当以下所有条件都成立时，切换模型或提供商：

主路由已用尽其短重试预算，或返回了提供商侧故障。
回退模型已获批准用于相同的数据类别、客户层级、端点家族、工具行为和输出格式。
产品负责人接受质量差异和用户体验。
财务负责人接受成本和配额差异。
日志同时记录请求的路由和选定的路由。

如果请求格式错误、未经授权、被安全策略阻止，或依赖回退不支持的提供商特定功能，则不要切换。Vercel 的 AI Gateway 模型回退文档将按顺序排列的回退模型描述为一种从故障或不可用状态中恢复的方法。可以将其视为一种有用的公开路由模式，但在生产中使用回退之前，仍应先定义自己的验收测试。

对于 Flatkey 买家来说，运维问题非常具体：如果某条上游路由出错，允许哪些回退路由，允许多少次尝试，以及工程团队之后在哪里查看路由链？AI API 负载均衡与故障转移这篇操作指南是设计该路由梯子的配套内容。

何时排队而不是同步重试

当用户不需要立即响应、提供商容量暂时受限，或请求量更适合批处理工作流时，就应将工作排入队列。队列并不是失败；它是一种避免 AI API 重试策略 与同步限制发生冲突的方式。

OpenAI 的速率限制指南区分了同步请求限制和批处理工作，并指出非即时使用场景可以采用批处理式执行，而不会影响同步请求速率限制。同样的产品原则也适用于单一提供商之外：将非紧急工作从交互流量中移开。

适合进入队列的情况包括：

批量丰富、摘要、嵌入、审核复核或报告生成。
面向客户的作业，且已经有异步状态页或 webhook。
新旧数据回填和迁移，其中新鲜度以分钟或小时计。
重试后等待窗口超过用户的交互延迟预算，但适合放入作业队列。

队列记录应保留原始请求所有者、API 密钥、路由策略、重试次数、请求的模型、入队时间、下次尝试时间以及预算所有者。否则，排队重试就会变成隐性成本。

何时采用关闭式失败

当继续执行会带来安全、合规、数据、预算或产品风险的不确定性时，应采用关闭式失败。这是 AI API 重试策略 的一部分，可防止可靠性工程变成无声的策略绕过。

以下情况应采用关闭式失败：

无效或已禁用的 API 密钥、项目权限失败、IP 允许列表失败，以及意外的账户所有权问题。
安全拦截、审核拦截、工具权限失败，以及数据边界错误。
配额或预算耗尽，且没有预算负责人批准超额使用。
如果保持不变就会重复的格式错误请求。
尚未通过质量、成本、隐私和合规检查的回退路径。
已经传递了部分内容且无法干净重放的流式响应。

关闭式失败并不意味着返回敌对式错误。它意味着系统返回受控消息，记录停止原因，在需要时提醒负责人，并避免隐藏的路由变更。这对于面向客户的 AI 功能尤为重要，因为静默回退可能会产生实质不同的答案。

面向生产团队的重试策略模板

使用此模板将阶梯转换为一条策略记录。它刻意保持通用，应根据你的网关、应用程序和合规规则进行调整。

{
  "policy_id": "chat-prod-retry-v3",
  "workflow": "customer-chat",
  "environment": "production",
  "idempotency": {
    "requires_client_request_id": true,
    "allow_replay_after_stream_started": false
  },
  "same_route_retry": {
    "retryable_status_codes": [408, 429, 500, 502, 503, 504],
    "max_attempts": 2,
    "backoff": "exponential_with_jitter",
    "max_elapsed_ms": 9000
  },
  "fallback": {
    "enabled": true,
    "allowed_reasons": ["primary_timeout", "provider_overload", "temporary_5xx"],
    "blocked_reasons": ["auth_error", "invalid_request", "safety_block", "budget_exhausted"],
    "allowed_models": ["approved-backup-chat-model"],
    "requires_quality_eval": true,
    "requires_cost_owner": true
  },
  "queue": {
    "enabled_for": ["bulk_summary", "nightly_enrichment"],
    "not_enabled_for": ["live_customer_chat"]
  },
  "fail_closed": {
    "auth_errors": true,
    "policy_errors": true,
    "unapproved_fallback": true,
    "quota_without_budget_owner": true
  },
  "logging": {
    "record_attempt_chain": true,
    "record_retry_after": true,
    "record_requested_and_selected_route": true,
    "content_logging_mode": "metadata_only"
  }
}

这不是 Flatkey API 合同。这是供工程、产品、财务和安全团队使用的审查模板。最重要的字段不是确切的 JSON 名称；而是每条恢复路径的明确停止条件。