GLM-5.3 推理全链路（十八）：重叠调度——GPU 前向还在跑时，调度器在 CPU 上做什么

这一篇补的是前十七篇里最难看见的一段

前十七篇一直在追一个问题的两个侧面：一条 GLM-5.3 请求在 GPU 上要经过哪些算子、跨哪些卡、搬多少字节。无论是第九篇的混批、第十篇的 CPU 侧路径，还是第十六篇的 launch 账本，叙述的都默认了一个前提——调度器是「同步」的：调度器先构造这一批请求，把它交给模型跑完，拿到结果，再去处理结果、选择下一批。

真实的推理服务不是这样跑的。decode 阶段一条 GLM-5.3 请求每步只算 78 层里的一行 token，单个 rank 上的 GPU 前向只有毫秒量级；而调度器在这一步要做的事情却不少：处理上一批的采样结果与停止条件、写回 KV 引用计数、组装下一批的 request pool 下标与 KV 槽位、检查前缀树命中、发布路由用的负载信息，还要在 Python 里把一堆小张量搬到 GPU 上。这些 CPU 工作如果和 GPU 前向串行执行，GPU 会在每一个 decode step 之后空闲一大段，TPOT 就从「GPU 前向时间」膨胀成「GPU 前向时间 + 调度开销」。

上图是 CUDA 视角下的「同步执行」：主机线程把拷贝与内核逐条压进 GPU 队列，然后在需要结果时同步；GPU 执行完毕、主机拷贝回来之后，才能继续准备下一条。推理服务里的同步调度就是这个形状——只不过「下一条」是下一批请求的全套输入准备，「结果」是采样出的 token。让两条流各自推进、只在必要处用事件相交，就是重叠调度的全部出发点。

SGLang 与 vLLM 都为此设计了重叠调度（overlap scheduling），但两者的做法、代码形态和代价完全不同：SGLang 是调度器在同一线程里「先发后收」，用一个等待队列把 CPU 处理推迟到下一个前向发射之后；vLLM 是把 EngineCore 拆成 step 循环与 worker 进程，并在 worker 侧引入了「上一批采样 token 直接在 GPU 内回填」的异步输入路径。更麻烦的是，重叠引入了一整套新的依赖：结果回读必须落在独立的流上、KV 池的写入必须给前向的读取让路（WAR 屏障）、上一批还没处理的结果要被下一批的调度逻辑「猜」出来（序列长度、结构化输出状态、投机草稿树）。

这一篇就把这段难看见的时钟拆开：先讲清楚哪几段 CPU 工作可以被藏进 GPU 前向里，再分别沿 SGLang 的 event_loop_overlap 与 vLLM 的 step / batch queue / async scheduling 三条路径逐行读过去，最后给出一张「什么情况下重叠会失效」的清单。GLM-5.3 在这两套框架里的部署形态（DP Attention + 专家并行 + MTP + DSA 稀疏注意力）会在每一处决定重叠能不能开、开了之后哪些地方必须显式同步，所以本篇不是脱离模型的框架通论，每一个例子都落回 GLM-5.3 的实际配置。

前十七篇的账本都默认「GPU 跑完这一批，才调度下一批」，本篇补上「GPU 跑这一批的同时，CPU 已经在准备下一批」这一段，账本才算按服务的真实时钟记账。

先分清：哪些 CPU 工作能藏，哪些藏不掉

在进入代码之前，得先有一个分类框架。把一个 decode step 拆成 CPU 侧与 GPU 侧的工作，可以分成四类：

|---|---|---|

第四类正是重叠调度最棘手的地方。同步调度时，调度器在构造下一批前已经拿到了本批采样结果，input token 明明白白；重叠调度时，下一批必须在 GPU 还没跑完之前就发射出去，input token 还不存在。SGLang 和 vLLM 对这一个问题的回答截然不同：

• SGLang 的 overlap 主要解决「第 2、3 类工作藏进 GPU 前向」，第 4 类问题则通过 FutureMap 的「延迟解析」处理：prepare_for_decode 在调度阶段只把 seq_lens 加一（按一步一个 token 预测），并把本批的 req_pool_indices 交给 FutureMap；真正的采样 token 由 worker 在 forward_stream 上「发布」到一张按 req_pool_idx 索引的缓冲里，等下一次 run_batch 进入前向时，再在 GPU 上把这些行 gather 进 input_ids——CPU 全程不碰 token 值。
• vLLM 的 step 循环本身只是「发射后阻塞等 future」，重叠度有限；真正激进的是 --async-scheduling：worker 在输入准备时直接读上一批停留在 GPU 上的 prev_sampled_token_ids，用 scatter 把它写进当前 input_ids 的对应行，全程不经过 CPU 回读。

两者的共同点是：重叠不是「让 CPU 多干一点活」，而是改变了数据依赖的形状——原来「本批输出 → 下一批输入」是 CPU 侧的内存依赖，现在变成了 GPU 内部或跨流的张量依赖。

SGLang：同一线程里的先发后收

SGLang 的调度器是一个单线程 Python 循环，跑在 schedule_stream 上（启动时专门挑一个与 forward_stream 不同的流，避免两个流在同一硬件队列上互相挤占）。dispatch_event_loop 根据配置在两个循环之间选一个：

1
def event_loop_normal(self):
2
    while True:
3
        self.ingest_requests()
4
        plan = self.get_next_batch_to_run(
5
            running_batch=self.running_batch, last_batch=self.last_batch
6
        )
7
        self.running_batch = plan.running_batch
8
        batch = plan.batch_to_run
9
        if batch:
10
            result = self.run_batch(batch)
11
            self.process_batch_result(batch, result)
12
        else:
13
            self.on_idle()
14
        self.last_batch = batch

event_loop_normal 就是开头说的同步形态：run_batch 发射前向后，会在同一个调用里把本批结果 D2H 拷回 CPU（batch_result.copy_to_cpu(...)），因此 run_batch 返回时 GPU 前向已经跑完；随后 process_batch_result 才在 CPU 上处理这份结果。整个 decode step 里，GPU 前向期间调度器线程没有别的事可做，只能等在同步拷贝上；下一批的调度必须等这一批处理完才能开始。

event_loop_overlap 则把「收」推迟了一个循环：

1
def event_loop_overlap(self):
2
    self.result_queue = deque()
3

4
    def pop_and_process():
5
        tmp_batch, tmp_result = self.result_queue.popleft()
6
        self.process_batch_result(tmp_batch, tmp_result)
7

8
    while True:
9
        self.ingest_requests()
10
        plan = self.get_next_batch_to_run(
11
            running_batch=self.running_batch, last_batch=self.last_batch
12
        )
13
        self.running_batch = plan.running_batch
14
        batch = plan.batch_to_run
15
        disable_overlap_for_batch = self.is_disable_overlap_for_batch(
16
            batch, last_batch=self.last_batch
17
        )
18

19
        if disable_overlap_for_batch:
20
            pop_and_process()
21

22
        if batch:
23
            batch_result = self.run_batch(batch)
24
            self._apply_war_barrier()
25
            self.result_queue.append((batch.copy(), batch_result))
26
        else:
27
            batch_result = None
28
            self._sched_idled = True
29

30
        if self.last_batch:
31
            if not disable_overlap_for_batch:
32
                pop_and_process()
33
        elif batch is None:
34
            self.on_idle()
35

36
        if self.is_generation:
37
            self.launch_batch_sample_if_needed(batch_result, batch)
38

39
        self.last_batch = batch

把一次循环按时间顺序排开，就是：

1
时间 →
2

3
CPU(schedule_stream):  | 调度第 N 批 | ─── 处理第 N-1 批 ─── | 调度第 N+1 批 ...
4
                          ^run_batch(N)发射                  ^process_batch_result(N-1)
5
GPU(forward_stream):                        |==== 前向 N ====|   |==== 前向 N+1 ====|
6
CPU(copy_stream):                                            |D2H N| ...

关键点有三个。

第一，处理第 N-1 批发生在第 N 批已经发射之后。process_batch_result(N-1) 里的所有 Python 工作——更新请求状态、决定哪条请求被停止、把前缀树节点插入、统计计数、打包输出发回 tokenizer 进程——都在 GPU 跑第 N 批前向的这段时间里完成。这就是重叠的全部收益来源：调度器的「第 2、3 类工作」被塞进了 GPU 的阴影里。

但「塞进去」不等于「完全免费」。process_batch_result 内部读结果时会触发 copy_done 的同步等待，而 copy_done 绑在 copy_stream 的 D2H 上；如果 D2H 本身还没排到，调度器会先卡在这段等待上，随后才继续做 Python 处理。也就是说，process_batch_result 的耗时由「等 D2H」与「真处理」两段组成：前者被前向 N 覆盖，后者才是真正由 CPU 花掉的时间。判断重叠是否有效，本质上是判断前者是否足够小——这取决于 copy_stream 能否与 forward_stream 真正并发，而不是取决于 Python 代码本身快不快。

第二，等待队列 result_queue 的深度结构上最多为 2。循环回到调度点时，队列里恰好保留着「刚发射、还没处理」的那一批，深度为 1；run_batch 发射第 N 批之后、pop_and_process 处理第 N-1 批之前，深度短暂为 2。这个上界说明了一件事：如果 process_batch_result 比一次 GPU 前向还慢，队列并不会越积越多，而是下一批的发射被整体推迟——CPU 处理挤占了本应留给前向的时间，GPU 出现空档。因此「队列深度」不是判断瓶颈的好指标，真正要看的是两次 launch 的间隔与调度线程自己的耗时，后面会讲怎么观测。

第三，batch.copy() 被放进了队列。ScheduleBatch 是会被复用的对象：下一轮 get_next_batch_to_run 会在这同一个对象上合并新请求、重写 input_ids、推进 seq_lens、替换 spec_info，而队列里的结果要等到那一轮之后才处理。所以必须在发射时做一次快照，把「结果所属的批」与「正在被改写的批」分开。这个拷贝本身也是 CPU 工作量的一部分，属于重叠要藏进 GPU 阴影里的开销。

还有一层容易被忽略的保护：run_batch 里包着一个 _forward_isolation(batch, overlap=True)。它在发射前对 ScheduleBatch 的字段做快照，把 sampling_info 换成只读副本（避免一次前向里多次 init_new 重复累加惩罚），前向结束后再恢复字段；同时在 overlap 模式下把批对象与快照「钉」进 batch_record_buf 两个迭代，防止 CUDA 缓存的复用器过早回收前向仍在读的张量。换句话说，重叠调度不仅要让 CPU 与 GPU 并行，还要让同一个 Python 对象在三个时间层里同时有效：GPU 正在读的那一份、CPU 正在改写的那一份、以及等待被处理的快照。这是重叠实现复杂度的主要来源。

run_batch 在重叠模式下做了什么不同的事

run_batch 在 enable_overlap 分支里，主要工作都在 forward_stream 上完成：

1
with self.forward_stream_ctx:
2
    self.forward_stream.wait_stream(self.schedule_stream)
3
    self.future_map.resolve_seq_lens_cpu(batch)
4
    ...
5
    resolve_forward_inputs(batch, self.future_map)
6
    with self._forward_isolation(batch, overlap=True):
7
        future_indices = batch.req_pool_indices
8
        batch_result = self.model_worker.forward_batch_generation(batch)
9
        if batch.spec_algorithm.is_none():
10
            self.future_map.publish(future_indices, batch.seq_lens + 1)
11
        batch_result.copy_done = self.device_module.Event()
12
        self._copy_result_to_cpu(batch_result, batch)

这里 forward_stream.wait_stream(self.schedule_stream) 是第一步，含义是「GPU 前向开始之前，先把 schedule_stream 上已经排队的 H2D 拷贝与调度阶段的小内核跑完」。因为 resolve_forward_inputs 里会往输入缓冲里写待解析的 input_ids（来自 FutureMap），这些写入是排在 schedule_stream 上的（run_batch 本身所在的线程），而前向在 forward_stream 上，两者之间没有隐式顺序，所以需要一个显式的 wait_stream 把 schedule_stream 的队列「接进」forward_stream。

publish 在非投机路径下只做一件事：在 forward_stream 上登记一个「这一批的输出已经可用」的事件，并把本批的 req_pool_indices 存起来。它并不消费结果，只登记「结果在哪里、何时可用」。这是 SGLang overlap 里最巧妙的一处：调度器并不需要在 CPU 上拿到采样结果才能发射下一批；它只需要知道「结果的地址」与「结果可用的时机」。

_copy_result_to_cpu 负责把结果拷回 CPU，它被安排在 copy_stream 上：

1
def _copy_result_to_cpu(self, batch_result, batch):
2
    copy_fn = partial(
3
        batch_result.copy_to_cpu,
4
        return_logprob=batch.return_logprob,
5
        return_hidden_states=batch.return_hidden_states,
6
    )
7
    self.copy_stream.wait_stream(self.forward_stream)
8
    with self.copy_stream_ctx:
9
        copy_fn()

SGLang 的三条流正是这张图的实例：schedule_stream 上是调度器的 H2D 与输入 gather，forward_stream 上是 78 层前向，copy_stream 上是本批结果的 D2H。图中重叠区就是「调度第 N+1 批的同时前向第 N 批」。

copy_stream 是一个「叶子流」，只等待 forward_stream，forward_stream 从不会等它。它的存在意义是：D2H 拷贝（把本批采样出的 token id、logprob 拷回 pinned 内存）可以和下一批前向同时在 GPU 上排队。如果 D2H 直接排在 forward_stream 上，它会排在本批前向之后、下一批前向之前，process_batch_result(N-1) 就要等前向 N 跑完才能读到结果，等于把等待从一个 GPU 前向的跨度拉长到半个循环；如果 D2H 排在 schedule_stream 上并且同步执行，则又阻塞了调度器线程本身。独立拷贝流让这三方各自独立推进。

_copy_result_to_cpu 里还有一条 confidential computing（CC）分支：在 NVIDIA CC 模式下，per-step 的 D2H 回读会被强制同步，直接阻塞调度器线程 → 重叠失效。SGLang 的处理方式是把它交给一个后台线程 AsyncD2HCopyWorker 去等。这一条代码注释值得单独看，因为它证明了一件事：重叠调度依赖 GPU 侧「D2H 可以不阻塞提交线程」这一硬件行为；一旦底层 API 变成同步的，上层就必须自己造一条线程来模拟异步。

1
def process_batch_result(self, batch, result):
2
    if self._deferred_responses:
3
        self.stream_released_deferred_outputs()
4
    # 轨迹上报在 overlap 模式下正好落在下一批前向的窗口里
5
    flush_trace_batch(batch.reqs)
6
    snapshot = self.publish_load_snapshot(force=batch.forward_mode.is_extend())
7
    self.load_publisher.publish_load_stat(
8
        self.load_inquirer.get_loads,
9
        force=batch.forward_mode.is_extend(),
10
        snapshot=snapshot,
11
    )
12
    if batch.forward_mode.is_decode():
13
        self.batch_result_processor.process_batch_result_decode(batch, result)
14
    elif batch.forward_mode.is_extend():
15
        ...
16
    # 前缀树的待写回备份在下一步调度前提交
17
    self.tree_cache.flush_pending_backups()
18
    self._record_step_counters(batch, result)
19
    self.metrics_reporter.log_batch_result_stats(batch, result)

四个需要显式同步的点

重叠把依赖从「线程内顺序」变成了「跨流顺序」，所以每一处原来看起来天然成立的顺序，现在都要显式声明。SGLang 的代码里能辨认出四个：

1
def _apply_war_barrier(self):
2
    runner = self.model_worker.last_shared_read_runner
3
    ev = runner.shared_read_done_event
4
    runner.shared_read_done_event = None
5
    if ev is not None and not envs.SGLANG_FORCE_COARSE_WAR_BARRIER.get():
6
        self.schedule_stream.wait_event(ev)
7
    else:
8
        self.schedule_stream.wait_stream(self.forward_stream)

1
if self.is_generation:
2
    self.launch_batch_sample_if_needed(batch_result, batch)

1
if self.needs_cpu_seq_lens:
2
    ...
3
    batch.seq_lens_cpu = batch.seq_lens.cpu()

1
if not batch.spec_algorithm.is_none():
2
    batch.spec_info = batch_result.next_draft_input
3
    batch.spec_info.future_dsa_topk_indices_available = (
4
        batch.spec_info.dsa_topk_indices is not None
5
    )
6
    batch.spec_info.future_indices = future_indices

1
if self.disaggregation_mode == DisaggregationMode.PREFILL:
2
    # 本批要早发的「缓存前缀」可能正被一次尚未完成的 HiCache load 写入，
3
    # 不能把它当成命中。
4
    load_pending = batch.hicache_consumer_index >= 0
5
    for req in batch.reqs:
6
        self.maybe_send_cached_prefix_chunk(req, allow_send=not load_pending)

为什么 PP 走向了另一条路

SGLang 在 PP 场景直接关闭重叠（_pipeline_parallel_overlap_disable），代码里也留着 # FIXME: pp is not compatible with overlap。这不是随手加的限制，而是两种并行的目标冲突：流水并行要的是多个微批同时在飞，每个 stage 都在处理不同的 batch，靠「stage 之间错开」填满流水线；SGLang 的 overlap 则假设一次只有一批在前向，靠「这一批的结果处理」去填下一批的窗口。把两者硬叠在一起，ScheduleBatch 就不再只对应一次前向：它可能在 stage 0、stage 3、stage 7 各有一份在飞的结果，result_queue 里存的 batch_result 也不再是「上一批」，而是「上一批在某个 stage 上的代理张量」。SGLang 的调度器没有为这种多 stage 的结果排队建模，所以选择关掉重叠、由 PP 自己的微批流水来提供并行度。

vLLM 的选择相反：它没有沿用「一批一结果」的队列，而是把 batch_queue 做成可容纳 max_concurrent_batches 个 future 的环形队列。PP=4 时队列深度就是 4，四个 stage 各自的 future 都在队列里；调度器在队列未满时继续调度，队列满时才阻塞取最早的一个。于是「重叠」在 vLLM 里不是「先发后收」的时序技巧，而是队列深度本身：只要队列里有 future 在飞，GPU 就有活干；调度器本地要做的，只是保证每个 future 都携带正确的 SchedulerOutput，以便结果回来时能对上号。

这也解释了为什么 vLLM 的 async scheduling 在 PP 上受限：async 输入回填需要「上一批采样 token 直接留在 GPU 上」，而 PP 的中间 stage 根本不采样。代码里为此有一条跨 stage 的采样 token 广播：最后一个 stage 在 sample_tokens 里调用 _pp_broadcast_prev_sampled_token_ids，把形状为 [num_reqs, 1] 的采样结果用 torch.distributed.broadcast 发给所有 stage；中间 stage 收到后填进自己的 input_batch.prev_sampled_token_ids，再走与单机相同的 scatter 回填路径。广播异步发起（async_op=True），结果在 _prepare_input_ids 开头才 wait()，于是「广播在飞」的时间同样被这一 stage 的前向盖住。它只对 [num_reqs, 1] 成立——纯 decode 每请求正好一个 token；分块预填里采样的是 dummy token，代码直接跳过广播。即便如此，V1 Model Runner 的注释仍把 async + PP>1 + V1 标成「不完整支持」，max_concurrent_batches 因此只按 PP 度返回，不额外多留一批。

vLLM：step 循环、batch queue 与异步调度

先看进程边界，因为这决定了 vLLM 能在哪里重叠。调度器在 EngineCore 进程里，模型前向在 worker 进程里；execute_model(non_block=True) 返回的是一个跨进程的 future，而不是本进程内可以随手读的张量。因此 vLLM 的「等待」天然带着一次 IPC 往返：调度器把 SchedulerOutput 发过去，worker 跑完再把 ModelRunnerOutput 发回来。想把这段等待藏起来，要么把多批 future 排成队列（batch queue），要么把输入 token 的回填也搬到 worker 里（async scheduling）。

vLLM 的调度器与 SGLang 的形态不同。vLLM V1 把 EngineCore 拆成一个单独的进程（EngineCoreProc），调度器在 EngineCore 主线程里跑，worker 在子进程里跑模型。主线程与 worker 之间通过 multiprocessing 的 future 与消息队列通信，模型前向的返回值不是张量，而是一个 Future[ModelRunnerOutput]。

1
def step(self):
2
    if not self.scheduler.has_requests():
3
        return {}, False
4
    scheduler_output = self.scheduler.schedule(self._should_throttle_prefills())
5
    future = self.model_executor.execute_model(scheduler_output, non_block=True)
6
    grammar_output = self.scheduler.get_grammar_bitmask(scheduler_output)
7
    with self.capture_iteration_details(...):
8
        model_output = future.result()
9
        if model_output is None:
10
            model_output = self.model_executor.sample_tokens(grammar_output)
11
    self._process_aborts_queue()
12
    engine_core_outputs = self.scheduler.update_from_output(scheduler_output, model_output)
13
    ...

1
def step_with_batch_queue(self):
2
    batch_queue = self.batch_queue
3
    ...
4
    if self.scheduler.has_requests():
5
        scheduler_output = self.scheduler.schedule(...)
6
        exec_future = self.model_executor.execute_model(scheduler_output, non_block=True)
7
        ...
8
        batch_queue.appendleft((future, scheduler_output, exec_future))
9
        if len(batch_queue) < self.batch_queue_size and (
10
            model_executed or self.scheduler.has_requests()
11
        ):
12
            return None, model_executed   # 队列没满，先不消费
13
    # 队列满了或者没有新请求可调度：阻塞等最早的一批
14
    future, scheduler_output, exec_model_fut = batch_queue.pop()
15
    model_output = future.result()
16
    ...
17
    engine_core_outputs = self.scheduler.update_from_output(scheduler_output, model_output)

1
if not scheduler_output.pending_structured_output_tokens:
2
    grammar_output = self.scheduler.get_grammar_bitmask(scheduler_output)
3
    future = self.model_executor.sample_tokens(grammar_output, non_block=True)
4
else:
5
    deferred_scheduler_output = scheduler_output

1
if self.input_batch.prev_sampled_token_ids is None:
2
    self.input_ids.copy_to_gpu(total_num_scheduled_tokens)
3
    return
4
...
5
if common_indices_match and max_flattened_index == (num_common_tokens - 1):
6
    # 批次未变化、无重排：一次切片拷贝即可
7
    self.input_ids.gpu[:num_common_tokens].copy_(
8
        self.input_batch.prev_sampled_token_ids[:num_common_tokens, 0],
9
        non_blocking=True,
10
    )
11
    return
12
# 批次有变化：用 scatter 把各请求的采样 token 写到新位置
13
self.input_ids.gpu.scatter_(
14
    dim=0,
15
    index=sampled_tokens_index_tensor,
16
    src=self.input_batch.prev_sampled_token_ids[prev_common_req_indices_tensor, 0],
17
)

1
self.input_batch.prev_req_id_to_index = {
2
    req_id: i
3
    for i, req_id in enumerate(self.input_batch.req_ids)
4
    if i not in invalid_req_indices_set
5
}

1
self.async_output_copy_stream = torch.cuda.Stream()
2
self.prepare_inputs_event = torch.cuda.Event(blocking=True)
3
...
4
self.valid_sampled_token_count_copy_stream = torch.cuda.Stream()
5
self.valid_sampled_token_count_event = torch.Event()

1
# 1. scheduler_output 必须包含本步调度的原始 token 数，worker 靠它决定输入。
2
# 2. 调度完成后立即推进 num_computed_tokens，
3
#    让同一请求在下一步还能马上被调度。
4
# 3. 如果投机草稿被拒，num_computed_tokens 与 num_output_placeholders
5
#    都会在 update_from_output 里按被拒数量回退。
6
for req_id, num_scheduled_token in num_scheduled_tokens.items():
7
    request = self.requests[req_id]
8
    request.num_computed_tokens += num_scheduled_token
9
    request.num_in_flight_tokens += num_scheduled_token

1
if (
2
    request.num_output_placeholders > 0
3
    # (num_computed_tokens + 1) - (num_output_placeholders - 1)
4
    and request.num_computed_tokens + 2 - request.num_output_placeholders
5
    >= request.num_prompt_tokens + request.max_tokens
6
):
7
    req_index += 1
8
    continue

1
num_scheduled_spec_tokens = (
2
    num_new_tokens
3
    + request.num_computed_tokens
4
    - request.num_tokens
5
    - request.num_output_placeholders
6
)

1
if not output_is_stale:
2
    if request.num_computed_tokens > 0:
3
        request.num_computed_tokens -= num_rejected
4
    if request.num_output_placeholders > 0:
5
        request.num_output_placeholders -= num_rejected

1
step 1: num_computed_tokens = 0,     spec_tokens = [],      prev_num_draft_len = 0
2
step 2: num_computed_tokens = 100,   spec_tokens = [a, b],  prev_num_draft_len = 0
3
step 3: num_computed_tokens = 102,   spec_tokens = [c, d],  prev_num_draft_len = 2

重叠会失效的场景：一张清单

重叠调度不是「开了就快」。下面这些场景下，重叠会明显打折或直接关闭，而且其中大部分在 GLM-5.3 的部署配置里真会发生：

连续两批都是 prefill。 SGLang 的 is_disable_overlap_for_batch 有一条判据是「连续两个 prefill 批则关闭重叠」。原因是 TTFT：两条 prefill 批叠加时，第二条 prefill 的发射会插到第一条的结果处理之前，导致第一条的 TTFT 反而变长。这条判据由环境变量 SGLANG_DISABLE_CONSECUTIVE_PREFILL_OVERLAP 控制，源码里的默认值是 False，即默认允许连续 prefill 重叠；只有显式打开这个开关，相邻 chunk 才会退回同步。对应到 GLM-5.3：第三篇讲的 1M 上下文分块预填里，每个 chunk 都是一次 prefill；是否在 chunk 之间保留重叠，取决于这台机器上 TTFT 与吞吐的权衡。混批（第九篇）中 8K 请求并进 decode 批，则不会触发这条判据。

DP Attention 下各 rank 的重叠决策必须一致。 注释里写得很清楚：

1
if self.require_mlp_sync:
2
    is_extend = lambda b: b and b.is_extend_in_batch
3
else:
4
    is_extend = lambda b: b and b.forward_mode.is_extend()

DP attention 下各 rank 处理的是不同的请求子集，但一次前向要在 MLP 后做 all_gather 同步 hidden state（第十七篇的 DP Attention 部分讲过），如果某个 rank 关闭了重叠、另一个没关，两边的发射节奏会错位，DP group 的同步点就会死锁。所以代码要求所有 rank 用全局同步过的 is_extend_in_batch 做判断，而不是各自的本地 forward_mode。这是一个典型例子：重叠逻辑的正确性依赖于全局一致性，而不是单 rank 局部的最优。

结构化输出与投机解码叠加。 is_disable_overlap_for_batch 的第二条：

1
need_grammar_sync = (
2
    batch
3
    and not batch.spec_algorithm.is_none()
4
    and batch.grammar_needs_sync()
5
    and batch.forward_mode.is_decode()
6
    and len(self.result_queue) > 0
7
)

对支持 grammar-overlap 的算法，FSM 在 verify() 内部通过 grammar barrier 推进（_advance_pending_grammar），不需要关闭重叠。但不支持 grammar-overlap 的算法（如 host 侧草稿）在这里必须关闭重叠，做一次同步。GLM-5.3 的 MTP 是 GPU 侧草稿，且在 21 层 DSA 层上跑，是否支持 grammar-overlap 由 supports_grammar_overlap() 决定；这个开关一旦为假，每一步 decode 都会命中同步，重叠的收益直接归零。

GPU 只跑到一半，D2H 又必须在批内完成。 如果注意力后端需要 CPU 侧 seq_lens，resolve_seq_lens_cpu 会插入一次 .cpu()；如果后端需要隐藏状态回传（return_hidden_states，例如 embedding 请求或某些 reward 模型），_copy_result_to_cpu 的 CC 分支也会退回同步。这些都在「每 step 一次」的粒度上加了一个隐式同步点。

整条重叠被框架自动关掉。 最彻底的一种失效并不发生在每次调度的判断里，而是启动时就被改写。SGLang 的 arg_groups/overrides.py 里有一组 register_post_process 钩子，会按模型与部署形态把 disable_overlap_schedule 强制读成 True：_pipeline_parallel_overlap_disable 判断 pp_size > 1 时打一条 warning 并关闭重叠；Mamba/线性注意力模型如果 mamba_radix_cache_strategy 退化成 no_buffer，同样关闭；embedding 模型的稀疏头、diffusion LLM 等也会关闭。GLM-5.3 的官方部署是 DP Attention + EP、PP=1，正好绕开了第一条；但只要为了把 1M 上下文塞进多机而启用 PP，重叠就被自动关掉，调度器的 Python 开销会重新暴露在每一步的前向之外。上线前值得把启动日志里的这类 warning 逐条核对一遍。

CPU 处理比 GPU 前向慢。 这不是配置问题而是负载问题：process_batch_result(N-1) 要做 prefix tree 插入、KV 引用计数、流式输出打包、采样计数，再加上 DeepEP 的 dispatch 元信息更新，在 GLM-5.3 的 78 层 + 9 专家结构下，这些 CPU 工作量并不小。一旦比前向慢，下一批的发射就被整体推到处理之后，GPU 出现空档，TPOT 反而变差。判断方式很简单：看 process_batch_result 的耗时与一次前向的时间比。

怎么判断重叠是否真的生效

重叠调度是「看不见就测不到」的一类机制，线上至少有四个可观测点：

第一，调度器线程真正占用的 CPU 时间。 SGLang 的 metrics 里有 scheduler time accounting（start_scheduler_time_accounting / record_scheduler_active），它用墙钟时间与 time.process_time_ns() 两条时钟做对照：调度器线程「醒了但没在算」的差值就是它被阻塞在同步点（.cpu()、事件同步、内核提交）上的时间。同步调度时，这段阻塞时间等于每个 decode step 的一次前向；重叠生效时，它应大幅缩小到只剩显式的同步点（WAR 屏障、事件等待）。

第二，结果张量的到达延迟。 把「第 N-1 批的采样数据实际可用」与「第 N 批被发射」两个时间戳相减。同步调度下前者总在后者之后；重叠调度下前者应该被前向 N 盖住，差值接近 0 或为负。

第三，decode step 的 launch 间隔。 _record_step_counters 用一个连续判据来统计「有效 decode 步」的时间：

1
contiguous = (
2
    not batch.after_idle_gap
3
    and prev_iter + 1 == start_iter
4
    and prev_is_prefill == is_prefill
5
)
6
step_us = int((batch.launch_ts - prev_launch_ts) * 1e6)

这个指标统计的是「两次 launch 之间的时间」，在重叠调度下约等于 GPU 前向时间加上少量发射开销；在同步调度下则包含完整的 CPU 处理时间。同一配置下两个模式的差值，就是重叠藏起来的那段。

第四，TPOT 的分布而不是均值。 GPU 在前向期间本来就是忙的，有没有重叠对 GPU 前向时长几乎没有影响，所以平均 TPOT 的差别有限；差别体现在分布上——同步调度会让每个 decode step 后面固定挂一段「GPU 等 CPU」的空档，P99 明显高于 P50；重叠调度把这段空档吃掉之后，分布会收拢，尾部变短。这正是重叠调度的主要收益：它主要改善的是尾延迟与时间线的平滑度，吞吐提升只是附带。

GLM-5.3 在 vLLM 上还要看一个额外指标：两次 step 的输出间隔是否呈现周期性台阶（batch_queue 的节奏）。台阶的深度就是 batch_queue_size 相关的延迟，在排查「前端看起来一卡一卡」时，先确认是否是 batch queue 的节奏，再去怀疑 GPU。

把 GLM-5.3 的部署参数对照一遍

把前文的判断落回 GLM-5.3 的实际启动参数，可以得到一张「哪些开关会改变重叠形态」的对照表：

这张表里最容易被误判的是「默认开启」这一条：disable_overlap_schedule 的默认值是 False，所以 GLM-5.3 在单机 DP Attention 部署下通常就是重叠模式；但「默认开」不等于「实际生效」，前面列的 grammar 同步、PP override、needs_cpu_seq_lens 都会在运行时把某些 step 拉回同步。排障时不要只看启动参数，要看每一步的实际路径。

小结

重叠调度改变的是服务的时钟结构：同步调度时，GPU 的前向与 CPU 的处理是两个串行的阶段；重叠调度后，它们变成两条并行的流水线，中间只通过几个显式的同步点（WAR 屏障、D2H 事件、grammar barrier）相连。SGLang 用「同一线程里的先发后收 + FutureMap 延迟解析」实现，vLLM 用「step 循环 + batch queue + async 输入回填」实现，两条路线的共同点是：

• 发射这一侧被压到最小：调度器只登记「结果在哪里、何时可用」，不读结果；
• 消费这一侧被推迟：结果处理永远发生在下一批发射之后；
• 依赖这一侧被显式化：原先靠线程顺序保证的依赖，变成跨流事件、WAR 屏障、占位计数。

对 GLM-5.3 这类 DP Attention + 专家并行 + DSA + MTP 的模型，重叠并非全收益：连续 prefill、DP 一致性、grammar 同步、CPU 侧 prefix tree 更新都会在具体配置下开关它。第十六篇的 launch 账本与第十七篇的精度账本都默认「GPU 前向一结束、调度器立刻拿到结果」；本篇补上这一段后，一条请求在服务里真正的时间线才算完整——GPU 上的 78 层与 CPU 上的调度循环，是两条同时流动的河。

把两套框架的办法放在一起，可以归纳成三条通用原则，换成别的推理框架也同样适用：

• 先把等待点找出来：同步调用、.cpu()、事件 synchronize()、future.result()，每一个都是 CPU 与 GPU 之间的一次「握手」；重叠的改造就是逐个判断这次握手能否推迟、能否移到独立流上、能否用事件代替同步。
• 再给每个握手配一条流或一个事件：D2H 用拷贝流，输入写入用调度流加 WAR 屏障，输出可用性用事件；流的拓扑定了，重叠的形态也就定了。
• 最后为「看不到的结果」补记账：序列长度、占位 token、草稿接受数、语法状态，这些原本由同步读取直接得到的信息，在异步下必须改用预测加事后修正来维护，且所有 rank 的决策要保持一致。

还有一个容易被忽略的收尾问题：退出边界上可能还存在没被处理的结果。SGLang 的 event_loop_overlap 在 gracefully_exit 时直接 break，不会在循环里再把 result_queue 消费一遍；资源的善后交给 run_scheduler_process 的 finally——那里会停掉 async_d2h_worker、调用 release_host_resources()，异常路径还刻意跳过同步与销毁，避免 GPU 已经卡死时退出流程再挂一次。这类边界在同步调度下几乎不存在：同步时每条请求的结果都已经在 run_batch 返回时处理过，退出时没有「在飞但未处理」的对象；重叠之后，框架必须接受「最后一批结果可能不再进入调度器」这一事实，并把清理放到资源释放层，而不是调度层。

下一篇将讨论 进程间的那一段控制面：tokenizer 进程、router、EngineCore 与前端这四方在一条请求的生命周期里如何互相通知，以及当一个 rank 慢下来时，这种通知怎样把尾延迟放大。

参考资料

1. GLM-5: from Vibe Coding to Agentic Engineering（GLM-5 技术报告，arXiv:2602.15763）
2. zai-org/GLM-5.3 模型卡（744B-A40B、FP8、78 层、256 专家、1M 上下文）
3. SGLang GLM-5.3 Cookbook（DSA 后端、MTP、DP Attention、PD 分离的启动参数）
4. SGLang 源码：scheduler.py（event_loop_overlap、result_queue、WAR 屏障与 launch_batch_sample_if_needed）
5. SGLang 源码：overlap_utils.py（FutureMap、publish、resolve_seq_lens_cpu 与跨批张量中继）
6. vLLM 源码：scheduler.py（num_output_placeholders、投机草稿切片与 update_from_output）
7. vLLM 源码：gpu_model_runner.py（async scheduling 的 prev_sampled_token_ids 回填与 deferred 修正）
8. vLLM Documentation: Optimization and Tuning（--async-scheduling、CUDA Graph 与批调度选项）
9. Efficient Memory Management for Large Language Model Serving with PagedAttention（PagedAttention 与连续批处理，arXiv:2309.06180）
10. SGLang: Efficient Execution of Structured Language Model Programs（RadixAttention 与前端/运行时结构，arXiv:2312.07104）
11. DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models（DSA 与 MLA 结构，arXiv:2512.02556）