连续批处理原理详解：提升大模型推理吞吐与利用率
连续批处理是一种面向推理服务的调度优化技术。它让请求在生成步动态加入或退出批次，提高吞吐和硬件利用率，帮助理解连续批处理与静态批处理的区别。
什么是连续批处理？
连续批处理，也称 Continuous Batching，是一种用于机器学习推理的调度和推理优化技术。它的核心做法是：让推理服务在运行中的批次里动态接纳新请求，并让已经完成的请求及时退出，而不是等整个批次全部结束后再处理下一批请求。
在 LLM 在线推理中，不同用户请求的到达时间、上下文长度和生成长度往往并不一致。如果仍按固定批次统一进入、统一结束，短请求完成后可能留下空闲位置，硬件资源也更容易出现等待或利用不足。连续批处理正是为减少这类等待和空转而设计。
要点： 连续批处理不是新的模型结构，也不是训练技巧，而是推理服务运行时的请求调度与资源利用优化方式。
连续批处理与静态批处理有什么区别？
静态批处理通常会等待预定数量的请求积累完成后，再把这些请求组成一个批次统一处理。连续批处理则不要求批次拥有固定的生命周期：当旧请求完成时，新请求可以加入正在运行的批次，使批次在推理过程中持续变化。
| 对比维度 | 静态批处理 | 连续批处理 |
|---|---|---|
| 请求进入批次的时机 | 通常等待达到预定数量或条件后统一进入 | 可在运行批次中动态补入 |
| 批次生命周期 | 批次内请求通常一起开始，等待整批完成 | 请求可陆续进入，也可陆续退出 |
| 对不同生成长度的适应性 | 短请求完成后可能等待长请求，形成空闲位置 | 短请求完成后可释放位置给新请求 |
| 主要优化目标 | 提高一次推理中的批量处理效率 | 提高持续在线服务中的吞吐量和硬件利用率 |
可以把静态批处理理解为一辆班车：等乘客凑够一批后发车，到站后再安排下一车。连续批处理更像一条持续运行的传送带：有任务完成后释放位置，后续任务可以尽快补上。
连续批处理的工作流程
连续批处理的流程围绕运行批次的动态更新展开。在 LLM 生成场景中，它可以在每个生成步接纳和退出请求，这是理解其原理的关键。
请求进入等待队列
用户请求到达推理服务后，会先进入调度队列。调度器会根据当前运行批次的容量、资源状态和请求情况，决定哪些请求可以进入推理。
形成运行批次并开始生成
调度器把若干请求组成运行批次后，推理引擎开始执行生成。对于自回归生成任务，请求通常会逐步生成 token，而不是一次性完成全部输出。
每个生成步检查完成状态
在每个生成步之后，系统会检查哪些请求已经达到结束条件，例如生成完成或达到设定的输出边界。已经完成的请求会从运行批次中退出。
新请求补入释放的位置
当运行批次中出现可用位置时，等待队列中的新请求可以加入当前批次，而不必等待所有旧请求都完成。这样，批次可以持续保持较高的有效负载。
一个简化示例
假设同一批次中有 3 个请求，其中一个请求只需要很短输出，另外两个请求需要更长输出。在静态批处理中，短请求完成后，该位置可能一直空着，直到整批结束。连续批处理则可以在短请求退出后，把队列中的新请求补入，让推理服务继续利用这部分计算和内存资源。
连续批处理为什么能提升推理吞吐？
连续批处理提升吞吐量的直接原因，是减少批次等待和批次空洞。对于请求持续到达的在线服务，如果运行批次能不断补入新请求，硬件资源就不容易因为部分请求提前完成而闲置。
LLM 推理还与内存效率密切相关。生成过程需要维护上下文和缓存，不同请求长度差异会影响内存占用和访问模式。当推理瓶颈与内存 IO 限制相关时，更好的调度和内存利用方式会影响整体生成效率。
连续批处理通常不需要修改模型权重。它更接近服务端运行时优化：通过调整请求进入、退出和批次更新方式，提高硬件利用率、整体吞吐量以及生成过程中的资源使用效率。
| 优化点 | 连续批处理的作用 |
|---|---|
| 等待时间 | 减少新请求等待整批结束的时间 |
| 批次空洞 | 已完成请求退出后，新请求可以补入 |
| 硬件利用率 | 持续保持运行批次负载，减少空转 |
| LLM 推理吞吐量 | 在请求持续到达时提升单位时间处理能力 |
| 模型权重 | 不依赖修改模型权重，属于推理侧优化 |
连续批处理与 PagedAttention 是什么关系？
连续批处理和 PagedAttention 常被一起提及，因为它们都与现代推理引擎提升高吞吐量有关。但二者关注点不同，不应混为同一个概念。
连续批处理侧重请求调度：哪些请求进入运行批次、哪些请求完成退出、何时把新请求补入。它解决的是在线推理中批次动态变化的问题。
PagedAttention 更偏向内存管理机制，通常与注意力相关缓存的组织和利用有关。它关注的是在生成过程中如何更高效地管理内存资源。二者可以在同一推理系统中配合使用，但连续批处理本身并不等于 PagedAttention，也不意味着模型结构被改变。
要点： 连续批处理的核心是动态调度请求；PagedAttention 的核心更偏向内存管理。二者都服务于推理效率，但解决的问题层次不同。
连续批处理适合哪些应用场景？
连续批处理更适合请求持续到达、请求长度差异明显、生成过程较长的在线推理场景。它的价值通常体现在大模型服务端，而不是离线一次性小规模推理。
| 用户需求 | 解决方式 | 可能效果 |
|---|---|---|
| 在线聊天请求持续到达 | 在运行批次中动态补入新请求 | 减少用户请求等待整批结束 |
| 文本生成长度不一致 | 已完成请求退出后释放位置 | 降低短请求完成后的批次空闲 |
| 代码生成等输出长度波动较大 | 每个生成步检查请求完成状态 | 提升对长短请求混合负载的适应性 |
| 希望提升 GPU 或其他加速硬件利用率 | 让运行批次保持更稳定的有效负载 | 提高整体吞吐和资源利用率 |
| 大模型部署需要优化推理服务 | 在调度和内存利用层面优化 | 改善在线服务的处理能力 |
实际收益会受到模型规模、请求分布、上下文长度、生成长度、硬件资源和推理引擎实现方式影响。因此，连续批处理适合作为推理服务优化的重要方向，但不应被理解为在所有负载下都能带来固定幅度提升。
理解连续批处理时容易混淆的问题
连续批处理不等于简单增大 batch size
增大 batch size 关注的是一次批量处理更多请求，而连续批处理关注的是运行批次能否动态更新。即使批次大小相同，是否允许请求在生成过程中进入和退出，也会带来不同的调度行为。
连续批处理主要用于推理阶段
连续批处理面向的是机器学习推理，尤其常见于 LLM 在线推理服务。它不是训练优化方法，也不负责改变模型学习过程。
连续批处理不会修改模型权重
连续批处理属于调度和内存利用层面的优化，不需要修改模型权重。它改变的是请求如何被组织、进入批次和退出批次，而不是模型参数本身。
连续批处理不是决定性能的唯一因素
LLM 推理吞吐量还会受到模型规模、上下文长度、请求到达模式、硬件能力和推理引擎实现影响。连续批处理可以减少等待和资源空闲，但需要与合适的内存管理、调度策略和部署配置共同发挥作用。