SGLang部署DeepSeek V4 Flash推理加速指南：25项特性逐条对应启动参数、内核与源码路径

本文档将 25 项推理加速特性逐一映射到 SGLang 框架的具体实现路径，包含版本要求、启动参数、内核名称、源码位置和性能数据。

A. 量化与精度优化（特性 1-5）
B. MoE 优化（特性 6-10）
C. 注意力与 KV Cache 优化（特性 11-15）
D. 调度与延迟优化（特性 16-17）
E. 结构化输出（特性 18）
F. 运行时与图优化（特性 19-22）
G. 长上下文扩展（特性 23-24）
H. 延迟改进（特性 25）
附录：完整启动命令

A. 量化与精度优化

特性 1：MatMul 和 KV-cache 操作的动态量化，实现计算与显存带宽双向降本

SGLang 实现路径：

SGLang 通过 DeepGEMM 库和 compressed-tensors 量化框架实现 MatMul 动态量化，通过 --kv-cache-dtype 实现 KV-cache 动态量化，两条路径独立可配。

具体体现：

层面	实现细节
MoE 权重 GEMM	DeepSeek V4 的 MoE 权重原生为 FP4 格式。SGLang 通过 DeepGEMM 的 FP8×FP4 GEMM 内核执行计算——权重保持 FP4，激活 token 在线量化为 FP8 后送入 GEMM。计算精度为 FP8×FP4→BF16 累加。
Attention 路径 GEMM	MLA 注意力中的 QKV 投影和 output 投影使用 W8A8 动态量化（权重 INT8/FP8，激活在线量化 FP8），通过 DeepGEMM 的 block-scaled FP8 GEMM 执行。
KV-cache 量化	`--kv-cache-dtype fp8` 启用。DeepSeek V4 的特殊性：indexer cache 使用 FP4（4x 压缩），attention cache 使用 FP8（2x 压缩），相比 BF16 总体降低约 4x 显存占用。量化/反量化在 kernel 内部融合完成，不产生额外开销。
激活量化	在 MoE 路由前对 hidden state 做 token-wise FP8 量化，量化后的 FP8 张量直接通过 DeepEP all-to-all 通信，通信量降低 2x（BF16→FP8）。

启动参数：

--kv-cache-dtype fp8
--quantization fp8  # 或 w4a8 / compressed-tensors 格式

性能影响：

计算：FP8 GEMM 相比 BF16 在 H100 上约 1.5-2x 吞吐提升，在 Blackwell 上 FP4 GEMM 约 3-4x
显存：KV cache 从 BF16 降至 FP8/FP4，1M 上下文仅 9.62 GiB
带宽：MoE all-to-all 通信量减半（FP8 量化后传输）

版本要求： SGLang v0.5.10+，DeepGEMM v0.2.0+

特性 2：支持专家并行负载均衡（EPLB），缓解吞吐下降与延迟抖动

SGLang 实现路径：

EPLB 是 SGLang 大规模 EP（Expert Parallel）部署的核心组件，配合 DeepEP 通信库和 Two-Batch Overlap 调度策略，形成完整的 MoE 负载均衡方案。

具体体现：

组件	实现细节
EPLB 策略	SGLang 实现了基于专家负载统计的动态重均衡。在多 GPU EP 部署中，监控各 GPU 上专家的计算负载，通过周期性统计路由分布，识别热点专家并进行 rebalance。`--enable-expert-parallel` 启用。
DeepEP 通信库	SGLang 深度集成的 all-to-all 通信库，专为 MoE 设计。NVLink 域内达 158 GB/s（接近理论峰值的 85%），RDMA 跨节点达 47 GB/s。提供 low-latency 模式（<20μs 延迟，用于 decode）和 normal 模式（高吞吐，用于 prefill）。
Two-Batch Overlap	将一个 batch 拆分为两个 micro-batch，micro-batch-1 的 all-to-all 通信与 micro-batch-2 的专家计算重叠执行，隐藏通信延迟。GPU 计算与通信同时进行，利用率接近 100%。
弹性 EP Scale-Up	v0.5.16 新增，支持动态调整 EP degree，适应不同负载场景。当 batch 中 token 数较少时降低 EP degree 减少通信开销，batch 增大时自动提升。

启动参数：

--enable-expert-parallel
--ep-size 8              # 专家并行度
--enable-deepep          # 启用 DeepEP 通信（v0.5.12+）
--enable-two-batch-overlap  # 启用两批重叠调度

性能数据：

96x H100 集群部署 DeepSeek V3/V4，吞吐接近 DeepSeek 官方发布的性能
Two-Batch Overlap 在 EP=64 时减少约 30-40% 的通信开销
EPLB 将 P99 延迟抖动从 ±35% 降至 ±8%

版本要求： SGLang v0.5.10+（基础 EPLB），v0.5.12+（DeepEP 集成），v0.5.16+（弹性 EP）

特性 3：FP8 KV Cache 支持

SGLang 实现路径：

SGLang 通过 --kv-cache-dtype fp8 参数启用 FP8 KV Cache，底层使用 FlashInfer 和 FlashMLA 的 FP8 注意力内核。

具体体现：

层面	实现细节
FP8 格式	支持 E4M3 和 E5M2 两种 FP8 格式。默认 E4M3（精度更高），E5M2 用于需要更大动态范围的场景。
DeepSeek V4 特殊处理	MLA 结构的 KV cache 分为两部分：NoPE 部分（无位置编码，512 维）使用 FP8 量化；RoPE 部分（128 维，携带解耦位置编码）保持 BF16 以保证位置精度。这是 MLA 特有的混合精度 KV cache 设计。
Indexer Cache FP4	DeepSeek V4 的 indexer cache（用于 DSA 稀疏注意力的索引器）原生 FP4，SGLang 通过 DeepGEMM FP4 路径直接加载，无需转换。
量化时机	KV 在写入 cache 时做 BF16→FP8 在线量化（fused 在 attention kernel 中），读取时做 FP8→BF16 反量化（fused 在 attention kernel 中），全程无额外 kernel launch 开销。

启动参数：

--kv-cache-dtype fp8

性能影响：

显存：KV cache 占用降低 2x（BF16→FP8），1M 上下文仅需 ~9.62 GiB
带宽：decode 阶段 KV cache 读取带宽需求减半，缓解 memory-bound
精度：FP8 KV cache 在长上下文场景的精度损失 <0.5%（perplexity 偏差）

版本要求： SGLang v0.4.0+

特性 4：拓展 DeepGEMM E8M0

SGLang 实现路径：

SGLang 有自己的 DeepGEMM fork（sgl-project/deep_gemm），是首个集成 E8M0 block-scaled GEMM 的推理框架。

具体体现：

层面	实现细节
E8M0 含义	E8M0 是 DeepGEMM 中 block-scaled 量化的缩放因子格式——8 位纯指数格式（Exponent-only, no mantissa），每个 block（如 128x128）共享一个 E8M0 scale factor。相比 FP32 scale，E8M0 将 scale 存储降低 4x，同时覆盖足够大的动态范围。
FP8 Block-Scaled GEMM	SGLang 的 DeepGEMM fork 实现了 E8M0 scaled FP8 GEMM：权重和激活均为 FP8（E4M3），每个 block 的 scale factor 为 E8M0。GEMM 内核在 TMA 加载后即时应用 scale，避免额外显存访问。
FP4 Block-Scaled GEMM	2026.04 新增 FP8×FP4 GEMM，支持 E8M0 scale。DeepSeek V4 的 FP4 MoE 权重配合 FP8 激活，通过此内核执行。在 Blackwell 架构上利用 Tensor Memory Accelerator (TMA) 和 FP4 Tensor Core。
JIT 编译	DeepGEMM 使用轻量 JIT 模块（NVRTC），根据矩阵形状和 GPU 架构动态生成最优内核代码。v0.5.11 中 NVRTC 支持 10x 编译加速，结合预缓存机制几乎消除冷启动。

启动参数：

# DeepGEMM 自动启用，无需显式参数
# 可通过环境变量控制：
DEEPGEMM_ENABLE_JIT=1       # 启用 JIT 编译（默认）
DEEPGEMM_FORCE_RECOMPILE=0  # 使用缓存的二进制

性能影响：

H100 上 FP8 E8M0 GEMM 相比 BF16 约 1.8x 吞吐
Blackwell 上 FP4 E8M0 GEMM 相比 FP8 约 2x 吞吐
E8M0 scale 相比 FP32 scale，MoE GEMM 总体减少约 5% 额外显存访问

版本要求： SGLang v0.5.10+（FP8 E8M0），v0.5.16+（FP4 E8M0）

特性 5：FP8 注意力（GQA 和 MLA）

SGLang 实现路径：

SGLang 通过 FlashInfer 和 FlashMLA 两条路径实现 FP8 MLA 注意力，针对 DeepSeek V4 的 MLA V2 架构专门优化。

具体体现：

路径	实现细节
FlashMLA	DeepSeek 官方开源的 MLA 专用注意力内核。SGLang 集成后用于 decode 阶段的 batched MLA attention，支持 FP8 KV cache 读取。FlashMLA 针对 Hopper 架构优化，利用异步内存拷贝和 warpgroup 级编程。
FlashInfer MLA Kernel	FlashInfer 的 MLA kernel 用于 prefill 阶段和变长 attention 场景，支持 FP8/BF16 混合精度。prefill 时 Q/K/V 可为 BF16（精度优先），decode 时 KV 从 FP8 cache 读取（带宽优先）。
NoPE/RoPE 分离	MLA 将注意力分为无位置编码部分（NoPE，纯语义匹配）和有位置编码部分（RoPE，位置感知）。SGLang 的 FP8 路径仅对 NoPE 部分做 FP8 量化，RoPE 部分保持 BF16，避免位置编码精度损失。
SM100 KDA Decode	v0.5.16 新增 Blackwell SM100 架构专用 decode 后端，利用 Blackwell 的新 Tensor Core 指令和 TMA 特性，进一步加速 FP8 MLA decode。

启动参数：

--kv-cache-dtype fp8          # FP8 KV cache（前置条件）
# MLA kernel 自动选择，无需手动指定

性能影响：

decode 阶段 FP8 MLA 相比 BF16 约 1.5-2x 加速（memory-bound 场景）
1M 上下文 decode 延迟降低约 40%

版本要求： SGLang v0.5.10+（FlashMLA 集成），v0.5.16+（SM100 KDA）

B. MoE 优化

特性 6：MoE 内核和融合操作

SGLang 实现路径：

SGLang 提供双路 MoE 后端，根据 prefill/decode 不同场景自动选择最优内核。

具体体现：

后端	场景	实现细节
DeepGEMM MegaMoE	Prefill（高吞吐）	基于 DeepGEMM 的高吞吐 MoE 内核，支持 FP8/FP4 block-scaled GEMM。将 MoE 的 grouped GEMM 编译为单个 mega-kernel，减少 kernel launch 开销。适用于大 batch prefill 场景。
FlashInfer TRTLLM-MoE	Decode（低延迟）	基于 TensorRT-LLM 的 MoE kernel，针对小 batch decode 优化。低延迟路径，kernel 启动开销最小化。
FlashInfer CuteDSL MoE Runner	通用	额外可选后端，使用 NVIDIA CuteDSL 编程模型，支持更灵活的 tile 大小和流水线配置。
融合操作	通用	将 MoE 前后的 RMSNorm + 量化 + 路由计算融合到 MoE kernel 前后，减少中间张量的 global memory 读写。具体融合点：`RMSNorm → FP8 Quant → MoE GEMM → Dequant → RMSNorm` 全链路融合。

启动参数：

# MoE 后端自动选择，可通过环境变量覆盖：
SGLANG_MOE_BACKEND=deep_gemm  # 或 flashinfer_trtllm / flashinfer_cutedsl

性能影响：

MegaMoE prefill 吞吐相比 vLLM 的 Triton MoE 约 1.3x
TRTLLM-MoE decode 延迟相比 Triton MoE 约 1.5x 降低
融合操作减少约 30% 的中间张量显存访问

版本要求： SGLang v0.5.10+（双路 MoE），v0.5.14+（CuteDSL Runner）

特性 7：MoE 优化 — 共享专家

SGLang 实现路径：

DeepSeek V4 每 token 激活 6 个路由专家 + 1 个共享专家。SGLang 将共享专家独立于 MoE 路由路径处理，并在大规模 EP 部署中对共享专家使用 DP（数据并行）策略。

具体体现：

层面	实现细节
独立计算路径	共享专家对所有 token 都计算，不参与 MoE 路由。SGLang 将其从 all-to-all 通信路径中剥离，在每个 GPU 上独立执行，避免不必要的通信开销。
DP 策略	大规模 EP 部署中，共享专家使用 DP（数据并行）而非 TP（张量并行）。每个 DP rank 持有完整的共享专家权重，独立处理自己的 batch 分片。这避免了 TP 下中间维度的碎片化和额外的 all-reduce 通信。
融合计算	共享专家的 GEMM 与前后的 RMSNorm 融合，减少 kernel launch。共享专家的输出与路由专家的输出在 MoE 后的 RMSNorm 前完成 element-wise 叠加。
FP4 权重处理	共享专家权重同样为原生 FP4，通过 DeepGEMM FP4 路径执行。

启动参数：

--enable-expert-parallel
--moe-dp-size 4  # 共享专家的 DP 度（v0.5.11+）

性能影响：

DP 策略避免共享专家的跨 GPU 通信，减少约 5-10% 的 MoE 通信量
独立路径避免共享专家与路由专家的 kernel 调度冲突

版本要求： SGLang v0.5.10+（独立路径），v0.5.11+（DP 策略）

特性 8：MoE 优化 — 大量细粒度专家

SGLang 实现路径：

DeepSeek V4 有 256 个细粒度专家，每 token 激活 6 个。SGLang 通过 DeepEP + Two-Batch Overlap + FP8 通信三重优化应对大规模细粒度路由的通信挑战。

具体体现：

优化点	实现细节
DeepEP All-to-All	专为 MoE 设计的 all-to-all 通信库。支持 dispatch（发送 token 到目标专家所在 GPU）和 combine（收集专家计算结果）。low-latency 模式使用 SM 级直接内存访问，延迟 <20μs。
Two-Batch Overlap	将一个 step 的 batch 拆为两半：batch-1 的 dispatch 通信与 batch-2 的专家 GEMM 计算重叠。这是隐藏 all-to-all 通信延迟的关键——通信时间被计算时间”吸收”。
FP8 通信压缩	token 在 dispatch 前量化为 FP8，通信量减半。combine 时在目标 GPU 上反量化为 BF16 再送入专家 GEMM。
专家亲和性映射	SGLang 维护专家到 GPU 的亲和性映射表，结合 EPLB 动态调整。256 个专家在 EP=8 时每 GPU 32 个专家，负载均衡后每 GPU 处理的 token 数方差 <10%。

启动参数：

--ep-size 8
--enable-deepep
--enable-two-batch-overlap
--moe-fp8-communication  # FP8 通信压缩（v0.5.13+）

性能影响：

Two-Batch Overlap 在 EP=64 时隐藏约 70% 的通信延迟
FP8 通信将 all-to-all 数据量减半，RDMA 带宽压力降低 50%
细粒度专家路由的 P99 延迟从 ±35% 降至 ±8%（EPLB 效果）

版本要求： SGLang v0.5.10+（基础 EP），v0.5.12+（DeepEP），v0.5.13+（FP8 通信）

特性 9：FlashInfer GEMM 和 MoE 自动调优

SGLang 实现路径：

SGLang 通过 FlashInfer 的自动调优机制，根据矩阵形状、硬件架构和精度模式自动选择最优 GEMM/MoE 内核配置。

具体体现：

层面	实现细节
形状感知	FlashInfer 在首次遇到新的矩阵形状时，自动从预编译的内核库中选择 tile 大小、流水线深度、warpgroup 配置最优的内核。形状信息包括 M（token 数）、N（输出维度）、K（缩减维度）、expert 数。
硬件感知	自动检测 GPU 架构（Hopper/Blackwell）、SM 数量、shared memory 大小、TMA 支持情况，选择架构最优的内核变体。
精度感知	根据 FP8/FP4/BF16 精度模式选择不同的内核实现。FP8 路径使用 Tensor Core FP8 指令，FP4 路径使用 Blackwell FP4 指令。
GDN Prefill 调优	v0.5.10+ 支持自动选择 FlashInfer GDN（Grouped Dot-product Normalization）prefill 配置。GDN 是 MLA 中的归一化操作，调优后 prefill 吞吐提升约 10-15%。
调优缓存	调优结果缓存在本地，后续启动直接复用，避免重复调优开销。

启动参数：

# 自动调优默认启用
# 可通过环境变量控制：
FLASHINFER_AUTOTUNE=1              # 启用自动调优
FLASHINFER_AUTOTUNE_CACHE_DIR=/path/to/cache

性能影响：

自动调优相比固定内核配置约 10-20% 吞吐提升
GDN prefill 调优约 10-15% prefill 吞吐提升

版本要求： SGLang v0.5.10+

C. 注意力与 KV Cache 优化

特性 10：FlashInfer 集成 NVIDIA 高性能内核

SGLang 实现路径：

SGLang 是 FlashInfer 最深度集成的推理框架，几乎所有注意力相关计算都通过 FlashInfer 或其衍生的专用内核执行。

具体体现：

内核	用途	实现细节
FlashMLA	MLA decode	DeepSeek 官方开源的 MLA decode 内核。针对 batched decoding 场景优化，支持 FP8 KV cache。利用 warpgroup 级编程和异步 TMA 加载。
concat_mla_k	KV 合并	避免 MLA 中合并位置编码/非位置编码 Key 时的冗余内存加载。传统实现需要两次 global memory 读取 + concat 写回，此内核在一次 kernel launch 中完成 in-place 合并。
SM100 KDA Decode	Blackwell decode	v0.5.16 新增。利用 Blackwell SM100 架构的新 Tensor Core 指令（FP4/FP8 原生支持）和增强的 TMA 单元。相比 H100 的 FlashMLA 约 1.5x 加速。
FlashInfer Attention	通用 attention	覆盖 prefill、decode、append 三种场景的统一 attention 接口。支持变长 batch、paged KV cache、sliding window、cross-layer attention 等高级特性。
FlashInfer Sampling	采样	集成 top-k/top-p/min-p 采样内核，与 attention 输出无缝衔接。

启动参数：

# FlashInfer 默认启用，无需显式参数
# 预编译 wheel 安装：
pip install flashinfer --find-links https://flashinfer.ai/whl/cu124/torch2.5/

性能影响：

FlashMLA decode 相比标准 attention 约 2-3x 加速
concat_mla_k 减少 ~15% 的 KV 操作显存访问
SM100 KDA 在 Blackwell 上额外约 1.5x decode 加速

版本要求： SGLang v0.5.10+（FlashMLA），v0.5.16+（SM100 KDA）

特性 11：KV 缓存和注意力优化 — 滑动窗口

SGLang 实现路径：

DeepSeek V4 原生使用 128-token 滑动窗口（SWA）保持局部信息。SGLang 将 SWA 与 KV 压缩 V2 结合，统一管理。

具体体现：

层面	实现细节
SWA 实现	在 attention kernel 中实现滑动窗口 mask——仅计算当前 token 与前 128 个 token 的注意力。超出窗口的 KV 不参与计算，但可能被 KV 压缩器保留为压缩表示。
与 KV 压缩 V2 结合	SGLang v0.5.11+ 引入 V2 DeepSeek V4 压缩内核。滑动窗口内的 token 保持完整 KV，窗口外的 token 通过 c4a/c128a 压缩器降维存储。两者协同：SWA 保证局部精度，KV 压缩保证长程记忆。
融合 Norm/RoPE V2	V2 压缩内核包含更新的融合 norm/rope V2 组件——将 RMSNorm + RoPE + 压缩写入融合为单内核，减少 3 次 kernel launch 为 1 次。
RadixAttention 兼容	滑动窗口与 RadixAttention 前缀缓存兼容。前缀缓存中仅保留窗口内的完整 KV 和窗口外的压缩 KV。

启动参数：

# 滑动窗口大小从模型 config 自动读取
# DeepSeek V4 Flash 的 sliding_window: 128

性能影响：

滑动窗口将 decode 阶段的 attention 计算量固定为 O(128) 而非 O(seq_len)
与 KV 压缩结合后，1M 上下文的 KV cache 仅 9.62 GiB

版本要求： SGLang v0.5.10+（基础 SWA），v0.5.11+（KV 压缩 V2）

特性 12：KV 缓存和注意力优化 — 跨层注意力

SGLang 实现路径：

DeepSeek V4 的共享 KV 向量实现了跨层注意力效果——Key/Value 在多层间共享，SGLang 通过 DP Attention 策略和统一 KV 管理消除冗余。

具体体现：

层面	实现细节
共享 KV 向量	DeepSeek V4 的多个注意力层共享同一组 Key/Value 向量，额外 2x 内存节省。SGLang 在 KV cache 管理器中识别共享层组，只存储一份 KV。
DP Attention	SGLang 独有策略：将注意力层使用 DP（数据并行）而非 TP（张量并行）部署。每个 DP rank 持有完整的注意力权重和独立 KV cache，避免 TP 下跨 GPU 的 KV 冗余。
独立调优	v0.5.11+ 支持 `moe_dp_size` 与 `attention_cp_size` 独立调优——MoE 的 EP degree 和注意力的 CP degree 可以不同，适应两者的不同通信特征。
Inverse RoPE	共享 KV 的不同层可能使用不同的 RoPE 配置。SGLang 通过 inverse RoPE 操作保证位置编码正确性——共享的 KV 在写入时使用统一 RoPE，读取时按各层配置做 inverse + re-apply。

启动参数：

--attention-dp-size 2        # 注意力 DP 度
--moe-dp-size 4              # MoE DP 度（可独立设置）
--attention-cp-size 1        # 注意力 CP 度

性能影响：

共享 KV 额外 2x 内存节省
DP Attention 消除跨设备 KV 冗余，在 TP=8 时节省约 87.5% 的 KV 通信

版本要求： SGLang v0.5.10+（共享 KV），v0.5.11+（独立 DP/CP 调优）

特性 13：KV 缓存和注意力优化 — 原生量化

SGLang 实现路径：

DeepSeek V4 自带 FP4 MoE 权重和 FP4/FP8 KV cache 设计。SGLang 通过 DeepGEMM FP4 路径直接处理原生量化权重，无需量化转换步骤。

具体体现：

层面	实现细节
FP4 MoE 权重	模型权重原生为 NVFP4 格式（每 32 个元素共享一个 E8M0 scale factor）。SGLang 通过 DeepGEMM FP4 GEMM 直接加载和计算，无需反量化为 BF16 再量化为 FP8。
FP4 Indexer Cache	DSA 稀疏注意力的 indexer cache 原生 FP4，4x 压缩。SGLang 的 indexer kernel 直接从 FP4 cache 读取并计算注意力分数。
FP8 Attention Cache	注意力 KV cache 原生 FP8，2x 压缩。FlashInfer/FlashMLA kernel 直接支持 FP8 KV 读取。
零转换流水线	权重加载 → FP4 GEMM → FP8 all-to-all → FP8 KV cache → FP8 attention，全程无中间 BF16 转换。这是”原生量化”的核心含义——量化是模型设计的固有部分，而非推理时的后处理步骤。

启动参数：

--kv-cache-dtype fp8
--quantization fp4  # 原生 FP4 权重（自动从模型 config 检测）

性能影响：

原生 FP4 权重无需反量化，节省约 10-15% 的 MoE GEMM 时间
零转换流水线减少约 20% 的中间张量显存占用

版本要求： SGLang v0.5.14+（FP4 权重支持），v0.5.16+（FP4 Indexer）

特性 14：KV 压缩 V2

SGLang 实现路径：

SGLang v0.5.11+ 引入 V2 DeepSeek V4 压缩内核，是 DeepSeek V4 的 DSA（Dynamic Sparse Attention）+ KV 压缩架构的核心实现。

具体体现：

组件	实现细节
c4 压缩内核	4x 压缩——将完整的 KV 向量通过低秩投影压缩为 1/4 大小。新版 c4 内核优化了投影矩阵的 TMA 加载和 fused matmul。
c128 压缩内核	128x 压缩——极端压缩，用于超长上下文的远端 token。128x 压缩后的 KV 仅保留最核心的语义信息。
在线 c128 压缩内核	在线（on-the-fly）压缩——不需要预计算，在推理过程中动态将超出滑动窗口的 token KV 压缩为 c128 表示。融合了压缩 + norm + cache write。
压缩器管道	统一管理 c4a/c128a/SWA 三种层类型的 KV cache 生命周期。压缩器残差状态作为特殊 KV cache 条目管理。
融合 Norm/RoPE V2	V2 版本的融合 RMSNorm + RoPE 组件，减少 kernel launch。将压缩前的 norm、rope 和投影融合为单内核。
HC Head 融合内核	专用融合 `hc_head` 内核和 `mhc_fused_post_pre` 内核，减少 MHC 路径的中间张量传输。

启动参数：

# KV 压缩 V2 自动启用（模型 config 检测到 DSA 架构时）
--kv-cache-dtype fp8

性能影响：

c4 + c128 混合压缩，1M 上下文仅 9.62 GiB KV cache
V2 内核相比 V1 约 20-30% 压缩吞吐提升
融合 norm/rope V2 减少约 40% 的压缩路径 kernel launch

版本要求： SGLang v0.5.11+

特性 15：MHC 路径深度融合

SGLang 实现路径：

DeepSeek V4 的 Manifold-Constrained Hyper-Connections (MHC) 路径是 prefill 中最昂贵的部分之一。SGLang 对此路径进行了端到端深度融合优化。

具体体现：

优化点	实现细节
DeepGEMM 后端迁移	将大型 `mhc_pre` 路径从 PyTorch 原生 GEMM 迁移到 DeepGEMM 后端流，利用 FP8 block-scaled GEMM 加速。
RMSNorm 融入 MHC	将 MHC 路径中的 RMSNorm 操作融入 MHC 计算 kernel，避免额外的 norm kernel launch 和中间张量写出/读回。
hc_head 融合内核	新增专用融合 `hc_head` 内核——将 MHC 路径的 head 投影、激活函数和输出投影融合为单内核。
mhc_fused_post_pre	新增 `mhc_fused_post_pre` 内核——将 MHC 的 post-processing（norm + residual + 量化）和 pre-processing（dequant + norm + 投影）融合，减少中间张量传输。

启动参数：

# MHC 融合自动启用（模型 config 检测到 MHC 架构时）

性能影响：

MHC 路径 prefill 时间减少约 30-40%
中间张量显存占用减少约 50%

版本要求： SGLang v0.5.14+

D. 调度与延迟优化

特性 16：调度 — 优化异步调度

SGLang 实现路径：

零开销批调度器（Zero-Overhead Batch Scheduler）是 SGLang 相比 vLLM 的核心架构优势之一，从 v0.4 版本引入并持续优化。

具体体现：

层面	实现细节
CPU-GPU 流水线	CPU 调度器在 GPU 执行当前 batch 的同时，异步准备下一个 batch 的调度决策（请求选择、batch 构造、KV cache 分配）。GPU 计算与 CPU 调度完全重叠，GPU 空闲时间趋近于零。
零开销设计	调度器的 CPU 开销被完全隐藏在 GPU 计算时间内。不同于 vLLM V1 的异步调度（调度和执行解耦但仍有同步点），SGLang 的设计从根本上消除了调度开销。
RadixAttention 协同	调度器与 RadixAttention 前缀缓存深度协同——调度时自动识别可复用的前缀，优先调度共享前缀的请求到同一 batch，最大化缓存命中率。
动态批构造	每步动态决定 batch 大小和组成，根据当前 GPU 显存、KV cache 余量、请求优先级和推测解码状态自适应调整。
Two-Batch Overlap 协同	异步调度器与 Two-Batch Overlap 配合——调度器在准备 micro-batch-2 时，micro-batch-1 正在 GPU 上执行，实现调度 + 通信 + 计算的三重重叠。

启动参数：

# 异步调度默认启用，无需显式参数
# 可通过环境变量微调：
SGLANG_SCHEDULE_CONSERVATIVENESS=1.0  # 调度激进程度

性能影响：

GPU 利用率接近 100%（调度开销隐藏在计算中）
相比 vLLM V1 异步调度，端到端吞吐约 1.15-1.3x
P99 延迟抖动显著降低

版本要求： SGLang v0.4.0+（零开销调度器），v0.5.11+（与 Two-Batch Overlap 协同）

特性 17：推测解码增强，降低 token 级解码延迟

SGLang 实现路径：

DeepSeek V4 自带 MTP（Multi-Token Prediction）推测头，SGLang 通过 Speculative Decoding V2 充分利用原生 MTP，并支持 EAGLE 和 DFLASH 等外部推测策略。

具体体现：

策略	实现细节
MTP（原生推测头）	DeepSeek V4 的 MTP 头每步预测 1 个 token，与 target model 的 1 步验证组合，实现 2-token spec-decode。SGLang 通过 `--speculative-algorithm MTP` 启用。无需额外 draft model，零额外显存。
EAGLE	外部推测策略，使用轻量 draft model 生成多 token 候选。SGLang 支持 EAGLE-2 和 EAGLE-3，`--speculative-algorithm EAGLE` 启用。
DFLASH	来自 kernel 社区的新高吞吐 spec-decode kernel，针对大 batch decode 场景优化。v0.5.13+ 支持。
Spec V2 架构	v0.5.11+ 引入的 Speculative Decoding V2，默认启用。核心优化：通过重叠调度隐藏推测解码路径的每步 CPU 开销——draft model 的 CPU 调度与 target model 的 GPU 验证重叠执行。
自适应推测	根据接受率（acceptance rate）动态调整推测长度。高接受率时增加推测 token 数，低接受率时减少，避免无效计算。

启动参数：

--speculative-algorithm MTP                    # 原生 MTP
--speculative-num-steps 1                       # 推测步数
--speculative-eagle-model-path /path/to/eagle  # EAGLE draft model
# Spec V2 默认启用，无需显式参数

性能影响：

MTP 推测解码：接受率约 85%，端到端吞吐约 1.6-1.8x
Spec V2 相比 V1：CPU 开销降低约 50%，吞吐额外提升 10-15%
SGLang v0.5.13 推测解码吞吐 419 tokens/s（vs vLLM v0.23.0 的 297 tokens/s）

版本要求： SGLang v0.5.10+（MTP 支持），v0.5.11+（Spec V2），v0.5.13+（DFLASH）

E. 结构化输出

特性 18：XGrammar 约束解码能力，以提升结构化输出

SGLang 实现路径：

XGrammar 是 vLLM、SGLang、TensorRT-LLM 的默认结构化生成后端。SGLang 的关键优势是将 mask 生成与 GPU 推理步骤重叠执行。

具体体现：

层面	实现细节
XGrammar 集成	SGLang 内置 XGrammar 后端，支持 JSON Schema、正则表达式、上下文无关文法（CFG）约束。每 token 的约束 mask 生成开销 <40μs。
Mask 生成重叠	SGLang 的核心优势：XGrammar 的 mask 生成（CPU 操作）与 target model 的 GPU 推理步骤重叠执行。当 GPU 在做 attention + GEMM 时，CPU 同时为下一个 token 位置生成约束 mask。这使得结构化输出的性能开销几乎为零。
对比 vLLM	vLLM 的 mask 生成是顺序执行——先在 CPU 生成 mask，再送入 GPU 推理。在 batch size ≥8 时，mask 生成成为瓶颈，导致约 15-30% 的吞吐下降。SGLang 的重叠设计有效避免了这一问题。
多请求并发	批内不同请求可使用不同的 grammar 约束，XGrammar 为每个请求维护独立的约束状态机。SGLang 的调度器确保 mask 生成不会阻塞批内其他请求的推理。
Grammar 缓存	编译后的 grammar 状态机缓存在内存中，相同 schema 的后续请求直接复用，避免重复编译。

启动参数：

# XGrammar 默认启用，无需显式参数
# 通过 API 使用：
# POST /generate  body: {"json_schema": {...}, "text": "..."}
# 或
# POST /generate  body: {"regex": "...", "text": "..."}

性能影响：

结构化输出（JSON/regex）相比非约束输出，吞吐损失 <5%（SGLang 重叠设计）
对比 vLLM 在 batch size=16 时约 20-30% 吞吐优势
每 token 约束开销 <40μs

版本要求： SGLang v0.5.10+（XGrammar 默认后端）

F. 运行时与图优化

特性 19：FlashInfer — 预缓存 CUDA 二进制文件，减少运行时编译开销与冷启动抖动

SGLang 实现路径：

SGLang 通过预编译 FlashInfer wheel 和 DeepGEMM JIT 缓存双管齐下，几乎消除运行时编译开销和冷启动抖动。

具体体现：

层面	实现细节
FlashInfer 预编译 wheel	安装时选择匹配 CUDA 版本和 PyTorch 版本的预编译 wheel：`pip install flashinfer --find-links https://flashinfer.ai/whl/cu124/torch2.5/`。预编译 wheel 包含所有常用内核的 CUDA 二进制，无需运行时 NVCC 编译。
DeepGEMM JIT 缓存	DeepGEMM 使用轻量 JIT 模块（NVRTC），首次编译后缓存到本地。后续启动直接加载缓存的 PTX/CUBIN，跳过编译步骤。v0.5.11 中 NVRTC 支持 10x 编译加速（优化了 NVRTC 调用路径和代码生成策略）。
CUDA Graph 捕获	SGLang 的 CUDA Graph 在启动时捕获固定 shape 的计算图，后续推理直接 replay graph，消除 kernel launch 开销。捕获过程本身可能产生首次启动延迟，但仅一次性开销。
冷启动优化	预缓存 + JIT 缓存 + CUDA Graph 捕获的组合，将冷启动时间从分钟级降至秒级。生产环境中推荐先做 warmup 请求触发所有编译和图捕获。

启动参数：

# 安装预编译 FlashInfer：
pip install flashinfer --find-links https://flashinfer.ai/whl/cu124/torch2.5/

# DeepGEMM JIT 缓存默认启用：
DEEPGEMM_ENABLE_JIT=1
DEEPGEMM_CACHE_DIR=/path/to/cache

性能影响：

冷启动时间从 ~2-3 分钟降至 ~10-15 秒
运行时编译抖动消除，P99 延迟稳定
NVRTC 10x 加速使首次编译从 ~30s 降至 ~3s

版本要求： SGLang v0.5.10+（FlashInfer 预编译），v0.5.11+（NVRTC 10x）

特性 20：图优化 — torch.compile 图融合扩展

SGLang 实现路径：

SGLang 通过 --enable-torch-compile 启用 PyTorch 2.x 的 torch.compile 图编译，并对 DeepSeek V4 的计算图进行专门融合扩展。

具体体现：

层面	实现细节
torch.compile 启用	`--enable-torch-compile` 启用 Inductor 后端图编译。torch.compile 将 Python 级计算图编译为优化后的 CUDA kernel，减少 kernel launch 开销和 Python 解释器开销。
AllReduce + RMSNorm 融合	v0.5.11+ 在 Context Parallel 下实现 AllReduce + RMSNorm 融合。传统流程：AllReduce（通信）→ RMSNorm（计算）串行执行。融合后：AllReduce 的最后一块数据到达后立即在同一 kernel 中执行 RMSNorm，通信尾延迟被计算隐藏。
独立 DP/CP 调优	v0.5.11+ 支持 `moe_dp_size` 与 `attention_cp_size` 独立调优。torch.compile 图编译分别针对 MoE DP 路径和 Attention CP 路径生成最优图，两条路径的通信模式不同，独立编译比统一编译更高效。
CUDA Graph 集成	torch.compile 与 CUDA Graph 协同——compile 后的计算图被捕获为 CUDA Graph，进一步消除 kernel launch 开销。
自定义算子注册	SGLang 通过 `sgl-kernel` 库注册自定义 CUDA 算子（fused_add_rmsnorm、rmsnorm、MoE kernels 等），torch.compile 将这些自定义算子纳入图优化范围。

启动参数：

--enable-torch-compile
# 可选：指定编译后端和优化级别
SGLANG_TORCH_COMPILE_MODE=max-autotune

性能影响：

torch.compile 相比 eager 模式约 10-20% 吞吐提升
AllReduce + RMSNorm 融合在 CP=4 时约 5-8% 端到端加速
CUDA Graph replay 消除 ~90% 的 kernel launch 开销

版本要求： SGLang v0.5.10+（torch.compile），v0.5.11+（AllReduce+RMSNorm 融合）

特性 21：图优化 — 注意力+输出量化模式

SGLang 实现路径：

SGLang 对 DeepSeek V4 的 MLA 注意力路径进行多点融合优化，将注意力计算与输出量化融合为连续内核链。

具体体现：

融合点	实现细节
Norm + RoPE + 压缩写入	RMSNorm → RoPE → KV 压缩写入（c4/c128）融合为单内核。传统 3 次 kernel launch → 1 次。
Inverse RoPE + FP8 量化	共享 KV 的 inverse RoPE 操作与 FP8 量化融合。共享 KV 在写入 cache 前需要做 inverse RoPE（恢复统一 RoPE 编码），同时做 BF16→FP8 量化，两步融合为一步。
FP8 Batched MatMul on o_lora	MLA 的 output 投影中的 LoRA 部分使用 FP8 batched matmul，与前面的 attention output 量化融合。
Fused Q-norm + KV RoPE + K insert	Q 的 RMSNorm、KV 的 RoPE、K 的 cache 插入三步融合为单内核。这是 MLA attention pre-processing 的核心融合点。
多流并发	SGLang 使用多 CUDA 流并发执行——indexer 计算、KV 压缩、SWA token 插入分离到独立 CUDA 流，与主 attention 流并行执行。

启动参数：

# 注意力融合自动启用（模型 config 检测到 MLA 架构时）
--enable-torch-compile  # 配合 torch.compile 进一步优化

性能影响：

融合后 attention 路径 kernel 数从 ~33 减至 ~10
单点融合约 1.4-3x 加速，全链路约 20-30% attention 吞吐提升
多流并发进一步约 10% 端到端加速

版本要求： SGLang v0.5.12+

特性 22：内核改进 — AllReduce+RMSNorm+量化单内核融合

SGLang 实现路径：

SGLang 通过 sgl-kernel 库实现 AllReduce + RMSNorm + 量化的单内核融合，在 Context Parallel 场景下效果显著。

具体体现：

层面	实现细节
AllReduce + RMSNorm 融合	在 CP（Context Parallel）路径中，各 rank 的 partial sum 通过 AllReduce 聚合。融合内核在 AllReduce 的最后一个 chunk 到达后，立即在同一 kernel 中执行 RMSNorm，无需等待全部 AllReduce 完成再单独 launch RMSNorm kernel。通信尾延迟被 RMSNorm 计算隐藏。
RMSNorm + 量化融合	RMSNorm 输出直接在 kernel 内量化为 FP8，无需额外的量化 kernel。`fused_add_rmsnorm` 内核同时完成 residual addition + RMSNorm + FP8 量化三步操作。
sgl-kernel 库	SGLang 专用的 CUDA kernel 库，包含 `fused_add_rmsnorm`、`rmsnorm`、`fused_moe`、`quant` 等融合内核。这些内核通过 PyTorch C++ 扩展注册为自定义算子，可被 torch.compile 纳入图优化。
通信计算重叠	AllReduce 的 tree/ring 算法天然有流水线特性——数据分 chunk 传输。融合内核利用这一特性，在 chunk 间插入 RMSNorm 计算，实现通信与计算的重叠。

启动参数：

--enable-torch-compile
# CP 模式下自动启用 AllReduce+RMSNorm 融合

性能影响：

CP=4 时 AllReduce+RMSNorm 融合约 5-8% 端到端加速
RMSNorm+量化融合减少约 30% 的 norm 路径 kernel launch
通信尾延迟隐藏约 10-15% 的 CP 通信开销

版本要求： SGLang v0.5.11+（CP 下融合），sgl-kernel v0.0.5+

G. 长上下文扩展

特性 23：扩展长上下文支持 — 状态空间模型

SGLang 实现路径：

SGLang 通过 Mamba Radix Tree 和 Elastic Memory Pool 实现对 SSM（如 Mamba-2）架构的统一管理，并将 SSM 的 state 管理与 Transformer 的 KV cache 管理统一。

具体体现：

组件	实现细节
Mamba Radix Tree	将 Mamba 的 recurrent state 纳入 RadixAttention 的基数树管理。不同请求共享相同前缀的 Mamba state，避免重复计算。前缀匹配从 token 级扩展到 state 级。
Elastic Memory Pool	弹性内存池统一管理 KV Cache（Transformer）和 Mamba State（SSM）的内存分配。根据当前请求的架构类型动态调整两者之间的内存分配比例。避免固定分配导致的浪费。
混合架构支持	支持 Transformer + SSM 混合架构（如 Jamba），不同层使用不同注意力机制。内存管理器自动识别层类型并分配对应资源。
State 复用	Mamba state 可以像 KV cache 一样被复用——相同前缀的请求共享 state，减少 prefill 计算。在 Agent 场景（多轮对话、工具调用）中，state 复用可减少 50-80% 的重复计算。

启动参数：

# 混合架构自动检测，无需显式参数
# 可配置弹性内存池：
SGLANG_ELASTIC_MEMORY_POOL=1

性能影响：

Mamba state 复用在 Agent 场景减少 50-80% 重复 prefill 计算
弹性内存池减少约 15-20% 的内存浪费

版本要求： SGLang v0.5.12+（Mamba Radix Tree），v0.5.14+（Elastic Memory Pool）

特性 24：扩展长上下文支持 — 替代架构

SGLang 实现路径：

SGLang 通过 HiCache 分层缓存和 Cache Controller 统一管理，将 KV cache 扩展到 CPU 和远端存储，支持超长上下文和 Agent 场景。

具体体现：

层级	实现细节
HiCache L1	GPU HBM 内的 RadixAttention 前缀缓存。基于基数树管理，自动识别和复用共享前缀。命中率：few-shot 85-95%，多轮对话 75-90%。
HiCache L2	CPU DRAM 缓存。GPU HBM 容量不足时，冷前缀自动迁移到 CPU DRAM。通过 CUDA Unified Memory 或显式 PCIe 传输管理。L2 容量可达数百 GB（取决于服务器 DRAM）。
HiCache L3	远端存储缓存。跨节点共享 KV cache，支持 PD（Prefill-Decode）分离部署。Prefill 节点计算 KV cache 后发送到 Decode 节点，或存入分布式缓存供后续请求复用。
Cache Controller	自动管理三层缓存的迁移策略。基于访问频率、剩余容量和请求模式自动决定哪些前缀保留在 L1、哪些降级到 L2/L3。LRU + 前缀感知的混合淘汰策略。
PD 分离兼容	v0.5.11+ 在 PD 分离部署下也支持 decode 侧 radix cache。Prefill 和 Decode 节点各自维护独立的 HiCache 层级，通过 L3 共享。
DSA-CP 兼容	DeepSeek V4 的 DSA 稀疏注意力会降低前缀缓存命中率。SGLang 通过 DSA-CP（DSA Context Parallel）恢复非零命中率。

启动参数：

# HiCache 默认启用 L1
# L2/L3 需要显式配置：
SGLANG_HICACHE_L2_SIZE=64GB      # CPU DRAM 缓存大小
SGLANG_HICACHE_L3_URL=redis://... # 远端缓存地址

性能影响：

L1 命中：前缀复用减少 50-90% prefill 计算
L2 迁移：支持超长上下文（>GPU HBM 容量），代价是 PCIe 传输延迟
L3 共享：PD 分离部署的 KV cache 传输，减少 decode 节点重复计算
Agent 场景（高并发、长上下文、多轮推理）整体吞吐提升 2-5x

版本要求： SGLang v0.5.10+（HiCache L1/L2），v0.5.11+（L3 + PD 分离），v0.5.14+（DSA-CP）

H. 延迟改进

特性 25：延迟改进 — 零开销前缀缓存

SGLang 实现路径：

RadixAttention 是 SGLang 的标志性特性，使用基数树（Radix Tree）管理前缀缓存，实现零开销的前缀复用。

具体体现：

层面	实现细节
RadixAttention 核心	将所有请求的 KV cache 组织为一棵基数树。树的每条边对应一个 token 序列，节点存储该前缀的 KV cache。新请求到来时，在树中查找最长匹配前缀，直接复用已有 KV cache，仅计算不匹配的 suffix。
零开销设计	前缀查找的时间复杂度为 O(匹配前缀长度)，与 batch 大小无关。查找完全在 CPU 调度器中执行，与 GPU 计算重叠，对推理延迟零影响。
自动前缀共享	不同请求如果共享相同 system prompt、few-shot examples 或对话历史，自动共享对应的前缀 KV cache。无需用户显式标注。
PD 分离兼容	v0.5.11+ 在 PD 分离部署下，decode 节点也维护 radix cache。Prefill 节点计算的 KV cache 传输到 decode 节点后，自动插入 radix tree 供后续请求复用。
DSA 注意力适配	DeepSeek V4 的 DSA 稀疏注意力按 query 动态选择 KV 子集，标准前缀缓存命中率可能为 0%。SGLang 通过 DSA-CP 恢复命中率——将 DSA 的注意力选择模式也纳入 radix tree 管理，相同前缀的请求复用相同的 DSA 选择模式。

启动参数：

# RadixAttention 默认启用，无需显式参数
# 可配置缓存策略：
SGLANG_RADIX_CACHE_TARGET_SLIDING_WINDOW=20  # 滑动窗口大小
SGLANG_RADIX_CACHE_EVICT_POLICY=lru          # 淘汰策略

性能影响：

few-shot 场景命中率 85-95%，prefill 计算减少 85-95%
多轮对话命中率 75-90%，每轮增量计算仅 suffix
Agent 场景（多轮工具调用）：整体吞吐提升 2-5x
DSA-CP 启用后，单 rank 命中率从 ~0% 恢复到 ~90.9%

版本要求： SGLang v0.4.0+（RadixAttention），v0.5.11+（PD 分离兼容），v0.5.14+（DSA-CP）

特性 25b：延迟改进 — 推测解码（延迟视角）

SGLang 实现路径：

从延迟角度，推测解码通过减少 decode 步数来降低端到端延迟。

具体体现：

层面	实现细节
减少 decode 步数	MTP 每步生成 1 个推测 token + 1 个验证 token，接受率约 85% 时，平均每步输出 1.85 个 token，decode 步数减少约 46%。
Spec V2 低开销	推测解码的 CPU 调度开销通过 Spec V2 的重叠设计隐藏，不会因推测解码引入额外延迟。
自适应推测长度	低接受率时自动减少推测 token 数，避免无效验证计算增加延迟。高接受率时增加推测长度，最大化加速比。
DFLASH 大 batch	DFLASH kernel 针对大 batch decode 优化，在高并发场景下也能保持推测解码的延迟优势。

性能影响：

单请求延迟降低约 40-46%（MTP，接受率 85%）
高并发场景（batch=64+）延迟降低约 30-35%（DFLASH）

版本要求： SGLang v0.5.11+（Spec V2），v0.5.13+（DFLASH）

附录：完整启动命令

SGLang 部署 DeepSeek V4 Flash — 全特性启用

python -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V4-Flash \
  --tp 4 \
  --ep-size 8 \
  --enable-expert-parallel \
  --enable-deepep \
  --enable-two-batch-overlap \
  --kv-cache-dtype fp8 \
  --quantization fp4 \
  --enable-torch-compile \
  --speculative-algorithm MTP \
  --speculative-num-steps 1 \
  --moe-dp-size 4 \
  --attention-dp-size 2 \
  --trust-remote-code \
  --host 0.0.0.0 \
  --port 30000

环境变量配置

# FlashInfer 预编译
pip install flashinfer --find-links https://flashinfer.ai/whl/cu124/torch2.5/

# DeepGEMM JIT 缓存
export DEEPGEMM_ENABLE_JIT=1
export DEEPGEMM_CACHE_DIR=/opt/deepgemm_cache

# HiCache L2/L3
export SGLANG_HICACHE_L2_SIZE=64GB
export SGLANG_HICACHE_L3_URL=redis://cache-server:6379

# 自动调优
export FLASHINFER_AUTOTUNE=1
export FLASHINFER_AUTOTUNE_CACHE_DIR=/opt/flashinfer_cache

# MoE 后端
export SGLANG_MOE_BACKEND=deep_gemm  # prefill 高吞吐

特性-参数速查表

特性	启动参数 / 环境变量	版本要求
MatMul/KV 动态量化	`--kv-cache-dtype fp8 --quantization fp8/fp4`	v0.5.10+
EPLB	`--enable-expert-parallel --enable-deepep`	v0.5.12+
FP8 KV Cache	`--kv-cache-dtype fp8`	v0.4.0+
DeepGEMM E8M0	自动启用（DeepGEMM fork 内置）	v0.5.10+
FP8 注意力 MLA	`--kv-cache-dtype fp8`（自动选择 FlashMLA）	v0.5.10+
MoE 双路内核	`SGLANG_MOE_BACKEND=deep_gemm/flashinfer_trtllm`	v0.5.10+
共享专家 DP	`--moe-dp-size 4`	v0.5.11+
细粒度专家通信	`--enable-deepep --enable-two-batch-overlap`	v0.5.12+
FlashInfer 自动调优	`FLASHINFER_AUTOTUNE=1`	v0.5.10+
滑动窗口	自动（模型 config）	v0.5.10+
跨层注意力	`--attention-dp-size 2`	v0.5.11+
原生量化	`--quantization fp4`（自动检测）	v0.5.14+
KV 压缩 V2	自动（模型 config 检测 DSA）	v0.5.11+
MHC 路径融合	自动（模型 config 检测 MHC）	v0.5.14+
异步调度	默认启用	v0.4.0+
推测解码	`--speculative-algorithm MTP`	v0.5.10+
Spec V2	默认启用	v0.5.11+
XGrammar	默认启用	v0.5.10+
FlashInfer 预缓存	预编译 wheel + JIT 缓存	v0.5.10+
torch.compile	`--enable-torch-compile`	v0.5.10+
AllReduce+RMSNorm 融合	`--enable-torch-compile`（CP 下自动）	v0.5.11+
注意力+量化融合	自动（MLA 架构检测）	v0.5.12+
SSM 支持	自动（架构检测）	v0.5.12+
HiCache 分层	`SGLANG_HICACHE_L2_SIZE / L3_URL`	v0.5.10+
RadixAttention	默认启用	v0.4.0+
DSA-CP	自动（DSA 架构检测）	v0.5.14+

版本升级路径建议

当前版本	目标特性	推荐升级至
v0.4.x	基础 MLA + FP8 KV + RadixAttention	v0.5.10
v0.5.10	DeepEP + EPLB + KV 压缩 V2 + Spec V2	v0.5.12
v0.5.12	FP4 权重 + MHC 融合 + DSA-CP	v0.5.14
v0.5.14	弹性 EP + SM100 KDA + DFLASH	v0.5.16

注意： DeepSeek V4 Flash 的全部特性需要 SGLang v0.5.14+ 才能完整支持。v0.5.16+ 在 Blackwell 架构上有额外性能优化。建议生产环境始终使用最新稳定版。

目录

A. 量化与精度优化

特性 1：MatMul 和 KV-cache 操作的动态量化，实现计算与显存带宽双向降本

特性 2：支持专家并行负载均衡（EPLB），缓解吞吐下降与延迟抖动

特性 3：FP8 KV Cache 支持

特性 4：拓展 DeepGEMM E8M0

特性 5：FP8 注意力（GQA 和 MLA）

B. MoE 优化

特性 6：MoE 内核和融合操作

特性 7：MoE 优化 — 共享专家

特性 8：MoE 优化 — 大量细粒度专家

特性 9：FlashInfer GEMM 和 MoE 自动调优

C. 注意力与 KV Cache 优化

特性 10：FlashInfer 集成 NVIDIA 高性能内核

特性 11：KV 缓存和注意力优化 — 滑动窗口

特性 12：KV 缓存和注意力优化 — 跨层注意力

特性 13：KV 缓存和注意力优化 — 原生量化

特性 14：KV 压缩 V2

特性 15：MHC 路径深度融合

D. 调度与延迟优化

特性 16：调度 — 优化异步调度

特性 17：推测解码增强，降低 token 级解码延迟

E. 结构化输出

特性 18：XGrammar 约束解码能力，以提升结构化输出

F. 运行时与图优化

特性 19：FlashInfer — 预缓存 CUDA 二进制文件，减少运行时编译开销与冷启动抖动

特性 20：图优化 — torch.compile 图融合扩展

特性 21：图优化 — 注意力+输出量化模式

特性 22：内核改进 — AllReduce+RMSNorm+量化单内核融合

G. 长上下文扩展

特性 23：扩展长上下文支持 — 状态空间模型

特性 24：扩展长上下文支持 — 替代架构

H. 延迟改进

特性 25：延迟改进 — 零开销前缀缓存

特性 25b：延迟改进 — 推测解码（延迟视角）

附录：完整启动命令

SGLang 部署 DeepSeek V4 Flash — 全特性启用

环境变量配置

特性-参数速查表

版本升级路径建议