速率限制

Triggerfish 包含滑動視窗速率限制器，防止達到 LLM 供應商 API 限制。它透明地包裝任何供應商——代理迴圈不需要知道速率限制。當容量耗盡時，呼叫會自動延遲直到視窗滑動足夠以釋放容量。

運作方式

速率限制器使用滑動視窗（預設 60 秒）追蹤兩個指標：

• 每分鐘 token 數（TPM） —— 視窗內消耗的總 token 數（提示 + 完成）
• 每分鐘請求數（RPM） —— 視窗內的總 API 呼叫數

在每次 LLM 呼叫之前，限制器檢查兩個限制的可用容量。如果任一耗盡，呼叫會等待直到最舊的條目滑出視窗並釋放足夠的容量。每次呼叫完成後，記錄實際的 token 使用量。

串流和非串流呼叫都從相同的預算消耗。對於串流呼叫，token 使用量在串流完成時記錄。

OpenAI 層級限制

速率限制器內建 OpenAI 已發布的層級限制預設值：

層級	GPT-4o TPM	GPT-4o RPM	o1 TPM	o1 RPM
Free	30,000	500	30,000	500
Tier 1	30,000	500	30,000	500
Tier 2	450,000	5,000	100,000	1,000
Tier 3	800,000	5,000	100,000	1,000
Tier 4	2,000,000	10,000	200,000	10,000
Tier 5	30,000,000	10,000	200,000	10,000

這些是基於 OpenAI 已發布限制的預設值。您的實際限制取決於您的 OpenAI 帳戶層級和使用歷史。其他供應商（Anthropic、Google）在伺服器端管理自己的速率限制——限制器對 OpenAI 最有用，因為客戶端節流可以防止 429 錯誤。 :::

配置

使用包裝供應商時，速率限制是自動的。預設行為不需要使用者配置。限制器偵測您的供應商並套用適當的限制。

進階使用者可以透過 triggerfish.yaml 中的供應商配置自訂限制：

models:
  providers:
    openai:
      model: gpt-4o
      rate_limit:
        tpm: 450000 # 每分鐘 token 數
        rpm: 5000 # 每分鐘請求數
        window_ms: 60000 # 視窗大小（預設 60 秒）

速率限制保護您免受 429 錯誤和意外帳單。它與故障轉移鏈協同運作——如果速率限制被達到且限制器無法等待（逾時），故障轉移啟動並嘗試下一個供應商。 :::

監控使用量

速率限制器公開目前使用量的即時快照：

{tokensUsed, requestsUsed, tpmLimit, rpmLimit, windowMs}

CLI 和 Tide Pool 中的上下文進度條顯示上下文使用量。速率限制狀態在除錯日誌中可見：

[DEBUG] [provider] Rate limiter: 12,450/30,000 TPM, 8/500 RPM (window: 60s)

當限制器延遲呼叫時，它會記錄等待時間：

[INFO] [provider] Rate limited: waiting 4.2s for TPM capacity

通道速率限制

除了 LLM 供應商速率限制外，Triggerfish 還強制每通道的訊息速率限制以防止淹沒訊息平台。每個通道適配器追蹤出站訊息頻率，並在接近限制時延遲傳送。

這防止了：

• 因過量訊息導致的平台 API 封禁
• 失控代理迴圈造成的意外垃圾訊息
• Webhook 觸發的訊息風暴

通道速率限制由通道路由器透明地執行。如果代理產生輸出的速度超過通道允許的速度，訊息會排隊並以最大允許速率傳遞。

相關

• LLM 供應商和故障轉移 —— 故障轉移鏈與速率限制的整合
• 配置 —— 完整的 triggerfish.yaml 架構