Gemini API Rate Limit怎麼算？RPM、TPM、RPD、Spend Cap與429

Gemini API的Rate Limit不是單一「每分鐘幾次」。系統通常同時檢查Requests per Minute（RPM）、Input Tokens per Minute（TPM）與Requests per Day（RPD）；超過任何一個維度，都可能回傳429 RESOURCE_EXHAUSTED。部分帳戶還會受到10分鐘Rolling Window的Spend-based Rate Limit。

Quota按Google Cloud Project計算，不按API Key分開。建立十把Key不會得到十倍額度；同一Project下的服務、開發者和Worker會共同消耗限制。實際數字會依模型、Usage Tier、帳戶狀態和Preview狀態變動，應以Google AI Studio中的Active Rate Limits為準。

• RPM限制每分鐘請求數。
• TPM限制每分鐘輸入Token，不是只看Request數。
• RPD限制每日請求，於太平洋時間午夜重置。
• Quota按Project計算，不按API Key。
• Preview與Experimental模型通常限制更嚴格。
• Spend-based Limit以10分鐘Rolling Window檢查。
• Tier 1的Spend Cap目前為每10分鐘10美元，Tier 2與3為200美元。
• Batch API和Priority Inference有獨立或額外Rate Limit。
• 429需要先辨識是哪個維度超限，再決定Backoff或降載。

先講結論：Gemini API限流通常同時檢查RPM、Input TPM與RPD，並按Project而非API Key計算；部分帳戶另有10分鐘Rolling Spend Cap。本文整理Tier、Preview模型、Batch、Priority、429診斷、Token削減、Queue與申請提升。本文再補充背景、關鍵差異與可核對的脈絡。

這篇文章主要在談什麼？ Gemini API限流通常同時檢查RPM、Input TPM與RPD，並按Project而非API Key計算；部分帳戶另有10分鐘Rolling Spend Cap。本文整理Tier、Preview模型、Batch、Priority、429診斷、Token削減、Queue與申請提升。

讀者首先要掌握哪個重點？ Gemini API限流通常同時檢查RPM、Input TPM與RPD，並按Project而非API Key計算；部分帳戶另有10分鐘Rolling Spend Cap。本文整理Tier、Preview模型、Batch、Priority、429診斷、Token削減、Queue與申請提升。先抓住這個主軸，再閱讀後續細節。

標題中的關鍵對象有哪些？ Gemini API Rate Limit怎麼算？RPM、TPM、RPD、Spend Cap與429；文中依此整理相關人物、作品、事件或概念。

本文整理了哪些背景或脈絡？ 文章從「Gemini API Rate Limit」出發，補上形成背景、發展脈絡與讀者最容易混淆的重點。

這個主題的核心差異或看點是什麼？ 核心看點在於把「Gemini API Rate Limit」放回具體例子與前後關係中比較，而不是只列出名詞。

讀者可以從文中得到哪些實用資訊？ 文中依序整理關鍵名詞、人物／作品或事件，以及相關時間、地點、規格或觀察角度；細節以本文段落與引用來源為準。

這篇內容適合哪些搜尋需求？ 適合想快速了解「Gemini API Rate Limit」定義、背景、差異與延伸脈絡的讀者。

閱讀與查證時應注意什麼？ 若涉及活動、票價、上映、產品或時程，資訊可能更新，請以文中列出的官方或原始來源最新公告核對。

一句話怎麼總結？ Gemini API限流通常同時檢查RPM、Input TPM與RPD，並按Project而非API Key計算；部分帳戶另有10分鐘Rolling Spend Cap。本文整理Tier、Preview模型、Batch、Priority、429診斷、Token削減、Queue與申請提升。YOLO LAB 將資訊整理成可快速理解與延伸查證的架構。

文章實體化：Gemini API Rate Limit怎麼算？RPM、TPM、RPD、Spend Cap與429

本文以「Gemini API Rate Limit怎麼算？RPM、TPM、RPD、Spend Cap與429」為主線，補回模型／工具、輸入輸出、版本、成本、測試與使用邊界，讓技術名詞回到可執行的工作流程。

• 核心元件：把標題中的模型、工具、格式、企業或協定對應到實際輸入、輸出與依賴。
• 驗證方法：記錄版本、資料、環境、基準、錯誤案例與人工檢查，避免只引用功能宣稱。
• 治理邊界：說明權限、資料保存、成本、失敗回復與何時需要人工介入。

涉及版本、價格、企業資料或 API 行為時，以文章原始資料與供應商／公司最新文件核對。

RPM、TPM和RPD

限制	計算	常見觸發
RPM	一分鐘內Request數	大量小請求、Retry Storm
TPM	一分鐘內Input Tokens	長Context、PDF、多輪歷史
RPD	一天內Request數	大量批次與免費層
IPM	每分鐘圖片數	圖片生成模型
TPD	每日Token	特定模型或Tier

假設RPM上限20，即使每個請求只有100 Token，第21個Request仍會失敗。反過來，RPM只有5，但每個Prompt是200K Token，也可能先撞到TPM。

為什麼長Context特別容易撞TPM？

TPM usage ≈
system_prompt_tokens
+ conversation_history
+ retrieved_documents
+ files_and_multimodal_tokens
+ tool_context
across all requests in the rolling minute

• 重複傳送相同System Prompt。
• 每輪附上完整對話歷史。
• RAG Top-k過高。
• 一次加入大型PDF或影片。
• 多個Worker同時提交長Prompt。
• Retry重新傳送全部Context。

使用Context Cache、File Search、摘要、Chunk與Prefix設計，可以降低重複Input Token；不能因模型支援1M Context，就假設Quota也適合高並發1M請求。

Quota按Project而非API Key

同一Project中的所有API Key、服務帳戶和應用共享Rate Limit。這會影響多產品和多環境設計：

• Development流量可能影響Production。
• 單一客戶Burst可能拖慢其他Tenant。
• 多把Key不能繞過限制。
• 應按Environment或業務建立獨立Project。
• 仍需遵守Google政策，不把Project切分當成規避機制。

每個Project應建立Quota Owner、Budget Alert與流量Dashboard，避免不知道哪個Service耗盡額度。

Usage Tier怎麼升級？

Tier	一般資格方向	Billing Tier Cap
Free	Active Project或Free Trial	不適用
Tier 1	連結有效Billing Account	250美元
Tier 2	累計支付100美元且首筆成功付款滿3天	2,000美元
Tier 3	累計支付1,000美元且首筆成功付款滿30天	20,000至100,000美元以上

符合條件通常會提高Tier，但官方保留依帳戶狀態、安全與審查拒絕或調整的權利。Tier提升也不代表每個Preview模型都獲得相同限制。

Spend-based Rate Limit

除了RPM與TPM，Gemini API目前還可能依10分鐘Rolling Window限制支出速度，目的是避免短時間產生意外高額帳單。

Tier	每10分鐘Spend Limit
Free	不適用
Tier 1	10美元
Tier 2	200美元
Tier 3	200美元

• 長Context與高輸出容易快速累積費用。
• 高價模型或Deep Thinking影響更大。
• 並發Burst即使RPM未滿，也可能撞Spend Cap。
• 是否適用取決於Billing History和Account Standing。
• 超過時同樣回傳429。

Preview模型為什麼限制更嚴格？

• 容量仍在調整。
• 性能與成本曲線尚未穩定。
• 可能有較高單Request Compute。
• 需要控制濫用和異常流量。
• Endpoint可能更新或停止。

Preview模型不適合作為唯一無備援Production依賴。應保留Stable或較便宜模型Fallback，並對重要流量使用Admission Control。

Priority Inference

Priority Consumption提供較高服務優先級，也有自己的Rate Limit。官方目前指出預設Priority限制約為標準模型與Tier Rate Limit的0.3倍，同時仍會計入整體Interactive流量。

• 適合高價值、低延遲請求。
• 不能把全部流量無差別切到Priority。
• 需要獨立Queue和Budget。
• 超過Priority限制時要有Standard Fallback。

Batch API限制

Batch API使用獨立限制，適合非即時、大量可延後任務。官方目前列出：

• Concurrent Batch Requests：100。
• Input File Size：2GB。
• File Storage：20GB。
• 每模型Enqueued Tokens另有上限。
• Batch Quota和Interactive分開管理。

摘要、Embedding、離線評測和大量分類可優先考慮Batch，避免擠壓使用者即時流量。

429如何診斷？

1. 確認使用哪個Project與Model。
2. 到AI Studio查看Quota與Rate Limit。
3. 分開查看RPM、TPM、RPD和Spend。
4. 檢查是否為Preview或Priority限制。
5. 查看是否有Retry Storm。
6. 記錄Request Token、Latency和Error Metadata。
7. 只對可Retry請求執行Backoff。

Usage Dashboard可能有延遲，系統仍應自行維護近即時Token和Request Counter。

Exponential Backoff＋Jitter

delay = min(max_delay, base * 2^attempt)
delay = random(0, delay)
retry only before request deadline

• 尊重Server提供的Retry資訊。
• 加入Jitter避免所有Worker同時重試。
• 設定Max Attempts與Deadline。
• 不要Retry已執行外部副作用的Request。
• 持續429時打開Circuit Breaker。

降低TPM的方法

• 使用Explicit Context Caching。
• 只傳送Diff或新對話。
• 降低RAG Top-k與Chunk Size。
• 把舊歷史壓縮成可追溯Summary。
• File Search只取相關Chunk。
• 使用較短System Prompt。
• 按任務路由到較小Context模型。
• 避免Retry完整大型Prompt。

Gemini Context Cache的Break-even可閱讀Gemini Context Caching怎麼省錢？。

Production流量設計

request
  → estimate tokens and cost
  → tenant quota
  → model queue
  → rate limiter
  → Gemini API
  → retry / fallback / degraded mode

• 在Client前做Token預估。
• 每Tenant設定RPM／TPM Budget。
• Interactive和Batch分Queue。
• 高價模型需要Admission。
• 預留人工和低精度Fallback。
• 記錄429、Queue Time與Dropped Request。

供應商無關的Queue、Circuit Breaker與Fallback設計可閱讀AI API為什麼會限流？。

何時申請提升Rate Limit？

• 已完成Token削減與Caching。
• 正常流量持續撞到限制。
• 有穩定Billing與Usage History。
• 能提供模型、Region、Traffic Pattern與SLO。
• 已有防濫用和Budget Control。
• 能說明預估成長和高峰。

增加Quota不能修復無上限Retry、過度Context和缺少Tenant隔離。先完成流量治理，再申請容量。

常見問題

多建立幾把API Key能提高額度嗎？

不能。Rate Limit按Project計算，同一Project的Key共享Quota。

RPM沒滿，為什麼還是429？

可能撞到TPM、RPD、Spend Limit、Priority或特定模型限制。

升級Tier後一定不會限流嗎？

不會。Tier提高容量，但每個模型仍有限制，實際Capacity也可能波動。

官方資料

• Gemini API Rate Limits
• Gemini API Troubleshooting

Gemini API限流的正確管理方式，是同時看RPM、TPM、RPD、Spend與模型狀態。429不是單純「等一下再試」，而是流量、Token、成本和服務等級的診斷訊號。

先分清楚四種限制：RPM、TPM、RPD 與花費速度

Gemini API 的 rate limit 不是單一「每分鐘可以呼叫幾次」。Google AI for Developers 官方文件把常見限制拆成 requests per minute（RPM）、tokens per minute（TPM）與 requests per day（RPD），另外還有依花費速度計算的 spend-based rate limit。這幾個數字分別回答不同問題：請求是否太密、輸入量是否太大、一天的呼叫是否用完，以及短時間內的費用是否跑得太快。只盯著 RPM，常會把真正的瓶頸誤判成網路或 SDK 故障。

例如，一個批次請求可能只算一次 RPM，卻帶入很長的上下文而先撞到 TPM；另一個小請求在單分鐘內沒有超量，累積一天後仍可能撞到 RPD。若是昂貴模型、長輸出或大量並行工作，還可能收到與 spend-based limit 有關的 429 RESOURCE_EXHAUSTED。排查時要先記錄模型、專案、時間窗、輸入 token、輸出 token、HTTP 狀態與錯誤訊息，再決定是降速、縮短內容、換模型或調整用量層級。

限制是 project 級別，不是換 API key 就能解決

官方文件特別提醒，Gemini API 的 rate limits 是套用在 project，而不是單一 API key。這個觀念會直接改變架構判斷：同一個專案底下建立多把 key，並不會把 RPM、TPM 或 RPD 變成多份。若多個服務、測試環境與本機腳本共用一個 project，大家的流量會一起消耗同一組限制。把 key 輪替當成擴容方法，既不能修正容量規劃，也會讓真正的流量來源更難追蹤。

比較穩健的做法是先為不同生命週期拆分 project，例如開發、預發布與正式環境各自有清楚的帳務與監控邊界，再依權限與資料治理需要管理 key。拆分不是為了規避平台限制，也不能改變模型本身的容量；它的價值在於讓預算、告警、服務帳號、部署責任與錯誤追蹤能對得上。正式環境若要申請更高 tier 或 rate limit，也應以實際用量、錯誤率、峰值與預估成長提出理由。

429 不等於「等一下再重試」：先看是哪個時間窗

遇到 429 時，第一步不是立刻開十倍重試，而是辨認它屬於哪一種限制。若是 RPM，請求可能在短時間窗內過密；若是 TPM，降低單次輸入、輸出長度或並行數才有幫助；若是 RPD，等到官方定義的每日重置時間前，單純加快重試只會浪費資源。官方文件指出 RPD 以 Pacific Time 的午夜重置，跨時區的服務若把本地日期當成重置依據，容易在觀察上產生錯誤。

重試策略也要有界線：讀取 Retry-After 或錯誤訊息提供的線索，使用指數退避加上隨機抖動，設定最大嘗試次數與總等待時間，並把不可重試的驗證錯誤和可暫時恢復的配額錯誤分開。對非冪等工作，重試前要有 request idempotency 或工作佇列去重，否則一次 429 可能變成重複扣款、重複寫入或重複發送結果。真正成熟的限流器會在送出請求前就排隊，而不是等 API 拒絕後才被動補救。

TPM 的陷阱：輸入長度、輸出長度與併發會一起放大

Token limit 的困難在於，請求數看起來不多，token 卻可能快速累積。把完整對話歷史、工具結果、檔案內容與系統提示每次都重送，會讓每一個請求的輸入成本持續變大；若同時允許許多 worker 並行，瞬間 TPM 就會超過限制。改善方式包括摘要舊對話、只傳遞必要欄位、限制工具輸出、依任務選擇較小模型，以及在佇列層先估算 token 預算。

不要只用平均值做容量估算。平均每分鐘一千個 token 可能掩蓋尖峰十倍的批次；一個長尾請求也可能讓 P95 延遲與 TPM 同時失真。監控至少應保留每個 project、model、region 或服務路由的請求數、輸入輸出 token、並行數、429 分類、重試次數、排隊時間與實際費用。這些欄位才能回答「是流量增加，還是每個請求變胖」這個關鍵問題。

Spend cap 是預算護欄，不是即時斷路器

官方 billing 文件說明，Gemini API 可以在 billing account tier 與 project 層級設定 spend cap，但帳務資料處理存在延遲，長時間任務、批次工作與 agent session 也可能在資料尚未更新時產生額外用量。因此，spend cap 適合當成預算與風險護欄，不應被描述成毫秒級的硬斷路器。若服務需要即時成本保護，還要在自己的佇列、請求代理或工作編排層建立累積 token 與金額門檻。

成本控制應與可靠性一起設計。當費用快接近上限時，可以先降低輸出上限、暫停低優先工作、切換到適合的模型、延後批次，並讓使用者看到可理解的降級訊息。不要讓所有流量同時重試，也不要把「提高 tier」當成唯一答案；如果提示詞膨脹、快取失效或並行策略有問題，升級只會把浪費放大。

一個實用的 Gemini 配額排查順序

1. 確認身份：記下實際 project、model、環境與服務帳號，確認不是把測試流量誤送到正式 project。
2. 分類限制：從錯誤回應、監控與 AI Studio 的 active rate limits 交叉確認 RPM、TPM、RPD 或 spend-based limit。
3. 量測請求：查看一段完整時間窗的請求數、token、並行、重試與排隊，而不是只看單次成功率。
4. 先做減法：降低併發、縮短上下文與輸出、合併可合併工作，確認問題是否因流量形狀而改善。
5. 再談升級：只有在用量合理、監控完整且需求可說明時，才評估 tier 或 rate-limit increase。

這個順序能把「平台真的不夠」和「客戶端自己製造尖峰」分開。它也讓 429 從一個模糊錯誤，變成可以由團隊共同處理的營運事件：開發者看請求與 token，SRE 看併發與退避，財務或產品看 spend cap 與優先級，管理者再決定是否增加預算或改變服務承諾。

補充來源與圖像說明

本文補充以 Google AI for Developers 的 Gemini API rate limits 與 billing 官方文件為準，這些頁面的模型、tier、批次與費用規則可能隨平台更新，實際 active limits 應以自己的 AI Studio project 顯示為準。新增圖片是 Wikimedia Commons 的伺服器機房照片；它用來說明「配額背後是共享運算資源」的概念，不是 Google Gemini 或 Google Cloud 的機房照片，也不是本文的容量測試證據。Commons 檔案頁標示 CC BY-SA 授權，本文保留來源頁與 1280px 原圖連結。

• Google AI for Developers：Gemini API Rate limits
• Google AI for Developers：Gemini API Billing
• Wikimedia Commons：Wikimedia Servers-0001 44
• Wikimedia Commons：1280px JPEG
• Creative Commons：CC BY-SA 4.0

補充：429 不一定只是 RPM 超限

Google 官方文件指出，Gemini API 的限制通常要同時看 RPM、輸入 TPM 與 RPD，並可能受支出型限制影響；限制是以 project 為單位，不是單看 API key，且會依模型與使用層級變動。最新數值應直接查看 Google AI Developers rate limits，不要把文章中的固定表格當成永久配額。

排查 429 時，先記錄 project、模型、時間窗、輸入／輸出 token 與是否為 batch，再使用指數退避與請求併發控制。若是 TPM 而非 RPM，單純放慢請求未必足夠；若是帳務或 spend limit，則要回到配額與計費設定查原因。