连续批处理

Continuous Batching(迭代级调度,Orca 提出)= 不是等整批请求全部生成完再换下一批,而是在每个解码迭代(token 步)结束时就动态调整批成员: 已生成完(含最大长度截断)的请求移出批、等待中的新请求完成 Prefill 后插入批、批内各请求各自维护 KV 缓存进度。对比静态批 (request-level batching): 静态批把一批请求绑死到全部完成,最慢请求(如 40 个 token)拖住最快请求,快请求的 slot 在其余时间空转 → GPU 利用率低;连续批下每步 batch 都尽量装满,吞吐提升可达 2-3×(Orca 论文报告约 2.5×;混合长短请求、短请求占比高的负载提升最大——短请求完成快,slot 释放再插入,填充更密)。关键实现点: ① 新请求必须先做 Prefill(一次性算出整个 prompt 的 KV)才能加入 decode 迭代,prefill 与 decode 的混合调度决定了 TTFT;② 抢占 (preemption): 显存不足时,引擎可抢占部分请求的 decode slot(常见策略: 新 prefill 插队或按优先级驱逐),被抢占请求的 KV 缓存 swap 到 CPU 显存或直接丢弃重启,恢复时重新 prefill/续算;③ 批内序列长度参差 → 需要 padding 或分块注意力,避免 GPU 空算;④ 与 PagedAttention 天然配合: 分页 KV 让动态进出批的请求按需分配/释放块,无碎片。

所有主流推理引擎(vLLM/SGLang/TensorRT-LLM)的默认调度;在线对话/API 服务(请求到达无规律、长短混合)收益最大;面试高频“静态批 vs 连续批”“抢占与 swap”“为什么能提升 GPU 利用率”。

静态批的 GPU 空转来自两点——批内最慢请求阻塞整体(bubble),以及请求间到达间隙的批量等待。连续批把调度粒度从「请求」细化到「迭代」,每步都能有完成的请求腾位、有新请求补充,GPU 计算密度趋近 100%;数值上同等硬件吞吐提升约 2-3×,同时 TTFT 更可控(新请求不用等整批结束)。

静态批 vs 连续批的差异: 用两个具体请求(一个 10 token、一个 40 token)画时间线,说明静态批的空转与连续批的填充逻辑,以及吞吐为何可提升 2-3×。

迭代级调度机制: 每个解码迭代结束时引擎做什么(完成移出/新请求 prefill 后插入/批成员动态变化);为什么新请求必须先 prefill 才能 decode。

抢占 (preemption) 与 swap: 显存不足时抢占谁(新 prefill vs 旧 decode)、被抢占请求的 KV 放哪里(CPU swap / 丢弃重启),各自延迟代价是什么。

为什么短请求占比高的负载收益最大: 短请求完成快、slot 周转快;结合批内序列长度参差时的 padding/分块注意力代价说明取舍。

连续批如何与 PagedAttention、PD 分离配合: 分页 KV 使动态进出批无碎片;prefill/decode 分离后连续批分别在两阶段如何调度。