Inference Stack · SGLang

SGLang 部署前沿大模型

本册覆盖 SGLang 0.5.23 的完整部署链路:参数语义、显存与 KV 计算、并行拓扑、逐模型可复制命令、调优方法与故障排查。

引擎SGLang 0.5.23
核验2026-11-06
来源官方文档与仓库

00导读

这份文档讲什么

SGLang 在 2026 年的定位很清晰:它是 MoE 大模型推理性能的标杆实现。RadixAttention(基数树前缀缓存)、PD 分离、HiCache 分层缓存、DeepEP/MoRI 专家并行,这些能力让它成为 DeepSeek、Qwen、GLM、Kimi 这类稀疏模型的首选引擎之一。

本文只讲三件事:

  1. 参数到底控制什么 —— 不是抄 --help,而是说明它作用在哪个阶段、调大调小分别牺牲什么。
  2. 不同硬件怎么配 —— 官方 Cookbook 已验证的组合,附完整命令。
  3. 出问题怎么定位 —— 日志里看哪几个数字。

数据基准

组件基线说明
SGLang0.5.232026-10-30 发布
Python≥ 3.11官方 wheel 要求
CUDA12.x / 13.xBlackwell 需 CUDA 13 镜像
ROCm7.0 / 7.2 / 10.0MI355X 新特性多在 ROCm 10
引擎SGLang Runtime (SRT)另有 sglang-router 做多实例路由
时效性声明

SGLang 迭代极快,很多模型需要 --prerelease=allow 从 main 分支安装。凡涉及「默认值」的判断,请在目标机器上执行 python -m sglang.launch_server --help 确认。

三个必须先建立的心智模型

① RadixAttention 是 SGLang 的核心差异点。 vLLM 用块哈希做前缀缓存,SGLang 用基数树(radix tree)。基数树能表达「多个请求共享不同长度的公共前缀」这种树状结构,在 Agent、多轮对话、few-shot 场景下命中率更高。代价是调度器要维护树结构,CPU 开销略大。

② --mem-fraction-static 是显存的总闸门。 它一次性决定「权重 + KV 池」占多少显存,剩余部分留给激活和 CUDA Graph。这个参数设错,要么 OOM,要么 KV 池小得可怜。

③ SGLang 的并行维度比 vLLM 多一维。 除了 TP/PP/DP/EP,它还有 --attn-dp-size(TP 组内做注意力数据并行)和 --dcp-size(解码上下文并行)。DeepSeek 系的官方推荐配置几乎都会用到 --attn-dp-size。


012026 的部署格局

变化一:MoE 成为默认,通信成为主瓶颈

2026 年的旗舰模型清一色是细粒度专家混合:

模型总参激活专家数 / 激活数
DeepSeek-V4-Pro1.6T49B384 / 6
Kimi-K3.1-Pro2.8T—896 / 16
Qwen3.5-397B-A17B397B17B512 / 10
GLM-5.3743B39B256 / 8
MiniMax-M3427B26B128 / 4

激活比例压到 3%–6% 后,算力不再是瓶颈,跨卡 all-to-all 才是。这就是 SGLang 把大量工程投入放在 --moe-a2a-backend 和 --moe-runner-backend 上的原因。

变化二:上下文进入百万级

DeepSeek-V4、Kimi-K3、MiniMax-M3、GLM-5.3 都标称 1,048,576 token。Qwen3.5 原生 262,144,可通过 YaRN 扩到约 101 万。

直接后果:

  • Prefill 成本爆炸。 1M token 的 prefill 计算量相当于生成数万 token,必须靠 chunked prefill 切块。
  • PD 分离成为刚需。 混合调度下,长 prefill 会打断 decode,导致 ITL 抖动。SGLang 官方文档明确指出这是 PD 分离要解决的两个核心问题之一。

变化三:注意力架构分道扬镳

架构族代表SGLang 对应参数
MLADeepSeek-V3/V4、GLM、Kimi--attention-backend flashmla / trtllm_mla / tokenspeed_mla
稀疏注意力 DSADeepSeek-V4、GLM-5.3--attention-backend dsa、--dsa-topk-backend
线性注意力 GDNQwen3.5、Qwen3.8--linear-attn-prefill-backend、--mamba-radix-cache-strategy
线性注意力 KDAKimi-K3内置,需 --page-size 配合
GQA + 滑窗gpt-oss、Llama--attention-backend flashinfer / fa3 / fa4

2026 前沿模型一览

模型总参 / 激活上下文注意力精度备注
DeepSeek-V4-Pro1.6T / 49B1,048,576CSA + HCAFP4 / FP8需多节点
DeepSeek-V4.1-Flash552B / 8B·16B1,048,576SWA + CSAFP8视觉语言
Qwen3.5-397B-A17B397B / 17B262,144 → 1.01MGDN + 全注意力BF16 / FP8 / NVFP4 / MXFP4官方 Cookbook 覆盖最全
Kimi-K3.1-Pro2.8T / 16 of 8961,048,576KDA + 稀疏 MLAMXFP4需 day-0 分支
Qwen3.8-Flash-Next176B / 6B262,144Qwen4 预览,GDN + GQANVFP4 / FP8 / BF16 / MXFP451B N-gram embedding
GLM-5.3743B / 39B1,048,576MLA + DSAFP8 / NVFP4 / W4A8官方 Cookbook 有 Ascend 路径
MiniMax-M3427B / 26B1,048,576MSA 块稀疏MXFP8 / BF16 / NVFP4原生多模态
gpt-oss-120b117B / 5.1B131,072滑窗 + 全注意力MXFP4入门基线
注意

SGLang 对前沿模型的支持高度依赖镜像版本。Kimi-K3.1-Pro 需要 kimi-k3.1-day-0 分支,MiniMax-M3 需要 ≥ 0.5.22 的版本化镜像,Qwen3.5 需要 main 分支源码安装。部署前先确认镜像 tag,不要用 pip install sglang 的默认版本。


02显存预算与 KV 计算

显存的四块开销

CODE
┌────────────────────────────────────────────────────────────┐
│   Weights   │  KV Cache Pool  │  CUDA Graph  │ Activations │
└────────────────────────────────────────────────────────────┘
 └──── mem_fraction_static ────┘
                                 └──────── 剩余部分 ────────┘

SGLang 的划分方式和 vLLM 不同:--mem-fraction-static 同时覆盖权重和 KV 池,公式为:

CODE
mem_fraction_static = (model weights + KV cache pool) / GPU memory capacity

剩余部分留给激活和 CUDA Graph buffer。官方经验值:保留 5–8 GB 给激活即可。

怎么判断设得对不对

启动日志会打印一行关键信息:

CODE
max_total_num_tokens=665690, chunked_prefill_size=8192, max_prefill_tokens=16384,
max_running_requests=4096, context_len=65536, available_gpu_mem=13.50 GB

看 available_gpu_mem:

值判断动作
5–8 GB合适保持
10–20 GB太保守,KV 池浪费提高 --mem-fraction-static
< 5 GB有 OOM 风险降低 --mem-fraction-static

官方给的调法很直接:以 0.01 为步长往上加,直到压测出现 OOM,再退回来。

KV Cache 的两种算法

MHA / GQA / MQA(统一公式)

这三种架构用的是同一个公式,差别只在 n_kv_heads 取什么值:

CODE
KV_bytes_per_token = 2 × n_layers × n_kv_heads × head_dim × dtype_bytes
                     ↑                        ↑
                     K 和 V 各一份            这里是唯一的架构差异
架构n_kv_heads相对 MHA 的 KV 量例
MHA= n_heads1×Llama-1/2、GPT-3
GQA= n_heads / g1/gLlama-3(g=8)、Qwen3(g=8)
MQA= 11/n_headsPaLM、Falcon

所以 GQA 和 MHA 的差别就是分组比 g 倍——Llama-3-70B 是 64 个 query head 配 8 个 KV head(g=8),KV 只有 MHA 的 1/8。写公式时用 n_kv_heads 就把三者统一了,但不要把 "GQA / MHA" 并列成一个类别,读到的人容易误以为两者算法相同。

例:Llama-3.3-70B,BF16(64 q-heads / 8 kv-heads,g=8)

CODE
2 × 80 × 8 × 128 × 2 = 327,680 B ≈ 320 KiB / token

若换成 MHA(64 kv-heads),同样的模型会是 2.56 MiB/token —— 8 倍。

8K 上下文单请求就要 2.6 GB。这就是 GQA 模型的并发天花板。

MLA(DeepSeek / GLM / Kimi 系)

MLA 只缓存低秩潜向量 + RoPE 分量:

CODE
KV_bytes_per_token = n_layers × (kv_lora_rank + qk_rope_head_dim) × dtype_bytes

例:DeepSeek-V3,BF16

CODE
61 × (512 + 64) × 2 = 70,272 B ≈ 68.6 KiB / token

例:GLM-5,FP8

CODE
78 × (512 + 64) × 1 = 44,928 B ≈ 43.9 KiB / token

同样 FP8 下,GLM-5 每 token 只有 Llama-70B 的 1/7。这是 MLA 在长上下文场景的核心优势。

稀疏注意力的额外开销

DSA / MSA / CSA 会额外维护索引器状态,且通常不跟随主 KV 量化。Kimi-K3 的 KDA 层还为每条序列保留常数大小的循环状态,这部分不在分页 KV 池里。真实占用 = 公式值 + 索引器 + 状态池,务必以启动日志的 max_total_num_tokens 为准。

读懂 SGLang 的运行日志

SGLang 每个 decode step 会打印一行:

CODE
Decode batch. #running-req: 233, #token: 370959, token usage: 0.82,
cuda graph: True, gen throughput (token/s): 4594.01, #queue-req: 317
字段含义健康值
#running-req当前在跑的请求数接近 --max-running-requests
token usageKV 池使用率> 0.9 说明利用充分
#queue-req排队请求数100–2000
gen throughput生成吞吐越高越好

官方给的两个诊断信号:

  • token usage < 0.9 且 #queue-req > 0 → 服务太保守,降低 --schedule-conservativeness(如 0.3)。
  • 频繁出现 KV cache pool is full. Retract requests. → 太激进,提高 --schedule-conservativeness(如 1.3)。偶尔(约每分钟一次)出现是正常的。

03架构与参数作用点

SGLang 的进程与组件

CODE
Client
  │  HTTP / SSE
  ▼
┌─────────────────────────────────────────────┐
│  HTTP Server (FastAPI + uvicorn)            │
│  · 分词 / chat template / 多模态预处理        │
│  · OpenAI 兼容接口                            │
└───────────────┬─────────────────────────────┘
                │ ZMQ / IPC
                ▼
┌─────────────────────────────────────────────┐
│  Scheduler × (TP × DP × attn-dp)            │
│  · RadixCache:基数树前缀复用                 │
│  · Token 预算分配 / chunked prefill           │
│  · Retract(KV 不足时回退请求)                │
└───────────────┬─────────────────────────────┘
                ▼
┌─────────────────────────────────────────────┐
│  Model Runner × N (每卡一个)                  │
│  · Attention backend(fa3/fa4/flashmla/dsa) │
│  · MoE runner(deep_gemm/triton/flashinfer) │
│  · All-to-all(deepep/mooncake/nixl/mori)   │
└─────────────────────────────────────────────┘

一次请求的路径

CODE
① 接入        HTTP → 鉴权 → SSE 建连
                 ↓
② 输入处理    分词 → chat template → 多模态解码
                 ↓  --tokenizer-worker-num 可并行
③ 前缀匹配    RadixCache 查找最长公共前缀
                 ↓  --schedule-policy lpm 可优化
④ 排队调度    token 预算分配 → chunked prefill 切块
                 ↓  --max-prefill-tokens / --chunked-prefill-size
⑤ KV 分配     从 KV 池取页 → 不足则 retract
                 ↓  --page-size / --mem-fraction-static
⑥ 前向        prefill / decode → 采样
                 ↓  --attention-backend / --moe-runner-backend
⑦ 输出        反分词 → 流式推送
                 ↓  --stream-interval

延迟归属:

  • TTFT 主要由 ③④⑥(prefill)决定
  • ITL 几乎完全由 ⑥(decode 单步)决定
  • 吞吐 由 ④ 的 batch 效率和 ⑥ 的 kernel 效率共同决定

04核心参数详解

4.1模型与显存

参数默认含义与取舍
--model-path必填HF 仓库名或本地路径。生产用本地路径
--tp-size / --tp1张量并行度。要求 num_key_value_heads 能被 TP 整除,否则 KV 会被复制
--ep-size / --ep1专家并行度。DeepEP/Mooncake/NIXL/PPLX/MoRI 只支持 ep_size = tp_size
--dp-size1数据并行副本数。官方建议用 Router 而非 --dp-size 做 DP
--pp-size1流水并行度
--attn-dp-size1TP 组内的注意力数据并行组数,每个组一个 scheduler,FFN 仍走 TP
--dcp-size1解码上下文并行,把 MLA 潜变量切到多卡
--mem-fraction-static自动最重要的显存参数:权重 + KV 池占 GPU 的比例
--max-total-tokens自动直接指定 KV 池 token 数,覆盖自动计算
--context-length从 config 读模型最大上下文。OOM 时优先降这个
--quantization自动加载已量化 checkpoint 时无需指定;--quantization fp8 用于在线量化
--kv-cache-dtype自动fp8_e4m3 / fp8_e5m2。FP8 KV 通常必开

4.2调度与批处理

参数默认含义与取舍
--max-running-requests自动最大并发请求数。decode OOM 时优先降它
--max-queued-requests自动最大排队数,PD 分离模式下忽略
--chunked-prefill-size8192单次 prefill 的最大 token 数。prefill OOM 时降到 4096 或 2048
--max-prefill-tokens16384单批 prefill token 上限;实际取它与模型最大上下文的较大值
--schedule-policyfcfslpm(最长前缀优先,提升命中率)、random、dfs-weight、lof、priority、routing-key
--schedule-conservativeness1.0< 1 更激进(吃更多请求),> 1 更保守(减少 retract)
--page-size1KV 页大小。AITER 后端要求 16;Kimi-K3 的 mamba 策略要求 64
--cuda-graph-max-bs-decode自动(<160/256)decode CUDA Graph 的最大 batch。大 TP 时可提到 512–768,但会吃显存

4.3缓存

参数默认含义
--disable-radix-cache关闭(即默认启用)RadixAttention 前缀缓存。与 HiCache 互斥
--enable-hierarchical-cache / --enable-hicache关闭启用 host DRAM 二级 KV 缓存
--hicache-ratio1.5host 层大小为 device KV 的倍数
--hicache-size—直接指定 host 层大小(GB/rank),覆盖 ratio
--hicache-write-policy—write_through(写时同步镜像)/ write_back
--hicache-io-backend—kernel / direct
--hicache-mem-layout—page_first 等
--enable-unified-cache-external-linker关闭直接对接外部 KV 存储(如 Mooncake)
--mamba-radix-cache-strategyno_buffer混合 Mamba 模型的缓存策略:no_buffer(默认,省显存)/ extra_buffer(支持 overlap 调度,需 FLA 内核)

4.4后端选择

Attention backend(--attention-backend):

值适用
flashinfer通用,Hopper/Blackwell 上表现均衡
fa3 / fa4FlashAttention 3/4,H100/H200 用 fa3,B200/B300 用 fa4
flashmla / trtllm_mla / tokenspeed_mla / cutedsl_mlaMLA 模型专用
dsaDeepSeek Sparse Attention
aiterAMD,需 --page-size 16
triton兜底,兼容性最好

MoE all-to-all backend(--moe-a2a-backend):

值适用场景
none(默认)混合 EP+TP 场景,用 AllReduce/AllGather 派发
deepep大规模 EP,支持 normal / low_latency 两种模式
mooncake弹性 EP,基于 RDMA
nixl弹性 EP,NVIDIA NIXL,支持容错与动态扩缩
moriAMD ROCm 原生
flashinfer大规模 EP
pplxHopper 上的低延迟 decode EP,需 NVSHMEM

MoE runner backend(--moe-runner-backend):

值适用
auto(默认)按架构/硬件/量化自动选
deep_gemmFP8 block-wise 量化,prefill 用连续布局、decode 用 masked 布局
triton通用,建议配合 tuned config
flashinfer_trtllmBlackwell + TRT-LLM 内核
flashinfer_cutedslBlackwell + NVFP4

4.5解析器

参数说明
--tool-call-parser可设 auto 从 chat template 自动检测。可选值含 deepseekv4、glm47、kimi_k3、qwen3_coder、minimax_m3、gpt-oss 等
--reasoning-parser同上。可选 deepseek-v4、glm45、kimi_k3、qwen3、minimax_m3、step3p5 等
--served-model-name覆盖 /v1/models 返回的名字
实践建议

2026 年的模型几乎都支持 auto,但自动检测依赖 chat template 的元数据。如果模型用的是自定义编码器(如 Kimi-K3 的 XTML、DeepSeek-V4 的 Python encoder),auto 可能失效,需要显式指定。


05并行策略选型

本引擎的推理拓扑与 KV 存放

为便于阅读,下图使用小规模设备组解释机制,不代表旗舰模型能装入这些设备。

attention-DP 是 TP 组内的注意力数据分组,不等于完整模型副本。DeepEP 等后端的 EP/TP 约束需单独满足;共享专家融合会改变执行路径,不能只凭 ep-size 推断。

SGLang · A · Attention TP4 + routed TP4--tp-size 4 --ep-size 1示例:4 设备、8 个路由专家;GQA 有 8 个 KV head;无共享专家的模型省略左支路。同一请求 / 同一批 token设备 0 · Attn Layer权重 TP 切片 1/4KV heads 0–1(1/4)设备 1 · Attn Layer权重 TP 切片 2/4KV heads 2–3(1/4)设备 2 · Attn Layer权重 TP 切片 3/4KV heads 4–5(1/4)设备 3 · Attn Layer权重 TP 切片 4/4KV heads 6–7(1/4)共享专家 Shared Experts本图选取 TP4 权重切分所有 token 均进入此支路融合 / 其他放置方式另行核对路由专家 Routed Experts同一 token 的所选专家并行计算全部 E0–E7权重切片 1/4全部 E0–E7权重切片 2/4全部 E0–E7权重切片 3/4全部 E0–E7权重切片 4/4AllReduce:汇合权重切片结果共享输出 + 路由输出进入后续层;继续使用各模块的并行组
SGLang · A · Attention TP4 + routed TP4 · KV 已明确按 GQA 示例标注:TP4 每卡 2 个 KV head;attention-DP4 每卡保存自己请求的 KV。共享专家布局是图示前提,不是该引擎所有后端的默认承诺。
SGLang · B · Attention TP4 + routed EP4--tp-size 4 --ep-size 4示例:4 设备、8 个路由专家;GQA 有 8 个 KV head;无共享专家的模型省略左支路。同一请求 / 同一批 token设备 0 · Attn Layer权重 TP 切片 1/4KV heads 0–1(1/4)设备 1 · Attn Layer权重 TP 切片 2/4KV heads 2–3(1/4)设备 2 · Attn Layer权重 TP 切片 3/4KV heads 4–5(1/4)设备 3 · Attn Layer权重 TP 切片 4/4KV heads 6–7(1/4)共享专家 Shared Experts本图选取 TP4 权重切分所有 token 均进入此支路融合 / 其他放置方式另行核对路由专家 Routed ExpertsAllToAll dispatchE0–E1完整专家权重E2–E3完整专家权重E4–E5完整专家权重E6–E7完整专家权重AllToAll combine共享输出 + 路由输出进入后续层;继续使用各模块的并行组
SGLang · B · Attention TP4 + routed EP4 · KV 已明确按 GQA 示例标注:TP4 每卡 2 个 KV head;attention-DP4 每卡保存自己请求的 KV。共享专家布局是图示前提,不是该引擎所有后端的默认承诺。
SGLang · C · attention-DP4 + routed TP4--tp-size 4 --attn-dp-size 4 --ep-size 1示例:4 设备、8 个路由专家;GQA 有 8 个 KV head;无共享专家的模型省略左支路。不同请求 / 本地批次设备 0 · Attn Layer本地完整权重KV:请求 A 的完整历史设备 1 · Attn Layer本地完整权重KV:请求 B 的完整历史设备 2 · Attn Layer本地完整权重KV:请求 C 的完整历史设备 3 · Attn Layer本地完整权重KV:请求 D 的完整历史共享专家 Shared Experts本图选取本地完整副本所有 token 均进入此支路融合 / 其他放置方式另行核对路由专家 Routed ExpertsAllGather:汇集各 rank 的 token全部 E0–E7权重切片 1/4全部 E0–E7权重切片 2/4全部 E0–E7权重切片 3/4全部 E0–E7权重切片 4/4ReduceScatter:返回本地 token共享输出 + 路由输出进入后续层;继续使用各模块的并行组
SGLang · C · attention-DP4 + routed TP4 · KV 已明确按 GQA 示例标注:TP4 每卡 2 个 KV head;attention-DP4 每卡保存自己请求的 KV。共享专家布局是图示前提,不是该引擎所有后端的默认承诺。
SGLang · D · attention-DP4 + routed EP4--tp-size 4 --attn-dp-size 4 --ep-size 4示例:4 设备、8 个路由专家;GQA 有 8 个 KV head;无共享专家的模型省略左支路。不同请求 / 本地批次设备 0 · Attn Layer本地完整权重KV:请求 A 的完整历史设备 1 · Attn Layer本地完整权重KV:请求 B 的完整历史设备 2 · Attn Layer本地完整权重KV:请求 C 的完整历史设备 3 · Attn Layer本地完整权重KV:请求 D 的完整历史共享专家 Shared Experts本图选取本地完整副本所有 token 均进入此支路融合 / 其他放置方式另行核对路由专家 Routed ExpertsAllToAll dispatchE0–E1完整专家权重E2–E3完整专家权重E4–E5完整专家权重E6–E7完整专家权重AllToAll combine共享输出 + 路由输出进入后续层;继续使用各模块的并行组
SGLang · D · attention-DP4 + routed EP4 · KV 已明确按 GQA 示例标注:TP4 每卡 2 个 KV head;attention-DP4 每卡保存自己请求的 KV。共享专家布局是图示前提,不是该引擎所有后端的默认承诺。

官方依据:SGLang 并行与配置文档。图示策略存在不代表某个模型、精度、硬件组合已实测。

五种并行

CODE
TP(张量并行)        层内切权重,每层 all-reduce
PP(流水并行)        按层切,stage 间传激活
DP(数据并行)        整模型复制,各跑各的请求
EP(专家并行)        MoE 专家分散,all-to-all 派发
DCP(解码上下文并行)  MLA 潜变量与索引器 KV 切到多卡

SGLang 特有的两个维度

--attn-dp-size:TP 组内的注意力数据并行

这是 DeepSeek 系模型的官方推荐配置。它把注意力层按 DP 拆成多个组,每组一个独立 scheduler,FFN 仍走 TP。好处是:

  • 每个 DP 组有独立的 KV 池和调度队列,减少跨组同步
  • 配合 --enable-dp-lm-head 可避免 DP 组间的 all-gather

官方 DeepSeek 多节点示例:

BASH
python -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V3-0324 \
  --tp-size 16 \
  --attn-dp-size 8 \
  --moe-a2a-backend deepep \
  --mem-fraction-static 0.8

--dcp-size:解码上下文并行

把 MLA 潜变量和索引器 KV 切片到多卡,直接放大 KV 容量。Kimi-K3 在 DCP8 下 KV 容量约为 TP8 的 7 倍,代价是 decode 慢 7–25%。只在 KV 容量是瓶颈时用。

选型决策

CODE
模型能装进单卡?
├─ 是 → 单卡,无需并行
└─ 否 → 是 MoE?
        ├─ 否(稠密)→ TP = 卡数(单机);跨机加 PP
        └─ 是 → 瓶颈是延迟还是吞吐?
                ├─ 延迟 → TP 优先 + 小 max-running-requests
                └─ 吞吐 → DP(或 attn-dp)+ EP + 大 batch
                          · 单机:--tp 8 --ep 8 --moe-a2a-backend deepep
                          · 多机:--tp 16 --attn-dp-size 8
                └─ 长上下文 → 加 --dcp-size 或 HiCache

EP 的关键约束

DeepEP / Mooncake / NIXL / PPLX / MoRI 只支持 ep_size = tp_size。
混合 EP+TP(即 ep_size < tp_size)只能用 none 后端(AllReduce/AllGather 派发)。

这条约束经常被忽略,导致配置报错。如果确实需要 ep < tp,就得接受 none 后端的性能损失。

另外:

  • --deepep-mode auto 会在运行时自动切换 normal / low_latency 模式
  • --deepep-mode normal 适合 prefill(高吞吐)
  • --deepep-mode low_latency 适合 decode(低延迟 + CUDA Graph 兼容)
  • pplx 额外要求 --attn-dp-size > 1

PD 分离

SGLang 的 PD 分离支持 Mooncake 和 NIXL 两种传输引擎。

BASH
# Prefill 实例
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --disaggregation-mode prefill \
  --port 30000 \
  --disaggregation-ib-device mlx5_roce0

# Decode 实例
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-8B-Instruct \
  --disaggregation-mode decode \
  --port 30001 \
  --base-gpu-id 1 \
  --disaggregation-ib-device mlx5_roce0

# Router
python -m sglang_router.launch_router \
  --pd-disaggregation \
  --prefill http://127.0.0.1:30000 \
  --decode http://127.0.0.1:30001 \
  --host 0.0.0.0 --port 8000

DeepSeek 多节点 PD 分离(官方示例,2 节点 × TP16):

BASH
# Prefill(每节点都执行,node-rank 0/1)
python -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V3-0324 \
  --disaggregation-ib-device ${device_name} \
  --disaggregation-mode prefill \
  --host ${local_ip} --port 30000 \
  --trust-remote-code \
  --dist-init-addr ${prefill_master_ip}:5000 \
  --nnodes 2 --node-rank 0 \
  --tp-size 16 --attn-dp-size 8 \
  --moe-a2a-backend deepep \
  --mem-fraction-static 0.8

# Decode(额外限制并发)
python -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V3-0324 \
  --disaggregation-mode decode \
  --host ${local_ip} --port 30001 \
  --dist-init-addr ${decode_master_ip}:5000 \
  --nnodes 2 --node-rank 0 \
  --tp-size 16 --attn-dp-size 8 \
  --moe-a2a-backend deepep \
  --mem-fraction-static 0.8 \
  --max-running-requests 128
关键提醒

H200 上做 PD 分离可能需要 --privileged --ulimit memlock=-1(或 --device /dev/infiniband:/dev/infiniband --cap-add IPC_LOCK),否则 Mooncake 找不到 IB HCA,会静默回退到 TCP,导致大 checkpoint 的 KV 传输出现乱码。


06逐模型实战配置

6.1入门基线:gpt-oss-120b

BASH
# 单卡(H100/H200/B200,或 A100 80G)
python -m sglang.launch_server --model-path openai/gpt-oss-120b

# 多卡
python -m sglang.launch_server --model-path openai/gpt-oss-120b --tp 4

# 工具调用
python -m sglang.launch_server \
  --model-path openai/gpt-oss-120b \
  --tool-call-parser gpt-oss \
  --reasoning-parser gpt-oss

验证:

PYTHON
from openai import OpenAI

client = OpenAI(base_url="http://localhost:30000/v1", api_key="EMPTY")
r = client.chat.completions.create(
    model="openai/gpt-oss-120b",
    messages=[{"role": "user", "content": "Explain eigenvalues briefly."}],
)
print(r.choices[0].message.content)

SGLang 默认端口是 30000,不是 vLLM 的 8000。

6.2主力中坚:Qwen3.5-397B-A17B

官方 Cookbook 覆盖最全的模型,NVIDIA / AMD / Intel / Ascend 都有验证配置。

架构要点:Gated Delta Networks(线性,O(n))与全注意力交替,每 4 层一次全注意力;512 路由专家 top-10 + 共享专家;原生多模态(DeepStack ViT + Conv3d)。

NVIDIA 配置

BASH
# H200 × 8,FP8,吞吐优先(文本)
python -m sglang.launch_server \
  --model-path Qwen/Qwen3.5-397B-A17B-FP8 \
  --tp-size 8 \
  --mem-fraction-static 0.85 \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder \
  --enable-symm-mem

# B200/B300,FP8,加 Blackwell 专用优化
python -m sglang.launch_server \
  --model-path Qwen/Qwen3.5-397B-A17B-FP8 \
  --tp-size 4 \
  --moe-runner-backend flashinfer_trtllm \
  --linear-attn-prefill-backend flashinfer \
  --enable-flashinfer-allreduce-fusion \
  --reasoning-parser qwen3

硬件需求对照(官方 Cookbook):

精度权重显存H100 80GH200 141GB200 183GB300 275GMI300X 192GMI325X 256GMI355X 288G
BF16~800 GBtp16(2 节点)tp8tp8tp4tp8tp4tp4
FP8~400 GBtp8tp4tp4tp2tp4tp2tp2

AMD 配置

BASH
export SGLANG_USE_AITER=1
export SGLANG_USE_AITER_UNIFIED_ATTN=1
export AITER_FLYDSL_FORCE=1
export SGLANG_MAMBA_SSM_DTYPE=bfloat16

python -m sglang.launch_server \
  --model-path Qwen/Qwen3.5-397B-A17B-FP8 \
  --tp-size 4 \
  --attention-backend aiter \
  --page-size 16 \
  --enable-aiter-allreduce-fusion \
  --reasoning-parser qwen3

MXFP4 单卡(MI350X/MI355X):

BASH
export VLLM_ROCM_USE_AITER=1   # 注意:SGLang 的 MXFP4 路径沿用此变量名
export ROCM_QUICK_REDUCE_QUANTIZATION=INT4

python -m sglang.launch_server \
  --model-path amd/Qwen3.5-397B-A17B-MXFP4 \
  --tp-size 1 \
  --attention-backend aiter \
  --page-size 16 \
  --max-running-requests 64 \
  --reasoning-parser qwen3
注意

--max-running-requests 64 不是随便设的。单卡留下的 Mamba cache block 约 296 个,默认的 1024 会直接导致服务拒绝启动。

长上下文

Qwen3.5 原生 262,144。要跑更长需要开 YaRN:

BASH
python -m sglang.launch_server \
  --model-path Qwen/Qwen3.5-397B-A17B-FP8 \
  --tp-size 8 \
  --context-length 1010000 \
  --json-model-override-args '{"text_config":{"rope_parameters":{"rope_type":"yarn","factor":4.0,"original_max_position_embeddings":262144,"rope_theta":10000000,"partial_rotary_factor":0.25,"mrope_interleaved":true,"mrope_section":[11,11,10]}}}'

静态 YaRN 会把缩放因子固定,不服务长 prompt 时不要开。只跑 ~524K 的话,把 factor 减半到 2.0。

已知坑

现象原因处理
assert num_cache_lines >= batchCUDA graph 捕获尺寸 > Mamba cache降低 --cuda-graph-max-bs-decode
服务拒绝启动max_running_requests 超过单卡 Mamba block 数设 --max-running-requests 64
多模态 TTFT 高特征传输走 CPU设 SGLANG_USE_CUDA_IPC_TRANSPORT=1(会额外吃显存)
加载极慢397B 权重读取加 --model-loader-extra-config='{"enable_multithread_load":"true","num_threads":64}'

6.3旗舰:DeepSeek-V4-Pro

1.6T 总参 / 49B 激活,CSA + HCA 混合注意力。必须多节点。

官方 Cookbook 给出的策略分三档:

策略目标典型配置
Low-Latency单用户最快回复TP-only,小 batch
Balanced多用户常规服务TP + DP,中等并发
High-Throughput批量任务TP + DP,大并发,--attn-dp-size

MI355X 多节点(官方 1P1D 部署):

BASH
# Prefill 节点
python -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V4-Pro \
  --tp-size 4 \
  --ep-size 4 \
  --moe-a2a-backend mori \
  --disaggregation-mode prefill \
  --disaggregation-ib-device mlx5_0 \
  --mem-fraction-static 0.85 \
  --reasoning-parser deepseek-v4 \
  --tool-call-parser deepseekv4

# Decode 节点
python -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V4-Pro \
  --tp-size 4 \
  --ep-size 4 \
  --moe-a2a-backend mori \
  --attn-dp-size 8 \
  --enable-dp-attention-local-control-broadcast \
  --tokenizer-worker-num 8 \
  --stream-interval 20 \
  --prefill-decode-interval 10 \
  --disaggregation-mode decode \
  --disaggregation-ib-device mlx5_0 \
  --mem-fraction-static 0.85 \
  --max-running-requests 128

# Router
python -m sglang_router.launch_router \
  --pd-disaggregation \
  --prefill http://<prefill-ip>:30000 \
  --decode http://<decode-ip>:30001 \
  --host 0.0.0.0 --port 8000

投机解码:

  • 原始 Flash / Pro checkpoint 自带 MTP 头:

``bash --speculative-algorithm EAGLE \ --speculative-num-steps 3 \ --speculative-eagle-topk 1 \ --speculative-num-draft-tokens 4 ``

  • Pro Official(0813)没有 MTP 头,只有 DSpark:

``bash --speculative-algorithm DSPARK ``

AMD 注意

FP4 模型用原始 deepseek-ai/DeepSeek-V4-{Flash,Pro},FP8 模型用 sgl-project/DeepSeek-V4-{Flash,Pro}-FP8。用错 checkpoint 精度会异常。

6.4超大 MoE:Kimi-K3.1-Pro

2.8T 参数,896 专家激活 16 个,KDA 线性注意力 + 稀疏 MLA(24 层 MLA 加 DSA top-2048 索引器)。

必须用 day-0 分支:

BASH
git clone -b kimi-k3.1-day-0 https://github.com/sgl-project/sglang.git
cd sglang && pip install -e "python"

或用镜像:lmsysorg/sglang:dev-kimi-k31-pro

三档策略:

BASH
# Low-Latency(TP8)
python -m sglang.launch_server \
  --model-path moonshotai/Kimi-K3.1-Pro \
  --tp-size 8 \
  --mem-fraction-static 0.85

# High-Concurrency(DCP8,KV 切到 8 卡)
python -m sglang.launch_server \
  --model-path moonshotai/Kimi-K3.1-Pro \
  --tp-size 8 \
  --dcp-size 8 \
  --mem-fraction-static 0.85

# High-Throughput(PD 分离,prefill PP4×PCP2,decode DCP8·EP2)
Mamba ratio

Kimi-K3 的 KDA 层有循环状态,SGLang 提供 mamba ratio 计算器来平衡「KV 池」与「状态池」的显存分配。这个值设错会表现为「KV 还有空间但请求跑不动」。

完整的高并发配置(B300 / GB300):

BASH
python -m sglang.launch_server \
  --model-path moonshotai/Kimi-K3.1-Pro \
  --tp-size 8 \
  --dcp-size 8 \
  --attention-backend tokenspeed_mla \
  --kv-cache-dtype fp8_e4m3 \
  --mem-fraction-static 0.82 \
  --max-running-requests 128 \
  --speculative-algorithm EAGLE \
  --speculative-num-steps 3 \
  --reasoning-parser kimi_k3 \
  --tool-call-parser kimi_k3
布局适用关键参数代价
TP8基线--tp-size 8KV 容量最小
TP8 + DCP8超长上下文 / 多会话--dcp-size 8decode 慢 7–25%,KV 容量约 7 倍
PD 分离长 prompt + 高并发prefill PP4×PCP2 / decode DCP8·EP2需要 Router + 传输引擎
MI355XAMD 路径--moe-a2a-backend mori需 ROCm 10 镜像

6.5Qwen3.8-Flash-Next

Qwen4 架构预览:125B 主模型 + 51B N-gram embedding,每 token 激活 6B,262K 上下文,原生多模态。

精度与显存:

精度checkpoint最小显存推荐硬件
NVFP4Inferact/Qwen3.8-Flash-Next-NVFP4130 GB单 GB200 / GB300
FP8Qwen/Qwen3.8-Flash-Next-FP8250 GBB300 满 tray
MXFP4amd/Qwen3.8-Flash-Next-Quark-MXFP4219 GBMI355X
BF16Qwen/Qwen3.8-Flash-Next423 GB8×H200

B300 满 tray(TEP4):

BASH
python -m sglang.launch_server \
  --model-path Qwen/Qwen3.8-Flash-Next-FP8 \
  --tp-size 4 \
  --ep-size 4 \
  --moe-runner-backend flashinfer_trtllm \
  --linear-attn-prefill-backend flashinfer \
  --mem-fraction-static 0.85 \
  --enable-hierarchical-cache \
  --hicache-ratio 1.5 \
  --speculative-algorithm NEXTN \
  --speculative-num-draft-tokens 3 \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder

8×H200(TEP8 + Triton MoE):

BASH
python -m sglang.launch_server \
  --model-path Qwen/Qwen3.8-Flash-Next-FP8 \
  --tp-size 8 \
  --ep-size 8 \
  --moe-runner-backend triton \
  --mem-fraction-static 0.85 \
  --max-running-requests 256
三个约束

① 纯 TP 与 FP8 checkpoint 不兼容(128 宽量化块切不开),必须开 EP;② --max-running-requests 256 不要降,低了会触发 Mamba cache 容量错误;③ 压测 MTP 用 --dataset-name speed_bench,随机数据集测不出真实接受率。

6.6GLM-5.3

743B / 39B,MLA + DSA。官方 Cookbook 同时覆盖 NVIDIA、AMD、Ascend。

NVIDIA:

BASH
python -m sglang.launch_server \
  --model-path zai-org/GLM-5.3 \
  --tp-size 8 \
  --ep-size 8 \
  --moe-a2a-backend deepep \
  --dsa-topk-backend sgl-kernel \
  --tool-call-parser glm47 \
  --reasoning-parser glm45 \
  --mem-fraction-static 0.85

AMD MI355X(MXFP4 + EAGLE MTP):

BASH
export SGLANG_OPT_USE_TOPK_V2=true
export SGLANG_TIMEOUT_KEEP_ALIVE=900

python -m sglang.launch_server \
  --model-path amd/GLM-5.3-Quark-MXFP4-AttnFP8 \
  --tp-size 4 \
  --ep-size 4 \
  --trust-remote-code \
  --kv-cache-dtype fp8_e4m3 \
  --dsa-prefill-backend triton \
  --dsa-decode-backend triton \
  --tool-call-parser glm47 \
  --reasoning-parser glm45 \
  --chunked-prefill-size 32768 \
  --mem-fraction-static 0.85 \
  --max-running-requests 20 \
  --cuda-graph-max-bs-decode 20
批量限制

官方建议 --max-running-requests 和 --cuda-graph-max-bs-decode 都设为目标并发的 2 倍。

HiCache(host DRAM 二级缓存):

BASH
--enable-hierarchical-cache \
--hicache-size 180        # GB per rank;4 rank 需要约 720 GB host 内存
--hicache-write-policy write_through \
--hicache-io-backend kernel \
--hicache-mem-layout page_first

HiCache 扩展的是 RadixCache,与 --disable-radix-cache 互斥,同时开会启动失败。

6.7MiniMax-M3

427B / 26B,MSA 块稀疏注意力,原生多模态(图 + 视频 + 计算机操作)。

BASH
# NVIDIA Blackwell,MXFP8
python -m sglang.launch_server \
  --model-path MiniMaxAI/MiniMax-M3-MXFP8 \
  --tp-size 8 \
  --reasoning-parser auto \
  --tool-call-parser auto \
  --mem-fraction-static 0.85

# Hopper(H200)用 BF16 全精度
python -m sglang.launch_server \
  --model-path MiniMaxAI/MiniMax-M3 \
  --tp-size 8 \
  --reasoning-parser auto
必须用 --reasoning-parser auto

模型用 <mm:think>...</mm:think> 包裹思维链,auto 会从 chat template 检测正确解析器,然后把标签剥离、内容放到 message.reasoning_content。

镜像注意

M3 从 0.5.22 起进入正式版本镜像。旧 dev 镜像(dev-minimax-m3 等)已废弃。正式镜像不包含 MiniMax 的 MSA 稀疏注意力内核(fmha_sm100),稀疏步走内置 Triton 路径。

6.8配置速查表

模型推荐 TP/EP关键参数镜像
gpt-oss-120btp1 / tp4--tool-call-parser gpt-osslmsysorg/sglang:latest
Qwen3.5-397Btp4–8--enable-symm-mem、--moe-runner-backend flashinfer_trtllmlmsysorg/sglang:latest
DeepSeek-V4-Protp4 + ep4(多节点)--moe-a2a-backend mori/deepepROCm 10 nightly / CUDA 13
Kimi-K3.1-Protp8--dcp-size 8(高并发)lmsysorg/sglang:dev-kimi-k31-pro
Qwen3.8-Flash-Nexttp4 + ep4 / tp8 + ep8--moe-runner-backend flashinfer_trtllm(B300)、triton(H200)lmsysorg/sglang:latest
GLM-5.3tp8 + ep8--dsa-topk-backend sgl-kernellmsysorg/sglang:latest
MiniMax-M3tp8--reasoning-parser autolmsysorg/sglang:v0.5.23-cu130

07调优方法论

先定义指标

指标定义主要决定因素
TTFT请求到首 token排队 + prefill 计算
ITL / TPOT相邻 token 间隔decode 单步耗时
Throughput每秒总 tokenGPU 利用率 × batch 效率
Goodput满足 SLO 的有效吞吐真正的业务指标

官方调优顺序

SGLang 官方文档给了一套很具体的调优流程,按顺序执行:

第一步:提高 batch size(吞吐优先)

看日志里的 #queue-req:

  • 频繁 #queue-req: 0 → 客户端提交太慢
  • 健康区间:100–2000
  • 太大 → 调度开销上升

第二步:提高 token usage

  • token usage > 0.9 说明 KV 池利用充分
  • token usage < 0.9 且 #queue-req > 0 → 降 --schedule-conservativeness 到 0.3
  • 频繁 KV cache pool is full. Retract requests. → 升到 1.3

第三步:调 --mem-fraction-static

  • 看 available_gpu_mem,目标 5–8 GB
  • 太高 → 加 --mem-fraction-static
  • 太低 → 减,否则会 OOM
  • 或者:以 0.01 步长往上加,直到 OOM 再退回

第四步:调 --cuda-graph-max-bs-decode

  • 默认只对小 batch 开 graph(< 160 或 256)
  • 大 TP 场景可以提到 512 或 768
  • 注意 CUDA Graph 吃显存,可能要同时降 --mem-fraction-static

第五步:其他手段

  • --enable-torch-compile:小模型 + 小 batch 有效
  • --quantization fp8:换更低的权重精度
  • --attn-dp-size 8:DeepSeek 系专用
  • --schedule-policy lpm:共享前缀多的场景(会引入调度开销)

按场景的配方

场景关键配置理由
低延迟对话--max-running-requests 8<br>--chunked-prefill-size 4096<br>EAGLE/MTP小 batch 降 ITL;小 chunk 减少 prefill 干扰
高吞吐批处理--max-running-requests 1024<br>--chunked-prefill-size 16384<br>--mem-fraction-static 0.9大 batch 摊薄权重读取
长上下文 / RAG--context-length 1000000<br>--kv-cache-dtype fp8_e4m3<br>--page-size 64KV 减半;大页减少元数据开销
多轮 Agent--enable-hierarchical-cache<br>--hicache-ratio 1.5<br>--schedule-policy lpmhost 层缓存长前缀;lpm 提升命中
在线混合负载--schedule-policy priority<br>--enable-priority-scheduling交互请求优先

压测

BASH
# 官方 benchmark 脚本
python -m sglang.bench_serving \
  --backend sglang \
  --host 127.0.0.1 --port 30000 \
  --model Qwen/Qwen3.5-397B-A17B-FP8 \
  --dataset-name random \
  --random-input 8000 \
  --random-output 1024 \
  --num-prompts 256 \
  --max-concurrency 64

启动时间优化

手段说明
--model-loader-extra-config='{"enable_multithread_load":"true","num_threads":64}'大模型多线程加载权重
--watchdog-timeout 1200397B 级模型加载慢,默认超时不够
--load-format fastsafetensors加速 safetensors 读取
预热 CUDA Graph首次请求会触发捕获,压测前先发几条

08生产化与排错

8.1容器化

BASH
docker run --gpus all \
  --shm-size 32g \
  --ipc=host \
  -p 30000:30000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  --env "HF_TOKEN=<your-token>" \
  lmsysorg/sglang:latest \
  python -m sglang.launch_server --model-path <model> --host 0.0.0.0 --port 30000
--shm-size 必给

SGLang 用共享内存做进程间通信。官方示例用 32g。

8.2监控

BASH
# 启用 Prometheus 指标
--enable-metrics

# 查看
curl http://localhost:30000/metrics

关键指标:

指标说明
sglang:num_running_reqs在跑请求数
sglang:num_queue_reqs排队请求数
sglang:token_usageKV 池使用率
sglang:gen_throughput生成吞吐
sglang:cache_hit_rate前缀缓存命中率
sglang:e2e_request_latency_seconds端到端延迟

8.3故障排查

现象最可能原因处理
启动 OOMmem-fraction-static 太高降到 0.8 或 0.7
prefill OOMchunk 太大降 --chunked-prefill-size 到 4096/2048
decode OOM并发太高降 --max-running-requests
服务拒绝启动(Qwen3.5 单卡)max_running_requests 超过 Mamba block 数设 --max-running-requests 64
assert num_cache_lines >= batchCUDA graph 尺寸 > Mamba cache降 --cuda-graph-max-bs-decode
KV 传输乱码(PD 分离)Mooncake 回退到 TCP加 --privileged --ulimit memlock=-1
推理内容为空reasoning parser 未配加 --reasoning-parser
工具调用变纯文本tool parser 不匹配显式指定 --tool-call-parser
吞吐上不去token usage 低降 --schedule-conservativeness
频繁 retractKV 池太小升 --schedule-conservativeness 或降并发
加载超时大模型权重慢--watchdog-timeout 1200 + 多线程加载

8.4安全

  • 默认无鉴权:需 --api-key 或网关
  • 多模态 URL 是 SSRF 入口:用 --allowed-media-domains 限制域名
  • --trust-remote-code 会执行模型仓库代码,只对可信来源开

09附录

A. 参数速查

参数一句话
--model-path模型路径
--tp-size张量并行度
--ep-size专家并行度(DeepEP 系要求 = tp)
--dp-size数据并行副本数
--attn-dp-sizeTP 组内注意力 DP 组数(DeepSeek 系关键)
--dcp-size解码上下文并行,放大 KV 容量
--mem-fraction-static权重 + KV 池占 GPU 比例
--max-running-requests最大并发
--chunked-prefill-size单次 prefill 最大 token
--max-prefill-tokens单批 prefill token 上限
--schedule-policyfcfs / lpm / priority 等
--schedule-conservativeness调度激进程度
--page-sizeKV 页大小
--kv-cache-dtypeKV 精度
--attention-backend注意力内核
--moe-a2a-backendEP 通信后端
--moe-runner-backendMoE 计算后端
--enable-hierarchical-cachehost DRAM 二级 KV 缓存
--speculative-algorithmEAGLE / EAGLE3 / NEXTN / STANDALONE / NGRAM
--disaggregation-modeprefill / decode

B. 环境变量

变量作用
SGLANG_USE_AITERAMD 启用 AITER 内核
SGLANG_USE_AITER_UNIFIED_ATTNAMD 统一注意力
SGLANG_MAMBA_SSM_DTYPEMamba 状态精度(bfloat16 省显存)
SGLANG_USE_CUDA_IPC_TRANSPORT多模态特征走 CUDA IPC,提升 TTFT
SGLANG_OPT_USE_TOPK_V2GLM-5.3 的 top-k 优化
ROCM_QUICK_REDUCE_QUANTIZATIONAMD 量化 all-reduce
SGLANG_DISAGGREGATION_BOOTSTRAP_TIMEOUTPD 分离引导超时
SGLANG_DISAGGREGATION_WAITING_TIMEOUTdecode 等待 prefill 完成的超时

C. 来源

来源用途
docs.sglang.io/docs/advanced_features/server_arguments参数完整释义与默认值
docs.sglang.io/docs/advanced_features/expert_parallelismEP 后端选型
docs.sglang.io/docs/advanced_features/pd_disaggregationPD 分离配置
docs.sglang.io/docs/advanced_features/hyperparameter_tuning官方调优流程
docs.sglang.io/cookbook/autoregressive/*逐模型验证命令
pypi.org/project/sglang版本核验

本文档基于 2026-11-06 可获取的公开资料整理。SGLang 与各模型迭代迅速,涉及默认值与支持状态的内容请以目标版本的 --help 与实际启动日志为准。