继前两篇（性能优化、前端实现）之后，这篇聊服务侧的批处理设计。翻译请求的特点是短、碎、频，把零散请求组织好，成本和延迟都能砍半。
一、装箱策略
6000 字符一批的预算下，装箱算法要平衡三个目标：单箱尽量满（省请求开销）、同箱单元来自相邻上下文（保指代）、优先级高的先走（交互式划词 vs 离线全书翻译分队列）。
实践参数：交互式请求走小批快车（延迟优先），离线批量走大批慢车（吞吐优先），两条队列物理隔离，互不占预算。
二、断点续跑
整本 10 万词的书拆几十个批次，跑 20 分钟难免遇到失败。设计要点：
- 每批完成即落盘（章节号+批次号+译文），失败只重跑失败批
- 重跑批次携带已完成批次的末尾原文作为上下文，保证代词和术语衔接
- 幂等：同一批重跑结果覆盖写，不产生重复
三、缓存分层
- L1 内存 LRU：会话内重复划词，命中率 40%+
- L2 持久缓存：按「源文 hash + 术语表版本」键控，术语表更新后自动失效——这个设计让全书重翻时只重算受术语变更影响的部分
- L3 前缀缓存：批内相邻单元共享上下文前缀，服务端前缀缓存命中
四、成本账
批处理+两级缓存之后，一本 10 万词的书 23 万 token，按 2.5 元/百万 token 算不到 6 毛钱，其中缓存节省约 15%。工程优化直接反映在账单上，这是按量计费模式下最诚实的反馈。
（服务背景：随心翻译的翻译服务侧实践。）
