连续批处理Continuous batching
每次推理迭代重新安排活跃请求，完成者退出，等待者按 token 与 KV 缓存预算加入。
- 核心约束
- 本轮 token 不超过预算，已调度请求获得所需的 KV 缓存空间。
- 适用问题
- 变长生成请求的在线推理服务。
- 边界与取舍
- 分块预填充与抢占可改善资源利用，也可能增加重算和排队；不自动保证严格公平。
常见操作#
按一次模型迭代组织请求；请求长度、token 预算和 KV cache 容量均参与调度。
| 操作 | 时间成本 | 条件与说明 |
|---|---|---|
| 在迭代边界调整批次 | 扫描 / 更新待运行请求与预算 | 已完成请求退出，新请求可加入；实际队列维护成本取决于调度实现。 |
| 执行本次模型计算 | 由本次 token 数、上下文长度、模型和硬件决定 | prefill 与 decode 计算形态不同，不能只按请求条数估算工作量。 |
| KV cache 不足时处理 | 拒绝继续调入、抢占或重算等策略 | 状态搬运和重算会增加成本；分块预填充是可组合的策略，不是连续批处理的同义词。 |
时间与空间#
- 时间成本
- 调度维护 + 每轮模型计算 + 缓存管理 / 抢占成本
- 空间成本
- 运行请求的 KV cache、请求状态与模型工作区
按迭代重新组批减少等待短请求结束后的空位，不保证任意负载下都有固定倍数吞吐提升；仍需测首 token 时延、每 token 时延和吞吐。
工程中的应用#
1 个案例 · 附源码vLLM V1 每轮分配 token 预算，先继续运行中的请求，再尝试接纳等待者；KV 块不足时抢占请求，把它放回等待队列。
附源码片段 · 调度与资源分配
基础原理参考资料
Yu et al. · Orca迭代级调度和动态组成生成批次的原始系统设计。
vLLM 0.8.5 · V1 schedulertoken 预算、运行 / 等待请求和缓存不足时的抢占路径。