SGLang 是一个面向大语言模型(LLM)与多模态模型(VLM)的高性能推理服务框架,由加州大学伯克利分校 LMSYS 团队主导开源、sgl-project 社区维护,相关论文发表于 NeurIPS 2024。它把「模型服务」与「结构化生成」合并到同一套引擎里:通过 RadixAttention 机制跨请求复用 KV 缓存,通过 XGrammar 压缩有限状态机做 JSON Schema/正则约束解码,并提供一套可编程的前端语言(Python DSL)编排多步生成链路。在实践中,SGLang 既能像 vLLM 一样对外提供 OpenAI 兼容的 /v1 接口,也能用 DSL 写出带工具调用、结构化校验的 Agent 逻辑,RAG 与 Agent 后端团队常把它用作高吞吐推理底座。
本攻略按「速览 → 安装 → 上手 → 核心能力 → 生产部署」的顺序展开,覆盖从单卡验证到多卡生产的完整路径,并附同类框架对比、典型应用场景、常见误区与面试题。
对 AI 从业者而言,掌握 SGLang 意味着同时掌握高吞吐服务部署、约束解码与多卡推理这三项 LLM 工程核心技能,是推理服务工程师与 LLM 平台组岗位的重要加分项。
目录
速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 SGLang:服务吞吐、结构化输出、Agent 编排难以兼得 → 一体化框架
传统 LLM 服务框架(如 vLLM、TGI)把「一次生成」当作基本单元:多轮对话、批量 few-shot、Agent 工具调用这类请求之间存在大量共享前缀(系统提示词、检索到的上下文、对话历史),但每个请求都会重新计算这些前缀的注意力,KV 缓存互不共享,显存与算力被重复消耗,吞吐始终上不去。结构化输出则更麻烦:通用框架先生成自由文本再做 JSON 解析,格式出错只能重试,每轮重试都重新走一遍 prefill,成本成倍放大。对 RAG/Agent 业务,这两点直接决定系统能否扛住生产流量。
SGLang 把「生成过程」抽象成一段可编程的 Python 编排(前端语言),编译器把编排解析成执行计划;后端引擎用 RadixAttention 在基数树上维护所有请求的 KV 缓存,前缀相同的请求自动复用缓存,调度器按缓存命中优先排布请求。约束解码侧,SGLang 接入 XGrammar 并把 JSON Schema/正则编译为压缩有限状态机(FSM),在采样阶段直接屏蔽非法 token,保证输出符合 schema,不需要生成后重试。「高吞吐」与「结构化」因此可以在同一套引擎内同时解决。
与 vLLM 的「纯服务优化」路线不同,SGLang 是「语言 + 引擎」双层结构:你可以完全不用 DSL,直接把它当 OpenAI 兼容服务用;也可以写 DSL 获得跨请求缓存复用和多步编排能力。这一设计带来更高上限,也让新手需要多学一层前端概念。
安装与环境配置:3 步就绪
步骤一·安装。SGLang 要求 Linux + Python 3.10+,CUDA 11.8 或 12.x;本文验证用的 1.1B 小模型 8GB 显存即可运行。官方推荐 pip 安装完整依赖(含 FlashInfer、Triton、XGrammar 等加速内核)。若编译环境不满足,直接使用官方 Docker 镜像 lmsysorg/sglang(已内置全部依赖,最省事)。
步骤二·配置。下载 Hugging Face 模型需要认证。拉取 Llama、Qwen2.5 等 gated 模型前,先执行 huggingface-cli login 或设置环境变量 export HF_TOKEN=你的token;公开小模型(如 TinyLlama)可跳过此步。
步骤三·验证。启动一个 1.1B 小模型验证整条链路:
另开终端执行 curl http://localhost:30000/v1/models,返回模型列表即安装成功。首次启动会从 Hugging Face 下载模型权重,请保持网络通畅。
pip install --upgrade pippip install "sglang[all]"
python -m sglang.launch_server \ --model-path TinyLlama/TinyLlama-1.1B-Chat-v1.0 \ --port 30000
快速上手:10 分钟跑通第一个结构化生成服务
最小可用闭环:启动服务 → 调 OpenAI 兼容接口对话 → 用 response_format 拿 JSON → 用 DSL 写多步提取链。前三步不需要写业务代码,第四步展示 SGLang 与 vLLM 的差异点。
1. 启动服务(命令见上一节),等待日志出现「The server is fired up and ready to roll!」即就绪。
2. 普通对话:向 POST http://localhost:30000/v1/chat/completions 发请求,字段与 OpenAI 完全一致(model、messages、temperature)。
3. 结构化输出:在请求体加 "response_format": {"type": "json_schema", "json_schema": {...}},返回的 content 保证是合法 JSON 且字段符合 schema。
4. DSL 多步提取:写一个 Python 文件运行(见下方代码),体会「生成内容参与下一轮拼接」的编排方式。
运行结果形如 {"name":"张三","company":"字节跳动","title":"算法工程师"},且必然符合 schema。进阶用法:服务端加 --enable-tools 可启用工具调用;DSL 中连续多次 sgl.gen 即可串起「先提取、再判断、再生成」的 Agent 链。
# demo_extract.py — 需要服务已在 30000 端口运行import sglang as sgl sgl.set_default_backend(sgl.OpenAIEndpoint("http://localhost:30000")) schema = { "type": "object", "properties": { "name": {"type": "string"}, "company": {"type": "string"}, "title": {"type": "string"}, },} @sgl.functiondef extract_json(s, text): s += "从以下文本提取人物信息,只输出 JSON:\n" + text + "\n" s += sgl.gen("info", max_tokens=256, json_schema=schema) state = extract_json.run(text="张三就职于字节跳动,担任算法工程师。")print(state["info"])
核心能力详解:3 大支柱
支柱一·RadixAttention 缓存复用。KV cache 是 LLM 生成时保存的历史注意力键值对,决定理解长上下文所需的内存。RadixAttention 用基数树(一般前缀树,即前缀共享的树结构)统一管理所有请求的 KV 缓存,多轮对话、共享系统提示词的请求自动复用公共前缀,并配合缓存感知调度(优先调度可命中缓存的请求)减少显存碎片。多轮与 Agent 场景收益最明显;论文在公开 benchmark 上报告最高 6.4 倍于既有系统的吞吐提升。
支柱二·结构化输出与压缩 FSM。约束解码把 JSON Schema、正则、EBNF 编译成有限状态机(FSM,一种状态转移图),采样时只允许当前状态合法的 token。XGrammar 负责把 schema 快速编译,SGLang 的压缩 FSM 进一步压缩状态表,使约束解码性能不低于甚至高于无约束采样——非法 token 被提前排除,生成长度更短。对外通过 response_format 暴露 OpenAI 风格接口,内部一次性生成合法 JSON,免去重试。
支柱三·服务能力与多卡扩展。连续批处理之外,SGLang 支持张量并行(--tp-size)、数据并行(--dp-size,含 DP attention 降低多卡通信开销)、PD 分离(prefill 与 decode 独立部署),并支持 EAGLE 投机解码、LoRA 服务、多模态模型(Qwen2-VL、Llama-3.2-Vision 等)以及 --enable-tools 工具调用。离线批量任务可直接用 from sglang import Engine 创建引擎。
生产部署与监控:从上线到运维
部署方式一·Docker 单节点。官方镜像已内置 CUDA/FlashInfer 等依赖,注意共享内存与 IPC 参数:
部署方式二·Kubernetes 多卡。单节点 8 卡时可用 --tp-size 4 --dp-size 2 组合张量与数据并行。liveness/readiness 探针指向 /health,真实生成探活用 /health_generate(会实际跑一次微型生成);滚动更新时先摘流再删 Pod;Hugging Face 缓存目录挂 PVC,避免每次重启重新下载模型。
可观测性。服务默认暴露 Prometheus 格式指标(/metrics),可采集吞吐、TTFT(首 token 延迟)、缓存命中率等;官方仓库提供 Grafana 面板模板;/get_server_info 返回并行配置与版本号,适合发布后校验。
<p class="para-label">避坑清单:</p>
<ul class="dash-list"><li>容器共享内存不足:Docker/K8s 默认 /dev/shm 过小会导致采样线程报错,必须设置 --shm-size(K8s 用 emptyDir medium=Memory)并开启 --ipc=host。</li><li>gated 模型拉取失败:Llama、Qwen2.5 等模型需先到 Hugging Face 接受协议,再通过 huggingface-cli login 或 HF_TOKEN 认证,否则服务启动阶段反复报 401/404。</li><li>版本与参数不匹配:response_format 的 json_schema 与 --enable-tools 是 v0.4+ 才支持,旧版本只支持正则约束;用新文档配置旧版本会报 unrecognized argument。</li><li>缓存命中率决定收益:RadixAttention 只在请求存在共享前缀时见效,随机独立短请求场景请先观察指标中的缓存命中率再谈优化。</li></ul>
docker run --gpus all --shm-size 32g --ipc=host -p 30000:30000 \ -v ~/.cache/huggingface:/root/.cache/huggingface \ lmsysorg/sglang:latest \ --model-path Qwen/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 30000
| 维度 | SGLang | vLLM | TensorRT-LLM | LMDeploy |
|---|---|---|---|---|
| 定位 | 前端语言 + 引擎一体的推理服务框架 | 高吞吐通用推理服务引擎 | NVIDIA 官方深度优化推理引擎 | 轻量高性能推理部署工具链 |
| 编排范式 | 可编程 Python DSL + 自动调度 | Request 级 API,无前端语言 | 图编译(engine build) | 无前端语言,提供 API 服务 |
| 类型约束 | XGrammar + 压缩 FSM,JSON/正则/EBNF | Guided decoding 多后端(Outlines 等) | 编译期约束解码支持 | 结构化输出支持有限 |
| 学习曲线 | 中:DSL 需额外学习 | 低:OpenAI 兼容开箱即用 | 高:需理解 TRT 引擎构建 | 中低 |
| 生态集成 | HF 模型即插即用,OpenAI 兼容 | HF 模型丰富,社区最成熟 | 需转换模型格式,绑定 NVIDIA 栈 | HF 模型,OpenAI 兼容 |
| 生产部署 | Docker/K8s,TP/DP/PP,PD 分离,指标齐全 | 部署成熟,企业支持完善 | NIM 与企业级支持深度绑定 | 国内环境实践多,轻量快速 |
| License | Apache 2.0 | Apache 2.0 | NVIDIA 专有(商用需授权) | Apache 2.0 |
| 适合谁 | 结构化输出 + Agent 链路 + 高吞吐团队 | 通用高吞吐服务与成熟生态用户 | NVIDIA 全栈深度调优团队 | 受限环境轻量部署团队 |
选型建议:通用高吞吐、追求社区成熟度选 vLLM;GPU 型号单一且深度绑定 NVIDIA 生态选 TensorRT-LLM;业务以 Agent/RAG 为主、需要 JSON 结构化输出与工具调用链的选 SGLang;在受限环境下做轻量快速部署选 LMDeploy。生产环境建议先用 SGLang 与 vLLM 在同等流量下压测对比 TTFT 与吞吐再定。
版本迭代
SGLang 于 2024 年 1 月随论文开源,随后以月级节奏迭代。v0.1-v0.3 完成从原型到多卡可用的演进;v0.4 是关键节点——多卡数据并行、结构化输出与工具调用三项能力落地;v0.5 转向延迟优化与部署基础设施(PD 分离、缓存生成)。以下版本记录整理自官方 Release 与博客,截至训练数据(2025-07),可能已有更新版本。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| v0.3.x | 2024-10 | 大规模多卡推理与多模态扩展 | 可服务 Llama-3.1-405B 级模型,多卡并行走向成熟 |
| v0.4.x | 2025-01 | 数据并行(DP attention)、XGrammar 结构化输出、工具调用 | 官方博客口径:8×H200 上 405B 模型相对 v0.3 吞吐最高提升 6.4x,decode 阶段提速约 3x |
| v0.5.x | 2025-05 | 分离式预填充(PD 分离)、缓存生成(cache generation) | prefill 与 decode 可独立扩缩容,长上下文与低延迟场景收益明显 |
| v0.5.3 | 2025-07 | 稳定性修复与依赖同步 | 截至训练数据的最新 patch 版本,建议生产跟进 |
SGLang 的迭代主线是从「能跑」走向「好部署」。v0.4 用官方博客公开的 6.4x/3x 口径建立了多卡与结构化场景的竞争力;v0.5 未公布统一的跨版本基准,重点转向 PD 分离等部署基础设施。选型建议:需要结构化输出与工具调用直接上 v0.4.3+,追求长上下文低延迟用 v0.5.x;逐版本细节可在 GitHub Releases 复核。
AI 应用场景
高并发 RAG 服务后端
阶段:RAG 管道构建 / 推理服务
解决的问题:知识库问答中所有请求共享系统提示词与检索片段,传统框架重复计算前缀注意力,浪费显存与算力。SGLang 用 RadixAttention 跨请求复用 KV 缓存,共享前缀越多、命中率越高,吞吐与首 token 延迟(TTFT)同时受益。
具体案例:论文在 ShareGPT 多轮对话等公开 benchmark 上报告相对既有系统最高 6.4x 吞吐提升,缓存友好场景(多轮对话、固定系统提示词)收益最明显;生产中以缓存命中率为核心指标决定是否扩容。
Agent 工具调用与结构化决策
阶段:Agent 编排
解决的问题:Agent 每步需要输出 JSON 格式的工具参数,自由生成再加解析重试的方式失败率与延迟不可控。SGLang 的约束解码保证一次生成合法 JSON,--enable-tools 直接提供工具调用服务形态,多轮工具调用历史还能被 RadixAttention 复用。
具体案例:客服工单 Agent 每轮决策需按 schema 输出 intent/tool/args 字段;启用 json_schema 约束后输出必然合法(官方文档承诺 schema 保证),省去整轮重试开销;官方 v0.4 博客将 guaranteed structured outputs 列为核心卖点。
多模态文档智能服务
阶段:文档智能 / 多模态推理
解决的问题:图文混合请求需要统一的服务与 API。SGLang 原生支持 Qwen2-VL、Llama-3.2-Vision 等视觉语言模型,与文本走同一套调度内核和 OpenAI 兼容接口。
具体案例:发票与合同信息抽取服务中,图片与文本一起发往 /v1/chat/completions,输出同样可加 json_schema 约束;相同图片反复出现时,图像 token 前缀复用进一步降低开销。
常见误区
误区SGLang 名字里有 Language,以为它是一门独立的脚本语言,接入时所有业务逻辑都要按它的语法重写,迁移成本很高。
正解它本质是一个 Python 库,前端 DSL 只是装饰器加上下文语法,底层仍是普通 Python。你完全可以不用 DSL,直接把它当 vLLM 用——OpenAI 兼容 API 开箱即用;只有需要多步编排或利用缓存复用写复杂链路时才需要写 DSL。
为何常见:官方强调"Structured Generation Language",加上示例代码风格独特,容易让人误以为是一套全新的编程语言。
误区听说 SGLang 吞吐比 vLLM 高几倍,以为随便什么请求进来都能白拿这倍速。
正解RadixAttention 的收益完全取决于请求间前缀重复度。多轮对话、few-shot、Agent 历史这类共享前缀场景收益显著;随机独立、互不相关的短请求场景收益有限,官方论文与博客都强调缓存命中率是先决条件。
为何常见:宣传材料以缓存友好场景为主,读者容易忽略流量分布这一前提。
误区JSON schema 约束解码等于每生成一个 token 都要过一遍校验,肯定更慢,能不用就不用。
正解SGLang v0.4 起使用 XGrammar 加压缩 FSM,约束解码通常在吞吐上不输无约束采样,因为非法 token 被提前屏蔽、生成长度反而更短;官方博客明确把结构化输出列为不牺牲性能的能力。早期 guidance 类方案每步重编译状态机的经验并不适用于 SGLang。
为何常见:基于早期约束解码实现的历史经验,忽略了压缩 FSM 的技术进步。
误区网上很多旧教程让人 `pip install sglang-llm`,装完发现 `import sglang` 报错或 API 对不上。
正解早期包名 sglang-llm 已废弃,正式包名为 sglang;安装请用 pip install "sglang[all]",导入统一为 import sglang。遇到教程里的旧包名,直接换成新包名即可。
为何常见:PyPI 上旧包名仍可搜索到,加上搜索引擎优先展示历史教程,容易装错。
误区以为通过 OpenAI 兼容 API 调用是“降级模式”,必须写 DSL 才有 RadixAttention 和批处理优化。
正解服务端对两种入口共用同一套调度内核,/v1 API 请求同样享有 RadixAttention 与连续批处理,单轮请求性能与 DSL 等价。DSL 的价值在于多步编排的逻辑表达,不是性能通道。
为何常见:把「框架自带语言」误解为唯一的性能入口,忽略了前后端共享引擎的架构事实。
面试题
Q1. SGLang 最核心的创新机制是什么?
- A.全新的稀疏注意力模型架构
- B.RadixAttention 的 KV 缓存跨请求复用← 正确答案
- C.自研的 INT4 权重量化算法库
- D.分布式训练数据并行框架
答案:B。RadixAttention 是 SGLang 的立身之本,它用基数树管理 KV cache 并在请求间复用公共前缀,直接解决多轮对话与 Agent 场景的重复计算问题;稀疏注意力、INT4 量化和训练框架都不是 SGLang 的核心定位。
Q2. 官方推荐的 SGLang 安装命令是?
- A.pip install sglang-llm
- B.pip install sglang
- C.pip install "sglang[all]"← 正确答案
- D.conda install -c sglang sglang
答案:C。官方文档推荐 pip install "sglang[all]" 以安装 FlashInfer、Triton、XGrammar 等加速依赖;pip install sglang 只装核心包,容易缺内核依赖;sglang-llm 是已废弃的旧包名。
Q3. 启动 SGLang 推理服务的标准命令是?
- A.python -m sglang.launch_server← 正确答案
- B.python -m sglang.server
- C.sglang start
- D.python run_server.py
答案:A。python -m sglang.launch_server --model-path <模型> --port <端口> 是跨版本稳定的启动入口;sglang.server、sglang start 都不是官方命令,run_server.py 是框架内部文件,不应用于启动服务。
Q4. 在 SGLang 前端语言中给生成结果加 JSON Schema 约束,正确写法是?
- A.sgl.gen("info", json_schema=schema)← 正确答案
- B.sgl.gen("info", schema=schema)
- C.sgl.gen("info", format="json")
- D.model.generate(json_schema=schema)
答案:A。sgl.gen 支持 json_schema 关键字参数,配合约束解码保证输出合法;schema/sformat 均非该 API 的合法参数名;model.generate 是 HF 风格接口,不经过 SGLang 的约束解码层。
Q5. SGLang v0.4+ 结构化输出依赖的底层技术是?
- A.生成后正则匹配并重试
- B.XGrammar 与压缩有限状态机← 正确答案
- C.提示词工程加人工校验
- D.两次采样投票选合法结果
答案:B。XGrammar 负责把 JSON Schema/正则编译为 FSM,压缩 FSM 在采样阶段屏蔽非法 token,实现一次性合法输出;重试、提示词和投票都无法提供「必然符合 schema」的保证。
Q6. 以下哪些场景能获得 RadixAttention 的明显收益?
- A.大量多轮对话共享同一系统提示词← 正确答案
- B.随机独立且互不相关的单轮短请求
- C.Agent 多轮工具调用共享对话历史← 正确答案
- D.每次请求使用完全不同的随机 few-shot 示例
答案:AC。RadixAttention 复用的是请求间共同的前缀 token,多轮对话与 Agent 历史天然满足;随机独立请求和完全不同的 few-shot 之间不存在公共前缀,缓存命中率低,收益有限。
Q7. SGLang 官方支持哪些多卡并行方式?
- A.张量并行(--tp-size)← 正确答案
- B.数据并行(--dp-size)← 正确答案
- C.从零预训练
- D.模型知识蒸馏
答案:AB。张量并行把单层切到多卡,数据并行(含 DP attention)在数据维度并行并降低通信开销,两者都是 SGLang 的正式启动参数;预训练与蒸馏是训练侧能力,不属于服务框架的并行范畴。
Q8. SGLang 的 PD 分离(Disaggregated Prefill)主要解决什么问题?
- A.模型训练阶段显存不足
- B.prefill 与 decode 资源需求差异导致的相互干扰← 正确答案
- C.数据集标注质量参差不齐
- D.模型参数量过大无法加载进显存
答案:B。prefill(预填充)是计算密集型、decode(解码)是访存密集型,两者混跑会互相拖累。PD 分离让两类阶段各自部署、独立扩缩容,是 v0.5 面向长上下文与低延迟场景的核心基础设施。
Q9. 生产部署 SGLang 时,以下做法正确的是?
- A.容器调大共享内存并开启 --ipc=host← 正确答案
- B.用 /health_generate 做真实生成探活← 正确答案
- C.单张 8GB 显存卡直接部署 70B 模型
- D.gated 模型需配置 HF_TOKEN 才能启动← 正确答案
答案:ABD。采样线程依赖大共享内存,必须扩 /dev/shm;/health_generate 会真实生成一次,比 /health 更能反映服务可用性;gated 模型必须认证;70B 模型即便量化后单卡 8GB 也不现实,需要多卡并行。
Q10. SGLang 与 vLLM 最本质的区别是什么?
- A.SGLang 只能运行自家私有模型格式
- B.SGLang 提供可编程前端语言并针对结构化与多步编排优化← 正确答案
- C.vLLM 不支持 OpenAI 兼容接口
- D.SGLang 不支持多卡并行推理
答案:B。两者都支持 HF 模型、OpenAI 兼容 API 与多卡并行;SGLang 的差异化在于前端 DSL 加 RadixAttention,对结构化输出、工具调用链等场景做了端到端优化,而 vLLM 更侧重通用请求的高吞吐。