> ## Documentation Index
> Fetch the complete documentation index at: https://docs.yingtu.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# API 流量能力与可用率
> 了解 Nano Banana API 至少 5,000 RPM 的接入能力、平台固定限流策略、官方上游 429 和不低于 98% 的可用率目标。
Nano Banana API 接入层至少支持每分钟 **5,000 个 API 请求**，文档中的图片生成和异步提交接口不设置固定的平台侧 RPM 上限。当前服务可用率目标不低于 **98%**。
这里的 5,000 RPM 指进入网关的请求量，不代表每分钟一定完成 5,000 张图片。最终完成速度仍取决于模型生成时间、请求内容和 Google 官方上游容量。
## 上线前先分清三个指标
| 指标 | 当前含义 |
| ---------- | --------------------------- |
| 接入能力 | 网关每分钟至少接收 5,000 个 API 请求 |
| 平台固定 RPM | Nano Banana 路由不设置固定平台上限 |
| 图片完成吞吐 | 由生成耗时、异步队列和官方上游容量共同决定 |
| HTTP `429` | Google 官方上游的速率、配额、消费或模型容量响应 |
| 可用率目标 | 不低于 98% |
98% 是当前运营可用率目标，不是历史监控统计，也不构成带服务抵扣或赔偿条款的正式 SLA。
## 5,000 RPM 应该怎样规划
同步请求会保持连接，直到模型返回完整结果；异步接口则在任务进入系统后返回 HTTP `202`，图片在后台继续生成。
如果业务存在突发流量、页面关闭后仍需继续生成，或者客户端不能长时间保持连接，应采用[异步任务](/cn/unified-api/async-tasks)。保存 `task_id` 后再查询任务状态，可以把请求接入与图片完成拆开管理。
平台不设置固定 RPM，并不意味着上游永远不会拥堵，也不意味着客户端应该无限创建连接。应用仍应根据自身预算、工作线程、队列长度和用户等待时间设置并发上限。
## 为什么仍然可能收到 429
Nano Banana 路由收到 HTTP `429` 时，应按 Google 官方上游的速率或容量问题处理。常见原因包括：
* 官方项目或模型的 RPM、IPM、TPM 或 RPD 限制；
* 上游消费等级或消费速率限制；
* 特定模型暂时没有足够容量；
* 高峰期的区域性资源紧张。
Google 对 `429 RESOURCE_EXHAUSTED` 的当前说明见 [Gemini API 限流文档](https://ai.google.dev/gemini-api/docs/rate-limits)。
客户端处理顺序：
1. 响应含 `Retry-After` 时，优先按照该时间等待；
2. 否则使用指数退避，并加入随机抖动；
3. 设置最大重试次数或总截止时间；
4. 连续出现 429 时降低突发并发；
5. 不要把参数错误、密钥错误或余额不足当成 429 重试。
## 可用率目标如何理解
服务目标是保持 98% 以上可用率。这个目标不能替代应用自己的容错：Google 官方服务异常、网络中断或单个模型容量变化仍可能造成短时失败。
生产客户端应保存 `responseId` 和异步 `task_id`，对临时错误做有上限的重试，并让最终失败能够进入业务补偿或人工处理流程。
## 生产接入建议
* API Key、模型 ID 和重试参数全部放入配置；
* 按业务预算和处理能力设置客户端并发；
* 长时间图片任务优先采用异步接口；
* 分别监控请求接入量、任务完成量、429 和 5xx；
* 日志保留模型 ID、HTTP 状态、`responseId`、`task_id` 和请求时间；
* 上线前阅读[错误与安全重试](/cn/getting-started/errors-and-retries)；
* 轮询代码必须设置截止时间，不能无限等待。
分清上游容量、参数、鉴权、余额和服务端错误。
快速接收请求，保存任务 ID，再查询最终结果。
加入 Retry-After、随机抖动、截止时间和终态处理。