现代 AI 系统的“动态调度员”：Continuous Batching（连续批处理）深度解析

在 LLM（大语言模型）的生产环境中，推理成本最高的部分之一就是 GPU 的利用率。如果你观察一个简单的推理请求，你会发现 GPU 在生成每个 token 时，大部分时间都在等待内存传输（Memory Bound），而不是在进行计算。而传统的静态批处理（Static Batching）虽然能提高吞吐量，但却引入了一个致命的问题：木桶效应。

静态批处理的痛点：等待最慢的那个

在传统的静态批处理中，系统将多个请求打包成一个 batch 一起输入模型。然而，不同请求生成的 token 数量截然不同——有的请求只需要回答“是”，有的则需要写一篇长文。

在这种模式下，整个 batch 必须等到最长的那个序列生成完毕（或触碰停止符）后才能释放。这意味着短请求在完成之后，其占用的显存空间依然被锁定，GPU 必须在后续的迭代中为这些已经完成的请求填充“填充符”（Padding tokens）。这种浪费不仅降低了吞吐量，还增加了不必要的计算开销。

Continuous Batching：打破同步的枷锁

为了解决这个问题，vLLM 等现代推理框架引入了 Continuous Batching（连续批处理）。它的核心逻辑是将批处理的粒度从“请求级”细化到了“token 级”。

工作原理：动态插入与退出

Continuous Batching 不再等待整个 batch 完成，而是在每一个迭代步（Iteration step）结束后，立即检查是否有请求已完成。

1. 即时退出：一旦某个序列生成了 <EOS> 或达到了最大长度，它会立即从当前 batch 中被剔除并返回结果给用户。
2. 即时插入：在同一个迭代步中，系统会检查等待队列。如果有新请求进入且显存允许， it will be directly inserted into the current running batch.

这意味着 GPU 的计算单元始终在处理有效的 token 生成任务，而不需要为了对齐长度而浪费资源在 padding 上。

核心支撑：PagedAttention 与内存管理

Continuous Batching 之所以可行，依赖于对 KV Cache 的精细化管理。如果使用传统的连续内存分配，频繁地插入和删除请求会导致严重的内存碎片化（External Fragmentation）。

PagedAttention 借鉴了操作系统虚拟内存的分页机制：
- 它将 KV Cache 分割成固定大小的“页”（Pages）。
- 每个请求的 KV Cache 不再要求物理连续，而是通过一个映射表（Block Table）分布在不连续的物理块中。
- 当 Continuous Batching 需要插入新请求时，只需分配若干个空闲页即可，无需移动现有数据。

实际影响：吞吐量的量级提升

从工程实践来看，Continuous Batching 带来了显著的性能飞跃：
- 吞吐量提升：相比静态批处理，吞put 通常能提升 2-4 倍。
- 首字延迟（TTFT）降低：新请求无需等待前一个 batch 全部结束即可进入计算流。
- 资源利用率最大化：GPU 的算力被更均匀地分布在所有活跃请求上。

总结

如果说 KV Cache 是 AI 的“短期记忆”，那么 Continuous Batching 就是这个记忆系统的“高效调度员”。它通过打破同步等待的僵局，让 LLM 推理从一种“排队等候”的模式转变为一种“流水线作业”的模式。对于任何追求高并发、低延迟的 AI 应用而言，这已成为基础设施级的标准配置。