连续批处理与调度 · CS2680 学习手册

同一批里的请求不会同时结束

假设服务器一次能处理两条生成序列。请求 A 需要四个 decode 步，请求 B 只需要一个。静态批处理把它们一起启动，并等整批结束再加入 C。B 完成后，属于它的处理位置可能空着，而 C 还在队列等待。输出长度难以准确预知，因此这类空洞在长短混合请求中很常见。

连续批处理在迭代边界重新决定活跃请求集合。B 完成后，下一个边界就可以移走它并接纳 C，让资源持续处理有效工作。ORCA 论文讨论的 iteration-level scheduling 是理解这一机制的经典入口。具体系统如何混合 attention、prefill 与 decode 有实现差异，不能把“支持连续批处理”直接等同于某个固定加速倍数。

先用理想化时间线看机制

继续使用两个位置，三个请求同时到达，长度依次为 A=4、B=1、C=1，假设每次迭代固定一秒，忽略 prefill。静态批处理第一批 A、B 在第 4 秒结束，C 在第 5 秒结束；即便允许 B 在第 1 秒把答案发给用户，C 仍要等到第 4 秒才入批。

连续批处理让 A、B 在第 1 秒各生成一个 token，B 离开；C 在第 2 秒完成，A 在第 4 秒完成。总工作量没有改变，空闲位置却被利用起来。真实硬件中迭代时间会随批大小、上下文和内存访问变化，所以这个算例解释的是调度机会，不是 GPU 速度预测。上线结论必须来自真实负载测量。

调度器面对两份预算

一份是当前迭代可以处理的 token 预算，影响每次运行量与延迟；另一份是长期保留的 KV 内存预算，约束活跃序列总长度。一个新请求可能只有几百个输入 token，但它之后还会不断生成，缓存会继续增长。只看当前能否入批，忽略未来增长，容易在运行中触发抢占或重计算。

长 prefill 会占用较多计算，影响已经开始流式输出的请求。chunked prefill 把长输入切成多段，在调度中与 decode 交错。较小分块有机会改善输出间隔，但也可能延长新请求首 token 等待；较大分块可能更高效，却制造更长停顿。最佳设置依赖负载与硬件，要查看实际版本的调度规则后测量。

本机实验：观察空位置如何被填上

下面模拟只有 decode、固定迭代时间、所有请求同时到达的系统。保存为 batching_lab.py 后运行。static 允许完成的请求立刻返回，但不提前补位；continuous 则每一步都补位。

from collections import deque

jobs = [("A", 4), ("B", 1), ("C", 1)]
def simulate(continuous):
    waiting = deque(jobs)
    active, done, tick = [], {}, 0
    while waiting or active:
        if continuous or not active:
            while waiting and len(active) < 2:
                name, steps = waiting.popleft()
                active.append([name, steps])
        tick += 1
        remaining = []
        for name, steps in active:
            steps -= 1
            if steps == 0:
                done[name] = tick
            else:
                remaining.append([name, steps])
        active = remaining
    return done, tick

static, t_static = simulate(False)
continuous, t_cont = simulate(True)
print("static", static, "total", t_static)
print("continuous", continuous, "total", t_cont)
assert (static["C"], continuous["C"]) == (5, 2)
assert (t_static, t_cont) == (5, 4)

把 A 改成二十步，你会看到 C 的等待差距扩大。再把所有任务改成相同长度，观察连续补位的收益是否缩小。两种情况下都不要把步数换算为真实毫秒，因为模拟没有建模批大小对每步耗时的影响。