题目重点：从 batchstring(list<string>) 与一次一批的 GPU 约束出发，推导批量聚合、超时、队列、故障和吞吐/尾延迟取舍。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 主训练版每个入站请求含若干字符串，后端可合并多个请求的字符串为一批；返回时保持每个请求内部输入顺序。GPU 对一批执行期间独占。
- 设最大 batch 容量 B、最大等待 W、请求 deadline D、单批执行时间 T(b)，这些数值均为讲解参数而非公开原题数值；若模型按输入长度差异耗时，T(b) 应实测为长度/输出分布的函数。
- 先按固定批处理，不引入 continuous batching；支持一台 GPU 的核心合同，再把多 GPU/多模型作为另一个来源的追问。
解题路线
- 入口给每个子输入分配 `(request_id,index)`，校验大小并放入有界队列；batcher 收集最多 B 项，在队首最早截止或等待 W 到达时封批。保持索引映射以拆回各调用者，避免合批后结果错位。
- GPU worker 一次只取一批。对每批记入队、封批、开始执行、完成四个时间点；入口可在队列超预算时拒绝或降级，等待中的请求取消要从批映射里标记为不需回传。
- 设平均填充 b、平均处理 T(b)、每秒请求输入项 λ，则单 GPU 的稳定条件近似 `λ·T(b)/b < 1`；大 B 增加吞吐但增加凑批等待和可能的 padding。以队列等待、batch 填充率、GPU 利用率、TTFT、完成率和 p99 端到端时延判断配置。
- 进程崩溃时，若输入批在持久队列中有 ack 语义，可重放未确认批；输出可能重复，调用方需 idempotency key 或以 request_id 去重。返回流式 token 时，固定批的生命周期与取消规则需另定。
手动走一遍
训练例 B=4、W=20ms：t=0 到 2 项、t=8 到 1 项、t=14 到 1 项，则 t=14 满 4 项封批；另一轮只有 2 项时，t=20 封批。若 T(4)=80ms，满批理想服务能力 4/0.08=50 项/秒；若到达 60 项/秒，队列会持续增长，单靠调整 W 不能解决容量不足。
规模与取舍
batcher 对每个输入项做 O(1) 排队与映射，单批拆回 O(b)；内存取决于有界队列 Q 与在途批 B，为 O(Q+B)。实际服务能力受 T(b)、请求长度、输出 token 数与 GPU 内存限制约束，不能仅从输入字符串数量推出延迟。
易错点与追问
容易失分的边界
- 把同批不同请求的输出按完成顺序返回，破坏输入索引。
- 只报 GPU 计算时延，不计排队、等待凑批、网络和回传，无法解释 p99。
- 队列无限增长仍继续接单，最终 deadline 全部过期。
- 将 的 fixed batch 限制与 的 rate limit 讨论混为同一场面试的统一要求。
- 宣称 GPU 处理 10 与 100 个输入耗时一定一样；这是来源中的直觉性说法，具体取决于模型、序列长度、batch 形状与硬件。
继续深挖
- 当半数 GPU 不可用时，容量估算、排队和按层级拒绝怎样联动？
- 一个池中大模型一批占 8 GPU、小模型占 1 GPU，怎样避免大模型或小模型饥饿？
- 若输出 token 数差异很大，何时改用 continuous batching 或按长度分桶？
