SGLang 两周优化 GLM-5.2：8×B300 上突破 500 TPS

SGLang Team 发布了针对 GLM-5.2-NVFP4 的服务优化复盘：在两周内，他们将 day-0 支持版本推进到更稳定、更适合生产的推理路径，并在 8×B300、batch size=1 的低延迟场景下实现超过 500 TPS。

图1：GLM-5.2 NVFP4 在 8×B300 上，Day-0 与 v0.5.15.post1 的性能对比。

核心结论

• 8×B300、bs=1 场景下吞吐超过 500 TPS。
• 为 GLM-5.2 MTP 实现无同步开销的 speculative decoding。
• 在 SGLang 中内置 IndexShare MTP 并接入 Spec V2。
• TopK-V2 在 80K ISL 下比 TopK-V1 快 2.33×。
• 通过 Indexer Prologue Fusion 将相关 kernel 数量从 12 个降至 4 个。
• 引入面向 BF16 层的 CuTe DSL GEMM 优化。

背景：GLM-5.2 的架构变化

GLM-5.2 延续了此前 GLM checkpoint 的主体结构：在 DeepSeek-V3 风格的 MoE 之上，叠加带 sparse-attention indexer 的 DSA。相比早期版本，它加入了两个关键变化：用于 DSA 的 IndexShare，以及结合 IndexShare 与 KVShare 的 MTP。

SGLang 从 day 0 起就在 Grace Blackwell / Blackwell 硬件上支持 GLM-5.2-NVFP4 checkpoint，并使用 trtllm-gen kernel 处理 sparse attention 与 MoE。此次优化的目标，是把最初可运行的栈升级为更快、更稳定、更适合生产部署的服务路径。

运行时优化：Spec V2 与零开销调度

Spec V2 是 SGLang 面向 speculative decoding 的 overlap runtime。它的核心思路是：当 GPU 在 forward stream 上执行当前模型 forward 时，CPU 与 plan stream 同时准备下一步所需的 KV allocation 和 metadata，从而把 CPU bookkeeping 隐藏在 GPU 执行时间内。

SGLang 最近默认启用了 Spec V2。理论上，overlap scheduler 可以让 CPU 在 GPU 仍忙于当前 iteration 时完成下一步准备，使两次 run_batch 之间几乎没有空泡。但在实际落地中，团队仍需要清理若干同步点：

• 让 DSA draft-extend path 支持 CUDA graph。
• 让 seq_lens_cpu 对 DSA 变为可选，从而消除 D2H sync。
• 移除残留的 H2D sync。
• 融合 _apply_cuda_graph_metadata 中的小型 eager metadata 操作。

这些 GPU bubble 被消除后，端到端 TPS 提升约 11%。

图2、图3：Spec V2 优化前后 decode trace 对比。优化后，run_batch iteration 之间不再出现明显空泡。

在 SGLang 中实现 IndexShare MTP

GLM-5.2 配备了较强的 MTP head，accept length 经常达到 5+。这对 agentic coding 等低延迟工作负载非常关键，因为较长的接受长度可以显著降低目标模型验证频率，提升交互式吞吐。

为了正确支持 GLM-5.2 的 MTP 行为，SGLang 对 speculative decoding runtime 做了两项改造。首先，IndexShare 要求 SGLang 在多个 draft step 之间复用 DSA indexer 的 top-k：draft step 0 计算出的 top-k 会被保留下来，并传递给后续 draft step，使它们无需重复运行 indexer。在长上下文下，这可将 draft-step 成本最高降低约 1.9×，且不会影响输出质量。

其次，top-k 的 seed 必须来自正确位置。在 SGLang 中，它来自上一轮 run_batch iteration 的 draft-extend。由于 Spec V2 的步骤异步执行，团队需要把这个 seed 穿过 overlap scheduler 的 relay buffer，确保它不会在 iteration 之间丢失。

Kernel 优化一：TopK-V2

DSA indexer 会把每个 query 转换为对历史 KV position 的 score，并从中选择 sparse attention 所需的候选位置。延续此前在 DeepSeek-V4 优化中提出的 Lightning-TopK 思路，SGLang 将原有 DSA TopK-V1 升级为 TopK-V2：它把 TopK 视为 selection 问题，而不是 sorting 问题。

图4：TopK-V2 使用 8 个 CTA 的 cluster 处理长 score row，每个 CTA 构建本地 10-bit histogram，再通过 cluster-wide reduction 定位边界 bin。

图5：TopK-V2 构建 histogram 时，会将 FP32 score 舍入到 FP16，并转换为保持数值顺序的 unsigned key；高 10 位用于选择 1024 个 bin。

TopK-V2 针对不同长度采用不同路径：短行和中等长度行使用 register-resident 或 single-CTA streaming path；长行则由 8 个 CTA 组成的 cluster 构建本地 10-bit radix histogram，并在 cluster 内归约，以定位包含第 2048 大 score 的 threshold bin。

高于 threshold bin 的值会直接输出；位于边界区域的候选项则进入精确的 FP32 radix selection。随后，逻辑位置会被转换为物理 indexer KV-cache slot。该 kernel 支持运行时 k 最高到 2048，并通过精确 tie-break 返回恰好 k 个条目。

此外，planning kernel 会根据 batch 的 sequence length 分布选择 cluster cutoff，并为 persistent cluster pool 构建 work list。生成的 plan 会在每次 forward 时创建，并在所有 DSA layer 间复用。TopK-V2 还将 selection 与 page-table transform 融合到单个 kernel 中，以进一步降低延迟。

图6：TopK-V1 与 TopK-V2 kernel latency 对比，测试场景为 batch size 1、6 个 draft token 的 target model verification。

基准结果显示，在 80K ISL 下，TopK-V2 将平均 kernel latency 从 40.7 μs 降至 17.5 μs，加速 2.33×。随着上下文长度增加，优势进一步扩大：在 1M ISL 下，latency 从 372.1 μs 降至 36.6 μs，加速达到 10.17×。这说明 TopK-V2 对长上下文工作负载的扩展性明显更好。

Kernel 优化二：Indexer Prologue Fusion

图7：DSA Indexer Prologue kernel 融合前后的依赖链变化。

DSA indexer prologue 会准备两类数据：一类是存入 indexer KV cache 的 key representation，另一类是用于计算 sparse attention candidate 的 query representation。原始实现由一连串小 kernel 与 projection 组成。

在融合前，key 分支依次执行 wk、LayerNorm、RoPE、Hadamard transform、FP8 quantization 与 cache store；query 分支执行 wq_b、RoPE、Hadamard transform、FP8 quantization 与 head-gate scaling。此外，weights_proj 是单独的 projection，用于产生 per-head gate。

PR #27705 从两个方向压缩这条依赖链。第一，将 wk 与 weights_proj 融合为单个 BF16 projection：wk_weights_proj。其输出被拆分为 key activation 与 raw head-gate weights，这样既移除了 indexer path 上的一个小 GEMM，也让 head-gate weights 能被融合后的 query kernel 直接复用。

第二，团队融合了 elementwise tail：

• Key path：LayerNorm + RoPE + FP8 quantization + paged indexer KV cache store。
• Query path：RoPE + FP8 quantization + head-gate scaling。

融合后的调度结构更短、更清晰：key 分支可以作为一个包含 cache store 的 kernel 执行，query 分支则作为另一个 fused kernel 执行，两者还能并行重叠。最终，相关 kernel 数量从 12 个降至 4 个。

融合路径还移除了 Hadamard transform。由于对 Q 和 K 应用相同的 orthonormal transform 会在量化前保持内积不变，其主要影响集中在量化表示上；融合后的路径改为直接量化未变换的 activation。

kernel 数量减少直接带来 decode throughput 提升，尤其在小 batch size 下更明显。batch size 1 时，decode throughput 约提升 8%；batch size 128 时，提升较小但仍稳定，约为 5%。

Kernel 优化三：BF16 GEMM 改进

图8：CuTe DSL BF16 GEMM 相对 cuBLAS GEMM 在不同 batch size 下的加速效果。

GLM-5.2 并非所有矩阵乘都运行在 NVFP4。为了保护精度，checkpoint 的量化策略保留了 attention projection 与 shared-expert MLP 的 BF16，仅对 routed expert 进行量化。

PR #30117 引入了可选的 CuTe DSL BF16 GEMM backend，来自 Flashinfer 的 TGV GEMM，专门面向这些 BF16 层。该 kernel 将工作在不同 warp 之间进行分工：部分 warp 专门从内存加载数据，一个 warp 负责矩阵乘，另一些 warp 负责写回结果。由于 load、compute、store 可以并行重叠，相比传统路径可降低等待时间，并在多个 batch size 上优于 cuBLAS。

整体效果与长上下文表现

综合 Spec V2、IndexShare MTP、TopK-V2、Indexer Prologue Fusion 与 GEMM 优化后，SGLang 在 GLM-5.2-NVFP4 上取得了更好的吞吐与延迟折中。尤其在 agentic workload 常见的低 batch、长上下文场景中，这些优化共同减少了 GPU bubble、CPU/GPU 同步、小 kernel launch 开销以及长序列 TopK 成本。

图9：GLM NVFP4 在 SGLang 上的 performance Pareto curve，展示不同配置下吞吐与交互性的权衡。

图10：在 4 张 GB300 GPU 上进行的 input sequence length ablation，展示输入长度变化对性能的影响。

总结

这次优化的关键不只是单点 kernel 加速，而是从 runtime overlap、MTP 语义、DSA indexer、长上下文 TopK、BF16 GEMM 到调度依赖链的系统级重构。最终，GLM-5.2-NVFP4 在 SGLang 上从 day-0 可用版本，提升为面向生产服务更高效的推理路径，并在 8×B300 上达到超过 500 TPS 的低延迟吞吐表现。