AI API 429/529/503错误重试规则：OpenAI、Claude、Gemini与Bedrock实践

调用AI API时，429、529和503错误频繁出现，但错误响应背后的含义和重试策略却因提供商而异。盲目重试可能加剧配额消耗或触发更严格的限流。本文基于官方文档，梳理OpenAI、Claude、Gemini和Bedrock的差异化重试规则，并介绍如何通过类型化包装器（typed wrapper）自动跳过配额错误，提升应用稳定性。

错误类型与重试原则

429（Too Many Requests）表示超出速率限制或配额，通常需要等待；529（Service Unavailable）是Anthropic特有的过载错误，表明服务暂时不可用；503（Service Unavailable）常见于服务端临时故障。重试的核心原则是：区分可重试错误（如503、529）与不可重试错误（如配额耗尽型429），并遵循响应头中的Retry-After字段。

指数退避与抖动：指数退避是指每次重试的等待时间按指数增长（如1秒、2秒、4秒、8秒），避免在服务端故障时持续高频请求。为避免大量客户端在同一时刻重试造成“惊群效应”，通常会在退避时间上加入随机抖动（jitter），例如在计算出的等待时间上乘以0.5到1.5之间的随机因子。AWS的“Full Jitter”策略建议等待时间取random(0, min(cap, base * 2^attempt))。对于AI API，建议设置最大重试次数（如3-5次）和最大等待上限（如30秒），防止无限重试耗尽资源。

幂等性与重试安全：重试前需确认请求是否幂等。对于文本生成类API，重复调用可能产生额外费用或重复内容，因此重试应结合业务幂等键（idempotency key）或去重逻辑。OpenAI等提供商支持通过Idempotency-Key请求头保证同一请求多次提交只执行一次，但并非所有API都支持，需查阅对应文档。

各提供商重试规则详解

OpenAI：区分速率限制与配额耗尽

OpenAI的429错误可能由速率限制（rate limit）或配额耗尽（quota exceeded）引起。速率限制通常通过Retry-After头指示等待时间，可重试；而配额耗尽错误（如insufficient_quota）不应重试，需检查账户余额或升级计划。建议使用指数退避（exponential backoff）并设置最大重试次数。

Claude（Anthropic）：529过载与Retry-After

Anthropic API返回529错误表示服务过载，通常伴随Retry-After头。官方建议对529进行重试，但需遵循退避策略。429错误可能涉及速率限制或配额，同样需要区分：速率限制可重试，配额问题需人工干预。

Gemini（Google）：429与503的退避策略

Google Gemini API的429错误表示速率限制，503表示服务不可用。两者均可重试，但429需遵循Retry-After，503建议使用指数退避。注意Google的配额管理较为严格，频繁重试可能导致更长的封禁时间。

Bedrock（AWS）：503与429的差异化处理

AWS Bedrock的429错误可能由限流或配额引起，503为服务端错误。Bedrock文档建议对503进行重试，429则需检查限流配置。由于Bedrock的配额与IAM策略关联，重试前应确认配额余量。

如何正确读取Retry-After头

Retry-After头有两种格式：秒数（如Retry-After: 120）或HTTP日期（如Retry-After: Wed, 21 Oct 2026 07:28:00 GMT）。解析时应优先使用秒数格式，若为日期则计算与当前时间的差值。若响应未提供该头，建议使用指数退避（如初始1秒，每次乘以2，最大30秒）。

HTTP日期格式解析注意事项：Retry-After的HTTP日期格式遵循RFC 7231，使用IMF-fixdate（如Wed, 21 Oct 2026 07:28:00 GMT）。解析时应使用支持该格式的库（如Python的email.utils.parsedate_to_datetime），并统一转换为UTC时间后与当前UTC时间比较，避免本地时区偏差导致等待时间计算错误。若解析失败或日期已过期，应回退到指数退避策略。部分代理或网关可能修改或剥离该头，因此在客户端侧设置合理的默认退避同样重要。

类型化包装器：自动跳过配额错误

为减少重复代码，可构建类型化包装器（typed wrapper），在捕获异常时根据错误类型决定是否重试。例如，对于OpenAI的RateLimitError，检查错误码是否为insufficient_quota，若是则直接抛出；对于529和503，则按退避策略重试。包装器可统一处理Retry-After头，并记录重试日志，便于监控。

错误分类与异常映射：不同SDK对HTTP错误的封装方式不同。OpenAI Python SDK将429映射为RateLimitError，其code字段可能为insufficient_quota或rate_limit_exceeded；Anthropic SDK使用APIStatusError并暴露status_code；Google Gemini SDK（如google-generativeai）抛出ResourceExhausted（对应429）和ServiceUnavailable（对应503）；AWS Bedrock通过botocore.exceptions.ClientError返回Error.Code（如ThrottlingException、ServiceUnavailableException）。类型化包装器应先按异常类型分流，再检查错误码或状态码，最后决定重试或直接抛出。建议为每个提供商定义独立的错误分类函数，避免跨SDK耦合。

实践建议与总结

• 始终优先读取Retry-After头，避免固定间隔重试。
• 区分配额错误与速率限制错误，配额错误不应重试。
• 为每个提供商配置独立的退避策略，避免跨服务干扰。
• 使用类型化包装器统一错误处理逻辑，提升代码可维护性。

通过遵循官方文档的差异化规则，并结合自动化重试机制，可显著降低AI API调用失败率，保障应用稳定性。