設定

語言

AI API Rate Limiting:運作原理與應對策略

T
TokenLab
·2026年2月26日·約 10 分鐘閱讀·更新 2026年7月14日·1951 次瀏覽
#速率限制#生產環境#錯誤處理#教學#最佳實踐
AI API Rate Limiting:運作原理與應對策略

來自 AI API 的 429 回應可能代表四種不同的情況:每分鐘請求數過多、每分鐘 Token 數過多、並發連線數過多,或是帳戶餘額不足。這四種情況都會回傳相同的狀態碼,因此解決方案取決於診斷出您實際觸發了哪種限制,而不是盲目地重試。本指南將剖析這些失敗模式,說明目前關於限制的證據有哪些(以及哪些沒有),並提供一套適用於生產環境的重試與備援模式。

重點摘要

  • 429 可能代表請求上限、Token 預算、並發限制或帳戶餘額不足。每一種情況都需要不同的解決方案,盲目重試只能解決其中一種。
  • 請在成功的回應中讀取速率限制標頭(headers),而不僅僅是在錯誤發生後才讀取,並在接近上限前進行流量調節(throttle)。
  • 客戶端的 Token 計算僅為估算值,而非保證。您的程式庫與供應商實際計算方式之間的 Tokenizer 差異,可能會使安全邊際比您想像的更窄。
  • 本文提供的證據中並未包含各模型與層級的確切 RPM/TPM 上限。請將您在其他地方看到的任何數字視為需要與您自己的帳戶儀表板核對的參考,而非固定常數。
  • 具備韌性的重試機制需要指數退避(exponential backoff)、抖動(jitter)、最大重試次數,並遵守 retry-after 標頭。切勿盲目重試非冪等(non-idempotent)的操作。

理解 AI API 速率限制:四種失敗模式

請求限制 (Request limits)

大多數供應商會計算每分鐘請求數 (RPM)。一旦超過,您會立即收到 429,通常回應主體為空。使用者快速翻頁瀏覽結果,或是未經調節的 cron job 執行,都是常見的觸發原因。

Token 限制 (Token limits)

這是團隊最容易低估的陷阱。供應商通常會將每分鐘 Token 數 (TPM) 與 RPM 分開執行,因此您可能會在遠低於請求上限的情況下觸發 429。長上下文模型使情況更為嚴重:根據 TokenLab 的即時定價證據(觀察於 2026-07-07),Claude Opus 4.8 和 GPT-5.5 皆支援約 1,000,000+ 個 Token 的上下文。將大型文件、完整程式碼庫或長對話歷史載入該視窗的呼叫,即使只是「一次」請求,也可能消耗掉您每分鐘 Token 預算的大部分。這是一種基於上下文視窗大小的容量規劃風險,而非單次呼叫的 Token 計算,因此請根據您自己的日誌驗證實際使用量,而非假設一個固定數字。

並發限制 (Concurrency limits)

供應商可能會容忍您的平均每分鐘流量,直到您同時開啟五十個串流為止。並發限制會限制同時進行中的請求或連線數。串流回應會讓連線保持開啟的時間更長,這比短暫的單次呼叫更快耗盡並發槽位。基於 Claude Sonnet 5 或 Kimi K2.7 Code 建構的程式設計代理,以及從 Gemini 3.5 Flash 串流的語音介面,都是常見的觸發原因,因為它們同時保持了許多長效連線。

配額或餘額耗盡 (Quota or balance exhaustion)

這在您的儀表板中看起來與速率限制相同:呼叫停止運作。但解決方法不同。如果您的帳戶預付點數用盡或達到硬性每日支出上限,API 回傳的錯誤會類似於速率限制。此時退避機制無效。您需要儲值餘額或提高支出門檻。

來源快照

資料點 來源 觀察時間
模型上下文視窗與每 Token 定價 TokenLab 即時模型/定價證據 2026-07-07
模型 SSOT 命名 (Claude Sonnet 5, GPT-5.5, Gemini 3.5 Flash 等) TokenLab 模型 SSOT 2026-07-07, 2026-07-14 到期
官方供應商 RPM/TPM 層級限制 本證據集未提供 未驗證,請檢查供應商帳戶儀表板
TokenLab 閘道標頭標準化行為 本證據集未提供 在依賴單一標頭架構前,請查閱 TokenLab API 文件

當前模型上下文視窗與定價 (TokenLab 即時證據)

這些數據直接來自 TokenLab 即時定價快照。它們並非 RPM 或 TPM 限制,而是顯示為何大型上下文模型上的單次呼叫可能會不成比例地消耗 Token 預算。

模型 供應商 上下文視窗 輸入 $/MTok 輸出 $/MTok 來源 觀察時間
Claude Sonnet 5 Anthropic 1,000,000 $2.00 $10.00 TokenLab 即時定價證據 2026-07-07
Claude Opus 4.8 Anthropic 1,000,000 $5.00 $25.00 TokenLab 即時定價證據 2026-07-07
Claude Fable 5 Anthropic 1,000,000 $10.00 $50.00 TokenLab 即時定價證據 2026-07-07
GPT-5.5 OpenAI 1,050,000 $5.00 $30.00 TokenLab 即時定價證據 2026-07-07
GPT-5.5 Batch/Flex OpenAI 1,050,000 $2.50 $15.00 TokenLab 即時定價證據 2026-07-07
Gemini 3.5 Flash Google 1,048,576 $1.50 $9.00 TokenLab 即時定價證據 2026-07-07
GLM-5.2 Z.ai 1,048,576 $0.93 $3.00 TokenLab 即時定價證據 2026-07-07
Kimi K2.7 Code Moonshot AI 262,144 $0.74 $3.50 TokenLab 即時定價證據 2026-07-07
DeepSeek V4 Pro DeepSeek 1,048,576 $0.44 $0.87 TokenLab 即時定價證據 2026-07-07
DeepSeek V4 Flash DeepSeek 1,048,576 $0.09 $0.18 TokenLab 即時定價證據 2026-07-07
Qwen3.7 Plus Alibaba 1,000,000 $0.32 $1.28 TokenLab 即時定價證據 2026-07-07
MiniMax M3 MiniMax 1,048,576 $0.30 $1.20 TokenLab 即時定價證據 2026-07-07

模型 SSOT 注意事項:這些名稱反映了 2026-07-07 觀察到的 TokenLab 模型 SSOT,於 2026-07-14 到期。命名與可用性變動頻繁。在將模型字串寫入生產程式碼之前,請確認它是否仍可在 TokenLab 模型目錄模型排行榜 中解析。

無需從零開始建構重試邏輯即可修復速率限制失敗

以上所有內容皆為診斷。補救工作(決定回退到哪個模型、追蹤每個使用者的並發數,以及即時掌握哪些模型系列運作正常)正是 TokenLab 路由層旨在處理的部分。與其手動在五個供應商之間建立回退矩陣,不如將請求指向 TokenLab,並讓閘道根據可用性與您的回退規則,從 當前模型目錄 中進行選擇。

一個誠實的提醒:TokenLab 位於多個上游供應商之前,每個上游都會回傳自己的標頭集、錯誤格式與重試語意。閘道是否將每個速率限制標頭完全標準化為一個一致的架構,或是將部分上游標頭原封不動地傳遞,在本文可用的證據中尚未確認。在編寫假設所有模型皆有統一架構的解析邏輯之前,請先驗證 TokenLab API 文件中的當前標頭行為。請以防禦性方式建構您的標頭解析器,檢查每個欄位是否存在,而非假設它一定存在。

讀取速率限制標頭

供應商會在回應標頭中回傳速率限制資訊,儘管確切名稱因供應商而異。常見模式如下:

x-ratelimit-limit-requests: 500
x-ratelimit-remaining-requests: 499
x-ratelimit-reset-requests: 12s
retry-after: 0

請在成功的回應中讀取這些資訊,而不僅僅是在 429 之後。保持剩餘預算的滾動計數,並在低於安全閾值(通常為 10-20% 的餘裕)時減速,儘管正確的數字取決於您的流量突發性,這並非本證據集所能指定的。

具備明確錯誤處理的重試邏輯

重試輔助函式需要處理的不僅僅是 429 的情況。它應該區分暫時性錯誤(429503、逾時)與客戶端錯誤(除 429 外的 4xx,這些錯誤重試也不會成功),並且在存在 retry-after 時應予以遵守。

async function callWithRetry(fn, maxRetries = 4) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    try {
      return await fn();
    } catch (err) {
      const status = err.status;

      // 除 429 外的客戶端錯誤重試也不會成功
      if (status && status >= 400 && status < 500 && status !== 429) {
        throw err;
      }

      // 無論錯誤類型為何,達到最大重試次數後放棄
      if (attempt === maxRetries) throw err;

      // 429:若存在 retry-after 則遵守,否則使用帶有抖動的退避機制
      if (status === 429) {
        const retryAfter = parseRetryAfterHeader(err);
        const delay = retryAfter
          ? retryAfter * 1000
          : Math.pow(2, attempt) * 1000 + Math.random() * 1000;
        await sleep(delay);
        continue;
      }

      // 503 或網路逾時:退避並重試,記錄以供觀察
      if (status === 503 || err.code === 'ETIMEDOUT' || err.code === 'ECONNRESET') {
        await sleep(Math.pow(2, attempt) * 1000 + Math.random() * 1000);
        continue;
      }

      // 未知的 5xx:使用退避重試,嚴格限制嘗試次數
      if (status && status >= 500) {
        await sleep(Math.pow(2, attempt) * 1000 + Math.random() * 1000);
        continue;
      }

      throw err;
    }
  }
}

切勿將非冪等操作(例如付款扣款或具有副作用的寫入)包裹在單純的重試迴圈中。在重試這些呼叫之前,請確認冪等性或使用冪等鍵(idempotency key)。

Token 估算準確度:為何本地計算會與供應商計算產生偏差

客戶端 Token 計算程式庫會近似模擬特定模型實際使用的 Tokenizer。tiktoken 與 OpenAI 的系列非常接近,但無法保證與 Anthropic、Google 或開放權重模型的 Tokenizer 完全吻合。差異會出現在特殊 Token、多位元組字元與系統提示詞格式化方面,並在長對話中累積。

減少偏差的實作步驟:

  • 讀取回應主體中回傳的實際 Token 使用量(大多數供應商包含提示詞與完成 Token 計數),並隨時間推移用其校準您的本地估算器。
  • 保持安全邊際,而非硬性邊界。如果供應商的 TPM 上限接近您的估算使用量,請延遲或拆分請求,而非在邊緣處發送。
  • 如果您的提示詞在呼叫間很大或重複,請參閱 TokenLab 關於 Token 化行為與提示詞拆分策略的報導,以取得在觸發上限前減少每請求 Token 數的具體方法。減少單次呼叫的 Token 數通常比協商更高的層級更便宜。

流量調節與模型回退

帶有抖動的指數退避。每次重試後等待時間加倍,並加入隨機抖動,以確保並發客戶端不會同步重試。

針對使用者或任務的流量調節。限制每個使用者的並發呼叫數(例如,3 個並發,每秒 5 個請求的突發量),這樣單一重度使用者就不會耗盡您全帳戶的限制並拖累其他人。

發送前的 Token 預算估算。在客戶端計算 Token,如果請求會導致超過您的追蹤 TPM 預算,請延遲或拆分它,而非發送後祈禱。

模型回退作為安全網。當主要模型回傳 429 時,路由至具有獨立限制且具備相當能力的替代模型。程式設計任務可以從 Claude Sonnet 5 回退至 DeepSeek V4 Pro 或 Kimi K2.7 Code。高流量、低成本的工作負載可以在 DeepSeek V4 Flash、Gemini 3.5 Flash 與 Qwen3.7 Plus 之間回退,這些模型皆位於當前模型目錄的低成本路由層中。

速率限制處理檢查清單

類別 檢查項目 立即行動 長期修復
請求限制 RPM 標頭值、突發頻率 調節客戶端請求,新增本地速率限制器 使用者層級、伺服器端佇列
Token 限制 各模型 TPM 預算、平均單次呼叫 Token、回應報告的使用量 預先計算 Token、拆分大型提示詞、在接近上限時延遲呼叫 具備 Token 預算的批次處理,將高流量工作路由至低成本模型
並發限制 最大同時串流或連線數 限制每個客戶端的並發請求,關閉閒置串流 連線池、交錯式串流啟動
配額 / 餘額 帳戶餘額、每日支出上限 儲值點數、調整支出門檻 低餘額警示、預付自動儲值

典型限制範圍:我們能與不能確認的內容

針對此主題的二次搜尋通常需要一份「典型」RPM/TPM 數字表。我們不會憑空捏造。已發布的各層級限制變動頻繁,因帳戶歷史與使用層級而異,且不屬於本文可用的證據範圍。

問題 狀態 驗證步驟
前沿模型的「典型」RPM 限制是多少? 本證據集未確認 直接檢查您的供應商帳戶儀表板或速率限制回應標頭
1M 上下文模型的「典型」TPM 限制是多少? 本證據集未確認 記錄一週流量中回應標頭的實際使用量,以建立您自己的基準
使用層級會改變這些數字嗎? 根據一般供應商行為推測,未在此基準測試 在您的供應商控制台中確認當前層級限制
TokenLab 的聚合限制是否與上游供應商限制完全吻合? 本證據集未確認 在進行容量規劃前,請查閱 TokenLab API 文件

限制

  • GPT-5.5、Claude Opus 4.8、Gemini 3.5 Flash 或此處提及的任何其他模型,皆無官方 RPM/TPM 數據。上述定價表中的每個數字皆為上下文視窗大小與每 Token 成本,而非速率限制。
  • TokenLab 的閘道是否在每個上游供應商之間完全統一了速率限制標頭,或是將部分原封不動地傳遞,在本文證據集中尚未確認。在您於文件中驗證當前閘道行為之前,請將標頭解析視為供應商特定的。
  • 本文中的模型名稱反映了 2026-07-07 觀察到的 TokenLab 模型 SSOT,於 2026-07-14 到期。在發布硬編碼模型字串的程式碼之前,請在 模型目錄 中確認當前可用性。
  • 本證據集未對 Token 估算準確度與供應商端計算進行基準測試。請根據回應報告的使用量校準您自己的估算器,而非信任固定的偏移量。

常見問題 (FAQ)

為什麼我的應用程式在請求數低於限制時仍收到 429 錯誤? 請先檢查每分鐘 Token (TPM) 預算。單一大型提示詞可能會耗盡 Token 配額,而請求數卻保持在低位。同時檢查並發:開啟的串流連線即使在 RPM 與 TPM 看起來都正常時,也可能阻塞新請求。

收到 429 時我應該立即重試嗎? 不應該。等待 retry-after 中指定的期間,如果該標頭不存在,請使用帶有抖動的指數退避。立即重試可能會導致「驚群效應」(thundering-herd effect)並延長您的鎖定視窗。

我如何知道我的本地 Token 計算是否會與供應商實際向我收費的金額相符? 無法完全準確得知。客戶端 Tokenizer 僅為近似值。讀取每個回應主體中回傳的 Token 使用量,並隨時間推移用其校準您的估算器,並保持安全邊際,而非在您的估算上限處發送請求。

TokenLab 是否在每個模型中公開一組統一的速率限制標頭? 本文提供的證據中未確認。不同的上游供應商回傳不同的標頭格式,TokenLab 應用了多少標準化程度,應在當前 API 文件中驗證,而非假設。

如何在不升級方案的情況下避免速率限制? 結合 Token 預算、本地並發限制與模型回退。在發送前估算 Token,拆分長提示詞,並在達到主要限制時路由至替代模型,例如從 Claude Sonnet 5 路由至 DeepSeek V4 Pro。

開始使用

速率限制是建構 AI API 的必然事實,但它們不必導致服務中斷。TokenLab 的閘道讓您可以存取 當前模型目錄即時定價與吞吐量數據,讓您可以繞過限制進行路由,而不是盲目猜測。如果您也在評估聚合器的權衡,OpenRouter 比較 更深入地涵蓋了回退行為與營運開銷。請在 tokenlab.sh 取得您的 API 金鑰,並一次建構好重試與回退邏輯,而非針對每個供應商重複進行。

來源

價格觀測於 2026-07-07

分享:

公開模型最近更新

用本文涉及的模型開始構建

比較價格、測試路由,把文章研究直接變成可執行的 API 呼叫。