有人答完了，新请求为什么还在等？
V03/b0 · 先让 A 和 B 同时工作
| 槽位 | 轮 1 | 轮 2 | 轮 3 | 轮 4 | 轮 5 | 轮 6 |
|---|---|---|---|---|---|---|
| 槽 1 | A | A | … | … | … | … |
| 槽 2 | B | B | … | … | … | … |
先保持两个已接纳请求，观察 A 完成后的空位。固定步长调度示意，不是 GPU 加速倍数。
我们把系统缩成两个同时生成的位置。A 需要两步，B 需要四步，C 需要两步、已经在等待。这里先假设新请求的入场准备已经完成，目的是只看调度。第一轮 A 和 B 各向前走一步，第二轮再各走一步，于是 A 完成退出，而 B 还有两步。我们逐轮看谁在工作，不把等待的请求偷偷算作已经完成。
教师备课：指图与模拟问答
指图与推进 · 不朗读教师指向当前高亮对象，随后推进。
V03/b1 · 固定整批的空位
| 槽位 | 轮 1 | 轮 2 | 轮 3 | 轮 4 | 轮 5 | 轮 6 |
|---|---|---|---|---|---|---|
| 槽 1 | A | A | 空 | 空 | C | C |
| 槽 2 | B | B | B | B | 完成 | 完成 |
先保持两个已接纳请求，观察 A 完成后的空位。固定步长调度示意，不是 GPU 加速倍数。
如果规定这一批必须一起结束才能接下一批，A 空下来的位置就继续空着，直到 B 做完第四轮，C 才能开始。请求输出长短不同，这种等待可能很常见。图里的空格表达的是调度机会被浪费，不是说 GPU 上每个请求真的永远占一块独立物理座位。
教师备课：指图与模拟问答
指图与推进 · 不朗读教师指向当前高亮对象，随后推进。
V03/b2 · 下一轮让 C 加入
| 槽位 | 轮 1 | 轮 2 | 轮 3 | 轮 4 | 轮 5 | 轮 6 |
|---|---|---|---|---|---|---|
| 槽 1 | A | A | C | C | 完成 | 完成 |
| 槽 2 | B | B | B | B | 完成 | 完成 |
B 保持自己的四步生成；C 使用空下来的位置。固定步长调度示意，不是 GPU 加速倍数。
连续批处理在每个生成轮次重新安排活跃请求：A 完成以后，下一轮让 C 补进来，B 继续自己的生成。这样可以更及时使用可用容量，减少排队。不过这张图只有轮次，没有真实毫秒，不能据此宣布 GPU 快了多少倍；新请求的输入处理、缓存与延迟要求都仍要考虑。后训练也经常批量生成候选，所以这种服务组织还会影响训练成本。现在收回到最初那份 A/B 实验材料：模型为什么能读懂、为什么按要求回答、这次请求又怎样真正执行？
教师备课：指图与模拟问答
指图与推进 · 不朗读教师指向当前高亮对象，随后推进。
补充推导、边界与来源
设系统每轮最多容纳两个请求，A 需要 2 个生成步，B 需要 4 步，C 需要 2 步；C 已在等待，并假设入场所需准备已完成。固定整批完成再接新的策略下，A 在第 2 轮退出后，C 仍要等 B 到第 4 轮结束。连续批处理可以在第 3 轮让 C 进入，B 继续生成。
这是固定步长的调度示意，只展示空位利用和等待顺序。真实请求还有不同的 prefill 工作、缓存占用、延迟约束和到达时间；一轮的耗时也会随活跃批量变化。因此不能把示意中减少的轮数直接宣布为真实 GPU 加速倍数。调度器需要在吞吐、首 token 延迟、后续出字延迟和资源上限之间取舍。
连续批处理也会影响后训练中的候选生成，但这里不新增真实吞吐结论。关于 精确前缀共享、prefill/decode资源分离与KV传输 以及 候选生成与训练成本，可沿本页说明继续展开。
本页证据与条件
固定轮次调度教学构造；不是实测耗时