SGLang：把推理、结构化输出和 rollout 绑进同一套底座

Source: https://github.com/sgl-project/sglang

1. 项目概览

SGLang 不是“又一个 LLM serving 框架”这么简单。它更像一套 推理底座：把模型接入、缓存、调度、结构化输出、分布式拆分、function calling 和多模态支持收进同一套运行时。

从硬信号看，它已经不是轻量 demo：

Stars：26,446
Forks：5,558
Open issues：3,054
License：Apache-2.0
Latest release：v0.5.10.post1
最近更新：2026-04-26
README 明确把它定义为 high-performance serving framework
README 声称已被大规模生产部署，且在 rollout / post-training 里被广泛使用

这个项目的阶段很清楚：基础设施 / 平台型项目，而不是单点工具。

一句话判断

SGLang 的价值不只在“快”，而在于它把快、稳、可控、可编排、可拆分这些推理系统需求放到了一起。

2. 架构拆解

SGLang 的启动和运行链路可以粗略拆成三层：

CLI / SDK
  -> launch_server
  -> server_args / model config
  -> runtime entrypoints (HTTP / gRPC / Ray / encoder-only / disaggregation)
  -> scheduler + workers + router
  -> cache / attention / grammar / function call
  -> response streaming / rollout / metrics

关键入口

python/sglang/launch_server.py
- 负责按参数分发到 HTTP / gRPC / Ray / disaggregation / encoder-only 等模式
python/sglang/srt/server_args.py
- 集中定义大量运行参数：cache、grammar backend、scheduler、chunked prefill、disaggregation、parallelism、multimodal、LoRA、hierarchical cache
python/sglang/srt/constrained/grammar_manager.py
- 管理 JSON schema / regex / EBNF 等 grammar 约束请求
python/sglang/srt/layers/radix_attention.py
- RadixAttention 的核心实现
python/sglang/srt/disaggregation/*
- prefill / decode 拆分相关模块
python/sglang/srt/function_call/*
- 各种模型的 function calling / tool-use 解析器

结构分层

1) 接入层

负责把外部请求变成可执行的 model request：

OpenAI 风格 API
frontend language / structured prompting
gRPC / HTTP / Ray 接入

2) 调度与运行时层

负责把请求尽可能高效地跑起来：

continuous batching
chunked prefill
zero-overhead scheduler
cache-aware routing / load balancing
prefill-decode disaggregation

3) 能力层

负责把“推理可控性”做深：

RadixAttention
grammar-constrained decoding
function calling / tool use
multimodal / diffusion / embedding / reward models
多硬件后端适配

一个最小架构图

用户 / 应用
   |
   v
launch_server / API layer
   |
   v
scheduler / router / workers
   |
   +--> RadixAttention / KV cache
   +--> chunked prefill / continuous batching
   +--> grammar backend / function-call parser
   +--> disaggregation / load balancer
   |
   v
streaming response / rollout backend / metrics

和常见 serving 框架的直观区别

维度	SGLang	vLLM	TGI / TensorRT-LLM
核心焦点	推理底座 + 结构化输出 + rollout	通用高吞吐 serving	工程化部署 / 性能优化
缓存思路	RadixAttention / 前缀复用	PagedAttention	各自的 kernel / engine 优化
结构化输出	作为第一类能力	有支持，但不是最核心叙事	视实现而定
分布式拆分	PD disaggregation / router / load balancer	有分布式能力，但叙事不同	更偏特定部署栈
复杂度	高	中	中到高

这张表不是说谁绝对更强，而是说明：SGLang 选择了更“系统化”的路线。

3. 核心机制

3.1 RadixAttention：把共享前缀变成一等公民

SGLang 的标志性机制之一是 RadixAttention。它的基本思想是：

不是每个请求都从零开始算 KV cache
而是把可共享前缀组织成 radix tree
新请求到来时先找可复用前缀
命中越多，越能减少重复计算

这对以下工作负载尤其有效：

few-shot prompt
多轮对话
模板化请求
代码分析 / 结构化问答

它的本质不是“缓存”，而是 把前缀复用做成运行时策略。

3.2 Zero-overhead scheduler：减少 scheduler 自己的开销

SGLang v0.4 的一个明确卖点是 zero-overhead batch scheduler。它代表一种很现实的工程判断：

只要推理系统足够快，调度器本身就会成为瓶颈。

所以它要做的不是“有没有 scheduler”，而是：

scheduler 是否能低开销轮询
是否能减少 CPU 侧同步
是否能更好地配合 cache / batch / worker

这也是为什么 SGLang 的很多优化都围绕 scheduler 和 cache 一起出现，而不是孤立地优化某一个 kernel。

3.3 Structured outputs：grammar backend 不是附件，而是主能力

grammar_manager.py 和 server_args.py 里都能看到很强的 structured output 设计：

支持 xgrammar、outlines、llguidance、none
支持 JSON schema、regex、EBNF
结果会缓存，并且有异步编译 / ready 队列
对 grammar preprocessing 超时 / 失败也有显式处理

这说明 SGLang 不是把结构化输出当“后处理”，而是把它当作 推理路径的一部分。

为什么重要？因为很多 agent / tool-use / data extraction 场景里，真正的成本不是生成文本，而是：

生成结果不稳定
schema 不合法
工具调用格式不一致
后续系统无法可靠消费

SGLang 的做法是：在生成时就把约束纳进运行时。

3.4 Prefill-decode disaggregation：把一条链路拆成两段

从 launch_server.py 和 srt/disaggregation/* 可以看出，SGLang 不是只做单体推理，而是支持把推理拆成阶段：

prefill 负责长上下文和前缀构建
decode 负责逐 token 生成
中间通过 transport / router / worker 协作

这对大规模推理尤其重要，因为 prefill 和 decode 的资源特征并不一样。把它们拆开，才能：

更细地调度
更好地做 load balance
更容易做 offload / reserve / routing 策略

3.5 function calling：按模型适配不同工具调用格式

python/sglang/srt/function_call/ 下有大量 detector：

qwen
llama
mistral
deepseek
hermes
gpt_oss
gemma
glm 等

这说明 SGLang 面对的不是单一协议，而是一个“多模型、多格式、多工具调用习惯”的现实世界。

它的工程策略不是强行统一，而是：

识别模型特定格式
解析成统一请求语义
再交给后续执行链路

4. 优势与不足

优势

维度	优势
系统完整性	把 serving、structured output、disaggregation、function calling 组合成一套体系
性能叙事	从缓存、scheduler、load balancing、batching 多处同时优化
产品广度	同时覆盖语言模型、多模态、embedding、reward、diffusion 等方向
工程适配	支持多硬件、多后端、多部署形态
生态位置	不只是推理服务，更像 post-training / rollout 的基础设施层

不足

维度	风险 / 代价
复杂度	选项太多，调参门槛高，学习曲线陡
运行负担	scheduler、cache、router、disaggregation 叠在一起，排障成本高
维护面	open issues 量大，说明系统面宽、边界多
选型风险	对轻量 API 场景可能过重
认知成本	你得先理解它的系统哲学，才能用好它

关键 trade-off

SGLang 选的是“能力优先”路线，而不是“极简 API 优先”路线。它获得了更强的可控性和性能上限，但也付出了更高的复杂度。

5. 适合谁

最适合

推理基础设施团队
需要 structured outputs / function calling 的 agent 团队
做 RL / post-training / rollout backend 的团队
需要大规模、多模型、多硬件部署的人
研究 LLM serving 极限优化的人

不太适合

只想快速上线一个简单聊天 API 的团队
不想碰 batching / cache / router / disaggregation 的团队
对结构化输出和工具调用没有刚需的场景
预算有限、运维能力有限的小团队

何时该选它

你的需求已经从“能跑”进入“要可控地跑快、跑稳、跑复杂”
你需要把推理系统当成平台，而不是脚本
你在做 agent、工具调用、后训练或复杂多模型 serving

何时不该选它

你只需要标准 OpenAI 风格 API
你没有足够的 SRE / infra 人力去消化复杂 runtime
你对结构化输出、cache hit、router 策略并不敏感

6. 我的判断

SGLang 的本质不是“一个 serving 框架”，而是 把 LLM 推理工程化到可调度、可约束、可拆分、可 rollout 的底座。

它最值得重视的地方有三个：

缓存不是附属功能，而是核心能力
structured output 不是语法糖，而是系统约束
rollout / post-training 让它从 serving 走到了训练生态

如果你只把它当作“快一点的 API server”，会低估它；如果你把它当作“下一代推理基础设施”，它就很有研究价值。

结论：SGLang 值得深入研究，尤其适合把它当成 LLM 推理系统设计样板来读。 它不是最简单的选项，但很可能是最能代表“AI 推理平台化”的那一类项目之一。