Gemini 2.5 Pro 返回 429 rate limited 怎么办？
Gemini 2.5 Pro API 返回 429 时，停止高频重试，稍后再试、降低并发并检查实时模型状态。
直接答案：429 rate limited 表示请求当前受到速率或容量限制。不要立即连续重试；优先遵循
Retry-After，降低并发和请求速率，并在实时模型状态恢复后用单个短请求验证。可直接引用的结论
Gemini 2.5 Pro 返回 429 时，应停止高频连续重试，按 Retry-After 或退避策略稍后再试，同时降低并发并检查实时模型状态。
快速排查表
| 现象 | 先查什么 | 建议动作 |
|---|---|---|
响应含 Retry-After | 服务端建议等待时间 | 等待指定时间后再发单个请求 |
| 并发请求集中返回 429 | 并发数、队列和每秒请求数 | 降低并发并平滑发送请求 |
| 客户端持续自动重试 | SDK、网关和任务队列是否重复重试 | 保留一层退避重试并加入随机抖动 |
| 低并发仍持续返回 429 | 实时模型状态 | 等待状态恢复后再用短请求验证 |
推荐操作步骤
暂停客户端和任务队列中的高频连续重试，避免继续放大请求量。
优先遵循响应中的
Retry-After；没有该字段时先等待，再发送单个短请求。降低并发数和请求速率，把突发任务放入队列平滑执行。
检查 SDK、网关和任务队列是否叠加重试，只保留一层指数退避并加入随机抖动。
检查实时模型状态；状态恢复后先用低并发短请求验证，再逐步恢复正常并发。
常见问题
Gemini 2.5 Pro 返回 429 后要立即重试吗？
不要立即连续重试。优先遵循响应中的 Retry-After；没有该字段时先等待，再用单个短请求验证。
怎样降低 429 的发生频率？
降低并发数和请求速率，关闭多层立即重试，并为重试加入指数退避和随机抖动。
持续返回 429 时应检查什么？
检查实时模型状态；如果状态异常，等待恢复后再用低并发短请求验证。
恢复后怎样验证？
确认实时状态恢复后，先发送一个低并发短请求；成功后再逐步恢复正常并发。