ARTICLE · 1272797
SGLang低延迟模式: 厂商内核插件化,GB300提速1.38倍MI355X提速1.56倍
低延迟推理需要针对模型、硬件和负载深度定制内核，大量融合内核又难以在主仓库中长期维护。SGLang Low-Latency Mode用插件框架接入厂商专用内核，下文拆解NVIDIA与AMD两套实现各自省下的时间，以及插件系统的注册、校验、构建与运行时分发机制。
低延迟推理内核
低延迟推理存在大量针对特定模型、硬件与负载的优化空间，这些优化通常需要大规模内核融合，并在不同实现之间重复代码，维护难度很高。为支持这类专用化，SGLang推出SGLang Low-Latency Mode，通过插件框架把专用内核引入SGLang，在NVIDIA与AMD GPU上都带来显著的延迟下降。在四张NVIDIA GB300上的AgentX轨迹回放中，单并发会话时P90单用户token生成速度从671.2提升到928.4 tokens/s，为1.38倍；在四张AMD MI355X上，四并发会话时从331.6提升到516.0 tokens/s，为1.56倍。每组结果都是同一硬件上低延迟模式与SGLang基线的对比。
NVIDIA低延迟内核
在NVIDIA GPU上，降低延迟的方式是让相互依赖的内核与通信重叠执行，同时针对小批量专门优化注意力、MoE与草稿采样。这些内核位于sgl-nvidia-mega，在NVIDIA GB300上同时加速DeepSeek-V4.1-Flash搭配DSpark时的目标验证与草稿执行。
耗时分布
单请求时，DSpark每步验证六个token行，每个内核分到的工作很少，依赖等待与跨GPU通信反而成为延迟来源。在预热后的CUDA graph剖析中，插件只把验证图的内核数从1,205个减到1,189个，却把decoder层延迟中位数从96.8 µs降到68.4 µs。收益主要来自减少等待与重叠执行，降幅最大的是注意力区段。下表列出各区段的变化，随后逐项说明主要优化。
中位数基于四张GPU上每组780到800个样本。各区段中位数之和不等于整层中位数。剖析本身会影响计时，这些数据用于解释机制，而非报告服务性能。
低延迟专项优化
1. 在输入就绪之前启动下一个内核。 Programmatic dependent launch即PDL，允许内核在前驱仍在运行时启动，先准备屏障、配置张量内存并加载权重，再等待所需的输入。SGLang本已使用PDL，插件则把依赖释放点提前，让更多准备工作与正在进行的计算重叠。例如MoE归约一开始轮询对端结果，就立即放行下一层的第一个投影。
注意力路径还使用为小批量专门优化的投影GEMM，并在加载query时同步施加RoPE，省掉一个独立内核。在依赖允许的地方，注意力会在等待query之前先开始收集KV数据。单请求时，插件还在每步开始时把相互独立的Engram查找与投影移到旁路流上，其all-reduce仍留在主流，以保持各GPU间的通信顺序。
2. 在GEMM收尾阶段直接发布投影输出。 注意力输出投影之后，每张GPU持有一份需要跨卡归约的部分结果。SGLang的标准路径使用两个内核：GEMM先写出结果，再由一个融合内核读回、发送给对端，并完成归约、mHC更新与归一化。
插件同样使用两个内核，但把发送动作移入GEMM的epilogue。每个CTA在其他tile仍在计算时，就把已完成的tile从寄存器经NVLink多播存储直接发布到对端GPU。消费者内核经PDL启动，等待发布的结果到齐后再归约。通信因此更早开始，也免去了仅为发送而重读部分输出，消费者的计算本身保持不变。
3. 在路由完成之前启动专家GEMM。 低并发时，路由可能占MoE路径相当大的比重。在最多八行的情况下，每个专家选中的token都能放进一个八行tile。插件用位图与popcount放置这些tile，无需扫描或排序，同时保留SGLang的top-k选择结果。它提前启动第一个专家GEMM，让准备工作与路由重叠，并跳过填充权重中的全零tile。标准内核本已使用八行tile，收益来自更简单的路由、更早的执行和更少的无效计算。剖析中MoE窗口中位数从44.4 µs降到36.5 µs，第二个GEMM与归约几乎不变。
4. 把顺序草稿采样留在一个内核内。 DSpark的Markov head按顺序提出token。插件把全部五次提议合并为每张GPU一次内核启动，把head权重保留在寄存器中，同时在GPU间协调token选择。剖析得到的提议跨度从85.1 µs降到34.2 µs，SGLang的投机执行器与接受逻辑均未改动。
服务结果
在8K输入、1K输出的负载下，四张GB300上1到8个并发请求时，NVIDIA插件把单用户解码速度提升12% 到38%。两组运行使用相同配置与3.51的模拟平均接受长度，只切换插件开关。
AMD低延迟内核
在AMD GPU上，降低延迟的方式是把一个decoder层的大部分计算与通信合并进少数几个常驻内核。这些内核位于sgl-amd-mono，在AMD Instinct MI355X与MI350X上同时加速DeepSeek-V4.1-Flash搭配DSpark时的目标验证与草稿执行。
低并发时，每个decoder层要运行数十个小内核和两次张量并行all-reduce，主要有三项开销：
- 启动开销：
HIP graph消除了CPU侧的启动工作，但每个小内核在GPU上仍需2到4 µs - 空闲边界：
每个内核必须结束后下一个才能开始，一个内核收尾、下一个爬升期间计算单元空闲，权重加载也随之暂停 - 通信停顿：
每层要两次等待跨GPU的all-reduce，期间没有任何计算
每层两次常驻启动
常驻的FlyDSL内核把每层的大部分工作压缩进两次启动。K1负责mHC更新、query与KV投影以及KV cache写入；K2负责注意力、输出投影、其余mHC更新、MoE以及两次all-reduce。索引层在两者之间加入压缩、K2i打分与top-k。两次启动之间的边界保证K1的KV写入在K2读取之前对整张GPU可见。
启动内部的阶段重叠
每个阶段产出的值都与当前解码步的标签一同存储，下一阶段无论在同一GPU还是其他GPU上，只要标签匹配就能立即开始处理该值，步与步之间无需额外的标志位或重置。不依赖路由的权重在输入到达前就开始加载：K1的投影权重在归一化结束前加载，K2中的mHC混合权重与共享专家权重在其相乘的数据到达前加载。路由专家的权重则在路由器选定专家后加载。
把all-reduce搬进内核
每个输出投影tile计算完成后，K2就把它推送到每张GPU的内存，各GPU按rank顺序累加这些分块，同时其他工作组仍在产出tile，即推送与归约两个阶段。MoE输出也以同样方式归约。每次跨GPU等待都设有低于SGLang watchdog超时的截止时间，一旦超时，所有GPU上的本次启动都会停止，而不会让服务器挂起。
AMD实现兼容解码图，并直接接入SGLang的graph runner。内核编译与缓冲区准备在初始化阶段完成，随后SGLang为每种支持的形状捕获专用执行路径，并通过现有服务流程回放。
服务结果
在AgentX轨迹回放中，四张MI355X上1、4、8个并发会话时，AMD插件把P90单用户token生成速度提升45% 到56%，见开篇的总览图。两组运行使用相同的AgentX配置，搭配DSpark投机解码与TP4。
插件系统: 设计与集成
专用内核往往代码量很大。硬件、模型架构与并行配置的每种组合都可能需要独立实现，不同负载还会带来进一步的专用化。组合越多，需要审查、测试和维护的代码就越多。若把所有实现都并入SGLang，核心代码库会越来越难以维护，评审者与维护者的负担也会持续加重。
插件系统通过模型规格把这些外部库接入SGLang，规格中声明其依赖条件与支持的配置。内核团队可以独立开发实现，同时复用SGLang的调度与运行时资源。
集成过程把启动阶段的准备与执行阶段分开：
- Register：
插件为其支持的每种模型架构注册一份规格，描述实现的依赖条件并提供构建入口。SGLang借此发现外部实现，而模型支持的细节仍保留在拥有这些内核的库中。 - Guard：
专用内核对硬件、精度、并行方式与服务特性都有假设。SGLang在加载权重之前检查声明的依赖条件，使不兼容的配置尽早失败；插件构建之前还会对已加载的模型做额外检查。这些检查区分两种情况：服务器配置本身不受支持，以及受支持的服务器遇到了插件未覆盖的步骤。 - Build：
权重准备与执行资源在初始化阶段完成配置，供后续请求复用。集成方式适配各实现的需求：AMD可以在权重转换前保留checkpoint张量，NVIDIA则获得一个绑定，可在运行时状态就绪时访问这些状态。SGLang在确定KV cache大小之前构建插件，使其显存分配被计入，然后在模型的前向路径中安装分发逻辑。 - Runtime：
插件可能只覆盖特定的步骤类型与token数，因此专用执行与通用执行并存。安装的分发器根据插件的支持条件选择插件前向或SGLang原有前向。各张量并行rank必须对覆盖范围达成一致，以免进入不兼容的集合通信。这一选择嵌入ModelRunner现有的执行流程；graph捕获时会为每种形状记录所选路径，服务时直接回放graph，无需重复执行Python分发。
这一设计让内核团队能交付聚焦的优化，而不必把每个专用实现都加入SGLang核心代码库。集成工作集中在明确的接口上，各库可以逐步扩大覆盖范围。专用内核服务于其优化的场景，在受支持的配置内，其余步骤由SGLang的通用前向处理。
参考：https://www.lmsys.org/blog/2026-10-18-sglang-low-latency-mode
