Continuous / Dynamic Batching

一句话定位：批处理决定 GPU 能否被”喂满”。静态 Batching 因木桶效应大量空转，Continuous Batching 把调度粒度从”整个请求”细化到”每次迭代”，是 LLM 服务吞吐提升的关键一招。

1. 静态 Batching 的木桶效应

• 做法：攒够 N 个请求组成一个 batch，一起跑到全部完成才返回、才开始下一批。
• 问题：同批请求的输出长度差异极大（有的生成 10 token，有的 1000 token）。batch 必须等最长的那个跑完，先完成的请求所占的计算槽位一直空转 → GPU 大量空闲。
• 这就是典型木桶效应，与 Spark Stage 必须等最慢 Task（长尾）完成、拖慢整个 Stage 完全同构（见 1.1 / 1.2）。

2. Continuous Batching（迭代级调度）

核心变化：调度粒度从”请求级”变为**”迭代级”（iteration-level）**。

• 每生成一个 token（一次 decode 迭代）后重新审视 batch：
  • 完成即出队：已生成结束的请求立即返回并释放其槽位与 KV Cache block；
  • 新请求即插入：等待队列中的新请求立刻填补空出的槽位，无需等整批结束。
• 效果：GPU 始终保持接近满载的有效 batch，吞吐显著提升，同时排队延迟下降。
• 依赖：需要能灵活分配/释放 KV Cache 的显存管理，因此与 PagedAttention（3.5）天生互补；也常被称为 In-flight Batching（TensorRT-LLM 的叫法，见 3.8）。

3. Dynamic Batching（服务层聚合）

注意与 Continuous Batching 区分——层次不同：

• Dynamic Batching 在服务层：把短时间内到达的多个独立请求，按时间窗口（如最多等 5ms）或队列深度聚合成一个 batch 再送进模型。
• 目的是提高 GPU 批量效率，代价是引入排队等待延迟（窗口越大吞吐越好、延迟越高，是典型的吞吐/延迟权衡）。
• Triton Inference Server 的 Dynamic Batching 即为此类，适用于所有模型；而 Continuous Batching 针对自回归生成的迭代特性，两者可叠加使用。

4. 可迁移类比

Continuous Batching ≈ 流式微批处理（来一条处理一条、持续吞吐）；Dynamic Batching ≈ 攒批处理（按窗口攒够再算）。这正是流计算里”逐条 vs 微批”的经典取舍。

参考：NVIDIA Triton Inference Server 文档 Dynamic Batching 章节