【推理与部署篇03】SGLang深度解析

🚀 【推理与部署篇03】SGLang深度解析：RadixAttention与结构化生成

2026年最新版 | 覆盖 SGLang v0.5.12+ | 400,000+ GPU 生产验证

📑 目录

• 1. SGLang核心架构与设计理念
• 2. RadixAttention原理深度解析
• 3. XGrammar结构化生成
• 4. Overlap Scheduling调度优化
• 5. PD分离与HiCache层级缓存
• 6. 多模态与Embedding统一服务
• 7. 性能基准测试
• 8. 生产部署最佳实践
• 9. 关键参数调优指南
• 10. SGLang vs vLLM选型决策
• 面试加分点

1. SGLang核心架构与设计理念

1.1 什么是SGLang？

SGLang（Structured Generation Language）是由伯克利大学 LMSYS 实验室（LLM System）研发的新一代大模型推理引擎，定位不仅是推理加速器，更是一套完整的"大模型程序运行时"。

截至2026年5月，SGLang已在全球超过40万张GPU上部署，被 xAI、AMD、NVIDIA、Intel、LinkedIn、Cursor、Oracle Cloud 等顶级企业采用，GitHub 28K+ Stars，2026年已发布14个版本 [1]。

1.2 三层架构

┌──────────────────────────────────────────────┐
│ 前端DSL层（sglang.xxx） │
│ – @sgl.function 装饰器 + sgl.gen / sgl.select │
│ – 结构化生成流、约束解码、工具调用 │
├──────────────────────────────────────────────┤
│ 运行时层（Runtime） │
│ – RadixAttention 缓存管理 │
│ – Overlap Scheduling 调度引擎 │
│ – XGrammar 结构化输出后端 │
│ – HiCache 三级缓存卸载 │
├──────────────────────────────────────────────┤
│ 内核层（Kernels） │
│ – FlashInfer Attention │
│ – Triton FP8 GEMM / DeepGemm MLA │
│ – CUTLASS MoE Kernels │
│ – PD分离分布式协同 │
└──────────────────────────────────────────────┘

1.3 设计哲学

与 vLLM 的"纯推理引擎"定位不同，SGLang 将编译器概念引入推理系统：

2. RadixAttention原理深度解析

2.1 问题：传统前缀缓存的局限性

vLLM 的 Prefix Caching 基于哈希精确匹配：只有前缀完全一致才能复用缓存。在 RAG 或多轮对话中，不同请求的前缀往往部分相似（共享系统提示词但检索文档不同），哈希方案只能丢弃无法精确匹配的部分。

传统方案（vLLM Hash-based）：
请求1: [系统提示词] + [文档A] + [问题]
请求2: [系统提示词] + [文档B] + [问题]
↓
请求1缓存: [系统提示词||文档A||问题] → 只能完整匹配
请求2: 系统提示词部分需重新计算 ❌

RadixAttention（SGLang）：
请求1缓存: ┌系统提示词┐┌文档A┐┌问题┐
请求2: 重用 ↑ 计算新↑ 重用↑
↓
系统提示词部分自动复用 ✅

2.2 基数树（Radix Tree）结构

RadixAttention 的核心数据结构是基数树，每个节点存储一段连续的 Token 序列 [2]：

Root
├── "System: You are a helpful assistant."
│ ├── "What is the capital of France?" → "Paris"
│ ├── "What is the capital of Japan?" → "Tokyo"
│ └── "Translate to French: Hello" → "Bonjour"
├── "System: You are a coding assistant."
│ ├── "Write a Python function to…"
│ └── "Explain the time complexity of…"
└── "System: You are a data analyst."
└── …

关键特性：

• 最长公共前缀自动检测：新请求到达时，自动匹配已有树节点
• Token 级粒度：节点按连续 token 序列组织，比 Page 级更精细
• 部分复用：即使只有前缀部分匹配，也能复用共享节点
• LRU 驱逐：缓存满时淘汰最近最少使用节点

2.3 完整实现

import threading
from typing import Dict, List, Optional, Tuple
import heapq

class RadixTreeNode:
"""基数树节点"""
def __init__(self, token_ids: List[int]):
self.token_ids = token_ids # 节点存储的 token 序列
self.children: Dict[int, 'RadixTreeNode'] = {} # 子节点（首 token -> 节点）
self.kv_cache: Optional[Tuple] = None # 此节点对应的 KV Cache
self.last_access_time: int = 0 # 最后访问时间（LRU）
self.access_count: int = 0 # 访问次数
self.is_leaf: bool = True

class RadixAttention:
"""
RadixAttention 缓存管理器
支持最长公共前缀匹配、部分复用、LRU驱逐
"""
def __init__(self, max_cache_size: int = 100000):
self.root = RadixTreeNode([])
self.max_cache_size = max_cache_size
self.current_size = 0
self.lock = threading.Lock()
self.access_counter = 0

def match_prefix(self, token_ids: List[int]) –> Tuple[int, RadixTreeNode, List[RadixTreeNode]]:
"""
匹配最长公共前缀
返回：(匹配长度, 匹配到的节点, 路径上的节点列表)
"""
node = self.root
matched_len = 0
path = [node]
i = 0

while i < len(token_ids):
# 查找匹配的子节点
first_token = token_ids[i]
if first_token not in node.children:
break

child = node.children[first_token]
# 检查子节点内的序列是否能匹配
child_tokens = child.token_ids
j = 0
while j < len(child_tokens) and i < len(token_ids):
if child_tokens[j] != token_ids[i]:
break
j += 1
i += 1

if j > 0:
matched_len += j
path.append(child)
node = child

# 如果子节点的 token 没有完全匹配完，需要分裂
if j < len(child_tokens):
self._split_node(child, j)
# 分裂后重新获取节点引用
child = node.children.get(token_ids[matched_len – j] if matched_len – j < len(token_ids) else None)
if child:
path[–1] = child
continue
break

return matched_len, node, path

def _split_node(self, node: RadixTreeNode, split_pos: int):
"""分裂节点：从 split_pos 处切开"""
if split_pos <= 0 or split_pos >= len(node.token_ids):
return

# 新节点：保留后半部分
new_node = RadixTreeNode(node.token_ids[split_pos:])
new_node.kv_cache = None # 分裂后需要重新计算
new_node.children = node.children
new_node.is_leaf = node.is_leaf

# 原节点变为前半部分
node.token_ids = node.token_ids[:split_pos]
node.children = {new_node.token_ids[0]: new_node}
node.is_leaf = False

# 调整缓存大小
self.current_size -= len(new_node.token_ids)

def insert(self, token_ids: List[int], kv_cache: Tuple):
"""插入新的缓存序列"""
with self.lock:
# 先匹配已有前缀
matched_len, node, path = self.match_prefix(token_ids)

# 计算需要新插入的 token
remaining = token_ids[matched_len:]
if not remaining:
# 完全命中已有节点，更新 KV Cache
node.kv_cache = kv_cache
node.last_access_time = self.access_counter
node.access_count += 1
self.access_counter += 1
return

# 逐段创建新节点
current = node
start = 0
while start < len(remaining):
# 尝试找到最大的可合并段
end = start + 1
while end <= len(remaining):
if self._is_mergeable(remaining[start:end]):
end += 1
else:
break
end -= 1

segment = remaining[start:end]
new_node = RadixTreeNode(segment)
new_node.last_access_time = self.access_counter
self.access_counter += 1

current.children[segment[0]] = new_node
current.is_leaf = False
current = new_node
start = end

# 最后的节点保存 KV Cache
current.kv_cache = kv_cache
current.is_leaf = True
self.current_size += len(remaining)

# LRU 驱逐
while self.current_size > self.max_cache_size:
self._evict_lru()

def _is_mergeable(self, tokens: List[int]) –> bool:
"""判断一段 token 是否可以合并为单一节点（启发式）"""
return len(tokens) <= 64 # 最大节点长度

def _evict_lru(self):
"""LRU 驱逐：找到最久未访问的叶子节点并移除"""
# BFS 找到最久未访问的叶子
stack = [(self.root, 0)]
oldest_node = None
oldest_time = float('inf')

while stack:
node, depth = stack.pop()
if node.is_leaf and node != self.root:
if node.last_access_time < oldest_time:
oldest_time = node.last_access_time
oldest_node = node
for child in node.children.values():
stack.append((child, depth + 1))

if oldest_node and oldest_node.kv_cache:
self.current_size -= len(oldest_node.token_ids)
oldest_node.kv_cache = None
oldest_node.last_access_time = 0

def get_cache(self, token_ids: List[int]) –> Optional[Tuple]:
"""获取匹配的 KV Cache"""
matched_len, node, _ = self.match_prefix(token_ids)
if node and node.kv_cache:
node.last_access_time = self.access_counter
node.access_count += 1
self.access_counter += 1
return node.kv_cache, matched_len
return None, matched_len

def get_cache_hit_rate(self) –> float:
"""计算缓存命中率"""
total_nodes = 0
cached_nodes = 0
stack = [self.root]
while stack:
node = stack.pop()
if node != self.root:
total_nodes += 1
if node.kv_cache is not None:
cached_nodes += 1
for child in node.children.values():
stack.append(child)
return cached_nodes / max(total_nodes, 1)

2.4 实测效果

在共享前缀明显的场景（RAG、Agent 系统提示词、多轮对话），RadixAttention 相比 hash-based 方案有显著优势 [3]。

2.5 UnifiedRadixTree

SGLang v0.5.0+ 引入 UnifiedRadixTree，将传统 Radix Tree 与层级缓存结合：

GPU VRAM (最快, 最小)
└── Radix Tree 热节点
↓ LRU 驱逐
CPU RAM (中等, 大)
└── Radix Tree 温节点
↓ LRU 驱逐
SSD (最慢, 最大)
└── 冷节点持久化

允许缓存远超 GPU 显存限制的 KV Cache，对长上下文服务至关重要。

3. XGrammar结构化生成

3.1 为什么需要结构化生成？

Agent 场景的核心需求：模型输出必须严格遵守 JSON Schema、正则表达式或 EBNF 语法。传统方案（先生成后验证）：

传统方案：生成文本 → JSON解析 → 验证schema → 失败重试 ❌
→ 30%+ 重试率
XGrammar：约束解码 → 每一步只生成合法token ✅
→ 0 重试率

3.2 XGrammar 工作原理

XGrammar 是 SGLang 默认的结构化输出后端（2024.11 发布），实现零开销约束解码：

用户定义 Schema
↓
XGrammar 编译为上下文无关文法 (CFG)
↓
在采样过程中实时计算合法 token 集合
↓
LM Head 输出概率 → 屏蔽非法 token → 采样

核心特性：

• 编译时优化：Schema 预编译为 CFG，运行时零开销
• token 级约束：每一步只采样合法 token
• 支持格式：JSON Schema、正则表达式、EBNF、structural_tag
• 多工具注册：一个请求内同时注册多个函数

import sglang as sgl

# === 方式1：@sgl.function 装饰器 DSL ===
@sgl.function
def extract_city_info(s, document):
s += "从以下文档提取城市信息：\\n"
s += document + "\\n"
s += "输出 JSON：\\n"
s += "{\\n"
s += ' "name": ' + sgl.gen("name", max_tokens=8,
regex=r'"[^"\\\\]*(?:\\\\.[^"\\\\]*)*"') + ",\\n"
s += ' "country": ' + sgl.gen("country", max_tokens=8,
regex=r'"[^"\\\\]*(?:\\\\.[^"\\\\]*)*"') + ",\\n"
s += ' "latitude": ' + sgl.gen("latitude", max_tokens=8,
regex=r'-?\\d+\\.\\d+') + ",\\n"
s += ' "population": ' + sgl.gen("population", max_tokens=8,
regex=r'-?\\d+') + "\\n"
s += "}\\n"

# === 方式2：OpenAI API 兼容（XGrammar structural_tag）===
response = client.chat.completions.create(
model="qwen3-32b",
messages=[{"role": "user", "content": "北京的天气怎么样？"}],
response_format={
"type": "structural_tag",
"format": {
"type": "triggered_tags",
"triggers": ["<function="],
"tags": [
{
"begin": "<function=get_current_weather>",
"content": {
"type": "json_schema",
"json_schema": {
"type": "object",
"properties": {
"location": {"type": "string"},
"unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
},
"required": ["location", "unit"]
}
},
"end": "</function>"
},
{
"begin": "<function=get_forecast>",
"content": {
"type": "json_schema",
"json_schema": {
"type": "object",
"properties": {
"location": {"type": "string"},
"days": {"type": "integer", "minimum": 1, "maximum": 7}
},
"required": ["location", "days"]
}
},
"end": "</function>"
}
]
}
}
)

3.3 性能对比

4. Overlap Scheduling调度优化

4.1 传统调度瓶颈

LLM 推理的典型流程：

CPU: 接收请求 → 预处理(Tokenize) → 调度决策 → …
↓ 等待
GPU: ← 执行推理 →

CPU 预处理和调度决策是同步阻塞的，GPU 在等待期间空闲。

4.2 Overlap Scheduling

SGLang 实现 CPU 和 GPU 的流水线重叠：

传统调度:
GPU: ██████推理██████ ██████推理██████ ██████推理██████
CPU: 准备下一批 准备下一批
↑ GPU 空闲等待 ↑ ↑ GPU 空闲等待 ↑

Overlap Scheduling:
GPU: ██████推理██████ ██████推理██████ ██████推理██████
CPU: 准备下一批 准备下一批 准备下一批
时间 →
↑ 零等待 ↑ ↑ GPU 始终满载 ↑

4.3 Zero-Overhead Batch Scheduler

SGLang v0.4+ 的 Zero-Overhead Batch Scheduler 进一步消除调度开销：

class OverlapScheduler:
"""
CPU-GPU 重叠调度器
在 GPU 执行当前批次时，CPU 预计算下一批
"""
def __init__(self, max_batch_size: int = 256):
self.max_batch_size = max_batch_size
self.pending_queue = [] # 等待调度的请求
self.running_batch = None # 当前 GPU 执行批次
self.next_batch = None # 预计算的下一批

def submit(self, request):
"""提交请求"""
self.pending_queue.append(request)

def schedule_async(self):
"""
异步调度：在 GPU 空闲时预计算下一批
此方法在 CPU 线程中异步执行
"""
if self.next_batch is not None:
return # 已经预计算了下一批

if not self.pending_queue:
return

# 批处理策略：优先相同长度的请求
batch = []
remaining = []
ref_len = None

for req in self.pending_queue:
if ref_len is None:
ref_len = len(req.input_ids)
batch.append(req)
elif abs(len(req.input_ids) – ref_len) / ref_len < 0.3:
batch.append(req)
else:
remaining.append(req)

self.pending_queue = remaining

# 预计算：Tokenize、KV Cache 分配、调度决策
self.next_batch = self._prepare_batch(batch)

# 利用 RadixAttention 匹配缓存
for req in self.next_batch:
cache, matched = self.radix_cache.get_cache(req.input_ids)
req.cached_prefix_len = matched

def _prepare_batch(self, batch):
"""预计算批次元数据"""
# 最大序列长度
max_len = max(len(r.input_ids) for r in batch)

processed = []
for req in batch:
processed.append({
"input_ids": req.input_ids,
"cached_prefix_len": 0,
"prefill_len": len(req.input_ids),
"decode_len": 0,
"max_tokens": req.max_tokens,
"sampling_params": req.sampling_params,
"block_table": self._allocate_blocks(max_len + req.max_tokens),
})

return processed

def step(self):
"""
执行一步调度
返回需要 GPU 执行的批次
"""
if self.running_batch is None and self.next_batch is None:
self.schedule_async()
return None

# 交换批次
self.running_batch = self.next_batch
self.next_batch = None

# 异步预计算下一批
self.schedule_async()

return self.running_batch

实测效果：在低并发（c=1）场景下 Overlap Scheduling 可将 GPU 利用率从 65% 提升至 92%+ [4]。

5. PD分离与HiCache层级缓存

5.1 PD分离（Prefill-Decode Disaggregation）

预填充和解码阶段对资源需求完全不同：

SGLang 支持将 Prefill 和 Decode 分配到不同 GPU：

请求到达
↓
Prefill GPU（高算力：H100/B300）
├── 计算完整 KV Cache
├── 通过 NCCL 传输
↓
Decode GPU（高带宽：H200/B300）
├── 复用已计算 KV Cache
├── 逐 token 生成
↓
返回结果

配置示例：

# Prefill 节点（2 GPU）
python -m sglang.launch_server \\
–model-path Qwen/Qwen3-32B \\
–disaggregation-mode prefill \\
–tp 2 \\
–host 0.0.0.0 –port 30001

# Decode 节点（4 GPU）
python -m sglang.launch_server \\
–model-path Qwen/Qwen3-32B \\
–disaggregation-mode decode \\
–tp 4 \\
–host 0.0.0.0 –port 30002

# 路由节点
python -m sglang.launch_server \\
–model-path Qwen/Qwen3-32B \\
–disaggregation-mode router \\
–prefill-server http://prefill:30001 \\
–decode-server http://decode:30002 \\
–host 0.0.0.0 –port 8000

5.2 HiCache层级KV Cache卸载

HiCache 实现 GPU → CPU → SSD 三级缓存：

class HiCacheManager:
"""
HiCache 层级缓存管理器
支持 GPU VRAM → CPU RAM → SSD 三级卸载
"""
def __init__(self, gpu_cache_size: int, cpu_cache_size: int,
ssd_cache_path: str):
self.gpu_cache = {} # GPU VRAM 缓存
self.cpu_cache = {} # CPU RAM 缓存
self.ssd_cache_path = ssd_cache_path # SSD 持久化
self.gpu_limit = gpu_cache_size
self.cpu_limit = cpu_cache_size

# 访问频率跟踪
self.access_stats = defaultdict(lambda: {"count": 0, "last_access": 0})

def get(self, key: str) –> Optional[bytes]:
"""按优先级查找缓存"""
if key in self.gpu_cache:
self._update_stats(key)
return self.gpu_cache[key]

if key in self.cpu_cache:
# 提升至 GPU（如果有空间）
self._promote_to_gpu(key)
self._update_stats(key)
return self.cpu_cache[key]

# 检查 SSD
ssd_path = os.path.join(self.ssd_cache_path, key)
if os.path.exists(ssd_path):
data = self._read_ssd(ssd_path)
# 提升至 CPU
self._promote_to_cpu(key, data)
self._update_stats(key)
return data

return None # 缓存未命中

def set(self, key: str, data: bytes):
"""写入缓存（写入 GPU）"""
self._ensure_gpu_space(data)
self.gpu_cache[key] = data
self._update_stats(key)

def _ensure_gpu_space(self, data: bytes):
"""确保 GPU 有足够空间，不够则驱逐到 CPU/SSD"""
current_size = sum(len(v) for v in self.gpu_cache.values())
if current_size + len(data) <= self.gpu_limit:
return

# 按访问频率排序驱逐
evict_candidates = sorted(
self.gpu_cache.keys(),
key=lambda k: self.access_stats[k]["count"]
)

for key in evict_candidates:
if current_size + len(data) <= self.gpu_limit:
break

# 驱逐到 CPU
self._evict_to_cpu(key)
current_size -= len(self.gpu_cache.pop(key))

def _evict_to_cpu(self, key: str):
"""GPU → CPU 驱逐"""
if key not in self.gpu_cache:
return
self._ensure_cpu_space(self.gpu_cache[key])
self.cpu_cache[key] = self.gpu_cache[key]

def _promote_to_gpu(self, key: str):
"""CPU → GPU 提升"""
if key not in self.cpu_cache:
return
self._ensure_gpu_space(self.cpu_cache[key])
self.gpu_cache[key] = self.cpu_cache.pop(key)

def _update_stats(self, key: str):
self.access_stats[key]["count"] += 1
self.access_stats[key]["last_access"] = time.time()

6. 多模态与Embedding统一服务

6.1 统一服务架构

SGLang 的一大特色是可以用同一个服务进程同时处理：

• 纯文本 LLM 推理
• 多模态 VLM 推理（Qwen-VL、LLaVA、MiniCPM-V、NVILA）
• Embedding 向量化（Qwen3-Embedding、GME）
• 重排序（Reranker）

# 一个服务，全部支持
python -m sglang.launch_server \\
–model-path Qwen/Qwen3.6-VL-32B \\
–host 0.0.0.0 –port 8000

# 客户端统一调用
import sglang as sgl

# LLM 文本生成
response = sgl.chat("Hello, how are you?")

# VLM 多模态
response = sgl.chat(
"这张图片里有什么？",
images=["https://example.com/photo.jpg"]
)

# Embedding
embeddings = sgl.embed(["文本1", "文本2"])

# 同一个进程，无需部署多套服务

6.2 模型支持矩阵（v0.5.12）

7. 性能基准测试

7.1 标准 Benchmark（H100）

数据来源：AIMultiple 2026-04 基准测试 [5]。即使在相同 kernel（FlashInfer）下，SGLang 的调度层优化带来了 29% 吞吐优势。

7.2 RTX PRO 6000 Blackwell 实测

同精度（GPTQ-INT4）下 SGLang 领先 17% [6]。

7.3 TTFT 首Token延迟对比

7.4 高并发P95尾延迟

SGLang 在高并发下延迟分布更稳定，P95 尾延迟仅为中位数的 1.2-1.4 倍，而 vLLM 可达 9-12 倍 [3]。

8. 生产部署最佳实践

8.1 基础 Docker 部署

# 拉取 SGLang 官方镜像
docker pull lmsysorg/sglang:v0.5.12.post1

# 启动服务
docker run –gpus all \\
–shm-size 32g \\
-p 8000:8000 \\
-v ~/.cache/huggingface:/root/.cache/huggingface \\
lmsysorg/sglang:v0.5.12.post1 \\
python -m sglang.launch_server \\
–model-path Qwen/Qwen3-32B \\
–host 0.0.0.0 \\
–port 8000 \\
–mem-fraction-static 0.90 \\
–max-num-seqs 256 \\
–enable-mix-precision fp16

8.2 Kubernetes 生产部署

apiVersion: apps/v1
kind: Deployment
metadata:
name: sglang–server
spec:
replicas: 3
selector:
matchLabels:
app: sglang
template:
metadata:
labels:
app: sglang
spec:
containers:
– name: sglang
image: lmsysorg/sglang:v0.5.12.post1
command:
– python
– –m
– sglang.launch_server
args:
– ––model–path
– Qwen/Qwen3–32B
– ––host
– 0.0.0.0
– ––port
– "8000"
– ––mem–fraction–static
– "0.90"
– ––max–num–seqs
– "256"
– ––enable–metrics
ports:
– containerPort: 8000
resources:
limits:
nvidia.com/gpu: 2
requests:
nvidia.com/gpu: 2
volumeMounts:
– name: model–cache
mountPath: /root/.cache
– name: shared–memory
mountPath: /dev/shm
volumes:
– name: model–cache
persistentVolumeClaim:
claimName: model–cache–pvc
– name: shared–memory
emptyDir:
medium: Memory
—
apiVersion: v1
kind: Service
metadata:
name: sglang–service
spec:
selector:
app: sglang
ports:
– port: 8000
targetPort: 8000
type: ClusterIP
—
# HPA：基于 GPU 利用率和请求延迟自动扩缩
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: sglang–hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: sglang–server
minReplicas: 2
maxReplicas: 10
metrics:
– type: Pods
pods:
metric:
name: sglang_gpu_utilization
target:
type: AverageValue
averageValue: 80
– type: Pods
pods:
metric:
name: sglang_request_latency_p99
target:
type: AverageValue
averageValue: 2000 # 2秒

8.3 Prometheus + Grafana 监控

SGLang 原生暴露 Prometheus 指标：

# prometheus-scrape-config.yaml
scrape_configs:
– job_name: 'sglang'
scrape_interval: 10s
static_configs:
– targets:
– 'sglang-service:8000'
metrics_path: '/metrics'

关键监控指标：

Grafana 告警规则：

groups:
– name: sglang_alerts
rules:
– alert: HighLatency
expr: sglang_ttft_ms{quantile="0.99"} > 5000
for: 5m
labels:
severity: warning
annotations:
summary: "SGLang P99 latency > 5s"

– alert: LowCacheHitRate
expr: sglang_cache_hit_rate < 0.3
for: 10m
labels:
severity: warning
annotations:
summary: "RadixAttention cache hit rate below 30%"

– alert: GPUMemoryPressure
expr: sglang_gpu_mem_usage_gb > 75
for: 5m
labels:
severity: critical
annotations:
summary: "GPU memory > 75GB"

9. 关键参数调优指南

9.1 显存与批处理

9.2 缓存与调度

9.3 分布式

9.4 解码与采样

9.5 SM120（Blackwell）兼容配置

# Blackwell SM120 MoE 模型兼容启动
SGLANG_DISABLE_DEEP_GEMM=1 \\
python -m sglang.launch_server \\
–model-path MiniMax-M2.5-228B \\
–fp8-gemm-backend triton \\
–moe-runner-backend triton \\
–kv-cache-dtype fp8_e4m3 \\
–mem-fraction-static 0.85

10. SGLang vs vLLM选型决策

10.1 全维度对比（2026年5月）

10.2 场景推荐

你的场景
│
├── 多轮对话 / 客服机器人 → SGLang ✅
├── RAG知识库问答 → SGLang ✅（RadixAttention优势）
├── Agent工具调用 → SGLang ✅（XGrammar + structural_tag）
├── 结构化JSON输出 → SGLang ✅（3倍加速）
├── 多模态统一服务 → SGLang ✅（同一进程）
├──
├── 高并发短请求 → vLLM ✅
├── 长文本生成 → vLLM ✅（PagedAttention成熟）
├── 已有vLLM生态 → vLLM ✅
├── 快速搭建Demo → vLLM ✅（文档丰富）
└── 社区/第三方集成优先 → vLLM ✅

10.3 混合部署策略

生产环境中，推荐根据场景混合使用：

请求入口 → 路由层
├── RAG/Agent/多轮对话 → SGLang 集群
│ ├── RadixAttention + XGrammar
│ └── 统一服务 (LLM + VLM + Embedding)
│
└── 批量推理/长文本 → vLLM 集群
├── PagedAttention + Chunked Prefill
└── 成熟批处理调度

📌 面试加分点

1️⃣ RadixAttention vs PagedAttention 核心区别

2️⃣ 结构化生成的三种实现路径

3️⃣ SGLang 核心优化流水线

请求到达
↓
RadixAttention 前缀匹配 → 缓存命中则跳过重复计算
↓
Overlap Scheduling → CPU 预计算下一批（GPU 零等待）
↓
XGrammar 约束解码 → 每一步屏蔽非法 token
↓
FlashInfer Attention → 高效注意力计算
↓
FP8/Triton Kernel → 混合精度加速
↓
HiCache 层级缓存 → GPU→CPU→SSD 三级卸载

4️⃣ SGLang 性能调优口诀

“缓存看命中，显存定并发，量化选精度，分离治长文”

• 缓存命中率 < 30% → 检查 RadixAttention 配置或调整请求结构
• GPU 显存利用率 < 80% → 增大 –mem-fraction-static 和 –max-num-seqs
• 小型模型（<20B）→ 优先 BF16 而非量化
• 大型模型（>70B）→ PD 分离 + FP8 量化
• 长上下文场景 → 启用 HiCache 层级卸载

参考来源