低并发场景（例如一个用户同时只有一两个会话的智能体应用）下，单个请求每步要算的数据很少，延迟主要花在内核启动、内核之间的等待和多卡通信上。SGLang、NVIDIA 和 AMD 团队在这篇 LMSYS 博客里介绍 SGLang 低延迟模式：用一个插件框架，把厂商为特定模型和硬件写的高度融合内核接进 SGLang，而不把这些代码合进 SGLang 主仓库。测试模型是 DeepSeek-V4.1-Flash 加 DSpark 投机解码，在 AgentX 智能体轨迹回放上，4 张 NVIDIA GB300、1 个并发会话时，每用户 P90 生成速度从 671.2 提到 928.4 token/s（1.38 倍）；4 张 AMD MI355X、4 个并发会话时，从 331.6 提到 516.0 token/s（1.56 倍）。对照组都是同一硬件上的标准 SGLang。

1. 问题：小批量时时间花在哪里

在 1 个请求时，DSpark 每步只验证 6 行 token，每个内核的计算量很小，前后依赖和跨 GPU 通信占了大头。为特定模型、硬件和并发规模做深度融合能显著降延迟，但每种组合都要单独一套实现，全部放进 SGLang 主仓库会让代码和评审负担不断增大。

2. 方法

2.1 NVIDIA：让相互依赖的内核和通信重叠（sgl-nvidia-mega）

作者先在预热后的 CUDA graph 下剖析了一个解码层（1 个请求，各区段中位数）：

内核总数只从 1,205 减到 1,189，延迟下降主要来自减少等待和让工作重叠，而不是减少内核数量。具体做了四件事：

1. 下一个内核提前启动。 利用 PDL（programmatic dependent launch，允许后一个内核在前一个还在运行时就开始），把"可以开始"的信号发得更早，让后一个内核先准备屏障、加载权重。注意力在等 query 之前先开始收集 KV；RoPE 在加载 query 时顺便做掉，省掉一个单独内核。
2. 在矩阵乘法的收尾阶段直接发送结果。 注意力输出投影之后，每张卡只有部分和，需要跨卡归约。原来是矩阵乘法写回显存、再由下一个内核读出来发给其他卡；插件让每个线程块算完自己那块就通过 NVLink 多播直接写到其他卡，不必等整个矩阵乘法结束。

1. 路由没结束就开始专家矩阵乘法。 最多 8 行时，每个专家选中的 token 能放进一个 8 行的块，插件用位图和计数直接定位，不需要扫描或排序，并提前启动第一个专家矩阵乘法。MoE 区段中位数从 44.4 µs 降到 36.5 µs。
2. 投机解码的草稿采样放进一个内核。 DSpark 的草稿头按顺序提出 5 个 token，插件在每张卡上用一次内核启动完成，草稿阶段耗时从 85.1 µs 降到 34.2 µs，验收逻辑不变。

2.2 AMD：每层合并成两个常驻内核（sgl-amd-mono）

在 AMD 上，作者认为三项开销最大：即使用 HIP graph，每个小内核在 GPU 上仍要 2–4 µs；内核之间有空转；每层两次跨卡 all-reduce 期间没有计算。插件用 FlyDSL 写了两个常驻内核覆盖一层的大部分工作：K1 做 mHC 更新、Q/KV 投影和写 KV cache；K2 做注意力、输出投影、MoE 和两次 all-reduce。阶段之间用"带解码步编号的值"传递，编号对上就可以开始算，不需要另外的标志位。all-reduce 放进内核内部：每算完一块输出就推到所有卡上，其他工作组同时继续算。每次跨卡等待都设了比 SGLang 看门狗更短的超时，超时则所有卡一起终止这次启动，而不是让服务挂住。

2.3 插件框架

外部内核库通过四步接入：注册（声明支持哪些模型结构）、检查（加载权重前检查硬件、精度、并行方式是否兼容，不兼容就尽早报错）、构建（初始化时准备好权重和资源，在确定 KV cache 大小之前构建，所以显存占用会被计入）、运行时分派（插件只覆盖部分步骤类型和 token 数，不覆盖的步骤回到 SGLang 原有的前向）。

3. 实验

3.1 AgentX 轨迹回放

这组实验检验插件在接近真实的智能体负载下能提速多少。设置：DeepSeek-V4.1-Flash + DSpark，TP4，每用户 P90 生成速度，只切换插件开关。

NVIDIA 上并发越高，提速越小；AMD 上三档都在 1.45 倍以上。

3.2 NVIDIA 固定长度负载

输入 8K、输出 1K，模拟的平均接受长度为 3.51。在 1–8 个并发请求下，NVIDIA 插件把每用户解码速度提高 12%–38%。

4. 局限

目前只支持 DeepSeek-V4.1-Flash + DSpark 这一组合，GLM-5.3、K3、MiniMax M3 等还在开发中。博客说明剖析本身会影响计时，分区段数字用于解释机制，不代表服务性能。外部内核不经过 SGLang 常规代码评审，插件接口的 CI 和性能回归测试还在计划中；接口本身也还在早期，会继续调整。博客没有给出精度对比，只说明不改变投机解码的验收逻辑。

5. 实践意义

如果你的负载是低并发、对单用户延迟敏感（例如编码或智能体会话），并且正好用 DeepSeek-V4.1-Flash 在 GB300 或 MI355X 上部署，可以试这个模式。对其他模型，更有参考价值的是方法：在小批量下先剖析等待和通信时间，再决定融合哪些内核；以及用插件方式把专用内核隔离在主框架之外。

投机解码用一个小的草稿模型先猜几个 token，再让大模型一次性并行验证，猜中的越多（接受长度越长）越快。草稿模型通常用蒸馏训练：让它的输出概率分布尽量贴近目标模型，包括目标模型自己也不确定的那些低概率 token。海信的作者认为这和真正目标不一致：验证时只看草稿给出的 token 能否被目标模型接受，草稿只要把最可能的几个 token 排对就够了，不必复现整个分布。他们提出 RCSD，在 EAGLE 框架里用 HASS（一种按蒸馏训练草稿模型的方法）训好的草稿模型作为起点，再用 DPO 或 GRPO 继续训练，训练信号直接来自"目标模型自己生成的序列"和"草稿模型参与生成的序列"之间的对比。在 Qwen3-1.7B 和 Llama-3.1-8B 上，接受长度在 HumanEval、MT-Bench、GSM8K、ShareGPT 四个数据集和草稿步数 3–6 的所有设置中都高于 HASS，论文报告平均提高 35%，在 ShareGPT 等实际负载上端到端快 1.35 倍。

1. 问题：蒸馏目标和接受长度不一致

蒸馏最小化的是前向 KL 散度，会迫使草稿模型把容量分给目标分布里的所有区域，包括低概率的尾部。草稿模型比目标模型小几个数量级，做不到完全复现。作者的论点是：KL 损失低不等于接受率高，KL 损失高也可能接受率很好，关键在于前几个候选 token 的排序是否和目标模型一致。

2. 方法

两种训练方式都从 HASS 训好的草稿模型出发，并以它作为冻结的参考模型。

DPO 版。 对同一个提示构造一对序列：

• "好"的序列：完全由目标模型自回归生成；
• "差"的序列：目标模型生成 1 个 token，草稿模型不经验证接着生成 k 个，如此交替。

然后用标准 DPO 损失训练草稿模型，让它对"好"序列的概率相对参考模型上升、对"差"序列的概率下降。"差"序列中由目标模型生成的那些 token 在计算损失时被屏蔽，避免惩罚本来就和目标模型一致的部分。

GRPO 版。 对同一个提示生成一组序列：一条由目标模型直接生成，另外几条按不同的 k（每次草稿连续生成 1、2、3 个 token）交替生成。每条序列的分数是两项标准化后相加：目标模型给这条序列的对数概率，和这条序列的接受率。再用 GRPO 的裁剪目标加 KL 约束训练。

3. 实验

3.1 接受长度

这组实验检验 DPO/GRPO 继续训练能否让草稿模型被接受的 token 更多。设置：Qwen3-1.7B 和 Llama-3.1-8B 作为目标模型，在 90% 的 ShareGPT 上训练；在 HumanEval、MT-Bench、GSM8K 和剩下 10% 的 ShareGPT 上测试；草稿步数（每轮猜几个 token）从 3 到 6。

Qwen3-1.7B，步数 6 时的平均接受长度：

Llama-3.1-8B，步数 6：

结果：两种方法都明显超过 HASS，GRPO 多数情况下略好于 DPO，但两者差距很小。步数越大提升越多，论文举例 Qwen3-1.7B 在 GSM8K 上相对提升从步数 3 的 31% 增加到步数 6 的 49%。Llama-3.1-8B 上 ShareGPT 提升最明显，这也是训练数据所在的分布。

3.2 吞吐

这组实验检验接受长度的提升能否变成实际速度。设置：Llama-3.1-8B-Instruct，SGLang 5.5.0。论文没有写明这组的草稿步数，图中的接受长度与上表步数 3 的数值相同。

（单位：输出 token/s）结果：ShareGPT 上 GRPO 版从 142.3 提到 176.6 token/s，其他三个数据集提升较小。

4. 局限

• 论文多处声称"不影响生成质量"，但没有给出质量评测结果。按投机解码的验证机制，输出应由目标模型决定，但实验部分没有对此单独验证。
• 标题写的是"持续学习"和"特定领域"，正文没有持续学习的实验，评测集也是通用数据集，没有领域专属场景。
• 方法描述前后不完全一致：Figure 3 左侧说"好/差"序列来自验证中被接受和被提前拒绝的 token，而方法章节和右侧写的是"目标模型单独生成"对"目标与草稿交替生成"。
• Figure 2 标题说基线是 SFT，图例写的是 HASS。
• 吞吐只测了 Llama-3.1-8B 一组配置；没有报告训练成本，也没有和其他非蒸馏训练方法对比。

5. 实践意义

如果你已经部署了 EAGLE/HASS 风格的草稿模型，这篇论文提示一个低成本的后续步骤：用目标模型自己生成的数据，在现有草稿模型上再做一轮 DPO 继续训练，数据构造不需要人工标注或额外奖励模型。GRPO 版只比 DPO 稍好，实现更复杂。由于缺少质量评测和训练成本数据，上线前需要自己核对输出一致性和训练开销。

稀疏注意力（例如 DeepSeek-V4.1-Flash、GLM-5 系列使用的按索引选取历史 token 的注意力）让每步解码只读一部分 KV cache，但没被选中的历史以后还可能被选中，所以全部历史仍要保存。长上下文、多请求时，存这些历史的显存决定了能同时解码多少请求。Scitix.AI 的 UlaCache 把所有 GPU 的 KV 池和可选的 CPU 内存编进同一个"逻辑地址空间"：推理引擎只拿逻辑地址分配和选取 KV，数据实际放在哪张卡或 CPU 上由 UlaCache 负责搬运和更新映射。这样 GPU 和 CPU 各存不同的历史，而不是 CPU 存全量、GPU 存副本。在 SGLang 中用 GLM-5.3、输入 64K–128K token 的 Multi-LexSum 请求测试，开启投机解码、GPU 和 CPU 内存预算相同时，峰值解码吞吐相对 HiSparse 在 8×H200 上提高 1.16 倍（DP）和 1.70 倍（TP），在 8×B300 上提高 1.73 倍（DP）和 2.51 倍（TP）。

1. 问题：存储空间大多被副本占掉

作者用 GLM-5.3 在 8×B300 上统计了两种现有做法的 KV 分配：

两个来源的重复：

• 跨卡重复。 模型使用 MLA（多头潜在注意力）时，按注意力头切分的 TP 让每张卡都存同一份 KV。8 卡 TP 下只有 12.5% 是不重复的历史。
• GPU 与 CPU 重复。 HiSparse 把完整历史放 CPU，把选中的部分复制到 GPU。它的 5330 万个物理槽只存了 3000 万个不重复的历史位置，GPU 那部分不增加容量。

此外，HiSparse 给每个请求固定大小的 GPU 缓存配额。请求变少时，剩下的请求也用不上空出来的显存。作者给出的例子：8×B300、DP、开投机解码、批大小 1 时，GPU 本来装得下所有历史，HiSparse 的每 token 时延（TPOT）仍比纯 GPU 的 SGLang 高 23.5%。

2. 方法

统一逻辑地址。 每个 KV 条目有一个固定的逻辑地址，映射表记录它当前在哪个 GPU 槽或 CPU 槽。KV 在 GPU 和 CPU 之间移动时，只改映射，不改逻辑地址。

• DP 模式：每张卡管理自己的 GPU 池和 CPU 池，容量是两者之和。
• TP 模式：所有卡的 GPU 池合成一个分布式地址空间，每张卡存每个请求历史的不同部分（逻辑地址 t 放在第 t mod P 张卡上）。负责计算的卡另有一个本地 GPU 缓冲区，缓存最近选中的 KV，下一步再被选中时直接复用，只从本卡或其他卡取缺失的部分。共享同一稀疏选择的层可以在当前层计算时预取后面层需要的 KV。

PB-LRU（并行分桶 LRU）。 开启 CPU 存储后，GPU 池由所有请求共享，需要决定把哪些 KV 换出到 CPU。标准 LRU 每次都要扫描整个池，PB-LRU 把 GPU 槽按最近使用时间分成若干桶，命中检测和更新并行处理，用分层位图快速找到可替换的槽，优先替换最冷的桶，并保护当前注意力计算正要用的条目。数据先搬运，搬完再更新映射，保证后续访问读到的是已就绪的数据。

3. 实验

设置：GLM-5.3，FP8 权重和 KV cache，8×H200 和 8×B300。基线是 GPU 存全部 KV 的 SGLang 和用 CPU 存历史的 HiSparse。投机解码用 MTP，草稿 2 步。三个系统的 GPU 显存分配相同，CPU 预算为每张 H200 128 GB、每张 B300 192 GB。负载是 Multi-LexSum，输入 64K–128K token，每个请求贪心生成 2,048 个 token。

3.1 容量与可同时解码的请求数

这组实验检验统一地址能否在相同内存下装下更多历史、接纳更多请求。

可接纳的请求数：

TP 模式下差距最大，因为 UlaCache 消除了 MLA 的跨卡重复。DP 模式下 HiSparse 本来就用 CPU 存历史，差距较小。

3.2 吞吐与延迟

这组实验检验容量增加能否变成吞吐提升，以及低负载时多出来的查找和调度是否拖慢单请求。

• 吞吐。 开投机解码时峰值吞吐相对 HiSparse 为 1.16×（H200 DP）、1.70×（H200 TP）、1.73×（B300 DP）、2.51×（B300 TP）。B300 TP 不开投机时，UlaCache 峰值吞吐是 SGLang 的 3.51 倍。峰值对比取各系统在所有批大小中的最高值，提升主要来自能同时解码更多请求。
• 低负载延迟。 批大小 1–8 的八种配置下，UlaCache 的 TPOT 都低于 HiSparse，但高于 SGLang。作者认为差距来自额外的查找、调度和 TP 通信。

3.3 PB-LRU 消融

这组实验检验分桶近似会不会降低缓存命中率，以及能省多少调度时间。设置：8×H200 DP，PB-LRU 和基于时间戳的普通 LRU 回放同一组访问记录，缓存容量相同。

结果：两者 GPU 命中率相差不到 0.10 个百分点；在较大批大小下，PB-LRU 调度快约 1.5–2.3 倍。批大小小、几乎不需要替换时，普通 LRU 反而更快，因为 PB-LRU 仍要维护桶的元数据。

4. 局限

只测了一个模型（GLM-5.3）和一种负载（Multi-LexSum 长文摘要）。吞吐对比取峰值，各系统峰值出现在不同的批大小上，所以数字主要反映"能装下多少请求"，不是同一批大小下的单步速度。低并发时比纯 GPU 的 SGLang 慢。论文没有报告精度，因为 UlaCache 不改变注意力本身的选取。

5. 实践意义

如果你在 SGLang 上服务使用 MLA 和稀疏注意力的模型（GLM-5、DeepSeek-V4.1 一类）、请求上下文很长、瓶颈是显存装不下更多并发请求，尤其是用 TP 部署时，UlaCache 的思路值得关注：先消除跨卡和 GPU/CPU 之间的重复存储，再谈换入换出。若主要场景是低并发、对单请求延迟敏感，纯 GPU 的 SGLang 仍更快。