把几个请求放进同一批，能减少单独处理的开销，但请求长度不同：短请求结束以后，它占过的位置能否及时交给下一个请求，会影响资源利用。连续批处理的核心，是在生成迭代之间重新组织正在执行的请求。

一个两槽位的排程

假设A、B、C都已等待，只需1、3、2个抽象步骤，最多同时执行两个请求。静态批先处理A与B，要等B完成才开启C，因此需要3+2=5步。若A完成后就把C放进空位，三步可以完成全部请求。

总有效工作为1+3+2=6个槽位步。静态排程有2×5=10个槽位步，理想补位有2×3=6个槽位步。这个模型说明空位的来源，不能据此宣称某个实际引擎加速5/3倍。

复算排程，但别当作性能测试

代码已执行，验证静态5步、补位3步和总有效工作6。它省略预填充、不同序列长度的单步成本、内存分配、等待到达时间与调度开销，只用于解释机制。队列操作也为了简洁采用列表，不是生产调度器实现。

lengths = [1,3,2]
slots = 2
static_steps = sum(max(lengths[i:i+slots]) for i in range(0,len(lengths),slots))
queue = list(lengths)
active = []
steps = 0
while queue or active:
    while queue and len(active)<slots:
        active.append(queue.pop(0))
    active = [n-1 for n in active if n>1]
    steps += 1
assert static_steps == 5 and steps == 3
assert sum(lengths)==6
print('static / refill steps:',static_steps,steps)
print('useful slot steps:',sum(lengths))

vLLM官方项目将连续批处理列为功能。功能存在并不意味着所有负载都获益相同：若请求长度接近、排队不足、显存受限或每步代价增加，理想补位模型就不足以预测结果。

吞吐和单请求延迟一起看

提高吞吐可能同时让某个请求等待更久，所以基准要记录请求到达、首token、后续间隔、结束及失败情况。可以沿用TTFT与token间隔的客户端测量定义，再与服务端调度指标对照。

改变并发时，保持输入输出长度分布相近，报告完成请求数和测量窗口；不能把“开始处理”的数量当成完成吞吐。显存预算也要考虑在执行序列的KV状态，不能只依据槽位数量估算可承载请求。

连续批处理提供的是更灵活的调度机会。是否提高实际吞吐、改善尾部延迟，最终要由具体模型、硬件与负载验证。

English version

参考资料

Official documentation

补发说明：实际补发日期为北京时间2026年10月10日，文章日期保留原计划2026年10月10日19:00。代码为原创教学验证，没有运行真实模型性能测试。