Continuous Batching 为什么提高吞吐？

Serving load pattern examples。请求长度与到达时间不齐时，连续批处理通过动态重组减少空槽。

图：请求长度与到达时间不齐时，连续批处理通过动态重组减少空槽。来源：Serving load pattern examples，作者 vLLM Project contributors，许可 Apache-2.0。

考察意图

考察在线生成请求长度不一致时的 GPU 调度与服务权衡。

60–90 秒口述答案

静态批处理要等同一批所有序列结束，短请求完成后仍可能占据批次位置。Continuous Batching 在 token 迭代边界动态移除完成请求并加入新请求，让设备持续处理有效 token，降低空槽和等待，因此提高总体吞吐。它需要调度器管理每条序列的状态和 KV Cache。批次变大可能提高吞吐，却增加排队、每 token 延迟和尾延迟，所以还要按优先级、上下文和 SLO 做准入与调度。

深入解释

Prefill 与 Decode 的计算特征不同，调度器可能拆分大 Prefill，避免阻塞正在生成的请求。

工程权衡

吞吐优先、延迟优先和公平性策略不能同时最大化；长上下文和长输出请求应有独立配额。

完整复习答案

先拆开一次请求

画出每个迭代步移除已完成序列、插入新请求的调度过程，并比较静态批次的 padding 与尾部空槽。

用数量级定位瓶颈

吞吐收益以排队和公平性为代价；需要 token budget、抢占/换出、chunked prefill 与优先级策略。

静态批次中四个请求分别生成 10、40、80、100 token，短请求完成后槽位长期空闲。连续批处理每个 decoding step 移除完成请求并补入新请求，提高有效 token 占比；但若不断插入长 Prefill，也可能阻塞正在 Decode 的交互请求。

这个估算给出量级。代入项目参数时需要写明忽略项，并保持单位一致。

压测应回答什么

围绕“Continuous Batching 为什么提高吞吐”，压测写明模型、dtype、并行度、硬件、输入输出长度分布和到达方式，同时报告 TTFT、TPOT、端到端尾延迟、tokens/s 与显存水位。容量取满足 SLO 的安全点。

追问参考

吞吐提升但 P99 变差，调度器可能做了什么？

对“Continuous Batching 为什么提高吞吐”而言，吞吐提高而 P99 变差通常来自更大批次、更长等待窗口或 Prefill 抢占 Decode；查看 queue time、batch token 数和每阶段时间即可区分。

OOM 是权重、激活、临时 workspace 还是 KV Cache 导致？

回到“Continuous Batching 为什么提高吞吐”，需要区分：OOM 要按权重、KV、激活、workspace 与碎片拆账，并用输入/输出长度、并发和块水位复现，不能只归因于“模型太大”。

怎样判断方案已经达到上线条件？

“Continuous Batching 为什么提高吞吐”进入发布方案前，性能结论需绑定硬件、dtype、模型、并行度、长度分布、并发模型和 SLO；离线峰值不能直接当线上容量。

常见错误回答

把 Continuous Batching 当成简单增大 batch size，忽略请求在生成过程中动态进出。

连续追问

Prefill/Decode 如何共同调度？
Chunked Prefill 解决什么问题？
怎样控制尾延迟？

项目结合

准备并发阶梯压测，报告吞吐、TTFT、TPOT、P95/P99 与拒绝率，而不只给平均延迟。