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 的结果。 ...

2026年8月30日 · 4 分钟 · Hellokitty

SAC:面向稀疏注意力大模型的 CXL 解耦 KV Cache 系统

本文翻译并整理自论文 SAC: Disaggregated KV Cache System for Sparse Attention LLMs with CXL(arXiv:2606.19746v1,2026 年 6 月 18 日)。原论文采用 CC BY 4.0 许可。为适应博客阅读,本文省略参考文献列表中的完整出版信息,但保留正文结构、关键论证、实验结果与附录要点。 随着大模型进入长上下文与稀疏注意力时代,推理系统的主要瓶颈正从算力转向内存容量。传统 RDMA 解耦 KV Cache 系统会在解码前把完整前缀 KV Cache 搬回本地;但稀疏注意力每一步只访问少量 top-k 条目,这种“全量搬运、少量使用”的方式会同时浪费网络带宽和本地内存。 SAC 的核心思路是:使用 CXL 的低延迟、缓存行粒度 load/store 语义,把 KV Cache 留在解耦内存池中,只在计算时按需读取被选中的 top-k 条目。论文在 DeepSeek-V3.2 与 SGLang 上的实验显示,相比 RDMA 基线,SAC 可实现最高约 2.1 倍吞吐量、9.7 倍更低的 TTFT,以及 1.8 倍更低的 TBT。 摘要 大模型向长上下文推理扩展,使服务系统的主要瓶颈从计算能力转向内存容量。面向稠密注意力模型的传统方案通常采用基于 RDMA 的解耦内存池,在解码开始前,以粗粒度方式将整个前缀 KV Cache 从远端存储取回本地内存。 然而,这种方法并不适合新兴的稀疏注意力模型。解码过程中虽然只有很少一部分 KV 条目真正活跃,系统仍然要把完整 KV Cache 拉回本地,从而造成严重的传输瓶颈和本地内存浪费。 ...

2026年8月28日 · 5 分钟 · Hellokitty