连续批处理

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 更可控(新请求不用等整批结束)。

检验攻克程度：针对「连续批处理」专属刷题排雷

做单选排雷题、推导选项机制，答错自动收录进专属错题本。