AI API 的速率限制同時在多個維度上運作，理解每一個可以避免大量挫折。大多數供應商至少施加兩種限制：每分鐘請求數（RPM）和每分鐘 token 數（TPM）。RPM 限制你能發出多少 API 呼叫，不論大小 —— Anthropic 的免費層可能允許 5 RPM，而付費層提供 1,000+ RPM。TPM 限制每分鐘流通的 token 總量（輸入 + 輸出）。你可以各自獨立地觸及任一限制。一個常見的意外是：你遠未達到 RPM 限制，卻因為發送帶有大型上下文視窗的長提示而觸及了 TPM。一些供應商還施加每日請求數（RPD）和每日 token 數（TPD），建立一個在 UTC 午夜重置的每日上限。
供應商執行這些限制的機制遵循幾種標準模式。最常見的是令牌桶演算法（或其近親滑動視窗）。想像一個能容納 60 個 token 量的桶。它以每秒一個的速率回填。每次請求從桶中消耗與其 token 數成正比的量。如果桶空了，你的請求就會被以 HTTP 429（Too Many Requests）拒絕。回應標頭告訴你需要知道的資訊：x-ratelimit-limit-requests、x-ratelimit-remaining-requests、x-ratelimit-reset-requests 及其 token 對應欄位。聰明的客戶端程式碼會主動讀取這些標頭，而非等到被 429。Anthropic、OpenAI 和大多數其他供應商在每次回應中都包含這些標頭。
當你確實被限速時，標準做法是帶有抖動的指數退避。第一次 429 後等 1 秒，然後 2 秒，然後 4 秒，然後 8 秒 —— 並加入隨機分量（抖動），這樣如果你的 50 個平行工作器同時被 429，它們不會在完全相同的時刻重試並立即再次被 429。大多數供應商 SDK（Anthropic 的 Python SDK、OpenAI 的 SDK）自動處理基本的重試邏輯，但生產系統通常需要更精密的方法：帶有優先級的請求佇列、根據剩餘配額主動節流的自適應速率限制，以及在供應商明顯過載時快速失敗而非堆積更多重試的斷路器。
速率限制的策略影響決定了嚴肅應用的架構方式。如果你需要透過 Claude 處理 10 萬份文件，你不能直接發出 10 萬個並行 API 呼叫。你需要管理並發，可能運行 20-50 個平行請求並從佇列中供給它們。Anthropic 提供了一個 Batch API，具有獨立的、更高吞吐量的速率限制，且享有 50% 的成本折扣 —— 專為這種使用場景設計。OpenAI 也有類似的批次端點。對於需要保證容量的應用，企業層和承諾使用協議提供了與共享池隔離的專屬吞吐量。不言而喻的現實是，速率限制不僅是關於公平性 —— 它們是關於 GPU 分配。你發出的每個請求都需要 GPU 時間，而供應商只能服務與其 GPU 數量相當的並行請求。速率限制是保持供需平衡的機制。