报错长这样
429 Too Many Requests
Rate limit reached
group requests-per-minute limit exceeded
Too many pending requests, please retry later
API_KEY_RATE_5H_EXCEEDED
API_KEY_RATE_1D_EXCEEDED
请求太频繁这是什么意思
你发请求的速度太快了，超过了允许的频率。
就像高速公路的限速，超速会被拦下来。
两种限流，分别怎么处理
| 报错关键词 | 谁在限 | 怎么解决 |
|---|---|---|
group requests-per-minute | 本站的分组频率限制 | 降低并发，等一下 |
Too many pending requests | 上游排队满了 | 降低并发，等一下 |
rate limit | 上游的速率限制 | 等一下 |
API_KEY_RATE_xxx | 你的密钥在 5 小时/1 天/7 天维度超限 | 等额度重置 |
第一步：等 60 秒
最简单有效。 大多数限流是按「每分钟」算的，等一分钟自动恢复。
第二步：降低并发
如果你在跑批量任务：
| 做法 | 效果 |
|---|---|
| 从同时 10 个请求改成 3 个 | 立刻缓解 |
| 每次请求之间加 1 秒间隔 | 平均下来不超频 |
| 分批处理，每批之间停一下 | 避免瞬时高峰 |
如果用的是工具批量调用
| 工具 | 怎么降并发 |
|---|---|
| 自己写的脚本 | 加 sleep 或信号量控制 |
| Cherry Studio | 设置里找「并发数」，调小 |
| 翻译/总结类工具 | 找「速度」「并发」设置 |
| 爬虫类 | 加请求间隔 |
第三步：看是不是密钥级别超限
如果报错是 API_KEY_RATE_5H_EXCEEDED 这类：
| 报错 | 含义 | 恢复时间 |
|---|---|---|
_5H_ | 5 小时内的额度用完 | 等 5 小时窗口滚动 |
_1D_ | 一天的额度用完 | 等第二天 |
_7D_ | 一周的额度用完 | 等下周 |
这种是硬限制，等多久都无法提前，只能等窗口过去，或者联系客服调整限额。
第四步：不是你的问题
如果报错是 Too many pending requests：
这是上游排队满了，全站用户共用。
| 现象 | 说明 |
|---|---|
| 你才发了 1 个请求也报这个 | 不是你超频，是上游堵了 |
| 换模型就好 | 那个模型的线路排队 |
| 过一会自动好 | 排队消化了 |
这种情况不用改你的配置，等一会或换模型。
避免反复被限流
| 建议 | 说明 |
|---|---|
| 提前规划用量 | 批量任务分批跑，别集中 |
| 设合理并发 | 3-5 并发对多数任务够用 |
| 长任务用流式 | 减少单次请求时间 |
| 监控用量 | 后台看当天的调用次数 |
检查清单
□ 等 60 秒重试过了吗？
□ 是不是在跑批量任务？并发是多少？
□ 报错里是 5H / 1D / 7D 吗？（密钥额度）
□ 还是 pending requests？（上游排队）
□ 换一个模型试试还是不行
联系我们并提供：
- 完整报错
- 你的调用频率（大概每分钟几次）
- 是否在跑批量任务
- 出现时间