請求控制與批次翻譯
理解 Token Bucket、burst request、LLM 批次、重試回退，以及低配額 API 的保守設定。
網頁請求設定位於 設定 → 翻譯 → 請求控制。影片字幕在 設定 → 影片字幕 中有一套獨立設定。
預設值
| 設定 | 預設 | 適用範圍 |
|---|---|---|
| 每秒平均請求數 | 8 | 此翻譯流程中的所有 provider 請求 |
| 最大突發請求數 | 60 | 此翻譯流程中的所有 provider 請求 |
| 每批最大字元數 | 1000 | 僅 LLM provider |
| 每批最大段落數 | 4 | 僅 LLM provider |
Token Bucket 如何運作
- 啟動時，桶內已有「最大突發請求數」個 token。
- 每啟動一個佇列請求消耗一個 token。
- 按「每秒平均請求數」持續補充，直到容量上限。
- 只要有 token，到期的請求即可啟動。
所以 burst 容量不是並行上限。預設容量 60 表示滿桶可立即放行最多 60 個排隊請求，並不保證網路中最多只有 60 個請求。
小數有效：0.25 每 4 秒補充一個 token，0.5 每 2 秒一個。
不要把 provider 的「每分鐘請求數」直接填入每秒欄位；先除以 60，並確認是否另有短時間 burst 限制。
選擇速率與容量
| API 配額 | 保守起始設定 |
|---|---|
| 每分鐘 60 次，未說明 burst | 速率 1、容量 1 |
| 每分鐘 15 次 | 速率 0.25、容量 1 |
| 每 10 秒 1 次 | 速率 0.1、容量 1 |
| 高吞吐本機模型 | 從 8 / 60 開始，再觀察延遲和記憶體 |
遇到 429 或配額錯誤時，先把容量設為 1，再降到 provider 的持續速率。LLM 批次能減少請求總數，但不會讓過大的初始 burst 變安全。
LLM 批次何時送出
批次翻譯只用於 LLM provider。來源語言、目標語言、provider 和上下文相同的項目可以成為同一批，遇到以下任一條件便送出：
- 再加入一項會超過字元上限；
- 段落/字幕段數達到上限；
- 目前字元數達到上限；
- 約
100ms 的收集視窗結束。
預設 1000 字元與 4 段兼顧節省請求和結構化輸出穩定性。更大批次可能降低開銷，但錯誤會影響更多段，也可能超過模型限制。
重試與單筆回退
LLM 必須為每個輸入回傳一個譯文。數量不正確時，Read Frog 最多重試三次，再將該批改為逐筆翻譯。一般網路錯誤由請求佇列的重試策略處理，與回傳數量不符是不同失敗。
進行中的重複內容會去重，成功結果也可從快取重用。統計頁會比較原始段落請求與實際批次請求。
實用設定
- 嚴格免費額度：速率依文件（常見
0.1–1）、容量1、每批600–1000字元、2–4段。 - 結構化輸出不穩定：降為
500–800字元與2段。 - 快速本機模型：從預設開始，逐步增加並觀察延遲、記憶體和回退。
網頁與字幕不共用 bucket。字幕重視即時性，網頁通常可以使用較保守的速率。