LLM API 速率限制：安全處理 429、重試與並行
作者：Nicho
一個正式環境的 LLM 應用程式需要的不只是重試迴圈。它需要知道為什麼請求被拒絕、它能接納多少工作量，以及何時該停止嘗試。
實務上的起點很簡單：將錯誤分類、控管請求接納，並且只重試那些在操作期限內有合理機會恢復的失敗。在沒有這些控管的情況下增加重試次數，可能讓一次小小的流量尖峰演變成更長時間的服務中斷。
本指南涵蓋供應商中立的應用程式設計。確切的配額、錯誤碼、標頭與計費規則取決於你的供應商、模型、帳號與閘道。
了解你觸及了哪一種限制
這些控管回答的是不同的問題：
| 控管 | 衡量的內容 | 應用程式的回應 |
|---|---|---|
| 請求速率 | 在時間窗內被接納的請求數 | 調整起始步調並平滑突發流量 |
| token 速率 | token 用量或預估的 token 需求 | 保留 token 容量並限制請求大小 |
| 並行數 | 目前正在處理中的請求數 | 限制 worker 數量或使用 semaphore |
| 支出或餘額 | 財務可用性 | 檢查計費或預算控管 |
舉例來說，OpenAI 分別記錄了請求與 token 限制，其適用範圍可包含專案與共用模型系列。因此，一個新的 API Key 不一定代表新的容量。其文件也區分了暫時性的速率限制錯誤與硬性支出上限，即使兩者都使用 429。請閱讀錯誤內容，而不是只憑狀態碼做判斷。OpenAI 速率限制文件
HTTP 標準定義了 429，但並未規定服務如何辨識呼叫方或計算請求數。它也將 Retry-After 列為選用。不要假設每個相容於 OpenAI 的端點都有完全相同的節流行為。HTTP 429 規格
依較嚴格的限制來規劃流量規模
設想一個簡化的假設額度：每分鐘 60 個請求與每分鐘 120,000 個 token。如果每個請求消耗 4,000 個計入的 token，token 容量每分鐘只能支援 30 個這樣的請求：
120,000 tokens/minute ÷ 4,000 tokens/request = 30 requests/minute
這是規劃用的範例，不是供應商配額或精確的排程器。服務可能會保留預估的輸出、使用更短的執行時間窗，或對不同的 token 類別採用不同的計算方式。
請衡量你自己的請求大小分布。只看平均值會掩蓋大型文件上傳與長時間生成。請為這些離群值保留餘裕，而不是以數學上的最大值為目標。
請為起始與處理中的工作使用不同的控管。單靠並行上限並不能強制每分鐘的請求數：快速回應可能很快釋出位置，導致起始數過多。反過來說，請求速率限制器也無法阻止緩慢的串流持續累積並耗盡連線。
把接納控管放在重試之前
一個實用的請求路徑是：
Authenticated request → bounded queue → rate/token admission → worker → provider
請刻意設計佇列：
- 設定佇列長度上限與最長等待時間。
- 讓互動式請求的期限比背景工作更短。
- 以清楚的應用程式層回應拒絕或延後超量的工作。
- 在派送前移除已取消與已到期的工作。
- 在共用同一上游配額的多個副本之間共享准入狀態。
否則，增加應用程式伺服器可能讓流量倍增，而上游容量維持不變。對於混合工作負載，請保留部分容量給面向使用者的請求，讓文件匯入工作無法佔用所有名額。
這些是架構建議，並非保證特定閘道會提供佇列或可調整的並行控制。
使用單一有界重試原則
重試應該有負責人。在新增另一層迴圈前，先檢查 SDK 行為。在一種假設性設定中，三層應用程式嘗試包住三層 SDK 嘗試，可能讓一個邏輯操作產生九次上游嘗試。
實務上可行的原則是：
- 使用供應商文件記載的錯誤資訊來分類失敗。
- 對於需要變更憑證、權限、計費或請求內容的錯誤，立即停止。
- 只有在嘗試次數與時間預算都還有剩餘時，才重試符合條件的暫時性失敗。
- 遵循有效的伺服器重試指引；否則使用有上限的指數退避搭配抖動。
- 回傳最終失敗時附上足夠的脈絡，以便安全地調查。
Retry-After 可以指定延遲或日期。將適用的伺服器延遲視為下限，而不是可以縮短的建議。如果它超過該操作的剩餘期限，請延後工作或清楚失敗，而不是提早重試。HTTP Retry-After 語意
隨機化的等待可減少同步的重試浪潮。逾時與有界的嘗試次數可避免重試無限期佔用資源。AWS 的工程指引說明了為何重試可能放大過載，以及為何逾時無法證明某個操作沒有產生效果。AWS 關於逾時與重試的指引
不要盲目重播串流或代理動作
在顯示文字後停止的串流，與在工作開始前就被拒絕的請求並不相同。你的介面需要明確的不完整狀態。自動重新開始可能重複文字、消耗額外的 token，或產生不同的答案。
代理工作流程需要額外的界線：重試模型生成時，不得自動重播已完成的工具動作。記錄動作結果，並在動作服務支援時使用冪等機制。回應失敗並不構成把同一封電子郵件寄兩次或把同一筆訂單建立兩次的理由。
監控邏輯工作，而不只是 HTTP 成功
請分別追蹤這些項目：
- 邏輯操作與上游嘗試。
- 佇列等待與進行中的請求。
- 依文件記載的錯誤原因分類的拒絕次數。
- 每個完成操作的輸入/輸出用量與成本。
- 逾時、已取消的工作與不完整的串流。
使用請求識別碼與去識別化的中繼資料。預設避免記錄授權標頭或完整提示。如果重試讓每項完成任務的成本加倍，錯誤率下降就不算勝利。
將閘道控管與容量分開檢查
cheapaimodel 公開的定價與帳號資訊說明了每個 Key 的預算、到期、模型/IP 允許清單，以及帳號餘額耗盡時會出現的 403 回應。餘額不足並不是縮短退避時間就能解決的狀況。這些控管也不代表請求或 token 輸送量沒有限制。
在擴大串接規模之前，請查看目前的 cheapaimodel 文件，並確認你打算使用的路由的適用限制。讓准入控管與重試政策保持可設定，這樣變更時就不必改寫應用程式邏輯。
目標是可預期的完成工作：有界的等待、可解釋的失敗、受控的支出，以及有助於復原而非與之對抗的重試。