SGLang 双 Stream 重叠调度:如何把 CPU 后处理藏到 GPU 计算背后
大模型自回归推理看起来是纯 GPU 工作:每一步做一次模型前向,采样一个 token,再把 token 喂给下一步。然而在高性能推理系统里,GPU 计算只是流水线的一部分。采样结果回传、EOS 判断、请求回收、KV Cache 管理、下一批组装和元数据准备,都可能在两次前向之间制造空洞。 SGLang 的 Overlap Scheduling 解决的正是这个问题。它不是简单地“多开一条 CUDA stream”,而是同时完成两件事: 让当前步产生的 token 留在 GPU,直接作为下一步输入,解除下一次 forward 对 CPU 读值的依赖; 用 scheduler stream 和 engine stream 构造软件流水线,让 GPU 计算当前批次时,调度器处理上一批次的结果。 本文以 Mini-SGLang 的 python/minisgl/scheduler/scheduler.py 为线索,解释 overlap_loop、_forward 和 _process_last_data 背后的依赖重排。 先看结论:优化的不是“提交速度”,而是依赖关系 CUDA kernel 的提交本来就是异步的。CPU 把工作放进 stream 后,不必等待 GPU 完成。因此一个自然的问题是:只用一条 stream,只要 CPU 提交得足够快,不也能让 GPU 连续工作吗? 如果系统只有计算任务,这个判断基本成立。但自回归推理存在一个控制依赖:调度器通常要知道采样出的 token,才能判断请求是否命中 EOS、是否应该释放资源,以及下一轮有哪些请求仍应留在 batch 中。 串行执行会形成如下链条: GPU: forward(B1) ── idle ── forward(B2) ── idle ── forward(B3) CPU: 处理 B1 处理 B2 读 token 读 token 判 EOS 判 EOS 组 B2 组 B3 GPU 完成 B1 后,CPU 才读取结果并决定 B2。此时 GPU 没有可执行的新工作,只能等待。这不是 CPU 调用 CUDA API 太慢,而是 B2 在逻辑上依赖 B1 的结果。 ...