リクエスト制御とバッチ翻訳
Token Bucket、burst request、LLM バッチ、再試行、個別フォールバック、低クォータ API 向け設定を説明します。
ページ翻訳は 設定 → 翻訳 → リクエスト制御、動画字幕は 設定 → 動画字幕 に独立した設定があります。
既定値
| 設定 | 既定 | 対象 |
|---|---|---|
| 1 秒あたりの平均リクエスト | 8 | その翻訳フローの全 provider |
| 最大 burst リクエスト数 | 60 | その翻訳フローの全 provider |
| 1 バッチの最大文字数 | 1000 | LLM のみ |
| 1 バッチの最大段落数 | 4 | LLM のみ |
Token Bucket
バケットは容量分の token が入った状態で始まり、1 リクエストの開始ごとに 1 token を消費します。平均レートに従って継続的に補充され、token があれば期限を迎えたキューを開始できます。
したがって burst 容量は同時実行数の上限ではありません。既定の 60 は、満杯なら最大 60 件をすぐに解放できるという意味です。
小数も有効です。0.25 は 4 秒に 1 token、0.5 は 2 秒に 1 token を補充します。
「毎分リクエスト数」をそのまま毎秒欄に入れないでください。60 で割り、短時間 burst の制限も確認します。
保守的な設定例
| API 制限 | 開始値 |
|---|---|
| 60 回/分、burst の記載なし | rate 1、capacity 1 |
| 15 回/分 | rate 0.25、capacity 1 |
| 10 秒に 1 回 | rate 0.1、capacity 1 |
| 高速なローカルモデル | 8 / 60 から遅延とメモリを観測 |
429 が出る場合は、まず容量を 1 にし、rate を持続制限まで下げます。バッチは LLM の総リクエスト数を減らしますが、大きすぎる初期 burst を安全にはしません。
LLM バッチの送信条件
バッチは LLM provider だけで使用されます。同じ provider、翻訳元/先、コンテキストの項目がまとまり、次のいずれかで送信されます。
- 次の項目で文字数上限を超える
- 段落/字幕数が上限に達する
- 現在の文字数が上限に達する
- 約
100ms の収集時間が終わる
既定の 1000 文字/4 段落は、節約と構造化出力の安定性のバランスです。大きなバッチは効率的ですが、失敗の影響範囲やモデル上限超過の可能性も増えます。
再試行と個別フォールバック
LLM は各入力に 1 件の訳文を返す必要があります。件数が一致しない場合、Read Frog は最大 3 回再試行し、その後は個別翻訳へフォールバックします。通常のネットワーク失敗はリクエストキューの再試行ポリシーで処理されます。
処理中の重複はまとめられ、成功結果はキャッシュできます。統計ページで元の段落数と実際のバッチ数を比較できます。
厳しい無料枠では capacity 1、rate 0.1–1、600–1000 文字、2–4 段落から始めます。構造化出力が不安定なら 500–800 文字/2 段落に下げます。ローカルモデルでも大きな burst はサーバーを過負荷にできます。