限流与重试

限流来源

来源	触发条件	响应
IP 级限流	同一 IP 在窗口内请求过多	429，带 Retry-After 响应头（单位秒）
用户模型请求限流	同一账号在窗口内的成功请求数或总请求数超限	429，响应体给出窗口与上限，例如「您已达到请求数限制：N 分钟内最多请求 M 次」

总请求数限制把失败请求也算进去。所以持续发送格式错误的请求同样会把配额耗尽，提示里会写明「包括失败次数」。

上游切换与重试

上游账号触发限流或异常时，网关会自动切到下一个可用账号，调用方无需改动。因此你收到的 429 通常来自网关自身的限流层，而不是某一个上游账号。

长会话保持账号亲和，上下文不因切换中断。但已经开始输出的流式响应无法续接，中断后需要整条重试。

客户端重试建议

1. 只对 429 和 5xx 重试。4xx 里的其他状态是请求本身的问题，重试不会变好。
2. 有 Retry-After 就按它等待，没有就用指数退避加随机抖动。
3. 设置重试上限，避免把总请求数配额耗光。
4. 流式请求重试时从头发起，不要尝试断点续传。

重试决策示意图，非控制台截图。设置次数上限，避免失败请求继续消耗限流配额；点击图片查看大图。

验证

观察一次 429 的完整响应头和响应体：

curl -i https://ai.roibest.com/v1/chat/completions \
  -H "Authorization: Bearer $ROIBEST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"your-model","messages":[{"role":"user","content":"hello"}]}'

-i 会打印响应头。正常时返回 200；被限流时是 429，检查是否存在 Retry-After。

常见问题

一直 429，但我请求并不频繁。 可能是共享出口 IP 触发了 IP 级限流，也可能是失败请求把总请求数配额吃掉了。先把请求本身修对，再观察。

429 没有 Retry-After。 用户模型请求限流不返回该响应头，按响应体里的窗口时长退避即可。

要提高上限。 限流阈值由部署配置决定，联系管理员调整。

并发多少合适？ 先从个位数并发起步，观察 429 比例再逐步加。没有一个对所有账号通用的数值。