<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>SGLang on Hellokitty&#39;s Blog</title>
    <link>https://yangyang233333.github.io/tags/sglang/</link>
    <description>Recent content in SGLang on Hellokitty&#39;s Blog</description>
    <generator>Hugo</generator>
    <language>zh-CN</language>
    <lastBuildDate>Sun, 30 Aug 2026 23:09:10 +0800</lastBuildDate>
    <atom:link href="https://yangyang233333.github.io/tags/sglang/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>SGLang 双 Stream 重叠调度：如何把 CPU 后处理藏到 GPU 计算背后</title>
      <link>https://yangyang233333.github.io/posts/sglang-overlap-scheduling/</link>
      <pubDate>Sun, 30 Aug 2026 23:09:10 +0800</pubDate>
      <guid>https://yangyang233333.github.io/posts/sglang-overlap-scheduling/</guid>
      <description>&lt;p&gt;大模型自回归推理看起来是纯 GPU 工作：每一步做一次模型前向，采样一个 token，再把 token 喂给下一步。然而在高性能推理系统里，GPU 计算只是流水线的一部分。采样结果回传、EOS 判断、请求回收、KV Cache 管理、下一批组装和元数据准备，都可能在两次前向之间制造空洞。&lt;/p&gt;
&lt;p&gt;SGLang 的 Overlap Scheduling 解决的正是这个问题。它不是简单地“多开一条 CUDA stream”，而是同时完成两件事：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;让当前步产生的 token 留在 GPU，直接作为下一步输入，解除下一次 forward 对 CPU 读值的依赖；&lt;/li&gt;
&lt;li&gt;用 scheduler stream 和 engine stream 构造软件流水线，让 GPU 计算当前批次时，调度器处理上一批次的结果。&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;本文以 Mini-SGLang 的 &lt;code&gt;python/minisgl/scheduler/scheduler.py&lt;/code&gt; 为线索，解释 &lt;code&gt;overlap_loop&lt;/code&gt;、&lt;code&gt;_forward&lt;/code&gt; 和 &lt;code&gt;_process_last_data&lt;/code&gt; 背后的依赖重排。&lt;/p&gt;
&lt;h2 id=&#34;先看结论优化的不是提交速度而是依赖关系&#34;&gt;先看结论：优化的不是“提交速度”，而是依赖关系&lt;/h2&gt;
&lt;p&gt;CUDA kernel 的提交本来就是异步的。CPU 把工作放进 stream 后，不必等待 GPU 完成。因此一个自然的问题是：只用一条 stream，只要 CPU 提交得足够快，不也能让 GPU 连续工作吗？&lt;/p&gt;
&lt;p&gt;如果系统只有计算任务，这个判断基本成立。但自回归推理存在一个控制依赖：调度器通常要知道采样出的 token，才能判断请求是否命中 EOS、是否应该释放资源，以及下一轮有哪些请求仍应留在 batch 中。&lt;/p&gt;
&lt;p&gt;串行执行会形成如下链条：&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;&#34;&gt;&lt;code class=&#34;language-text&#34; data-lang=&#34;text&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;GPU:  forward(B1) ── idle ── forward(B2) ── idle ── forward(B3)
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;CPU:               处理 B1                 处理 B2
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;                   读 token                读 token
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;                   判 EOS                  判 EOS
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;                   组 B2                   组 B3
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;GPU 完成 &lt;code&gt;B1&lt;/code&gt; 后，CPU 才读取结果并决定 &lt;code&gt;B2&lt;/code&gt;。此时 GPU 没有可执行的新工作，只能等待。这不是 CPU 调用 CUDA API 太慢，而是 &lt;code&gt;B2&lt;/code&gt; 在逻辑上依赖 &lt;code&gt;B1&lt;/code&gt; 的结果。&lt;/p&gt;</description>
    </item>
    <item>
      <title>SAC：面向稀疏注意力大模型的 CXL 解耦 KV Cache 系统</title>
      <link>https://yangyang233333.github.io/posts/sac-cxl-sparse-attention/</link>
      <pubDate>Fri, 28 Aug 2026 17:30:00 +0800</pubDate>
      <guid>https://yangyang233333.github.io/posts/sac-cxl-sparse-attention/</guid>
      <description>&lt;blockquote&gt;
&lt;p&gt;本文翻译并整理自论文 &lt;strong&gt;SAC: Disaggregated KV Cache System for Sparse Attention LLMs with CXL&lt;/strong&gt;（arXiv:2606.19746v1，2026 年 6 月 18 日）。原论文采用 CC BY 4.0 许可。为适应博客阅读，本文省略参考文献列表中的完整出版信息，但保留正文结构、关键论证、实验结果与附录要点。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;随着大模型进入长上下文与稀疏注意力时代，推理系统的主要瓶颈正从算力转向内存容量。传统 RDMA 解耦 KV Cache 系统会在解码前把完整前缀 KV Cache 搬回本地；但稀疏注意力每一步只访问少量 top-k 条目，这种“全量搬运、少量使用”的方式会同时浪费网络带宽和本地内存。&lt;/p&gt;
&lt;p&gt;SAC 的核心思路是：使用 CXL 的低延迟、缓存行粒度 load/store 语义，把 KV Cache 留在解耦内存池中，只在计算时按需读取被选中的 top-k 条目。论文在 DeepSeek-V3.2 与 SGLang 上的实验显示，相比 RDMA 基线，SAC 可实现最高约 &lt;strong&gt;2.1 倍吞吐量、9.7 倍更低的 TTFT，以及 1.8 倍更低的 TBT&lt;/strong&gt;。&lt;/p&gt;
&lt;h2 id=&#34;摘要&#34;&gt;摘要&lt;/h2&gt;
&lt;p&gt;大模型向长上下文推理扩展，使服务系统的主要瓶颈从计算能力转向内存容量。面向稠密注意力模型的传统方案通常采用基于 RDMA 的解耦内存池，在解码开始前，以粗粒度方式将整个前缀 KV Cache 从远端存储取回本地内存。&lt;/p&gt;
&lt;p&gt;然而，这种方法并不适合新兴的稀疏注意力模型。解码过程中虽然只有很少一部分 KV 条目真正活跃，系统仍然要把完整 KV Cache 拉回本地，从而造成严重的传输瓶颈和本地内存浪费。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
