上线前先分清三个指标
98% 是当前运营可用率目标，不是历史监控统计，也不构成带服务抵扣或赔偿条款的正式 SLA。
5,000 RPM 应该怎样规划
同步请求会保持连接，直到模型返回完整结果；异步接口则在任务进入系统后返回 HTTP202，图片在后台继续生成。
如果业务存在突发流量、页面关闭后仍需继续生成，或者客户端不能长时间保持连接，应采用异步任务。保存 task_id 后再查询任务状态，可以把请求接入与图片完成拆开管理。
平台不设置固定 RPM，并不意味着上游永远不会拥堵，也不意味着客户端应该无限创建连接。应用仍应根据自身预算、工作线程、队列长度和用户等待时间设置并发上限。
为什么仍然可能收到 429
Nano Banana 路由收到 HTTP429 时，应按 Google 官方上游的速率或容量问题处理。常见原因包括：
- 官方项目或模型的 RPM、IPM、TPM 或 RPD 限制；
- 上游消费等级或消费速率限制；
- 特定模型暂时没有足够容量；
- 高峰期的区域性资源紧张。
429 RESOURCE_EXHAUSTED 的当前说明见 Gemini API 限流文档。
客户端处理顺序：
- 响应含
Retry-After时，优先按照该时间等待； - 否则使用指数退避，并加入随机抖动；
- 设置最大重试次数或总截止时间；
- 连续出现 429 时降低突发并发；
- 不要把参数错误、密钥错误或余额不足当成 429 重试。
可用率目标如何理解
服务目标是保持 98% 以上可用率。这个目标不能替代应用自己的容错：Google 官方服务异常、网络中断或单个模型容量变化仍可能造成短时失败。 生产客户端应保存responseId 和异步 task_id，对临时错误做有上限的重试，并让最终失败能够进入业务补偿或人工处理流程。
生产接入建议
- API Key、模型 ID 和重试参数全部放入配置；
- 按业务预算和处理能力设置客户端并发；
- 长时间图片任务优先采用异步接口；
- 分别监控请求接入量、任务完成量、429 和 5xx；
- 日志保留模型 ID、HTTP 状态、
responseId、task_id和请求时间； - 上线前阅读错误与安全重试；
- 轮询代码必须设置截止时间，不能无限等待。
处理 429 与其他错误
分清上游容量、参数、鉴权、余额和服务端错误。
使用异步任务
快速接收请求，保存任务 ID，再查询最终结果。
实现安全轮询
加入 Retry-After、随机抖动、截止时间和终态处理。