# 连续批处理：谁先结束，就先腾出位置

中文合成旁白 · 1280×720 · 20 fps · 112.04 秒

**00:00:00,000 · 变长请求**
连续批处理优化的是多个请求怎么一起执行。它不改变每个请求内部逐步生成的计算依赖。

**00:00:08,068 · 变长请求**
假设 A、B、C 分别要生成二轮、五轮和三轮。它们同时开始，却不会同时结束。

**00:00:16,226 · 固定批次的空等**
如果等整批结束才换下一批，A 在第二轮结束后留下空位置，C 在第三轮结束后也留下空位置。

**00:00:24,357 · 固定批次的空等**
现在 D 已在第二轮结束时完成输入处理，可以生成。但固定批次仍要等 B，第六轮才让 D 进来。

**00:00:33,022 · 逐轮重排**
连续批处理每轮都检查请求状态。谁结束，就回收它的执行资源，再选择下一轮的请求。

**00:00:41,451 · 逐轮重排**
所以第三轮，D 就能进入 A 腾出的逻辑位置，同时 B 和 C 继续生成。画中的位置不是固定计算核心。

**00:00:50,420 · 逐轮重排**
一轮结束后，再判定停止、移除完成请求、安排下一轮。批次的成员可以不断变化。

**00:00:58,477 · 加入请求的条件**
不过，D 能加入是有条件的。例子里它已经完成 Prefill；如果提示词还没处理，需要先为输入计算分配预算。

**00:01:08,031 · 加入请求的条件**
一段长提示词不能当作一个 Decode token 塞进来。调度器要检查计算预算、KV 空间和优先级。

**00:01:16,510 · 加入请求的条件**
长输入可以配合分块 Prefill，动态请求可以配合分页 KV。这些方法能组合，但不是同一个优化。

**00:01:25,456 · 吞吐与延迟**
更充分的批处理可能提高总吞吐，也可能拉长每轮时间，让单个请求的输出间隔变长。

**00:01:33,149 · 吞吐与延迟**
所以要一起看吞吐、首 token 等待时间，以及后续 token 的间隔。低并发时，可填补的空位也更少。

**00:01:42,101 · 吞吐与延迟**
连续批处理的关键，是在请求之间及时换人。它没有让同一个请求提前知道未来要生成的 token。

## 教学假设
A/B/C 分别需 2/5/3 轮 Decode。D 在第 2 轮结束时已完成 Prefill；各轮等时，仅演示三个逻辑批次位置，并非固定 GPU 核心。图中 D 的后续两轮只作示意。

## 原始资料
- [Orca：迭代级调度论文](https://www.usenix.org/conference/osdi22/presentation/yu)