AI API 速率限制將在規模化時節流你的行動應用程式

你的應用程式被 App Store 推薦。下載量暴增。5,000 個使用者在同一小時內打開應用程式。每個人都觸發了 AI 功能。你的後端向 OpenAI 發送 5,000 次 API 呼叫。

OpenAI 的 Tier 1 允許每分鐘 500 次請求。你剛剛超過了 10 倍。API 返回 HTTP 429（請求過多）。你的使用者看到錯誤訊息或永遠不會消失的載入動畫。

這不是假設情境。這是行動應用程式分發模式與為受控企業使用設計的 API 速率限制結合後的可預見結果。

各供應商的速率限制

OpenAI

你從 Tier 1（500 RPM）開始。達到 Tier 5 需要 $1,000 的累計消費和 30 天的帳號歷史。無法跳級。

Anthropic

Anthropic 需要手動升級層級。你提出申請，他們審核，他們決定。沒有自動擴展。

Google Gemini

Gemini 的免費層級極為有限（15 RPM）。隨用隨付更好，但仍有硬性上限。

行動應用程式如何觸及速率限制

同時使用量突增

行動應用程式具有突發性的使用模式。App Store 的推薦、一篇病毒式社群媒體貼文或產品發布可以推動數千名同時的首次使用者。不像網頁 SaaS 的使用量是逐步上升的，行動應用程式的下載量可以在一天內暴增 10-100 倍。

尖峰時段

行動使用量在當地時間晚上 7-9 點達到高峰。如果你的使用者集中在同一個時區，60-70% 的每日使用量壓縮在 3 小時的窗口內。你的每日平均值可能在限制範圍內，但尖峰時段會超過。

功能探索突增

當使用者第一次打開 AI 功能時，他們通常會快速發送 5-10 次請求來探索。這種「探索突增」意味著新使用者產生的請求量是穩定狀態使用者的 3-5 倍。在下載量突增期間，這會複合增長。

計算一下

1,000 MAU，每位使用者每天 3 次請求 = 每天 3,000 次請求 = 每小時約 125 次請求平均值。

但將 60% 的使用量壓縮到 3 個尖峰小時：3 小時內 1,800 次請求 = 每小時 600 次請求 = 10 RPM。在 Tier 1 下很舒適。

10,000 MAU 同樣的模式：尖峰時 100 RPM。在 Tier 1 下仍然沒問題。

50,000 MAU：尖峰時 500 RPM。在 Tier 1 限制的邊緣。任何突增都會超過。

現在加上一次 App Store 推薦，在一小時內帶來 5,000 次下載，每次下載產生 3 次探索請求：一小時內額外 15,000 次請求 = 在你的基線之上再增加 250 RPM。你至少需要 Tier 2，而這需要 $50 的先前消費和 7 天的帳號歷史。

觸及限制時會發生什麼

HTTP 429 回應

API 返回 429 狀態碼，附帶 retry-after 標頭。你的應用程式收不到 AI 回應。如果沒有適當的錯誤處理，使用者會看到當機、空白回應或無限載入狀態。

指數退避

標準重試策略是指數退避：等待 1 秒，重試，等待 2 秒，重試，等待 4 秒，重試。這在本已緩慢的 API 呼叫之上又增加了延遲。

對於等待 1-2 秒 AI 回應的使用者來說，增加 1-4 秒的退避重試意味著總共 3-6 秒。大多數使用者會放棄。

佇列擁塞

如果你為速率受限的請求實作伺服器端佇列，佇列會在突增期間增長。一個以 2 倍速率限制持續 10 分鐘的突增會產生一個需要 10 分鐘才能清除的積壓。佇列後面的使用者要等待 10 分鐘以上才能得到回應。

所有使用者的體驗都降級

速率限制是按組織計算的，不是按使用者計算的。當一次使用量突增觸發節流時，你應用程式的每個使用者都受到影響。已經使用該功能數個月的使用者與剛下載的新使用者收到相同的 429 錯誤。

緩解策略

請求節流

實作客戶端速率限制。限制每位使用者每分鐘的請求數。這能防止個別濫用，但無法解決同時使用者的問題。

伺服器端佇列

將所有 AI 請求透過你自己的伺服器路由。伺服器管理佇列並在速率限制內向 AI API 派發。這能平滑突增，但增加了延遲和伺服器基礎設施成本。

多個 API 金鑰

將請求分散到多個 API 金鑰或供應商帳號。這能倍增你的有效速率限制，但如果被偵測到會違反大多數供應商的服務條款。

模型備援鏈

如果你的主要供應商被速率限制，備援到次要供應商。OpenAI 被限制了？路由到 Gemini。這增加了複雜性，並需要維護多個整合。

快取

對於相同或類似的請求，快取回應。這減少了 API 呼叫，但只在使用者問類似問題時有效。獨特的使用者輸入（聊天互動的大多數情況）無法被快取。

結構性解決方案

速率限制之所以存在，是因為雲端供應商在所有客戶之間共享有限的 GPU 容量。平台上的使用者越多，每個人的限制就越緊。

裝置端推理沒有速率限制。「伺服器」就是使用者的手機。每個使用者都有自己的推理容量。1,000 個同時使用者意味著 1,000 個平行推理實例，各自獨立運行。

擴展模型根本上不同。雲端 API 共享一個池。裝置端給每個使用者自己的池。

為規模化做準備

如果你今天正在使用雲端 API 建構：

1. 了解你的層級。 檢查你目前的速率限制以及你離限制有多近。
2. 監控 429 率。 追蹤你的使用者觸及速率限制的頻率。如果超過 0.5%，你就有問題了。
3. 估算你的上限。 在什麼 MAU 下你的尖峰時段 RPM 會超過你的層級限制？那就是你的擴展懸崖。
4. 建構備援。 佇列、重試和優雅降級是生產應用程式的基本要求。
5. 規劃退出。 裝置端推理是長期解答。在你的領域資料上微調模型，使用像 Ertas 這樣的平台，匯出 GGUF，部署到使用者裝置。沒有速率限制、沒有共享基礎設施、沒有擴展懸崖。

Ship AI that runs on your users' devices.

Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.

View early bird pricingor join the waitlist →