DeepSeek V4 Flash推理加速指南：vLLM与SGLang双框架25项特性逐条解析

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

---

目录

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

---

A. 量化与精度优化

本文同时覆盖 vLLM 与 SGLang 两大推理框架的 DeepSeek V4 Flash 部署优化。每个特性先给出 vLLM 启动参数，再补充 SGLang 对应配置。

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

vLLM 实现路径：

vLLM 通过 HybridKVCache 管理器和分层量化策略实现 MatMul 与 KV-cache 的动态量化。DeepSeek V4 Flash 的部署中，量化路径分为 MoE 权重量化、注意力 GEMM 量化和 KV cache 量化三个独立维度，彼此可独立配置。

具体体现：

层面	实现细节
MoE 权重 GEMM	DeepSeek V4 的 MoE 权重原生为 FP4 格式（NVFP4），vLLM 在 Blackwell 架构上通过 TRTLLM-Gen 内核进行 NVFP4 GEMM。激活 token 在进入 MoE 前在线量化为 FP4，然后通过 FP4 Tensor Core 执行 GEMM，结果以 BF16 累加。在 Hopper 架构上，使用 TRTLLM FP8 MoE 内核：FP4 权重反量化为 FP8 后与 FP8 激活执行 block-scaled GEMM。
Attention 路径 GEMM	MLA 注意力中的 QKV 投影使用 FP8 block-scaled GEMM（通过 CUTLASS SM90 内核）。prefill 阶段使用 bf16，decode 阶段切换到 token-wise FP8。--quantization fp8 启用。
KV-cache 量化	--kv-cache-dtype fp8_ds_mla（DeepSeek V4 必选参数）。vLLM 对 DeepSeek V4 使用混合精度 KV cache：indexer cache 使用 FP4（4x 压缩），attention cache 使用 FP8（两阶段：prefill 时 bf16、decode 时 token-wise FP8）。1M 上下文仅需 9.62 GiB KV cache（bf16 估算值），FP4/FP8 混合后再降低约 2x。
激活量化	在 MoE all-to-all 通信前对 hidden state 做 token-wise FP8 量化。在 Blackwell 上进一步量化为 FP4 后再通信，通信量降低最多 4x。

启动参数：

--kv-cache-dtype fp8_ds_mla    # DeepSeek V4 专用 KV cache 类型
--quantization fp8              # 或 fp4（Blackwell）

性能影响：

• 计算：CUTLASS SM90 FP8 GEMM 在 H100 上约 1.5x 吞吐 vs BF16
• 显存：混合 FP4/FP8 KV cache，1M 上下文约 9.62 GiB（bf16 估算）→ 约 4.8 GiB（实际 FP4/FP8）
• 带宽：FP4 all-to-all 通信量相比 BF16 降低 4x

版本要求： vLLM 0.8.0+（基础），v0.24.0+（完整 FP4/NVFP4 支持，FlashInfer cute-dsl NVFP4 GEMM #42235）

---

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

vLLM 实现路径：

vLLM 通过 --enable-expert-parallel 启用专家并行，使用 Biased Group TopK 策略和 cluster-cooperative topK 优化专家利用率，在 AMD 平台上有专门的 AITER 优化路径。

具体体现：

组件	实现细节
Expert Parallel	--enable-expert-parallel 将 256 个专家的 MoE 层分散到各 TP rank 上。不同于 SGLang 的 EP degree 独立设置，vLLM 的 EP 与 TP 共享 parallelism degree。每个 TP rank 负责本地的一组专家，跨 rank 的路由通过 NCCL all-to-all 通信完成。
Biased Group TopK	vLLM 的 MoE 路由使用分组 TopK 策略（针对 DeepSeek 架构的分组路由优化），在组内做 biased selection 改善专家利用率。相比 naive TopK，在 AMD 平台上实现 4.9% 吞吐提升（通过 AITER 实现）。
Cluster-Cooperative TopK	v0.24.0 新增，针对 DeepSeek 低延迟场景。通过跨 GPU 协作的 TopK 策略，减少因路由不均衡导致的 tail latency。（PR #43008）
AITER Biased Group TopK	AMD ROCm 专属优化。通过 AITER 库实现 biased group TopK 和 fused softplus-sqrt-topk MoE router（PR #44945），在 AMD GPU 上实现与 NVIDIA 平台近似的专家利用率。
PD 分离 + DP 均衡	在 PD（Prefill-Decode）分离部署中，通过 DP supervisor 和 prefill step cadence 策略均衡 prefill 和 decode 节点间的负载（PR #46628, #44558）。

启动参数：

--enable-expert-parallel
--tensor-parallel-size 8    # EP 与 TP 共享此参数

性能影响：

• Biased Group TopK 改善专家利用率，减少约 15-20% 的专家闲置
• Cluster-cooperative TopK 降低 P99 延迟抖动约 20%
• AITER 路径在 AMD 上实现 4.9% 吞吐提升

版本要求： vLLM 0.6.6+（基础 EP），v0.24.0+（cluster-cooperative TopK）

---

特性 3：FP8 KV Cache 支持

vLLM 实现路径：

vLLM 对 DeepSeek V4 使用专用 fp8_ds_mla KV cache 类型，与 FlashMLA 和 FlashInfer 的 FP8 注意力内核深度集成。

具体体现：

层面	实现细节
fp8_ds_mla 专有缓存类型	--kv-cache-dtype fp8_ds_mla 是 DeepSeek V4 的必选参数。这是 vLLM 为此模型量身定制的 KV cache 量化方案，编码了 MLA 特殊的 K/V 布局（NoPE 512 维 + RoPE 128 维多路压缩）和分阶段精度策略。
两阶段精度	Prefill 阶段使用 bf16 KV cache（保证精度），decode 阶段切换到 token-wise FP8（缓解 memory-bound）。每次 decode step 时，新生成的 token 的 KV 以 FP8 量化写入，读取时在线反量化为 BF16 参与注意力计算。
Indexer Cache FP4	DSA 稀疏注意力的 indexer cache 使用 FP4，4x 压缩。vLLM 通过专用的 indexer kernel 处理 FP4 indexer cache 的读写。
FlashMLA 集成	vLLM 集成了 FlashMLA——DeepSeek 官方的 MLA decode 内核，直接支持 FP8 KV cache 的 batched decoding。FlashMLA 针对 Hopper 架构优化，利用 warpgroup 级编程和异步 TMA 加载。
HybridKVCache 管理	vLLM 自研的 HybridKVCache 管理器处理非连续内存布局——c4a 主 KV、c128a 主 KV、SWA KV、C4 indexer KV 和压缩器残差状态的统一管理，支持 FP8 精度下的 block 分配和前缀缓存。

启动参数：

--kv-cache-dtype fp8_ds_mla    # 必选

性能影响：

• 相比 BF16 KV cache，显存占用降低约 4x（FP8 attention + FP4 indexer）
• decode 阶段 FP8 注意力约 1.5-2x 加速（memory-bound 场景）

版本要求： vLLM 0.8.0+（fp8_ds_mla），V1 引擎完全支持

---

特性 4：拓展 DeepGEMM E8M0

vLLM 实现路径：

vLLM 通过 DeepGEMM 集成和 CUTLASS SM90 FP8 GEMM 实现 E8M0 block-scaled GEMM，同时在 Blackwell 上通过 TRTLLM-Gen 内核实现 FP4 GEMM。

具体体现：

层面	实现细节
DeepGEMM 集成	v0.11.0 起支持 DeepGEMM 作为 MoE 后端（适用于 Hopper 和 Blackwell GPU）。DeepGEMM 的 E8M0 block-scaled FP8 GEMM 用于 attention 路径和 MoE 路径的矩阵乘法。PR #46006 新增 PDL（Prefill-Decode Link）支持。
CUTLASS SM90 FP8 GEMM	vLLM 的注意力路径 GEMM 通过 CUTLASS SM90 FP8 Block Scaled GEMM 实现（PR #44572，支持 odd-M 的 swap_ab 策略，180-290% kernel 加速）。使用 E8M0 scale factor 格式，每个 block 的 scale 共享一个 E8M0 值。
NVFP4 GEMM	Blackwell 上通过 TRTLLM-Gen 内核进行 NVFP4 GEMM。DeepSeek V4 的 FP4 MoE 权重直接加载，无需反量化，激活 token 量化为 FP4 后送入 Tensor Core。FlashInfer cute-dsl NVFP4 GEMM（PR #42235）提供额外的 FP4 后端。
MXFP8 线性内核	v0.24.0 新增 FlashInfer cute-dsl MXFP8 linear kernel（PR #46393），支持 microscaling FP8 block-scaled 量化，提供比标准 FP8 E8M0 更精细的 block-scaled 粒度。
JIT 编译缓存	vLLM 的 DeepGEMM 和 CUTLASS 内核使用预编译 + JIT 缓存机制，首次启动后缓存二进制文件，避免重复编译。

启动参数：

# DeepGEMM 自动启用（v0.11.0+ 默认集成）
# CUTLASS SM90 FP8 在 Hopper 上自动启用

性能影响：

• CUTLASS SM90 FP8 odd-M 对比 naive kernel 180-290% 加速
• NVFP4 GEMM 在 Blackwell 上约 3-4x 吞吐 vs BF16
• MXFP8 micro-scaling 提供比标准 FP8 E8M0 约 5-10% 额外吞吐

版本要求： vLLM 0.11.0+（DeepGEMM 集成），v0.24.0+（NVFP4 + MXFP8）

---

SGLang 对应配置：

DeepGEMM 自动启用，无需显式参数

可通过环境变量控制：

DEEPGEMM_ENABLE_JIT=1 # 启用 JIT 编译（默认）
DEEPGEMM_FORCE_RECOMPILE=0 # 使用缓存的二进制

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


**vLLM 实现路径：**

vLLM 通过 FlashMLA 和 FlashInfer FA3 双路径实现 FP8 MLA 注意力，并针对 DeepSeek V4 的 NoPE/RoPE 分离架构有专门优化。

**具体体现：**

| 路径 | 实现细节 |
| --- | --- |
| **FlashMLA** | DeepSeek 官方 MLA decode 内核，vLLM 集成用于 batched decoding。支持 FP8 KV cache 读取、BF16 Q 计算和 token-wise FP8 量化写入。利用 warpgroup 级编程和异步 TMA 加载。 |
| **FlashInfer FA3** | vLLM V1 使用 FlashAttention 3 作为默认注意力内核。FA3 提供灵活的变长 batch 支持，同时处理 prefill 和 decode 的 token。支持 FP8 注意力计算。 |
| **NoPE/RoPE 分离** | MLA 的注意力分为无位置编码部分（NoPE，纯语义匹配）和位置编码部分（RoPE，位置感知）。vLLM 的 FP8 路径仅对 NoPE 部分做 FP8 量化，RoPE 部分保持 BF16。decode 时 NoPE 的 K/V 以 FP8 存储，读取后在 FlashMLA 内反量化。 |
| **SAM100 原生 DSA Indexer Decode** | v0.24.0 新增 Blackwell SM100 架构的 native DSA indexer decode 后端（PR #45322），为 DeepSeek V4 的 DSA 稀疏注意力在 Blackwell 上提供原生支持。 |
| **AMD Flash-Decode Split-K** | AMD ROCm 专属：DeepSeek V4 flash-decode split-K kernel（PR #44899）和 inverse-RoPE 融合（PR #45103），在 AMD GPU 上实现 MLA FP8 decode。 |

**启动参数：**

```bash
--kv-cache-dtype fp8_ds_mla    # FP8 KV cache（前置条件）
# FlashMLA / FA3 自动选择，无需手动指定

性能影响：

• FlashMLA decode 相比标准 attention 约 2-3x 加速
• FA3 统一 prefill/decode batch 减少调度开销
• SM100 native DSA indexer 在 Blackwell 上额外约 1.3x decode 加速

版本要求： vLLM 0.8.0+（FlashMLA），V1 引擎（FA3），v0.24.0+（SM100 native DSA）

---

B. MoE 优化

SGLang 对应配置：

MLA kernel 自动选择，无需手动指定

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


**vLLM 实现路径：**

vLLM 使用 Triton/CUTLASS/DeepGEMM 多路 MoE 后端，并针对 DeepSeek V4 的 ~33 个 per-layer 内核做激进融合。

**具体体现：**

| 后端 | 场景 | 实现细节 |
| --- | --- | --- |
| **TRTLLM FMHA MoE** | Decode（低延迟） | 基于 TensorRT-LLM 的 FMHA MoE kernel，针对小 batch decode 优化。DeepSeek V4 的 MoE 路径默认使用此后端。v0.11.0 修复了 TRTLLM FP8 MoE 的准确性 bug。 |
| **DeepGEMM MegaMoE** | Prefill（高吞吐） | vLLM 正在积极集成 DeepGEMM MegaMoE kernel（官方博客列为计划工作）。用于大 batch prefill 场景，支持 FP8/FP4 block-scaled GEMM。 |
| **CUTLASS Grouped GEMM** | 通用 | 通过 CUTLASS 的 grouped GEMM 实现 MoE 批量专家计算。v0.24.0 中 SM90 CUTLASS FP8 mm 新增 swap_ab 模式支持 odd-M 场景（180-290% 加速）。 |
| **融合操作** | 通用 | vLLM 博客记录的 DeepSeek V3.2/V4 融合策略：将 per-layer 的 ~33 个 kernel 融合为 ~10 个。融合包括：QK-Norm + RoPE + 量化；Compressor + RMSNorm + RoPE + cache write；Inverse RoPE + FP8 quant + o_lora batched matmul；Fused Q-norm + KV RoPE + K insert（10-20x 加速）。 |
| **Helion FP8/RMSNorm Quant 内核** | 通用 | v0.24.0 社区贡献的新 Helion 内核系列（PR #36902, #33790, #36895, #34432），针对 FP8 量化 + RMSNorm 路径的融合优化。 |
| **AMD FlyDSL W4A16 MoE** | AMD | AMD ROCm 专属 W4A16 FlyDSL MoE kernel（PR #44400）和 A8W4 MoE CDNA4 swizzle gate（PR #44804）。 |

**启动参数：**

```bash
# MoE 后端自动选择，可通过环境变量覆盖
VLLM_MOE_BACKEND=trtllm    # 或 deep_gemm / cutlass

性能影响：

• Kernel 融合后 per-layer 从 ~33 降至 ~10 kernel launch
• TRTLLM MoE decode 延迟相比 Triton 约 1.5x 降低
• CUTLASS SM90 odd-M 支持 180-290% 个别 GEMM 加速
• 融合 Q-norm + KV RoPE + K insert 达 10-20x 加速

版本要求： vLLM 0.8.0+（Triton/CUTLASS MoE），v0.11.0+（DeepGEMM），v0.24.0+（CUTLASS SM90 odd-M）

---

SGLang 对应配置：

MoE 后端自动选择，可通过环境变量覆盖：

SGLANG_MOE_BACKEND=deep_gemm # 或 flashinfer_trtllm / flashinfer_cutedsl

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


**vLLM 实现路径：**

DeepSeek V4 每 token 激活 6 个路由专家 + 1 个共享专家。vLLM 在 Expert Parallel 模式下将共享专家分布在各 TP rank 上独立计算。

**具体体现：**

| 层面 | 实现细节 |
| --- | --- |
| **独立计算路径** | 共享专家对所有 token 都计算，vLLM 将其独立于 MoE 路由路径。共享专家的权重在每个 TP rank 上复制一份（或 TP 分片），计算不参与 all-to-all 通信。 |
| **TP 分片策略** | 大规模部署中共享专家使用 TP 分片（与注意力权重共享 TP degree）。每个 TP rank 持有共享专家权重的一部分，计算后进行 all-reduce 聚合。这是与 SGLang 的 DP 策略不同的选择——vLLM 更偏向统一 TP 管理以简化配置。 |
| **FP4 权重处理** | 共享专家权重同样为原生 FP4，通过 TRTLLM-Gen NVFP4 内核（Blackwell）或 CUTLASS FP8（Hopper）执行。 |
| **融合 GEMM** | 共享专家 GEMM 与前后的 RMSNorm 融合到 MoE 融合通道中，减少 kernel launch。 |

**启动参数：**

```bash
--enable-expert-parallel
# 共享专家自动处理，无需额外参数

性能影响：

• 共享专家独立于 all-to-all 通信，无跨 GPU 路由开销
• 共享专家输出与路由专家输出在融合 kernel 内完成叠加

版本要求： vLLM 0.6.6+（基础 MoE EP）

---

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

vLLM 实现路径：

vLLM 通过 Expert Parallel + NCCL all-to-all + FP8/FP4 通信压缩应对 DeepSeek V4 的 256 个细粒度专家，并在 Blackwell 上实现 4x 通信压缩。

具体体现：

优化点	实现细节
NCCL All-to-All	vLLM 使用 NCCL 进行 MoE dispatch/combine 的 all-to-all 通信。--enable-expert-parallel 启用。不同于 SGLang 的 DeepEP（定制通信库），vLLM 使用标准 NCCL，在 H100 NVLink 域内性能相当，但在跨节点 RDMA 场景下略逊。
FP8 通信压缩	Token 在 dispatch 前量化为 FP8，通信量减半。Combine 时在目标 GPU 上反量化为 BF16。这是标准做法，vLLM 将其融合在 MoE router kernel 之后。
FP4 通信压缩	Blackwell 专属：Token 量化为 FP4 后再 all-to-all，通信量相比 BF16 降低 4x，相比 FP8 再降低 2x。结合 TRTLLM-Gen NVFP4 GEMM 实现端到端 FP4 流水线。
Qwen3-Next FP8 MoE 调优	vLLM 对 Qwen3-Next-80B 的 FP8 MoE kernel 做了 H100 专用优化（PR #44830，+25% 吞吐），对 DeepSeek V4 的 MoE 路径有间接收益。
PD 分离 + DP 均衡	在 PD 分离部署中，prefill step cadence 策略（PR #44558）改善非 PD 场景下的 DP 均衡，避免 MoE 通信不均衡导致的节点间等待。

启动参数：

--enable-expert-parallel
--tensor-parallel-size 8

性能影响：

• FP8 通信将 all-to-all 数据量减半
• FP4 通信在 Blackwell 上再减半（总计 4x vs BF16）
• Qwen3-Next 调优经验间接提升 DeepSeek V4 约 5-10%

版本要求： vLLM 0.6.6+（基础 EP），v0.24.0+（FP4 通信 + PD 均衡）

---

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

vLLM 实现路径：

vLLM 通过 compilation-config CUDA Graph + Persistent Batch + Triton 自动调优实现 GEMM/MoE 内核的自动选择和优化。

具体体现：

层面	实现细节
CUDA Graph 模式	vLLM V1 支持三种 CUDA Graph 模式：FULL_DECODE_ONLY（推荐用于 DeepSeek V4 decode）、PIECEWISE（分段 graph）、FULL（全量 graph）。CUDA Graph 捕获固定 shape 的计算图，后续推理直接 replay graph，消除 kernel launch 开销。
Persistent Batch	V1 引擎的核心技术：缓存输入张量，每步仅应用 diff（增量更新）。避免每步重建 input tensors 和 metadata，大幅减少 CPU 开销。结合 Numpy 操作替代 Python 原生操作，进一步降低 CPU 端延迟。
Triton 自动调优	vLLM 的 Triton 内核在首次遇到新 shape 时自动调优 tile 大小和流水线深度。VLLM_TRITON_FORCE_FIRST_CONFIG 可跳过调优直接使用默认配置（PR #42425），用于快速启动。Triton 重编译检测（PR #45631）避免重复调优。
FlashInfer AOT	v0.11.0 修复了 FlashInfer AOT（Ahead-of-Time）在 release docker 镜像中的集成问题。AOT 预编译确保内核在启动时立即可用，无需运行时 JIT。
torch.compile 通用优化	V1 引擎通过 torch.compile 实现 batch-invariant 优化（v0.11.0），对注意力后端的形状泛化支持使同一编译图可处理多种 batch size。

启动参数：

--compilation-config '{"cudagraph_mode": "FULL_DECODE_ONLY"}'
# Triton 调优：
VLLM_TRITON_FORCE_FIRST_CONFIG=1     # 跳过调优（快速启动）

性能影响：

• CUDA Graph replay 消除 ~90% 的 kernel launch 开销
• Persistent Batch 减少约 30-50% 的 CPU 调度开销
• Triton 自动调优相比固定配置约 10-15% 吞吐提升

版本要求： vLLM 0.8.0+（基础），V1 引擎（Persistent Batch + torch.compile），v0.24.0+（完整 CUDA Graph 模式）

---

C. 注意力与 KV Cache 优化

SGLang 对应配置：

自动调优默认启用

可通过环境变量控制：

FLASHINFER_AUTOTUNE=1 # 启用自动调优
FLASHINFER_AUTOTUNE_CACHE_DIR=/path/to/cache

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


**vLLM 实现路径：**

vLLM 深度集成 FlashInfer 和 FlashMLA，并在此基础上开发了专用的融合内核和多流并发策略。

**具体体现：**

| 内核 | 用途 | 实现细节 |
| --- | --- | --- |
| **FlashMLA** | MLA decode | DeepSeek 官方 MLA decode 内核。vLLM 集成用于 batched decoding，支持 FP8 KV cache。针对 Hopper 优化，使用 warpgroup 级编程。 |
| **FlashInfer Attention** | 通用 attention | vLLM V1 的核心注意力后端（替代 FA3 的位置）。支持变长 batch、paged KV cache、FP8/BF16 混合精度、GQA/MLA/滑动窗口等变体。 |
| **FlashAttention 3** | V1 默认 | vLLM V1 使用 FA3 作为默认注意力内核，支撑混合 prefill/decode batch 的高效执行。 |
| **FlashInfer NVFP4 GEMM** | FP4 GEMM | v0.24.0 新增 cute-dsl NVFP4 GEMM（PR #42235），在 Blackwell 上提供 FP4 GEMM 的额外后端选项。 |
| **FlashInfer MXFP8 线性内核** | MXFP8 | v0.24.0 新增 cute-dsl MXFP8 linear kernel（PR #46393），支持 microscaling FP8。 |
| **vLLM 自研融合内核** | DeepSeek V4 专用 | 三类融合：Compressor+RMSNorm+RoPE+cache insert（1.4-3x 加速）；Inverse RoPE+FP8 quant（2-3x 加速）；Q-norm+KV RoPE+K insert（10-20x 加速）。复用 DeepSeek V3.2 的 Q RoPE+quant+weight multiply 融合和 QK Norm 水平融合。 |
| **TopK 内核** | DSA 索引器 | vLLM 自研的 DSA 索引器 TopK 内核（PR #37421），根据序列长度动态选择最优算法，适配单 CUDA Graph。在 128K 上下文 decode 中贡献 17% per-token 延迟改善。 |

**启动参数：**

```bash
# FlashInfer 自动启用（预编译 wheel 安装后）
# 安装：pip install flashinfer --find-links https://flashinfer.ai/whl/cu124/torch2.5/
--trust-remote-code

性能影响：

• 融合内核：Compressor 融合 1.4-3x，Inverse RoPE 融合 2-3x，Q-norm 融合 10-20x
• TopK 自适应内核贡献 17% decode 延迟改善
• Per-layer kernel 从 ~33 降至 ~10

版本要求： vLLM 0.8.0+（FlashMLA/FlashInfer），v0.11.0+（FlashInfer AOT），v0.24.0+（NVFP4/MXFP8 cute-dsl）

---

SGLang 对应配置：

FlashInfer 默认启用，无需显式参数

预编译 wheel 安装：

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

vLLM 实现路径：

DeepSeek V4 使用 128-token 滑动窗口。vLLM 将 SWA 作为 HybridKVCache 的三种层类型之一统一管理。

具体体现：

层面	实现细节
SWA 类型层	vLLM 将 DeepSeek V4 的注意力层分为三种类型并以统一逻辑 block size（256 native token）管理：c4a 层（4x 压缩）、c128a 层（128x 压缩）、SWA 层（无压缩，仅滑动窗口）。
HybridKVCache	vLLM 的核心创新：统一的 KV cache 管理器处理三种层的异构内存需求。SWA 层保持每个 token 的完整 KV，block 物理大小为 256 token × per_entry_size。
压缩器残差作为 SWA KV	vLLM 的一个巧思：将压缩器（compressor）的残差状态作为滑动窗口 KV cache 管理。压缩器需要维护一个小滚动残差（C4: 8 token, C128: 128 token），vLLM 将其作为特殊的 KV cache 页面分配，利用现有的 paged allocator 管理。
统一逻辑 block size	所有三种层类型使用统一的逻辑 block size = 256 native token。c4a 层每个 block 物理存储 256/4=64 压缩条目，c128a 层存储 256/128=2 压缩条目，SWA 层存储 256 native token。这种设计使 slot mapping、调度器计数和 prefix-hit 检测可以无分支地统一处理。
RNN 类型前向传播	SWA 层的注意力量化模式通过 Attention SDK 处理，支持 RNN 类型的前向传播。与 vLLM 的 paged attention 框架兼容。

启动参数：

# SWA 大小从模型 config 自动读取
# DeepSeek V4 Flash 的 sliding_window: 128
--block-size 256                # 逻辑 block 大小

性能影响：

• 统一 block size 设计消除按压缩比例分支的内存管理开销
• 压缩器状态复用 paged allocator，避免侧缓冲区碎片
• 滑动窗口将 decode attention 计算量固定为 O(128)

版本要求： vLLM 0.8.0+（HybridKVCache），0.24.0+（AMD SWA 兼容）

---

SGLang 对应配置：

滑动窗口大小从模型 config 自动读取

DeepSeek V4 Flash 的 sliding_window: 128

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


**vLLM 实现路径：**

DeepSeek V4 的共享 KV 向量实现跨层注意力。vLLM 通过 inverse RoPE 保证位置编码正确性，并通过 HybridKVCache 管理共享 KV。

**具体体现：**

| 层面 | 实现细节 |
| --- | --- |
| **共享 KV 向量** | DeepSeek V4 的多个注意力层共享同一组 K/V 向量，额外 2x 内存节省。vLLM 在 HybridKVCache 中识别共享层组，只存储一份 KV 供多层使用。 |
| **Inverse RoPE** | vLLM 官方博客详细解释了为何需要 inverse RoPE：共享 KV 使用统一 RoPE 编码写入，各读取层有自己的 RoPE 配置（不同的相对位置或频率）。vLLM 在注意力输出后应用 inverse RoPE 消除共享的原始编码，再按当前层的配置 re-apply RoPE。Inverse RoPE 操作与 FP8 量化融合为单 kernel（2-3x 加速）。 |
| **DP Attention** | vLLM 在 PD 分离部署中支持 DP supervisor（PR #46628），通过 prefill step cadence 策略将注意力层的 DP 度与 MoE 层的 EP 度独立调优。但不同于 SGLang，vLLM 默认使用 TP 统一管理注意力层。 |
| **QK Norm 融合** | vLLM 从 DeepSeek V3.2 工作复用了 QK Norm 的水平融合（在 QK 投影之后、注意力之前，将 Q norm 和 K norm 融合为一个水平融合 kernel），减少一次 kernel launch。 |

**启动参数：**

```bash
# 共享 KV 自动检测（模型 config）
--tensor-parallel-size 4

性能影响：

• 共享 KV 额外 2x 内存节省
• Inverse RoPE + FP8 量化融合 2-3x 加速
• QK Norm 融合减少 1 次 kernel launch

版本要求： vLLM 0.8.0+（共享 KV + inverse RoPE），v0.24.0+（AMD inverse-RoPE 融合）

---

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

vLLM 实现路径：

DeepSeek V4 自带 FP4 MoE 权重和 FP4 indexer cache / FP8 attention cache。vLLM 通过 HybridKVCache 和 TRTLLM-Gen 内核原生支持，无需量化转换。

具体体现：

层面	实现细节
FP4 MoE 权重	模型权重原生为 NVFP4 格式。vLLM 在 Blackwell 上通过 TRTLLM-Gen 内核直接加载和计算，在 Hopper 上通过反量化→FP8 GEMM 路径。官方文档强调应使用模型自带的 FP4+FP8 Instruct checkpoint，无需额外量化。
FP4 Indexer Cache	DSA indexer cache 原生 FP4。vLLM 的 HybridKVCache 将其作为独立的 cache 类型管理，indexer kernel 直接处理 FP4 读取。
FP8 Attention Cache	注意力 KV cache 使用 fp8_ds_mla 类型，两阶段精度（prefill bf16, decode FP8）。
零转换流水线	权重加载 → TRTLLM-Gen NVFP4 GEMM → FP8 attention（decode）→ FP4 indexer，全程无中间 BF16 转换。vLLM 官方强调”stick with the official checkpoints”——原生量化是模型设计的一部分，不宜进一步压缩。
社区 INT4 对比	有 GGUF/AWQ/GPTQ INT4 量化可将 V4-Flash 压缩至 ~80GB（4x RTX 4090 可跑），但 vLLM 官方警告：官方 FP4+FP8 已经非常 aggressive，进一步到 INT4 会显著损失推理质量，特别是数学和推理任务。

启动参数：

# 原生 FP4 权重自动加载
--trust-remote-code

性能影响：

• 原生 FP4 MoE 权重节省约 50% 权重显存 vs FP8
• 零转换流水线减少约 15-20% 中间张量显存
• 无需额外量化步骤

版本要求： vLLM 0.8.0+（FP4 权重加载），0.24.0+（完整 FP4 内核）

---

特性 14：KV 压缩 V2

vLLM 实现路径：

vLLM 的 HybridKVCache 是 DeepSeek V4 KV 压缩架构的核心实现，通过统一 block size 和页面桶（page-size buckets）解决异构压缩的内存管理难题。

具体体现：

组件	实现细节
c4a / c128a / SWA 三层	vLLM 将 DeepSeek V4 的注意力层分为三种类型：c4a（4x 压缩，8 token 加权和，stride 4）、c128a（128x 压缩，128 token 加权和，stride 128）、SWA（无压缩，纯滑动窗口）。混合管理是 HybridKVCache 的核心挑战。
统一逻辑 block = 256	c4a 层每 block 物理存储 64 压缩条目，c128a 层存储 2 压缩条目，SWA 层存储 256 native token。所有层共享相同的逻辑 block size（256 native token 位置），使调度器和前缀缓存无需按压缩比例分支。
三页面桶	vLLM 将五路 cache（c4a 主 KV、c128a 主 KV、SWA KV、C4 indexer KV、压缩器残差）合并为三个页面桶（max/middle/min），每个桶由共享 block pool 支持。运行时无需按类型分区或核算，分配简化为桶查找。
最大桶	c4a 主 KV、SWA KV、c4a 压缩器状态、c128a 压缩器状态
中型桶	C4 indexer KV、C4 indexer 压缩器状态
最小桶	c128a 主 KV
压缩器状态管理	每个压缩器层维护一个小滚动残差（partial state）——C4: 8 token（overlapped），C128: 128 token。vLLM 将其作为特殊的 KV cache 条目，利用现有 paged allocator 管理，而非侧缓冲区。
融合压缩核	Compressor + RMSNorm + RoPE + cache insertion 融合为单 kernel（1.4-3x 加速）。为 indexer K cache 和 main-attention K cache 保留独立 kernel，使并行策略可针对各自 head dim 调优。
AMD 专属	AMD ROCm 上有 DSv4 flash-decode split-K kernel（PR #44899）和 inverse-RoPE 融合（PR #45103），Intel XPU 有 DeepSeek-V4 attention/MoE paths（PR #44144, #44517, #45240）。

启动参数：

--block-size 256
--kv-cache-dtype fp8_ds_mla

性能影响：

• 统一 block size + 三页面桶消除跨 pool 碎片化
• 压缩器状态复用 paged allocator，避免侧 buffer 碎裂
• Compressor 融合 1.4-3x 加速

版本要求： vLLM 0.8.0+（HybridKVCache），0.24.0+（AMD/Intel 优化完善）

---

SGLang 对应配置：

KV 压缩 V2 自动启用（模型 config 检测到 DSA 架构时）

–kv-cache-dtype fp8

### 特性 15：MHC 路径深度融合


**vLLM 实现路径：**

vLLM 官方博客将 MHC 列为"not covered in this post, as they are simpler model changes that are easier to adapt"。vLLM 通过通用融合框架处理 MHC，而非 SGLang 那样的专用深度融合。

**具体体现：**

| 层面 | 实现细节 |
| --- | --- |
| **通用融合架构** | vLLM 使用 torch.compile + 自定义 pass 处理 MHC 路径。torch.compile 的 Inductor backend 自动识别和融合 MHC 中的 GEMM + 激活 + Norm 链，生成优化后的 CUDA kernel。 |
| **DeepGEMM 通用 GEMM** | MHC 中的矩阵乘法通过 DeepGEMM 或 CUTLASS FP8 GEMM 执行，复用注意力路径的 GEMM 融合基础设施。 |
| **RMSNorm 融合** | vLLM 的 Helion 内核系列（PR #36902, #33790）提供了 RMSNorm + 量化的通用融合实现，应用于 MHC 路径的 norm 操作。 |
| **限制对比 SGLang** | vLLM 没有实现 SGLang 级别的 MHC 专用融合（如 hc_head 融合内核、mhc_fused_post_pre 内核），而是依赖通用的 torch.compile 图编译和自定义 pass。对于 DeepSeek V4 来说，MHC 路径的优化空间未必没有利用，但不如 SGLang 激进。 |

**启动参数：**

```bash
--compilation-config '{"cudagraph_mode": "FULL_DECODE_ONLY"}'

性能影响：

• torch.compile 图编译提供约 10-15% MHC 路径加速
• 未实现专用 MHC 融合，prefill 中 MHC 路径可能成为瓶颈

版本要求： vLLM 0.8.0+（基础），V1 引擎（torch.compile 通用融合）

---

D. 调度与延迟优化

SGLang 对应配置：

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

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


**vLLM 实现路径：**

vLLM V1 引擎引入了异步调度器（Async Scheduler），重新设计了 V0 的调度-执行架构。通过 Persistent Batch、diff-based 通信和 Piecewise CUDA Graphs 大幅减少 CPU 开销。

**具体体现：**

| 层面 | 实现细节 |
| --- | --- |
| **V1 异步调度器** | V0 的调度器与 Worker 0 共置同一进程（不对称架构），V1 将调度器和 Worker 0 分离到独立进程。通过缓存 worker 侧的请求状态、每步仅传输增量数据（diffs）来最小化 IPC 开销。 |
| **Persistent Batch** | V1 的核心技术：缓存上一步的输入张量，每步仅应用 diff（新增/移除请求的增量）。结合 Numpy 操作替代 Python 原生操作，大幅减少 CPU 端张量重建开销。 |
| **Piecewise CUDA Graphs** | V1 引入分段 CUDA Graph，缓解全量 CUDA Graph 的限制（固定 shape、内存重分配失败）。将计算图拆分为多个可独立更新的 piece，允许部分 piece 在不触发 full recapture 的情况下更新。 |
| **统一调度器** | V1 使用统一的调度器处理 prompt 和 output token（通过 `{request_id: num_tokens}` 字典动态分配 token 预算），不严格区分 prefill 和 decode 阶段。支持 FCFS 和基于优先级的调度策略。 |
| **对比 SGLang** | vLLM 的异步调度器仍在追赶 SGLang 的零开销设计。V1 的 diff-based 通信虽然减少了 IPC 开销，但调度决策与 GPU 执行之间仍有同步点（GPU 空闲率未达 SGLang 的趋近于零水平）。在 DeepSeek V4 的复杂 MoE 场景中，SGLang 的 Two-Batch Overlap 在调度-通信-计算三重重叠上有明显优势。 |
| **Ascend 平台** | Ascend 版本从 v0.12.0 起异步调度器更加稳定并推荐启用，通过 `--async-scheduling` 参数。 |

**启动参数：**

```bash
# V1 引擎异步调度默认启用
--async-scheduling    # 显式启用（Ascend 版本需要）
--scheduling-policy fcfs    # 或 priority

性能影响：

• V1 相比 V0 约 1.5-1.7x 吞吐提升（Llama 3.1 8B/70B）
• Persistent Batch 减少约 30-50% CPU 调度开销
• Piecewise CUDA Graph 减少约 60% 的 graph recapture 频率

版本要求： vLLM 0.8.0+（V1 引擎），0.11.0+（异步调度稳定）

---

SGLang 对应配置：

异步调度默认启用，无需显式参数

可通过环境变量微调：

SGLANG_SCHEDULE_CONSERVATIVENESS=1.0 # 调度激进程度

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


**vLLM 实现路径：**

DeepSeek V4 自带 MTP 推测头，vLLM 原生支持 MTP，同时支持 EAGLE/EAGLE-3、N-gram、Suffix 等多种推测策略。在 DigitalOcean 的 DeepSeek V3.2 部署中达到 230 TPS per-user 输出吞吐。

**具体体现：**

| 策略 | 实现细节 |
| --- | --- |
| **MTP（原生推测头）** | DeepSeek V4 的 MTP 头每步预测 1 个 token，接受率 >80%。vLLM 通过 `--speculative-config '{"method":"mtp","num_speculative_tokens":1}'` 启用。无需额外 draft model，零额外显存。vLLM 的 MTP 支持支持 1/2/3 步推测。 |
| **EAGLE / EAGLE-3** | 外部推测策略。vLLM 支持 EAGLE-3（NeurIPS '25），需要提供 EAGLE draft model（`--speculative-config` 中指定 model path）。vLLM 0.11.0 新增 Eagle 多模态支持（Qwen2.5-VL 启用）。DigitalOcean 的 MiniMax-M2.5 部署使用 custom EAGLE3 draft model。 |
| **N-gram / Suffix** | 零额外参数的推测策略。N-gram 在 prompt 中查找匹配的 token 序列作为推测目标，Suffix 使用后缀树。适用于代码补全和模板化输出。 |
| **DFLASH** | 高吞吐 spec-decode kernel。vLLM 支持 DFLASH 作为可选策略。 |
| **Tree Attention** | vLLM 支持 tree-structured proposals——验证器在一次 forward pass 中评估多个候选路径，而不是线性链。提高有效接受率。 |
| **并行 Drafting** | vLLM 支持 parallel draft token generation（`parallel_drafting: true`），对 EAGLE 和 draft-model 方法适用，进一步降低 draft 延迟。 |
| **V1 推理解码优化** | V1 引擎对推测解码做了针对性优化。Red Hat 2026 年 4 月的测试显示，vLLM 投机解码使代码工作负载每百万输出 token 成本下降 19.4%。 |

**启动参数：**

```bash
# MTP（原生）
--speculative-config '{"method":"mtp","num_speculative_tokens":1}'

# EAGLE-3
--speculative-config '{
  "method":"eagle3",
  "model":"path/to/eagle3-head",
  "draft_tensor_parallel_size":1,
  "num_speculative_tokens":5,
  "parallel_drafting":true
}'

# N-gram（零额外模型）
--speculative-config '{"method":"ngram","num_speculative_tokens":5}'

性能影响：

• MTP：接受率 >80%，吞吐约 1.8x（vs 无推测解码）
• EAGLE-3：3.0-6.5x 加速（vs 无推测解码），比 EAGLE-2 提升 20-40%
• 代码工作负载：每百万 output token 成本下降 19.4%
• 对比 SGLang：vLLM 推测解码吞吐约为 SGLang 的 71%（297 vs 419 tokens/s，DeepSeek 特定 bench）

版本要求： vLLM 0.8.0+（MTP 基础），0.11.0+（EAGLE-3 多模态），0.24.0+（DFLASH + 完整 tree attention）

---

E. 结构化输出

SGLang 对应配置：

Spec V2 默认启用，无需显式参数

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


**vLLM 实现路径：**

XGrammar 是 vLLM 的结构化生成默认后端（从 V1 起），V1 引擎将 guided decoding 的初始化移至非阻塞路径。vLLM 还支持 outlines 和 guidance 作为备选后端。

**具体体现：**

| 层面 | 实现细节 |
| --- | --- |
| **XGrammar 默认后端** | vLLM V1 默认使用 XGrammar 后端（`--guided-decoding-backend xgrammar` 或自动模式）。XGrammar-2（2026 年 5 月发布）实现约 80x 编译加速和 <40μs per-token 约束处理。 |
| **V1 非阻塞初始化** | V0 中，即使单个 constrained request 也会阻塞整个 engine。V1 将 grammar 编译移至非阻塞路径——GPU 推理与 CPU grammar 编译并行执行。Red Hat 的基准测试显示 V1 相比 V0 有"dramatically faster"的结构化输出性能。 |
| **对比 SGLang** | vLLM 的 mask 生成是顺序执行——CPU 生成 mask 后才送入 GPU 推理。在 batch size ≥8 时，mask 生成成为瓶颈（约 15-30% 吞吐下降）。SGLang 的核心优势是 mask 生成与 GPU 推理重叠执行，vLLM 正在计划将 guided decoding 移至 scheduler 级别以缓解此问题。 |
| **Jump Decoding（计划中）** | 正在开发的新特性：当模型被约束到已知序列（如 JSON 的结构性键和分隔符），vLLM 可以跳过不必要的 token 采样和 GPU 计算。例如 `{"name":"` 之后的字符串内容仍需要采样，但 `,` `}` 等结构 token 可以直接跳过。可显著加速长 JSON 生成。 |
| **多后端支持** | `--guided-decoding-backend` 支持三种后端：`xgrammar`（推荐，缓存好，适合长生成）、`guidance`（更快的时间到首 token，适合多租户动态场景）、`outlines`（基于 FSM，适合复用 schema 的大规模场景）。默认 `auto` 模式根据请求自动选择。 |
| **grammar 缓存** | XGrammar 编译后的 grammar 状态机缓存在内存中。vLLM 的 V1 设计使相同 schema 的后续请求直接复用缓存，避免重复编译。 |

**启动参数：**

```bash
--guided-decoding-backend xgrammar    # 推荐
# 通过 API 使用：
# POST /v1/chat/completions
# extra_body={"guided_json": {"type": "object", ...}}
# 或 guided_regex / guided_choice / guided_grammar

性能影响：

• XGrammar-2：每 token 约束开销 <40μs（占推理时间的 <1%）
• V1 非阻塞初始化：消除 schema 编译的 engine 阻塞
• vs SGLang：batch size ≥8 时落后约 15-30% 吞吐（mask 生成未重叠）
• Jump Decoding（计划中）：结构 token 跳过可减少约 30-50% 生成步数

版本要求： vLLM 0.8.0+（XGrammar），V1 引擎（非阻塞），0.24.0+（XGrammar-2）

---

F. 运行时与图优化

SGLang 对应配置：

XGrammar 默认启用，无需显式参数

通过 API 使用：

POST /generate body: {“json_schema”: {…}, “text”: “…”}

或

POST /generate body: {“regex”: “…”, “text”: “…”}

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


**vLLM 实现路径：**

vLLM 通过 FlashInfer AOT（Ahead-of-Time）预编译 wheel、Triton 缓存和 CUDA Graph 捕获实现快速冷启动。

**具体体现：**

| 层面 | 实现细节 |
| --- | --- |
| **FlashInfer AOT wheel** | vLLM 使用预编译的 FlashInfer wheel：`pip install flashinfer --find-links https://flashinfer.ai/whl/cu124/torch2.5/`。pre-built wheel 包含所有常用内核的 CUDA 二进制。v0.11.0 修复了 AOT 在 release docker 镜像中的集成问题。 |
| **Triton 缓存** | vLLM 的 Triton 内核编译后缓存到 `~/.triton/cache/`。Triton 重编译检测（PR #45631）避免重复编译。`VLLM_TRITON_FORCE_FIRST_CONFIG` 可跳过自动调优直接用默认配置加速首次启动。 |
| **CUDA Graph 捕获** | vLLM 的 CUDA Graph 在首次推理时捕获固定 shape 的计算图，后续直接 replay。`--compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}'` 指定捕获模式。捕获过程产生一次性启动延迟，后续稳定。 |
| **DeepGEMM JIT** | vLLM 的 DeepGEMM 集成使用 JIT 编译，首次编译后缓存。与 SGLang 的 NVRTC 10x 编译加速不同，vLLM 更依赖预编译 wheel 减少 JIT 需求。 |
| **冷启动对比** | vLLM 的冷启动时间通常在 30-60 秒（模型加载 + Triton 编译 + CUDA Graph 捕获），其中 CUDA Graph 捕获是最耗时阶段（~10-20s）。生产环境中建议先做 warmup 请求触发图捕获。 |

**启动参数：**

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

# Triton 快速启动：
VLLM_TRITON_FORCE_FIRST_CONFIG=1

# CUDA Graph 模式：
--compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}'

性能影响：

• 预编译 wheel 消除 FlashInfer 运行时编译
• Triton 缓存避免重复 JIT，后续启动加速约 50%
• CUDA Graph 捕获 ~10-20s（一次性）

版本要求： vLLM 0.8.0+（基础），0.11.0+（AOT 修复），0.24.0+（Triton 重编译检测）

---

SGLang 对应配置：

安装预编译 FlashInfer：

DeepGEMM JIT 缓存默认启用：

DEEPGEMM_ENABLE_JIT=1
DEEPGEMM_CACHE_DIR=/path/to/cache

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


**vLLM 实现路径：**

vLLM V1 引擎将 torch.compile 作为核心优化路径，支持 batch-invariant 优化、自定义 pass 和实验性 MPK 编译器集成（计划中）。

**具体体现：**

| 层面 | 实现细节 |
| --- | --- |
| **torch.compile 集成** | V1 引擎利用 torch.compile 的 Inductor backend 自动优化模型计算图。v0.11.0 新增 batch-invariant 支持——同一个编译图可处理多种 batch size，减少重编译。vLLM 博客详细说明了 torch.compile 在推理流水线中的核心地位。 |
| **自定义融合 pass** | vLLM 通过 torch.compile 的自定义 pass 实现模式匹配和融合。目前包括 rms_norm、quant 等自定义算子的模式匹配。博客提到"有一个正在执行的原型，可以模式匹配自定义算子的 torch 实现"。 |
| **实验性 MPK/Mirage 编译器** | vLLM 正在探索实验性的 MPK（Megakernel）编译器集成——为整个模型的前向传播生成单 kernel（megakernel）。相比 CUDA Graphs，可以进一步减少 CPU 开销并消除 kernel launch。相关 RFC 已发布。 |
| **FlexAttention 支持** | 正在改进的 FlexAttention 支持——允许通过 torch.compile 生成自定义 Triton attention 模板，无需为每个 attention 变体编写自定义 kernel。对 DeepSeek V4 的多种 attention 类型（c4a/c128a/SWA/DSA）有潜在价值。 |
| **全 CUDA Graph 支持** | 正在开发中的 FlashAttention v2 和 FlashInfer 的全 CUDA Graphs 支持。全 CUDA Graph 比分段 Graph 有更低的 CPU 开销，特别适合高开销场景。 |
| **对比 SGLang** | vLLM 的 torch.compile 集成更加通用化（batch-invariant、FlexAttention、计划中的 MPK），但 SGLang 对 DeepSeek V4 的图优化更专用（如 MHC 路径迁移到 DeepGEMM 流、AllReduce+RMSNorm 融合是在实际部署中实现而非 torch.compile 计划中）。 |

**启动参数：**

```bash
# torch.compile 在 V1 引擎中默认启用
--compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}'

性能影响：

• torch.compile 相比 eager 模式约 10-20% 吞吐提升
• Batch-invariant 减少 80%+ 的图重编译
• 计划中的 MPK megakernel 预计额外 10-15%

版本要求： vLLM 0.11.0+（batch-invariant torch.compile），V1 引擎

---

SGLang 对应配置：

可选：指定编译后端和优化级别

SGLANG_TORCH_COMPILE_MODE=max-autotune

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


**vLLM 实现路径：**

vLLM 对 DeepSeek V4 的 MLA 注意力路径进行激进融合，将 ~33 个 per-layer kernel 压缩为 ~10 个。

**具体体现：**

| 融合点 | 实现细节 |
| --- | --- |
| **Compressor + RMSNorm + RoPE + Cache Insert** | 压缩后的 K 立即通过 RMSNorm → RoPE → 写入 KV cache。全部 element-wise 操作融合为单 kernel。Main-attention K cache 和 indexer K cache 保留独立 kernel 以便针对各自 head dim 调优。1.4-3x 加速。 |
| **Inverse RoPE + FP8 Quant** | 主注意力输出通过 inverse RoPE 后进入 o_lora 投影的 FP8 batched matmul。融合两者避免连续的 HBM 往返。2-3x 加速。 |
| **Q-norm + KV RoPE + K insert** | Q 的 RMSNorm + KV 的 RoPE + K 的 cache 插入三步融合。复用 DeepSeek V3.2 的 Q RoPE + quant + weight multiply 融合和 QK Norm 水平融合。10-20x 加速。 |
| **三融合点合起来** | 注意力路径 kernel 数从 ~33 降至 ~10。batch size 1 时实现 1.28x speedup（85.8 → 109.3 tok/s on 4x GB200）。 |
| **多流并发** | 注意力前的操作拆分为三个并行分支：indexer 计算、主注意力 KV 压缩、滑动窗口 token 插入。在 c4a 层，indexer pipeline 在独立 CUDA stream 上与 KV 压缩和 SWA 插入并行执行。在 c128a 层（无 indexer），主 KV 压缩与 SWA 插入并行。5-6% 端到端延迟降低。 |

**启动参数：**

```bash
# 注意力融合自动启用（模型 config 检测到 DeepSeek V4 架构时）
--compilation-config '{"cudagraph_mode": "FULL_DECODE_ONLY"}'

性能影响：

• Kernel 数从 ~33 降至 ~10
• 单点融合 1.4-20x（取决于融合点）
• 多流并发 5-6% 端到端延迟降低
• Batch size 1 时 1.28x 加速

版本要求： vLLM 0.8.0+（基础融合），V1 引擎（多流并发）

---

SGLang 对应配置：

注意力融合自动启用（模型 config 检测到 MLA 架构时）

–enable-torch-compile # 配合 torch.compile 进一步优化

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


**vLLM 实现路径：**

vLLM 通过 one-shot fused all-reduce 和 AMD fused AR+RMSNorm+FP8 quant 实现通信-计算融合。在 DeepSeek V3.2/V4 路径中，融合主要体现在注意力路径的 norm + quant 链。

**具体体现：**

| 层面 | 实现细节 |
| --- | --- |
| **One-Shot Fused All-Reduce** | v0.24.0 新增 one-shot fused all-reduce PDL（通信 kernel NaN 修复，PR #45448）。将 all-reduce 通信与后续计算融合为单 kernel。 |
| **AMD Fused AR + RMSNorm + FP8 Quant** | AMD ROCm 专属：fused all-reduce + RMSNorm + per-group FP8 quant 单 kernel（PR #42864）。在 AMD 平台上实现通信与计算的深度重叠。 |
| **Helion RMSNorm + Quant** | vLLM 社区的 Helion 内核系列提供 RMSNorm + FP8 量化的通用融合实现（PR #36902, #33790, #36895, #34432）。应用于注意力路径和解码路径的 norm 链。 |
| **DeepSeek V4 路径融合** | vLLM 官方博客的融合图中，AllReduce 融合主要体现在 QK Norm 的水平融合（Q norm 和 K norm 在 attention 前合并为一个水平 kernel）。RMSNorm 在所有三个融合点中（Compressor + RMSNorm + RoPE + cache insert、Q-norm + KV RoPE + K insert）都被融入。量化融合在 Inverse RoPE + FP8 quant 点中实现。 |
| **CNN 通信融合** | vLLM 在内部使用 NCCL 而非 SGLang 的 DeepEP。AllReduce 融合更依赖于 NVIDIA NCCL 的 native 流水线特性，而非 SGLang 级别的 kernel-DIY 融合。 |

**启动参数：**

```bash
# 融合自动启用
--compilation-config '{"cudagraph_mode": "FULL_DECODE_ONLY"}'

性能影响：

• Helion RMSNorm+Quant 融合约 15-25% norm 路径加速
• AMD fused AR+RMSNorm+FP8 quant 约 5-8% 端到端加速
• DeepSeek V4 路径 norm 融合整合在三个融合点中

版本要求： vLLM 0.24.0+（one-shot fused AR + AMD 融合）

---

G. 长上下文扩展

SGLang 对应配置：

CP 模式下自动启用 AllReduce+RMSNorm 融合

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


**vLLM 实现路径：**

vLLM V1 对 Mamba-1 和 Mamba-2 提供原生支持，并支持混合 SSM+Transformer 架构（Jamba、NemotronH、FalconH1 等）。vLLM 对 SSM 的支持早于 SGLang，覆盖的混合模型更广。

**具体体现：**

| 层面 | 实现细节 |
| --- | --- |
| **Mamba-1 / Mamba-2 支持** | V1 引擎支持 Mamba-1 和 Mamba-2 层：`Mamba2ForCausalLM`、`MambaForCausalLM`、`FalconMambaForCausalLM` 等。 |
| **混合模型支持** | 支持 Transformer + SSM 混合架构：`JambaForCausalLM`、`Zamba2ForCausalLM`、`NemotronHForCausalLM`、`FalconH1ForCausalLM`、`GraniteMoeHybridForCausalLM`、`Plamo2ForCausalLM` 等。也支持其他非线性注意力混合架构（如 `Lfm2ForCausalLM`）。 |
| **限制** | 目前 Mamba 模型不支持前缀缓存（V1 引擎文档明确标注）。Mamba-1 模型在 V1 中需要禁用前缀缓存。Mamba-2 混合模型需要 FlashInfer 注意力后端。 |
| **对比 SGLang** | vLLM 的 Mamba 模型覆盖更广（15+ 架构），但 SGLang 的 Mamba Radix Tree 和 Elastic Memory Pool 在 SSM state 复用上有独特优势。vLLM 目前不支持 Mamba state 的跨请求复用（无 state 级前缀缓存）。 |
| **非 Transformer 长上下文** | vLLM 支持 RWKV（线性注意力）、RetNet（多尺度指数衰减）、DiffusionGemma（扩散语言模型）等替代架构，长上下文场景覆盖最广。 |

**启动参数：**

```bash
# Mamba 模型自动检测
# 混合模型需要：
--attention-backend flashinfer    # Mamba-2 混合模型需要 FlashInfer

性能影响：

• Mamba-2 O(n) 计算复杂度，长上下文场景内存效率优势显著
• 不支持 Mamba 前缀缓存，多轮对话场景性能不如 SGLang

版本要求： vLLM 0.8.0+（V1 Mamba-1/2），持续扩展中

---

SGLang 对应配置：

混合架构自动检测，无需显式参数

可配置弹性内存池：

SGLANG_ELASTIC_MEMORY_POOL=1

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


**vLLM 实现路径：**

vLLM 通过 KV offloading 多层缓存（GPU→CPU→远端存储）和 LMCache 集成支持超长上下文和 PD 分离部署。通过 Mooncake 连接器支持跨节点 KV cache 传输。

**具体体现：**

| 层级 | 实现细节 |
| --- | --- |
| **L1：GPU HBM** | vLLM 的 APC（自动前缀缓存）= 基于 content hash 的 KV block 缓存表。V1 引擎将 APC 设为默认启用。Block 大小默认 16 token。命中率取决于 workload 的共享前缀程度。 |
| **L2：CPU DRAM** | KV offloading 支持多层级异步批量查找（PR #44193）。通过 packed HMA KV-cache layout（PR #46205）在 CPU 端高效存储。parallel-agnostic fs-tier cache（PR #44733）支持文件系统层的持久化缓存。Offloading manager 提供 stats 和 labeled/CPU-usage 指标监控（PR #35669, #45957）。 |
| **L3：远端存储** | Mooncake layerwise connector 支持跨节点的分层 KV cache 传输（实验性）。Self-describing KV events（PR #43468）实现缓存事件同步。LMCache 集成通过 `--kv-transfer-config` 启用 MP Connector（如 `LMCacheMPConnector`）。 |
| **PD 分离** | v0.24.0 完善 PD 分离支持：DP supervisor（PR #46628）、DSV4 disaggregation（PR #45831）、removed P2pNcclConnector（PR #44854）。Prefill 节点计算后通过 Mooncake/LMCache 传输 KV cache 到 Decode 节点。 |
| **Non-blocking idle flush** | 空闲时的非阻塞 KV cache 刷写（PR #45595），在 GPU 空闲时自动将冷 KV cache 迁移到 CPU/存储，避免干扰热请求。 |
| **对比 SGLang** | vLLM 的 APC 是基于 content-hash 的块级缓存，SGLang 的 RadixAttention 是基于 radix tree 的 token 级缓存。在相同 workload 下，SGLang 的命中率通常更高（特别是 branching conversation 和跨请求部分前缀共享）。但 vLLM 的 block-hash 设计更简单，对 batch inference 的 overhead 更低。 |
| **DSA 注意力兼容性** | 两个框架都面临 DSA 注意力降低前缀缓存命中率的挑战。vLLM 通过 DSA-CP 恢复命中率（需要启用 `enable_dsa_cp`）。 |

**启动参数：**

```bash
# APC（默认启用）
--enable-prefix-caching

# KV offloading
--kv-transfer-config '{"kv_connector":"LMCacheMPConnector","kv_role":"kv_both"}'

# CPU offload
--cpu-offload-gb 64

性能影响：

• APC 在 RAG 场景 88-94% prefill 节省，多轮对话 60-80%
• L2 offload 支持超长上下文（>GPU HBM 容量），PCIe 传输延迟代价
• LMCache MP 跨节点 KV cache 共享

版本要求： vLLM 0.8.0+（基础 APC），0.22.0+（KV offloading），0.24.0+（PD 分离完善）

---

H. 延迟改进

SGLang 对应配置：

HiCache 默认启用 L1

L2/L3 需要显式配置：

SGLANG_HICACHE_L2_SIZE=64GB # CPU DRAM 缓存大小
SGLANG_HICACHE_L3_URL=redis://… # 远端缓存地址

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


**vLLM 实现路径：**

vLLM 的 APC（Automatic Prefix Caching）是基于 content-hash 的块级 KV cache 复用机制。V1 引擎进行了全面优化。

**具体体现：**

| 层面 | 实现细节 |
| --- | --- |
| **APC 核心机制** | 每个 KV block（默认 16 token）被 hash（`sha256`，可配 `xxhash`），与之前所有请求的 block 对比。Hash 匹配 → 复用已计算的 KV。基于 content-addressed 设计，与 token 序列无关。 |
| **V1 优化** | V1 引擎前缀缓存标注为"已优化"（vs V0 的"已优化"状态）。统一调度器天然支持前缀缓存——不区分 prefill 和 decode token，调度时自动检测可复用前缀。 |
| **SGLang 对比** | APC 是 hash table 设计（查表 O(1)），RadixAttention 是 radix tree 设计（树遍历 O(前缀长度)）。APC 对 batch inference 更友好（多条请求批量查表），RadixAttention 对 dynamic branching conversation 更友好（树结构天然适应分支）。 |
| **命中率因素** | APC 的命中率高度依赖 workload 特征。RAG + 稳定检索集：88-94% prefill 节省。多轮对话：60-80%（平均）。开放式 Q&A：0-5%（低分享前缀）。 |
| **DSA 兼容性** | DSA 稀疏注意力会显著降低 APC 命中率——因为 DSA 按 query 动态选择 KV 子集，共享前缀不可直接复用。需要启用 DSA-CP（`enable_dsa_cp`）。启用后单 rank 命中率可达 ~90.9%。 |
| **Eviction 策略** | V1 使用 LRU 淘汰策略。长前缀 block 在内存压力下最先被淘汰。需要合理设置 `--gpu-memory-utilization` 保留足够的 KV cache 预算。 |
| **安全性提升** | v0.22.1 默认使用 SHA-256 hash（`--prefix-caching-hash-algo sha256`），相比旧版 xxhash 更安全，防止恶意 hash 碰撞导致的 cache poison。 |

**启动参数：**

```bash
--enable-prefix-caching                      # V1 默认启用
--prefix-caching-hash-algo sha256            # hash 算法
--gpu-memory-utilization 0.90                # 预留 KV cache 预算
--enable-dsa-cp                              # DSA 场景恢复命中率

性能影响：

• RAG 场景：88-94% prefill 节省，TTFT 从 ~1.2s 降至 ~30ms
• 多轮对话：60-80% prefill 节省
• DSA-CP 启用后命中率从 ~0% 恢复到 ~90.9%

版本要求： vLLM 0.8.0+（V1 APC），0.22.1+（SHA-256 hash）

---

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

vLLM 实现路径：

从延迟角度，vLLM 的 MTP + EAGLE 推测解码与 Persistent Batch 和 CUDA Graph 协同，在每个 decode step 产生 1.85 个有效 token。

具体体现：

层面	实现细节
减少 decode 步数	MTP=1 时，每步输出 ~1.85 个有效 token（接受率 85%），decode 步数减少约 46%。EAGLE-3 可输出更多（取决于 num_speculative_tokens 设置，通常 3-5 个）。
V1 引擎协同	Persistent Batch 使推测解码的 CPU 开销最小化。CUDA Graph 在 FULL_DECODE_ONLY 模式下将整个 decode path（包括 draft 生成 + target 验证）捕获为单 graph，消除中间 kernel launch 开销。
batch size 敏感	推测解码的效果高度依赖 batch size 和 QPS。低 QPS（延迟优先）时 EAGLE/MTP 收益最大，高 QPS（吞吐优先）时收益递减——因为 draft model 的开销在大量请求中被摊销。N-gram 和 suffix 方法在所有 QPS 下提供适度、可预测的收益。
延迟 vs 吞吐权衡	单请求延迟降低约 40-46%（MTP）。高并发（batch=64+）时延迟降低约 25-30%，因为 GPU 已经满载，推测解码的 batch 扩展带来额外开销。

性能影响：

• 单请求延迟降低约 40-46%（MTP，接受率 85%）
• 高并发场景 25-30% 延迟降低
• DigitalOcean DSv3.2 benchmark：230 TPS per-user output（with MTP）

版本要求： vLLM 0.8.0+（基础），v0.24.0+（完整 tree attention + DFLASH）

---

附录：完整启动命令

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

vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --kv-cache-dtype fp8_ds_mla \
  --block-size 256 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --prefix-caching-hash-algo sha256 \
  --enable-chunked-prefill \
  --compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}' \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}' \
  --guided-decoding-backend xgrammar \
  --tokenizer-mode deepseek_v4 \
  --trust-remote-code \
  --host 0.0.0.0 \
  --port 8000

FP8 量化部署（非 Blackwell）

vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --tensor-parallel-size 4 \
  --enable-expert-parallel \
  --kv-cache-dtype fp8 \
  --quantization fp8 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.90 \
  --trust-remote-code \
  --tokenizer-mode deepseek_v4

LMCache 集成（超长上下文跨节点）

# 先启动 LMCache server
lmcache server --l1-size-gb 100 --eviction-policy LRU

# 启动 vLLM
vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --kv-cache-dtype fp8_ds_mla \
  --trust-remote-code \
  --tokenizer-mode deepseek_v4 \
  --kv-transfer-config '{"kv_connector":"LMCacheMPConnector","kv_role":"kv_both"}'

Docker 一键部署

docker run -d \
  --name vllm-deepseek-v4-flash \
  --gpus all --privileged --ipc=host \
  -p 8000:8000 \
  -v /data/models:/models:ro \
  -e VLLM_ENGINE_READY_TIMEOUT_S=3600 \
  vllm/vllm-openai:deepseekv4-cu129 \
  /models/DeepSeek-V4-Flash \
  --trust-remote-code \
  --kv-cache-dtype fp8_ds_mla \
  --block-size 256 \
  --enable-expert-parallel \
  --gpu-memory-utilization 0.95 \
  --max-model-len 131072 \
  --tokenizer-mode deepseek_v4

环境变量配置

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

# Triton 快速启动（跳过自动调优）
export VLLM_TRITON_FORCE_FIRST_CONFIG=1

# 调试 torch.compile
export VLLM_DEBUG_DUMP_PATH=/tmp/vllm_debug

# CPU offload（当 GPU 显存不足时）
# 在启动参数中添加：--cpu-offload-gb 64

特性-参数速查表

特性	启动参数 / 环境变量	版本要求
MatMul/KV 动态量化	--kv-cache-dtype fp8_ds_mla --quantization fp8/fp4	0.8.0+
EPLB	--enable-expert-parallel	0.6.6+
FP8 KV Cache	--kv-cache-dtype fp8_ds_mla（必选）	0.8.0+
DeepGEMM E8M0	自动启用（CUTLASS SM90 + DeepGEMM）	0.11.0+
FP8 注意力 MLA	--kv-cache-dtype fp8_ds_mla（自动选择 FlashMLA）	0.8.0+
MoE 融合内核	--compilation-config + 自动融合	0.8.0+
共享专家	--enable-expert-parallel（自动处理）	0.6.6+
细粒度专家	--enable-expert-parallel --tensor-parallel-size 8	0.6.6+
GEMM/MoE 自动调优	--compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}'	0.8.0+
滑动窗口	自动（模型 config）	0.8.0+
跨层注意力	自动（HybridKVCache 管理）	0.8.0+
原生量化	--trust-remote-code（自动检测 FP4 权重）	0.8.0+
KV 压缩 V2	--block-size 256（HybridKVCache）	0.8.0+
MHC 路径融合	--compilation-config（torch.compile 通用融合）	0.8.0+
异步调度	V1 引擎默认启用	0.8.0+
推测解码 MTP	--speculative-config '{"method":"mtp","num_speculative_tokens":1}'	0.8.0+
EAGLE-3	--speculative-config '{"method":"eagle3",...}'	0.11.0+
XGrammar	--guided-decoding-backend xgrammar	0.8.0+
FlashInfer 预缓存	预编译 wheel + Triton 缓存	0.8.0+
torch.compile	V1 引擎默认启用	0.8.0+
AllReduce+RMSNorm 融合	自动（Helion 内核 + 注意力融合路径）	0.8.0+
注意力+量化融合	自动（DeepSeek V4 attention 融合）	0.8.0+
SSM 支持	自动（Mamba-1/Mamba-2 架构检测）	0.8.0+
KV offloading	--kv-transfer-config + --cpu-offload-gb	0.22.0+
APC 前缀缓存	--enable-prefix-caching（V1 默认启用）	0.8.0+
DSA-CP	--enable-dsa-cp	0.22.0+

---

vLLM vs SGLang 关键差异汇总

维度	vLLM 优势	SGLang 优势
KV Cache 管理	HybridKVCache + 统一 block size + 三页面桶，解决 DeepSeek V4 异构压缩的最优内存布局	KV 压缩 V2 + HiCache L1/L2/L3 分层缓存
前缀缓存	APC 块级 hash（O(1) 查表，对 batch inference 更友好）	RadixAttention 基数树（对 dynamic branching 更友好）
调度器	V1 异步调度（追赶中，still catching up）	零开销批调度器 + Two-Batch Overlap（三重重叠）
推测解码	方法更多（EAGLE/N-gram/Suffix + MTP），生态更广	Spec V2 默认启用，吞吐 419 vs 297 tokens/s（约 1.4x）
结构化输出	多后端选择，V1 非阻塞初始化	XGrammar mask 与 GPU 重叠，batch ≥8 时约 15-30% 吞吐优势
MoE 通信	标准 NCCL + FP8/FP4 压缩	DeepEP 定制通信库 + Two-Batch Overlap
Mamba/SSM	15+ 架构覆盖，最早支持	Mamba Radix Tree + 弹性内存池（state 复用），Agent 场景更优
硬件覆盖	NVIDIA + AMD + Intel XPU + TPU + CPU + 华为 Ascend（最广）	NVIDIA 为主
生态/模型	200+ 架构，最大的开源推理社区	快速跟进，DeepSeek Day-0 支持
MHC 路径	torch.compile 通用融合	专用 hc_head/mhc_fused_post_pre 融合
Kernel 数	~33 → ~10（与 SGLang 相似的融合策略）	~33 → ~10（与 vLLM 相似的融合策略）
AMD 支持	AITER Biased Group TopK + AMD fusions（最成熟的 AMD 路径）	社区贡献为主

---

硬件推荐

配置	上下文长度	所需硬件	vLLM 参数
最小开发	128K	2× H200 141GB 或 4× A100 80GB	--tensor-parallel-size 2 --max-model-len 131072
生产推荐	256K	4× H200 或 8× A100	--tensor-parallel-size 4 --max-model-len 262144
1M 上下文	1M	8× H200 或更多	--tensor-parallel-size 8 --max-model-len 1048576
Blackwell	1M	2× B200 或 1× GB200 NVL	--tensor-parallel-size 2 --quantization fp4

---

版本升级路径建议

当前版本	目标特性	推荐升级至
0.6.x	基础 EP + FP8 KV + HybridKVCache	0.8.0 (V1 引擎)
0.8.x	DeepGEMM + EAGLE-3 多模态 + FP4 权重	0.11.0
0.11.x	KV offloading + LMCache + PD 分离 + DSA-CP	0.22.0
0.22.x	NVFP4 cute-dsl + MXFP8 + Cluster TopK + SM100 native DSA	0.24.0

注意： DeepSeek V4 Flash 的基本部署需要 vLLM 0.8.0+（hybrid KVCache + fp8_ds_mla 支持）。完整特性需要 0.24.0+。Blackwell 架构上的 FP4 端到端流水线需要 0.24.0+。始终使用官方 tagged release 而非 main/dev 分支（dev 分支存在 FP4 MoE 路由 bug）。

SGLang 对应配置：

FlashInfer 预编译

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 高吞吐

## 附录：完整启动命令

### vLLM 部署 DeepSeek V4 Flash — 全特性启用

```bash
vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --kv-cache-dtype fp8_ds_mla \
  --block-size 256 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --prefix-caching-hash-algo sha256 \
  --enable-chunked-prefill \
  --compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}' \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}' \
  --guided-decoding-backend xgrammar \
  --tokenizer-mode deepseek_v4 \
  --trust-remote-code \
  --host 0.0.0.0 \
  --port 8000

FP8 量化部署（非 Blackwell）

vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --tensor-parallel-size 4 \
  --enable-expert-parallel \
  --kv-cache-dtype fp8 \
  --quantization fp8 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.90 \
  --trust-remote-code \
  --tokenizer-mode deepseek_v4

LMCache 集成（超长上下文跨节点）

# 先启动 LMCache server
lmcache server --l1-size-gb 100 --eviction-policy LRU

# 启动 vLLM
vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --kv-cache-dtype fp8_ds_mla \
  --trust-remote-code \
  --tokenizer-mode deepseek_v4 \
  --kv-transfer-config '{"kv_connector":"LMCacheMPConnector","kv_role":"kv_both"}'

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

Docker 一键部署

docker run -d \
  --name vllm-deepseek-v4-flash \
  --gpus all --privileged --ipc=host \
  -p 8000:8000 \
  -v /data/models:/models:ro \
  -e VLLM_ENGINE_READY_TIMEOUT_S=3600 \
  vllm/vllm-openai:deepseekv4-cu129 \
  /models/DeepSeek-V4-Flash \
  --trust-remote-code \
  --kv-cache-dtype fp8_ds_mla \
  --block-size 256 \
  --enable-expert-parallel \
  --gpu-memory-utilization 0.95 \
  --max-model-len 131072 \
  --tokenizer-mode deepseek_v4

环境变量配置

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

# Triton 快速启动（跳过自动调优）
export VLLM_TRITON_FORCE_FIRST_CONFIG=1

# 调试 torch.compile
export VLLM_DEBUG_DUMP_PATH=/tmp/vllm_debug

# CPU offload（当 GPU 显存不足时）
# 在启动参数中添加：--cpu-offload-gb 64

特性-参数速查表

特性	启动参数 / 环境变量	版本要求
MatMul/KV 动态量化	--kv-cache-dtype fp8_ds_mla --quantization fp8/fp4	0.8.0+
EPLB	--enable-expert-parallel	0.6.6+
FP8 KV Cache	--kv-cache-dtype fp8_ds_mla（必选）	0.8.0+
DeepGEMM E8M0	自动启用（CUTLASS SM90 + DeepGEMM）	0.11.0+
FP8 注意力 MLA	--kv-cache-dtype fp8_ds_mla（自动选择 FlashMLA）	0.8.0+
MoE 融合内核	--compilation-config + 自动融合	0.8.0+
共享专家	--enable-expert-parallel（自动处理）	0.6.6+
细粒度专家	--enable-expert-parallel --tensor-parallel-size 8	0.6.6+
GEMM/MoE 自动调优	--compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}'	0.8.0+
滑动窗口	自动（模型 config）	0.8.0+
跨层注意力	自动（HybridKVCache 管理）	0.8.0+
原生量化	--trust-remote-code（自动检测 FP4 权重）	0.8.0+
KV 压缩 V2	--block-size 256（HybridKVCache）	0.8.0+
MHC 路径融合	--compilation-config（torch.compile 通用融合）	0.8.0+
异步调度	V1 引擎默认启用	0.8.0+
推测解码 MTP	--speculative-config '{"method":"mtp","num_speculative_tokens":1}'	0.8.0+
EAGLE-3	--speculative-config '{"method":"eagle3",...}'	0.11.0+
XGrammar	--guided-decoding-backend xgrammar	0.8.0+
FlashInfer 预缓存	预编译 wheel + Triton 缓存	0.8.0+
torch.compile	V1 引擎默认启用	0.8.0+
AllReduce+RMSNorm 融合	自动（Helion 内核 + 注意力融合路径）	0.8.0+
注意力+量化融合	自动（DeepSeek V4 attention 融合）	0.8.0+
SSM 支持	自动（Mamba-1/Mamba-2 架构检测）	0.8.0+
KV offloading	--kv-transfer-config + --cpu-offload-gb	0.22.0+
APC 前缀缓存	--enable-prefix-caching（V1 默认启用）	0.8.0+
DSA-CP	--enable-dsa-cp	0.22.0+

---

vLLM vs SGLang 关键差异汇总

维度	vLLM 优势	SGLang 优势
KV Cache 管理	HybridKVCache + 统一 block size + 三页面桶，解决 DeepSeek V4 异构压缩的最优内存布局	KV 压缩 V2 + HiCache L1/L2/L3 分层缓存
前缀缓存	APC 块级 hash（O(1) 查表，对 batch inference 更友好）	RadixAttention 基数树（对 dynamic branching 更友好）
调度器	V1 异步调度（追赶中，still catching up）	零开销批调度器 + Two-Batch Overlap（三重重叠）
推测解码	方法更多（EAGLE/N-gram/Suffix + MTP），生态更广	Spec V2 默认启用，吞吐 419 vs 297 tokens/s（约 1.4x）
结构化输出	多后端选择，V1 非阻塞初始化	XGrammar mask 与 GPU 重叠，batch ≥8 时约 15-30% 吞吐优势
MoE 通信	标准 NCCL + FP8/FP4 压缩	DeepEP 定制通信库 + Two-Batch Overlap
Mamba/SSM	15+ 架构覆盖，最早支持	Mamba Radix Tree + 弹性内存池（state 复用），Agent 场景更优
硬件覆盖	NVIDIA + AMD + Intel XPU + TPU + CPU + 华为 Ascend（最广）	NVIDIA 为主
生态/模型	200+ 架构，最大的开源推理社区	快速跟进，DeepSeek Day-0 支持
MHC 路径	torch.compile 通用融合	专用 hc_head/mhc_fused_post_pre 融合
Kernel 数	~33 → ~10（与 SGLang 相似的融合策略）	~33 → ~10（与 vLLM 相似的融合策略）
AMD 支持	AITER Biased Group TopK + AMD fusions（最成熟的 AMD 路径）	社区贡献为主

---

硬件推荐

配置	上下文长度	所需硬件	vLLM 参数
最小开发	128K	2× H200 141GB 或 4× A100 80GB	--tensor-parallel-size 2 --max-model-len 131072
生产推荐	256K	4× H200 或 8× A100	--tensor-parallel-size 4 --max-model-len 262144
1M 上下文	1M	8× H200 或更多	--tensor-parallel-size 8 --max-model-len 1048576
Blackwell	1M	2× B200 或 1× GB200 NVL	--tensor-parallel-size 2 --quantization fp4

---

版本升级路径建议

当前版本	目标特性	推荐升级至
0.6.x	基础 EP + FP8 KV + HybridKVCache	0.8.0 (V1 引擎)
0.8.x	DeepGEMM + EAGLE-3 多模态 + FP4 权重	0.11.0
0.11.x	KV offloading + LMCache + PD 分离 + DSA-CP	0.22.0
0.22.x	NVFP4 cute-dsl + MXFP8 + Cluster TopK + SM100 native DSA	0.24.0

注意： DeepSeek V4 Flash 的基本部署需要 vLLM 0.8.0+（hybrid KVCache + fp8_ds_mla 支持）。完整特性需要 0.24.0+。Blackwell 架构上的 FP4 端到端流水线需要 0.24.0+。始终使用官方 tagged release 而非 main/dev 分支（dev 分支存在 FP4 MoE 路由 bug）。