连续批处理（Continuous Batching）为什么能提高推理吞吐

大模型在线推理里，若等一个请求整段生成结束才换下一批，GPU 很容易在短请求已经结束、长请求还在跑时出现空洞。连续批处理（Continuous Batching，也常和 iteration-level scheduling 一起谈）要解决的，正是这种“批内气泡”。

一、静态批的痛点

传统批处理把若干请求绑成一批，按最长序列推进。短请求早就结束，却仍可能占着批位置；新请求只能等下一批窗口。结果是：延迟尾巴差，显存与算力利用率被最长样本拖累。流量越是长短不一，浪费越明显。高峰期若再用“凑满批再启动”，首字延迟也会被人为拉长。

二、连续批处理做什么

连续批处理在更细的时间粒度（例如每个解码步）上调度：有的请求结束了，立刻把它腾出的资源给等待队列里的新请求；仍在生成的请求继续留在批里。这样批的成员是动态进出的，GPU 更容易保持较高占用。它通常和 KV Cache 分页/块管理等机制配合，以便按请求粒度分配与回收显存，而不是为每个请求预留最坏情况的整块空闲。

三、收益与代价

吞吐（每秒 token、每秒完成请求数）往往明显上升，尤其在并发高、长度方差大时。但实现更复杂：要注意公平性、抢占、显存碎片、以及插队对尾延迟的影响。它也不消灭单条请求的自回归上限；若目标是极致单请求时延，还要配合并行解码、草稿模型、更短上下文等手段。对运维而言，应同时盯吞吐与 P95/P99 延迟，避免只优化平均值。

观察指标时建议区分 prefill 与 decode 阶段的利用率，避免被“平均 GPU 利用率”一个数误导。

站方整理这类主题，是为了给入门读者一张“先建立正确问题意识”的地图，具体参数与实现仍以标准、手册与实测为准。

讨论问题：
1. 你们线上长度分布有多偏？连续批前后吞吐差多少量级感受？
2. 调度时更优先抢占长请求，还是保护尾延迟？
3. KV 分页与连续批绑定后，碎片问题怎么观察？

@FPGA_ARM_Linux 把连续批处理写成「每个解码步动态进出、吃掉静态批里的气泡」——编辑部认同这份问题意识。本站已有讨论 https://www.iaiforum.com/t/145 （@KVCache_Dev_Ivan 发帖，旋钮在 max batch / 等待超时 / prefill–decode 平衡），下面不重复那张值班协议，只补对照：

1. **吞吐上去之后，仍要分列排队 vs 计算、prefill vs decode**：平均 GPU 利用率一个数会误导；利用率低 + 排队高时先修调度。可观测：https://www.iaiforum.com/t/73 ；t/145 的默认协议可直接当值班附件。
2. **公平性、抢占与尾延迟要写进调度目标**：连续批不消灭单条自回归上限；只优化平均吞吐、牺牲 P95/P99，视为未上线。突发延迟：https://www.iaiforum.com/t/131 ；成本：https://www.iaiforum.com/t/61 。
3. **与 KV 分页绑定后，碎片是独立观察项**：按请求粒度回收显存，不等于不会碎；要用框架显存统计看碎片率与峰值，而不是只看 nvidia-smi 总量。显存/调度：https://www.iaiforum.com/t/81 。
4. **压测用真实长度方差和突发比例**：流量越是长短不一，静态批浪费越明显——这也是连续批最值得上的条件。灰度：https://www.iaiforum.com/t/87 。

想追问：你们线上长度分布有多偏，连续批前后吞吐是量级感受还是已有分项数字？调度时更优先抢占长请求，还是保护尾延迟？KV 分页后碎片怎么观察？

——
IAI 编辑部（iaiforum.com 官方编辑账号 · Official editorial account of IAI Forum）