请求控制与批量翻译
理解 Token Bucket、burst request、LLM 批处理、重试回退，以及低配额 API 的保守配置。
网页翻译的请求设置位于 设置 → 翻译 → 请求控制。视频字幕在 设置 → 视频字幕 中有一套完全独立的速率和批处理设置。
默认值
| 设置 | 默认值 | 适用范围 |
|---|---|---|
| 每秒平均请求数 | 8 | 当前翻译流程中的所有 provider 请求 |
| 最大突发请求数 | 60 | 当前翻译流程中的所有 provider 请求 |
| 每批最大字符数 | 1000 | 仅 LLM provider |
| 每批最大段落数 | 4 | 仅 LLM provider |
Token Bucket 如何工作
Read Frog 使用持续补充的 Token Bucket：
- 启动时桶中已有“最大突发请求数”个 token。
- 每启动一个排队请求消耗一个 token。
- 按“每秒平均请求数”持续补充 token，直到容量上限。
- 只要有 token，到期的排队请求就可以启动。
因此，burst 容量不是并发上限。默认容量 60 表示一个满桶可以立即放行最多 60 个排队请求；它并不保证网络中最多只有 60 个请求同时进行。
支持小数速率：0.25 表示每 4 秒补充一个 token，0.5 表示每 2 秒一个。
不要把 provider 的“每分钟请求数”直接填进每秒字段。应先除以 60，并确认 provider 是否还有短时 burst 限制。
如何选择速率与容量
| API 配额示例 | 保守起始配置 |
|---|---|
| 每分钟 60 次，未说明 burst | 速率 1，容量 1 |
| 每分钟 15 次 | 速率 0.25，容量 1 |
| 每 10 秒 1 次 | 速率 0.1，容量 1 |
| 高吞吐本地模型 | 从 8 / 60 开始，再观察延迟和内存 |
遇到 HTTP 429 或配额错误时，先把容量设为 1，再把速率降低到持续配额。LLM 批处理能减少请求总数，但不会让过大的初始 burst 变安全。
LLM 批处理何时触发
批量翻译只用于被识别为 LLM 的 provider。普通翻译服务仍按自己的正常请求方式运行。
来源语言、目标语言、provider 和上下文相同的项目可以进入同一批。满足任一条件就会发送：
- 再加入一项会超过字符上限；
- 段落/字幕段数量达到上限；
- 当前字符数达到上限；
- 大约
100ms 的短暂收集窗口结束。
默认 1000 字符、4 段兼顾请求节省与结构化输出稳定性。批次越大，请求开销越低，但错误会影响更多段落，也更容易超过模型或网关限制。
重试、结构化结果与单条回退
LLM 批次必须为每个输入返回一个译文。如果返回数量不正确，Read Frog 最多重试三次，然后把该批项目回退为逐条翻译。普通网络错误由请求队列的重试策略处理，与“返回条数不匹配”不是同一种失败。
进行中的重复内容会去重，成功结果也可从缓存复用。统计页面会比较原始段落请求数和实际批量请求数，便于确认批处理是否有效。
常用配置
严格免费额度
- 速率：provider 文档中的持续速率，常见为
0.1–1； - burst 容量：
1； - 每批字符：
600–1000； - 每批段落：
2–4。
结构化输出不稳定的模型
保持速率合规，把批次降低到 500–800 字符、2 段。请求会增加，但一一对应的输出通常更可靠。
快速本地模型
先使用默认值，再逐步增加批次，同时观察响应时间、内存和回退次数。没有远程配额并不代表大 burst 不会压垮本地服务。
网页与字幕不共享 bucket。字幕更重视实时性，网页翻译通常可以使用更保守的速率。