Nano Banana 出图 API 为什么用 RPM 而不是 QPS？同步调用模式下的速率限制本质解析

作者注：深度解析 Nano Banana Pro 和 Nano Banana 2 等图像生成 API 为什么用 RPM 而不是 QPS 作为速率限制指标，从 Gemini 同步调用的阻塞特性出发，理解两种指标的适用场景差异

如果你用过文本 LLM 的 API，可能习惯了 QPS（每秒查询数）这个指标。但到了 Nano Banana Pro 和 Nano Banana 2 这类出图 API，官方文档讨论的全是 RPM（每分钟请求数）——为什么出图 API 不谈 QPS？这不是命名偏好的问题，而是图像生成的同步阻塞调用模式决定了 QPS 在这个场景下几乎没有意义。本文将从技术底层讲清楚这个区别。

核心价值: 读完本文，你将理解 RPM 和 QPS 在不同 API 场景下的本质差异，以及为什么 Gemini 图像 API 的同步调用模式让 QPS 变成了伪命题。

RPM vs QPS 核心要点

先直接回答问题：出图 API 用 RPM 不用 QPS，是因为同步调用的阻塞时间太长，QPS 没有实际意义。

概念	定义	适用场景	出图 API 适用？
QPS	每秒查询数（Queries Per Second）	毫秒级响应的高频服务	不适用
RPS	每秒请求数（Requests Per Second）	与 QPS 基本等价	不适用
RPM	每分钟请求数（Requests Per Minute）	秒-分钟级响应的慢速服务	适用
IPM	每分钟图片数（Images Per Minute）	图像生成专用	最适用
RPD	每天请求数（Requests Per Day）	配额管理	适用

为什么出图 API 的 QPS 是伪命题

理解这个问题的关键在于 Gemini 出图 API 的同步调用特性。

当你调用 Nano Banana 2 生成一张图片时，API 是同步阻塞的——你发出请求后，HTTP 连接保持打开，客户端一直等待，直到图片生成完毕（13-170 秒）才返回响应。在这整段时间里，这个连接什么都不做，就是等。

对比一下：

Claude API（文本）：首个 Token 在 50-200ms 内返回，流式传输，1 秒内就能拿到有用的结果
Nano Banana 2（1K 图片）：最快也要 13 秒才返回，连接全程阻塞

所以对于出图 API 来说，"每秒能处理多少请求"（QPS）这个问题本身就不成立——因为一个请求就可能占用你 13 秒以上。用 RPM 才是合理的度量单位。

🎯 类比: QPS 像是衡量快餐店每秒能出几份快餐。RPM 像是衡量一家正式餐厅每小时能服务多少桌。你不会用"每秒上菜数"来衡量法餐厅的效率，因为一道菜本身就需要 30 分钟。
通过 API易 apiyi.com 调用 Nano Banana 2，RPM 不受官方限制，可以并发更多请求。

Gemini 出图 API 同步调用的技术细节

这是理解 RPM vs QPS 的关键基础。

Nano Banana 2 同步调用的阻塞过程

客户端发送请求
    │
    ▼
TCP 连接建立 ──────────────────────────────────┐
    │                                          │
    ▼                                          │
服务端接收提示词                                 │ 连接保持打开
    │                                          │ 客户端阻塞等待
    ▼                                          │
扩散模型推理（13-170 秒）                        │
    │                                          │
    ▼                                          │
图片编码为 base64                               │
    │                                          │
    ▼                                          │
返回响应（包含图片数据）────────────────────────┘
    │
    ▼
客户端接收图片

在这个过程中，客户端的线程/进程被完全占用。如果你用单线程同步调用，1 分钟最多只能发出 60 / 生成时间 个请求——对于 13 秒的 1K 图片，单线程 QPS 约为 0.077（每秒 0.077 个请求），换算成 RPM 才 4.6。

Nano Banana 2 不同分辨率的阻塞时间

分辨率	典型生成时间	单线程 RPM 上限	单线程"QPS"
0.5K	~8 秒	~7.5 RPM	0.125
1K	~13 秒	~4.6 RPM	0.077
2K	~30 秒	~2 RPM	0.033
4K	~90-170 秒	~0.4-0.7 RPM	0.006-0.011

看到了吗？4K 分辨率下，单线程的"QPS"只有 0.006——也就是说平均每 170 秒才能完成 1 个请求。在这个量级下，讨论 QPS 毫无意义，RPM 才是有效的度量。

RPM 和 QPS 分别适合什么场景

QPS 适合的场景

QPS 作为速率指标有意义的前提条件是：单次请求的响应时间远小于 1 秒。

服务类型	典型响应时间	QPS 是否有意义	原因
CDN / 缓存	1-10ms	极有意义	每秒可处理数千请求
数据库查询	5-50ms	有意义	每秒可处理数百请求
文本 LLM 首 Token	50-200ms	有意义	每秒可启动 5-20 请求
搜索 API	100-500ms	有意义	每秒可完成 2-10 请求

RPM 适合的场景

RPM 作为速率指标更合理的场景：单次请求的响应时间在秒级到分钟级。

服务类型	典型响应时间	为什么用 RPM	Gemini 官方限制
图像生成	8-170 秒	1 秒内完不成 1 个请求	RPM + IPM
视频生成	30-300 秒	单次请求占用分钟级	RPM
批量数据处理	分钟级	任务粒度大于秒	RPM + RPD
文件转换	5-60 秒	单次处理耗时长	RPM

Gemini 出图 API 的四维速率限制

Google 对 Gemini 出图 API 设计了四个维度的速率限制，触发任何一个就会被限速：

维度	含义	免费层	Tier 1（付费）
RPM	每分钟请求数	5-15	150-300
TPM	每分钟 Token 数	有限	较高
RPD	每天请求数	20-100	1,000+
IPM	每分钟图片数	有限	较高

注意 IPM（每分钟图片数）——这是专门为图像生成设计的指标。因为一个请求可能生成多张图片，所以 RPM 和 IPM 不是简单的一对一关系。

如何提升出图 API 的实际吞吐量

理解了 RPM 的本质后，下一个问题是：如何在 RPM 限制下最大化出图效率。

多线程并发 + RPM 上限的计算

假设你需要每分钟生成 20 张 1K 图片：

单线程 RPM = 60秒 / 13秒 ≈ 4.6 张/分钟
需要线程数 = 20 / 4.6 ≈ 5 个并发线程

但还要确保 5 个并发线程的 RPM 总量（约 23 RPM）不超过账户的 RPM 配额。免费层只有 5-15 RPM，Tier 1 付费有 150-300 RPM。

出图 API 并发优化建议

优化策略	效果	适用场景
多线程/协程并发	线性提升（受 RPM 限制）	实时出图场景
Batch API 异步	不阻塞 + 价格 5 折	可容忍延迟的批量场景
降低分辨率	单图时间减少 → RPM 提升	预览图、缩略图
API易中转	突破官方 RPM 限制	高并发生产环境
客户端超时设置	避免无效等待	所有场景（1K 建议 300s，4K 建议 600s）

🎯 实战建议: 如果你需要高并发出图，通过 API易 apiyi.com 调用 Nano Banana 2 是最简单的方案——不受官方 RPM 限制，价格还有 28% 折扣，4K 固定价仅 $0.045。

常见问题

Q1: 如果用异步并发发 10 个请求，RPM 算几？

算 10。RPM 计算的是你在 1 分钟内发出的请求数量，不管这些请求是否已经返回。即使你用异步并发同时发出 10 个请求，它们各自阻塞 13 秒后陆续返回，这 10 个请求都算在同一分钟的 RPM 内。所以多线程并发可以提升吞吐量，但不能绕过 RPM 配额。

Q2: Gemini Batch API 是不是异步的？能绕过 RPM 吗？

是的。Gemini Batch API 是异步模式——你提交一批请求后立即返回任务 ID，不阻塞客户端。任务在后台处理，完成后通知你获取结果。Batch API 有独立的配额（按 Token 计），不占用实时 RPM 配额，而且价格还便宜 50%。缺点是不保证实时性，适合"不急着要"的批量场景。

Q3: OpenAI 的 chatgpt-image-latest 也是同步阻塞的吗？

是的。chatgpt-image-latest 也是同步调用，响应时间约 44-60 秒。开发者社区报告 gpt-image-1 的超时问题频繁出现，建议设置至少 300 秒的超时。所以 OpenAI 的图像 API 也用 RPM 作为速率限制指标，逻辑和 Gemini 一样——因为同步阻塞的响应时间太长，QPS 没有意义。

Q4: API易如何突破官方 RPM 限制？

API易通过多账号池轮询机制实现——平台维护多个 Gemini API 账号，客户端的请求被自动分配到不同账号上，每个账号各自有自己的 RPM 配额。对开发者来说等效于 RPM 大幅提升，不需要自己管理多个 API Key。同时享受 28% 折扣和 4K 固定价 $0.045 的价格优势。

总结

Nano Banana 出图 API 用 RPM 而不是 QPS 的核心原因：

同步阻塞决定了度量单位: Gemini 出图 API 是同步调用，1 个请求阻塞 13-170 秒，1 秒内连 1 个请求都完不成——QPS 这个"每秒"粒度的指标在这里毫无意义，RPM（每分钟）才是合理的度量
RPM 适合慢速服务，QPS 适合快速服务: 简单判断标准——如果单次响应 < 1 秒用 QPS，> 1 秒用 RPM。出图、视频、文件转换都属于 RPM 场景
提升吞吐量的核心是并发 + 配额: 多线程并发可以线性提升吞吐，但受 RPM 配额限制。通过 API易多账号池轮询可以突破单账号 RPM 上限

推荐通过 API易 apiyi.com 调用 Nano Banana 2——不受官方 RPM 限制，价格 28% 折扣，4K 固定价 $0.045。

📚 参考资料

Gemini API Rate Limits: 官方速率限制文档
- 链接: ai.google.dev/gemini-api/docs/rate-limits
- 说明: 包含 RPM、TPM、RPD、IPM 四维限制的完整说明
Nano Banana Pro 同步 vs 异步 API 对比: 两种调用模式的技术差异
- 链接: help.apiyi.com/en/nano-banana-pro-sync-async-api-comparison-en.html
- 说明: 包含阻塞时间、超时设置和吞吐量计算
OpenAI Rate Limits: OpenAI 的速率限制文档（RPM 体系）
- 链接: developers.openai.com/api/docs/guides/rate-limits
- 说明: 对比 Gemini 和 OpenAI 的速率限制设计思路
API易文档中心: 突破 RPM 限制的出图 API 接入
- 链接: docs.apiyi.com
- 说明: Nano Banana 2 高并发接入和折扣价格

作者: APIYI 技术团队
技术交流: 欢迎在评论区讨论，更多资料可访问 API易 docs.apiyi.com 文档中心

Nano Banana 出图 API 为什么用 RPM 而不是 QPS？同步调用模式下的速率限制本质解析