📌 项目总览
SGLang（Structured Generation Language）是一个面向大语言模型和多模态模型的高性能推理服务框架。它由 UC Berkeley 和 LMSYS 团队于 2024 年初发布，通过前后端协同设计：后端以 RadixAttention 为核心实现高效的 KV cache 复用，前端提供嵌入 Python 的领域特定语言（DSL）来控制生成过程。
💡 核心洞察：SGLang 的哲学是简单、可定制、高性能。与 TensorRT-LLM 的复杂 C++ 技术栈不同，SGLang 的核心调度器完全用 Python 实现，却能在性能上匹敌甚至超越闭源实现。这使得研究人员和工程师可以快速理解、修改和扩展框架。
🌱 起源与背景
SGLang 诞生于 UC Berkeley 的 Sky Computing Lab 和 LMSYS 的联合研究。LMSYS 运营着知名的 Chatbot Arena 平台，每天服务数百万用户，这让他们对高效推理有着第一手的深刻理解。
发展时间线
- 2024/01：SGLang 首次发布，提出 RadixAttention，相比 Guidance 和 vLLM 实现最高 5x 吞吐量提升
- 2024/07：v0.2 发布，定位通用推理引擎（SRT），在 Llama-8B 到 Llama-405B 上全面 benchmark
- 2024/09：v0.3 发布，DeepSeek MLA 7x 加速，torch.compile 1.5x 加速
- 2024/12：v0.4 发布，Zero-overhead scheduler、Cache-aware load balancer、xgrammar 结构化输出
- 2025/01：Day-1 支持 DeepSeek V3/R1，覆盖 NVIDIA 和 AMD GPU
- 2025/03：正式加入 PyTorch 生态系统
- 2025/06：获得 a16z Open Source AI Grant，成为 RL 训练后端标配
- 2025/10：原生支持 TPU（SGLang-Jax backend）
- 2026/02：在 NVIDIA GB300 NVL72 上解锁 25x 推理性能
✅ 关键里程碑：SGLang 从一个研究原型迅速成长为事实上的行业标准。它不仅是生产推理引擎，还是 AReaL、verl、Miles 等前沿 RL 后训练框架的默认 rollout 后端。
🏗️ 核心架构
SGLang 采用前后端分离、协同优化的架构设计：
前端：Structured Generation Language
一个嵌入 Python 的领域特定语言（DSL），用于编写复杂的 LLM 程序。它支持：
- 解释器模式：逐行执行，适合开发和调试
- 编译器模式：将程序编译成优化后的执行图，适合生产部署
- 控制流：分支、循环、条件生成等编程结构
- 外部交互：调用工具、API、数据库等
后端：SRT（SGLang Runtime）
通用推理引擎，核心模块包括：
- RadixAttention：基于 Radix Tree 的 KV cache 管理和前缀复用
- Batch Scheduler：高效的 CPU 调度器，支持 zero-overhead 重叠执行
- Attention Backend：集成 FlashInfer、FlashAttention、Triton 等高性能 kernel
- Model Runner：基于 PyTorch，支持 torch.compile 加速
- Load Balancer：cache-aware 路由，分布式场景下最大化前缀命中率
代码结构（python/sglang/）：
- lang/ : 前端 DSL
- srt/ : 后端推理引擎（核心）
- multimodal_gen/: 图像/视频生成加速
- eval/ : 评估工具
- launch_server.py: 服务启动入口
- api.py : OpenAI 兼容 API
🌳 RadixAttention 深度解析
RadixAttention 是 SGLang 的核心创新，也是它与 vLLM 最根本的区别所在。
问题背景
在复杂的 LLM 程序中（如 Agent、多轮对话、RAG、少样本学习），存在大量的KV cache 复用机会：
- 多个请求共享相同的 system prompt
- 多轮对话中历史上下文被反复使用
- Few-shot 示例在多批次请求中重复出现
- 结构化生成中的固定模板前缀
传统系统（如原始 vLLM）将每个请求视为独立的，即使 80% 的 token 完全相同，也会重新计算 KV cache。
Radix Tree 数据结构
SGLang 使用 Radix Tree（基数树/压缩前缀树） 来组织 KV cache。与标准 Trie 相比，Radix Tree 的节点数量更少，因为相同前缀被压缩到同一个节点中。
class TreeNode:
def __init__(self):
self.children = defaultdict(TreeNode)
self.parent = None
self.key = None # Token sequence
self.value = None # KV cache indices
self.lock_ref = 0 # Reference count
self.timestamp = 0 # For LRU eviction
三个请求的树形示例：
- Request 1: What is the capital of France?
- Request 2: What is the capital of Germany?
- Request 3: What is the weather today?
树结构：root → [What is the] → [capital of] → [France?] / [Germany?] 和 [What is the] → [weather today]
核心操作
- Prefix Matching（match_prefix）：新请求到达时，遍历树找到最长匹配的缓存前缀，返回对应的 KV cache 位置
- Prefix Insertion（insert）：请求完成后，将新 token 序列插入树中。若与现有节点部分匹配，触发节点分裂（split）
- Eviction：采用 LRU 策略，参考计数为 0 的节点可被淘汰
- 节点合并（merge）：删除节点后，若父节点仅剩一个子节点，触发合并以保持树的紧凑
📊 性能收益：
- 内存节省：3 个请求各 1000 token，共享 800 token 前缀时，内存从 3000 降至 1400 token（53% 节省）
- 计算节省：Prefill 只需计算未缓存的新 token，TTFT 大幅降低
- Agent 场景：多轮对话中 cache hit 率可达 75-95%
⚡ Zero-Overhead Batch Scheduler
在 v0.4 中，SGLang 将 CPU 调度器的效率推向了极致。核心洞察是：CPU 调度开销可以与 GPU 计算重叠。
问题：CPU 成为瓶颈
LLM 推理不仅需要 GPU 计算，还需要 CPU 做大量工作：batch 调度、内存分配、前缀匹配（radix cache 遍历）。一个未优化的引擎可能将多达 50% 的时间花在 CPU 开销上。
解决方案：CPU-GPU 重叠
调度器提前一个 batch 运行，在当前 GPU 计算的同时，准备下一个 batch 所需的所有元数据。通过创建 future token 和精心安排 CUDA 事件同步，实现真正的流水线。
🔧 实现细节：
- 在当前 GPU step 执行时，CPU 已经开始构建下一个 batch 的 input tensors
- Radix cache 的遍历、block 分配、prefix matching 全部隐藏在 GPU 计算期间完成
- Nsight profiling 显示：连续 5 个 decode batch 之间，GPU 没有任何空闲时间
📈 性能数据：
- 相比 v0.3：吞吐量提升 1.1x
- 相比其他 SOTA 基线：吞吐量提升 1.3x
- 优化在小模型和大 TP 场景下效果最显著
🎯 Cache-Aware Load Balancer
在分布式部署（Data Parallelism）场景下，SGLang v0.4 引入了一个革命性的负载均衡器，它根据 KV cache 命中率来路由请求，而不是简单的轮询。
核心思想
传统的轮询负载均衡器将请求均匀分配给各个 worker，但完全忽略了前缀缓存的局部性。Cache-aware router 维护一个近似 Radix Tree（通过 worker 上报的信息惰性更新），预测每个 worker 对 incoming 请求的 cache hit rate，将请求发送给命中率最高的 worker。
关键特性
- 多节点支持：单 router 连接分布式 worker，支持横向扩展
- 无通信设计：不需要 worker 间同步 cache 状态，使用传递的信息模拟近似树
- 纯 Rust 实现：sglang-router 独立包，带 Python bindings 和 CLI
- Drop-in 替代：直接替换现有的 --dp-size 参数即可启用
# 启用 Cache-aware Router（一键替换 DP）
python -m sglang_router.launch_server \
--model-path meta-llama/Meta-Llama-3.1-8B-Instruct \
--dp-size 8
📝 前端 DSL：Structured Generation Language
与 vLLM 等纯 serving 引擎不同，SGLang 提供了一个前端编程接口，让用户可以用 Python DSL 编写复杂的 LLM 程序，而不是仅仅发送单个 prompt。
为什么需要前端 DSL？
现代 LLM 应用越来越复杂：Agent 需要多轮调用、工具使用、条件分支；RAG 需要检索+生成+后处理；结构化输出需要 JSON/Regex 约束。传统的"发一个 prompt 等一个回答"模式无法高效表达这些程序。
核心 API 概念
- sgl.gen()：生成文本，支持 regex/JSON schema 约束
- sgl.select()：从选项中选择，用于分类/决策
- sgl.fork()：并行执行多个分支
- sgl.run()：执行程序，支持 interpreter/compiler 两种模式
后端协同优化
前端 DSL 和后端 Runtime 是协同设计的。编译器可以分析整个程序的执行图，提前规划 KV cache 的复用路径。例如，一个多分支的生成程序，编译器可以识别出所有分支共享的前缀，只计算一次。
💡 关键优势：前端 DSL 让跨调用优化成为可能。vLLM 只能优化单个请求的 serving，而 SGLang 可以优化整个 LLM 程序的执行效率。
🔩 其他关键特性
1. 压缩有限状态机（Compressed FSM）for 结构化输出
将 JSON schema 或 regex 模式编译成压缩 FSM，直接指导 token 采样过程，而不是先采样再拒绝。实现 3x faster JSON decoding（v0.2），v0.4 集成 xgrammar 后可达 10x faster。
2. Prefill-Decode Disaggregation（PD 分离）
将计算密集的 prefill 阶段和带宽密集的 decode 阶段分离到不同的 GPU 集群。SGLang 在 96 H100 GPU 上部署 DeepSeek 时，通过 PD 分离 + 大规模 EP 实现显著的吞吐量提升。
3. Data Parallelism Attention for DeepSeek MLA
DeepSeek 模型使用 MLA（Multi-head Latent Attention）且只有 1 个 KV head。若使用 TP=8，会导致 KV cache 重复存储。SGLang 对 attention 部分采用 DP，让各 worker 独立处理不同 batch，MoE 层前做 all-gather，实现 1.9x decode 吞吐量。
4. 广泛的硬件支持
NVIDIA（GB200/B300/H100/A100/Spark/5090）、AMD（MI355/MI300）、Intel Xeon CPU、Google TPU、Ascend NPU。特别是 AMD MI300X 上的 DeepSeek-R1 推理优化，达到了业界领先水平。
5. RL & Post-Training 原生支持
SGLang 不仅是推理引擎，还是训练框架的 rollout 后端。原生集成 AReaL、verl、Miles、slime 等 RL 框架，支持在线推理+反馈循环。
⚖️ SGLang vs vLLM：全面对比
1. Prefix Caching：RadixAttention vs PagedAttention APC
这是两者最根本的区别：
| 维度 | SGLang RadixAttention | vLLM APC |
|---|
| 数据结构 | Radix Tree（压缩前缀树） | Hash Table（哈希表） |
| 索引粒度 | Token 级别 | Block 级别（16-32 tokens） |
| 查找方式 | 树遍历，天然最长前缀匹配 | 逐 Block 哈希查找 |
| 动态前缀 | 任意位置分支，灵活性高 | 需 Block 对齐，灵活性稍低 |
| 内存开销 | 较高（树节点、指针） | 较低（仅哈希表条目） |
| CPU 开销 | 调度时 radix tree 遍历有开销 | Hash 查找更快 |
| 适用场景 | 动态前缀、Agent 多轮对话 | 固定 system prompt、前缀相对固定 |
来源：RadixAttention 技术详解及 vLLM APC 对比，CSDN 昇腾专区
💡 关键差异：SGLang 的 Radix Tree 天然支持最长前缀匹配和任意位置分支，而 vLLM 的 hash-based block table 需要 block 对齐（通常 16 或 32 tokens），这可能导致前缀匹配精度损失。但 vLLM 的 hash 查找在 CPU 开销上更低。
2. 前端能力
- SGLang：内置 Structured Generation DSL，支持复杂程序编写、跨调用优化
- vLLM：纯 serving 引擎，无前端 DSL，通过 OpenAI API 接收请求
3. 代码复杂度与可定制性
- SGLang：核心调度器 <4K 行 Python，高度模块化，易于修改
- vLLM：代码量超过 100K 行，V0/V1 引擎重构中，复杂度较高
4. 性能表现
- SGLang：在多数 benchmark 中优于 vLLM，小模型/大 TP 场景优势更明显
- vLLM：性能良好，但 CPU 调度开销较高，高 RPS 下延迟增长较快
5. 生产部署
- SGLang：40万+ GPU，xAI、Cursor、LinkedIn 等采用，RL 训练后端
- vLLM：部署广泛，社区生态成熟，文档和工具链丰富
6. 硬件支持
- SGLang：NVIDIA、AMD、Intel CPU、TPU、Ascend NPU
- vLLM：主要是 NVIDIA GPU，AMD 支持较弱
7. 关系与互补
SGLang 明确承认从 vLLM 学习设计并复用代码。两者并非完全竞争关系：
- vLLM 是通用 serving 引擎的标杆，生态最成熟
- SGLang 是下一代高效推理引擎，在特定场景（前缀共享、结构化生成、RL 训练）有明显优势
- 两者都在快速迭代，互相借鉴（vLLM 也在改进 prefix caching，SGLang 复用 vLLM 的模型并行设计）
🏭 生产部署与生态
大规模生产部署
SGLang 已被部署在超过 400,000 个 GPU 上，每日生成数万亿 token。主要采用方包括：
- xAI：Grok 模型的 serving 基础设施
- AMD：MI300X 上的 DeepSeek-R1 推理优化
- NVIDIA：GB200 NVL72 上的大规模 EP 部署
- LinkedIn、Cursor：生产推理服务
- Oracle Cloud、Google Cloud、Azure、AWS：云平台集成
RL & Post-Training 生态
SGLang 已成为 RL 训练框架的事实标准 rollout 后端：
- AReaL（Inclusion AI）：开源 RL 训练框架
- verl（Volcano Engine）：大规模 RL 训练
- Miles、slime、Tunix：各类 post-training 框架
原因：SGLang 支持在线推理+实时反馈，延迟低、吞吐量高，适合 RL 的 rollout-collect-update 循环。
开源社区
- 托管于 LMSYS 非营利组织
- 65+ 核心贡献者，社区活跃
- 每周公开开发会议，Slack 社区支持
- 长期贡献者可获得 Cursor、Claude Code、OpenAI Codex 等 coding agent 赞助
🏆 重要认可：
- 2025/03：加入 PyTorch 生态系统
- 2025/06：获得 a16z Open Source AI Grant
- 成为开源 LLM 推理引擎的事实行业标准
🎓 关键收获
- RadixAttention 是 SGLang 的灵魂：Radix Tree 替代 hash table 管理 KV cache，天然支持最长前缀匹配和任意位置分支，在 Agent/多轮对话场景有显著优势
- 前后端协同设计：前端 DSL 让跨调用优化成为可能，这是 SGLang 区别于纯 serving 引擎的根本差异
- Zero-overhead scheduler：CPU 调度与 GPU 计算重叠，将 CPU 开销隐藏到 GPU 计算中
- Cache-aware load balancer：分布式场景下根据前缀命中率路由请求，1.9x 吞吐量提升
- 简单可定制的哲学：核心调度器 <4K 行 Python，性能却匹敌 C++ 实现
- SGLang 不是 vLLM 的替代品：两者是互补关系。vLLM 生态成熟、通用性强；SGLang 在特定场景（前缀共享、结构化生成、RL 训练）有明显优势
- 从研究到生产的极速跨越：1 年多时间内从论文原型成长为 40万+ GPU 的行业标准
📚 参考资料
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12