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？同步調用模式下的速率限制本質解析