Continuous Batching 是什么？它和攒一批再处理差在哪

先这样答

先看老办法的问题。静态批处理把若干请求凑成一批送进 GPU，想法是摊薄成本，但生成任务的长度事先不知道：同一批里有的请求几十个 token 就完成，有的要生成上千个。批必须整体进整体出，短任务做完只能陪着长任务空等，这段时间 GPU 明明有算力却接不了新请求，显存也被占着腾不出来。

连续批处理把调度粒度从「一批请求」细化到「一次生成步」。模型每生成一个 token 就是一次调度机会：完成的请求立刻退出、释放显存，排队的新请求立刻补进批里，批的组成在整个服务过程中动态变化。配合 PagedAttention 这类按小块分配的显存管理，请求进出的成本也低，随时换人不再昂贵。对用户的效果是排队时间短，长任务不再拖累短任务，吞吐和延迟同时改善。

一句话区分：攒批是批次级的静态调度，连续批处理是迭代级的动态调度，差别就在「什么时候允许换人」。它现在是 vLLM、TGI 这类推理服务框架的标配，回答时点出「调度粒度」这个词，就答到点子上了。

面试官会怎么追问

• 「为什么早期框架做不到按步调度？」 两个前提不满足：没有好的显存管理时，请求中途进出批次要搬运和整理内存，代价太高；调度器也缺少每步检查批内状态的机制。显存按小块分配之后，进出成本降下来，按步调度才划算。
• 「批越大越好吗？」 不是。批越大吞吐越高，但每个请求分到的算力变少，吐字速度下降，延迟和吞吐要按业务目标平衡。在线对话服务会控制批大小保吐字速度，离线批任务则放开批大小冲吞吐。
• 「它和流式输出什么关系？」 没有直接关系，但要配合才成立。流式输出要求每个 token 算完立刻送达，如果服务端被长任务堵住，流式就名存实亡；连续批处理保证服务器不被单个长请求拖住，多用户同时流式生成才撑得住。

回答的坑

• 把连续批处理说成「批切得更细」。核心是调度时机的变化：从整批完成才能换人，变成每一步都能换人，这是两个不同的调度模型。
• 只讲吞吐不讲延迟。短请求不再陪跑，首 token 和完成时间都提前，延迟收益是用户最先感知到的部分，漏掉这层答案少一半。