直接答案
503 表示服务当前无法处理请求，通常是暂时状态；先降低流量并读取 Retry-After，不要用并发重试继续压垮服务。
这篇内容解决什么问题
解决 service_unavailable、overloaded_error、维护或容量不足导致的 HTTP 503。
OpenAI 兼容 APIAnthropic 兼容 API批处理任务高并发客户端
01
先确认症状与影响范围
请求返回 503 Service Unavailable、service_unavailable 或过载信息。响应可能包含 Retry-After，表明服务希望客户端等待后再尝试。
全部模型同时失败更像网关或平台维护；只有某个模型失败更像模型容量、路由或上游健康状态。
- 读取 Retry-After、request ID 和错误类型。
- 比较模型列表、一个已知可用模型和目标模型。
- 暂停批处理，观察单个最小请求是否恢复。
02
常见原因与责任边界
503 是明确的暂时不可用信号，但持续时间和影响范围取决于生成响应的服务层。恢复策略必须防止所有客户端同时重试。
- 服务维护、部署或健康检查暂时失败。
- 模型或网关容量不足，队列拒绝新请求。
- 负载均衡器后没有健康实例。
- 客户端重试风暴使短时故障持续扩大。
03
按层执行最小诊断
首先降低请求率并检查公开状态信息，然后每个恢复窗口只发送少量探测请求。不要把大量业务流量当作健康检查。
记录失败模型和成功模型的差异。若模型列表成功但目标模型持续 503，可按业务允许的模型降级策略处理。
- 01暂停高并发停止 worker 自动重试，保留少量健康探测。
- 02读取恢复提示尊重 Retry-After 和服务状态信息。
- 03缩小影响面区分平台、协议、模型和区域范围。
- 04渐进恢复从单请求开始逐级恢复流量并观察错误率。
低频健康探测语言：bash
date -u
curl -sS -D /tmp/api-503.headers -o /tmp/api-503.body -w 'status=%{http_code} total=%{time_total}
' 'https://<your-api-host>/v1/models' -H "Authorization: Bearer ${API_KEY:?set API_KEY first}"
sed -n '1,30p' /tmp/api-503.headers
04
针对根因完成修复
客户端应尊重 Retry-After、使用带抖动退避和熔断。业务需要连续性时，只能切换到事先验证过、能力满足要求的模型或队列稍后处理，不能在故障时临时猜测兼容模型。
- 01熔断达到错误率阈值后停止直接调用并快速失败或排队。
- 02退避按 Retry-After 或指数退避等待，加入随机抖动。
- 03受控降级仅切换到已测试模型，并标记能力与成本差异。
- 04渐进放量恢复后分阶段增加流量，避免同时唤醒所有 worker。
05
验证修复而不是只看一次成功
恢复判断应基于一段观察窗口内的成功率和延迟，而不是一次探测。逐级放量时若 503 回升，应自动退回上一稳定级别。
- 探测、低流量和正常流量三个阶段均有指标。
- Retry-After、退避、熔断和最大等待时间生效。
- 排队任务不会重复提交或重复计费。
06
安全边界与升级证据
状态检查和支持升级不需要分享 API Key 或业务提示词。不要通过未知代理、账号轮换或大规模探测绕过服务容量控制。
- 健康探测低频且不携带敏感业务数据。
- 降级模型经过权限、质量和数据边界评估。
- 恢复操作可审计并能快速回滚。
官方来源与核验范围
本文以协议规范和客户端官方文档为事实依据。错误文案、重试头和配置字段可能随服务或客户端版本变化；执行前请核对来源，并对日志与请求样例脱敏。
查看技术核验方法