SGLang：从前端 DSL 到 SRT 服务运行时

SGLang 是一个面向大语言模型与多模态模型的开源服务框架，由 LMSYS 组织下的 sgl-project/sglang 仓库以 Apache-2.0 许可证发布。截至 2026-08-09，该仓库约有 31.6k 星标，最新发布版本为 v0.5.17（2026-08-08）。在所有这些数字之前，有一句话更能说明问题：SGLang 实际上是两个系统——一个内嵌于 Python、用于编写”LLM 程序”的前端语言，以及一个最初被称为 SRT（SGLang Runtime）的服务运行时。理解两者之间的边界，就能同时看懂这个项目的历史和它在推理引擎中的当前位置。

本文是一次概念层面的巡览：前端与运行时、RadixAttention 与前缀复用、缓存感知调度、结构化生成、并行能力，以及今天与 vLLM 的比较边界在哪里。文中的性能数字均引自一手来源（NeurIPS 2024 论文、官方发布博客与官方文档），并标注了日期、硬件与基准版本；我们没有在本地复现任何一项。

两张面孔：前端语言与运行时#

论文 SGLang: Efficient Execution of Structured Language Model Programs（arXiv:2312.07104，2023-12-12 首次发布，2024-06-06 修订，作为海报论文在 NeurIPS 2024 上报告）开篇即给出了一个至今仍然成立的设计拆分：

1. 前端——一种内嵌于 Python 的领域特定语言（DSL），用于表达带生成调用、分支与并行的提示词程序；
2. 运行时（SRT）——一个调度器、一个基数树 KV 缓存管理器与一个模型执行器，负责执行这些程序（或普通的服务请求）。

论文明确指出两部分可以独立工作：前端可以对接远程 API 模型，运行时也可以完全不涉及 DSL 地服务普通请求。这种独立性是解读 SGLang 演进的关键——运行时成长为通用的服务引擎，而前端成为该项目（可选的）另一张面孔。

前端：内嵌于 Python 的 DSL#

前端语言就是普通的 Python，加上 @function 装饰器。在函数内部，通过追加消息块（s += user(...)、s += assistant(...)、s += system(...)）和生成调用来构建一个 State 对象。依据论文与当前官方文档中的前端教程，核心原语包括：

• gen("name", ...)——生成文本并绑定到变量；支持 max_tokens、stop、temperature，以及 choices=[...] 或 regex=... 等约束。
• select(...)——从选项中选取（论文中”受限选择”的术语）。
• s += ... / extend——向对话状态追加内容。
• fork / join——启动程序的并行分支。
• image(...)——为多模态模型附加图片。

由于 gen 是非阻塞的，一个程序内可以并发执行多个生成调用。文档记载了两种执行模式：解释器模式（异步流执行器，直接运行程序内的并行）与编译器模式（把程序追踪为一张图）。此外，”前端提示”（frontend hint）会先把 fork 分支的公共前缀发给运行时，让基数缓存将其吸收（下文详述）。同一个程序既可以跑在本地 SRT 服务器上，也可以通过运行时端点抽象对接 API 后端（支持 OpenAI、Anthropic 等）——这一设计早于并平行于今天的各类 agent 框架。

官方前端教程中的最小示例：

from sglang import function, user, assistant, gen

@function
def basic_qa(s, question):
    s += user(question)
    s += assistant(gen("answer", max_tokens=512))

state = basic_qa("List 3 countries and their capitals.")
print(state["answer"])

运行时：SRT#

运行时一侧——调度器加基数树 KV 缓存加模型执行器——才是今天大多数人所说的”SGLang”。当前项目对外提供三种使用方式：

• OpenAI 兼容 API（/v1/chat/completions、/v1/completions，另有 Anthropic 与 Ollama 兼容端点），标准 OpenAI 客户端无需改动即可使用；
• 原生 /generate 端点，直接传 sampling_params；
• **离线 sgl.Engine**，进程内批推理，无需 HTTP 服务器。

官方快速入门这样启动服务器：

python3 -m sglang.launch_server --model-path qwen/qwen2.5-0.5b-instruct --host 0.0.0.0 --port 30000

并等待 The server is fired up and ready to roll! 这一横幅输出。README 的功能列表概括了运行时当前的范围：RadixAttention 前缀缓存、零开销 CPU 调度器、预填充–解码分离（PD disaggregation）、投机解码、连续批处理、分页注意力、张量/流水线/专家/数据并行、结构化输出、分块预填充、量化与多 LoRA 批处理。

RadixAttention：把前缀复用当作一等公民#

大多数服务负载会反复发送很长的共享前缀：多轮对话历史、few-shot 示例、系统提示、检索增强上下文。如果不缓存，每个请求都要重新计算这些词元的键值激活。论文的招牌优化 RadixAttention 把 KV 缓存组织成基数树（radix tree），使共享前缀只计算一次、被多次引用。

用基数树实现前缀复用#

KV 缓存被组织成一棵树，每个节点保存一段连续词元的 KV 张量（按 1 词元或多词元页分页）；从根到叶的路径就是完整的请求前缀。共享前缀的请求共享相应节点。论文（第 3 节）的关键机制：

• 淘汰采用”叶优先”的 LRU：最近最少使用的叶子树先被释放，不会动到活动请求依赖的节点。
• 引用计数保护在途请求：被当前批次引用的节点不会被淘汰。
• 缓存与运行中的请求共享同一个内存池，空闲的缓存内存会在负载下自动收缩、容量允许时再增长。
• 缓存感知调度优先选择共享前缀最长的请求，这近似于对树做深度优先遍历。论文定理 3.1 表明：当缓存容量最多为一个最大请求长度时，这种 DFS 顺序能达到离线最优缓存命中率。
• 无命中时开销很小：论文在 ShareGPT 工作负载、空缓存条件下测得的吞吐损失低于 0.3%。

该机制同样覆盖多模态：图片词元通过对输入图片取哈希来复用（批次内或跨请求相同的图片跳过重复编码）；数据并行部署则通过路由器层面的元树（meta-tree）把请求路由到已经持有其前缀的工作节点。

首篇发布博客（2024-01-17）报告 RadixAttention 在含共享前缀的工作负载上带来最高 5 倍吞吐提升；论文自身的头条数字是相对于同时代一流推理系统的最高 6.4 倍吞吐（覆盖 agent 控制、逻辑推理、few-shot 基准、JSON 解码、RAG 流水线与多轮对话等任务）。两者都是 2024 年基准上的官方声称，而非独立测量。

从 2024 年论文到今天的缓存栈#

论文中的基数树只存在于 GPU 内存、且仅按请求管理。2026 年的状态由两项有文档记载的演进定义：

• 会话感知基数缓存（由 UnifiedRadixCache 实现）。应用在每个请求上携带 session_id；请求结束后其可复用的缓存叶在会话名下注册，/close_session 负责释放。淘汰时优先选择未被引用的节点，其次是会话引用节点，再次按 LRU；对混合模型还有组件级联规则：淘汰一个全注意力（Full attention）节点会连带其滑动窗口注意力（SWA）与 Mamba 数据；淘汰 SWA 只连带 Mamba 数据。会话引用是软保护而非内存钉扎。启用方式：SGLANG_ENABLE_UNIFIED_RADIX_TREE=1 加 --enable-session-radix-cache。
• HiCache（2025-09-10 发布）仿照 CPU 三级缓存把缓存扩展到 GPU 之外：GPU 内存为 L1，主机内存为 L2，分布式存储为 L3（集成 Mooncake、3FS、NIXL、AIBrix KVCache 等）。HiRadixTree 记录每段 KV 落在哪个层级，通过”本地匹配 → 预取 → 回写”的工作流跨层级保持复用。

树之外：缓存感知调度#

v0.4 发布（2024-12-04）中有两项调度改进，值得与 RadixAttention 本身分开理解：

• 零开销批调度器。把 CPU 侧的工作——组批、内存分配、前缀匹配——与 GPU 计算重叠，具体做法是让调度器提前一个批次运行。v0.4 公告报告相对上一版本 1.1 倍吞吐、相对其他一流基线 1.3 倍（小模型与大张量并行规模收益最大），并用 Nsight 剖析验证。该特性默认开启；当前文档以 --disable-overlap-schedule 作为 A/B 对照开关。
• 缓存感知负载均衡器（sglang-router）。在数据并行部署中，路由器为每个工作节点维护一棵近似基数树，把请求路由到前缀匹配最好的节点，且无需跨节点同步。v0.4 公告报告最高 1.9 倍吞吐与 3.8 倍缓存命中率提升（8× A100-80GB、generated-shared-prefix 工作负载、v0.4 对比 v0.3）。它作为独立的 Rust 包发布（pip install sglang-router），可替换 --dp-size 直接使用。

与两者相关的是分块预填充（--chunked-prefill-size）：把长提示切成小块，使一个批次内预填充与解码工作可以混跑，而不是被单个超长提示卡住——这对长上下文和 PD 分离部署尤为重要。

结构化生成#

“结构化输出”指约束解码过程，使输出保证匹配某个文法——JSON schema、正则表达式或 EBNF 文法。这是论文时代的另一项优化，此后后端几经更替。

压缩有限状态机（论文时代）#

论文的做法（第 4 节）把正则/JSON 约束编译成有限状态机，然后通过合并单转移边进行压缩，使解码器可以在一次前向传播中连跳多个词元（”Jump Forward”），再用原始分词器重新分词。发布博客（2024-02-05）报告相对当时基线快 3 倍的 JSON 解码。

XGrammar 与今天的后端#

自 v0.4 起，默认文法后端是 XGrammar（来自 MLC/Apache TVM 社区）；服务器参数 --grammar-backend 可选 xgrammar、outlines、llguidance 或 none。约束通过 OpenAI 兼容的 response_format（例如 {"type": "json_schema", "json_schema": {...}}）或 extra_body/采样参数（regex=...、ebnf=...）传入，还包括面向工具调用式输出的 structural_tag 格式。XGrammar 自己的论文（arXiv:2411.15100，2024 年 11 月，MLSys 2025）报告文法执行相对既有受限解码库最高 100 倍加速、端到端近乎零开销；v0.4 公告则报告当时 SGLang + XGrammar 的 JSON 解码比其他开源方案快最高 10 倍。同样：这是 2024 年基准上的官方数字。

并行：TP、PP、DP、EP 与 PD 分离#

概念上，运行时组合了四个经典维度，外加分离式部署：

• 张量并行（TP）——--tp-size（别名 --tensor-parallel-size）：把每层权重切分到多张 GPU 上，逐层做 all-reduce。单机装下大模型时的默认选择。
• 流水线并行（PP）——--pp-size：把层切分到多张 GPU，配合微批次流水（文档记载了异步微批次，如 --pp-async-batch-depth），用于单机放不下的模型。
• 数据并行（DP）——--dp-size：复制模型、按请求划分工作节点。这里正是缓存感知路由器大显身手之处，因为朴素的轮询会破坏前缀局部性。
• 专家并行（EP）——--ep-size：对 MoE 模型把专家分布到多张 GPU，用 all-to-all 通信把词元路由到正确的专家。all-to-all 后端可通过 --moe-a2a-backend 选择（当前文档列出 deepep、mooncake、nixl、mori、pplx 等），专家负载均衡可用 --enable-eplb 开启。
• 注意力专用 DP（--enable-dp-attention）——一种 MoE 风格混合：注意力走数据并行、FFN 走张量并行，目标是 MLA 这类只有一个 KV 头的模型（DeepSeek 系），因为朴素 TP 会复制 KV 缓存。v0.4 公告报告在 8× H100-80GB 上（DeepSeek-Coder-V2）相对 v0.3 1.9 倍解码吞吐。
• 预填充–解码（PD）分离——--disaggregation-mode prefill|decode 把两个阶段拆分到独立服务器，各自独立扩缩与调度；KV 缓存通过传输后端（--disaggregation-transfer-backend，默认 mooncake，另有 nixl、ascend、mori 等）在两台机器间移动，解码侧还可选基数缓存（--disaggregation-decode-enable-radix-cache）。多节点部署方式见部署文档。

官方里程碑显示这一维度持续扩张：96× H100 上的 PD + 大规模 EP（2025-05-05；GB200 第一部分博客 2025-06-16 报告 2.7 倍解码提升，第二部分 2025-09-25 报告 3.8 倍预填充 / 4.8 倍解码）、JAX/TPU 后端（2025-10-29）、以及声称 NVIDIA GB300 NVL72 上 25 倍的写稿（2026-02-20）。这些数字都是各自硬件与版本下的官方博客声称——适合作为趋势证据，不宜当作可移植的基准。

今天 SGLang 与 vLLM 的边界在哪里#

vLLM（vllm-project/vllm）是 SGLang 最近的邻居：同为 Python、Apache-2.0 的服务引擎，提供 OpenAI 兼容 API、分页 KV 缓存管理、连续批处理、TP/PP/DP/EP/上下文并行与可插拔文法后端（同样集成 XGrammar、Outlines 与 guidance）。截至 2026-08-09，vLLM 约有 88.6k GitHub 星标，SGLang 为 31.6k。vLLM 源自 PagedAttention 论文（arXiv:2309.06180，SOSP 2023），该论文报告在 2023 年硬件上相对 FasterTransformer 与 Orca 的 2–4 倍吞吐。

边界不在两张功能清单里——两者已经趋同——而在于项目的外层形态：

• vLLM 只有引擎。它通过 OpenAI 兼容、Anthropic 兼容与 gRPC API 以及离线引擎服务请求。没有前端编程语言：没有 @function 程序、没有请求定义层的 fork/join 并行、没有解释器/编译器双模式。
• SGLang 是引擎加前端。同一个运行时可以纯粹当作 OpenAI 兼容服务器使用，但 DSL 层仍然是受支持、有文档的多步生成程序表达方式，且前端还可以对接非 SGLang 后端（OpenAI/Anthropic API）。
• 前缀缓存同源。vLLM 的自动前缀缓存（RFC issue #2614，2024-01-26 提出）明确以 RadixAttention 为模型设计其块淘汰策略——先查引用计数、再 LRU、再前缀长度。因此”基数树式”缓存如今已是行业常规做法而非差异化优势；差异在于各自如何在其上继续建设（SGLang 的会话感知分层与 HiCache，vLLM 的哈希表设计）。
• 服务基准是引擎对引擎、且带日期的。两个项目都发布吞吐对比（SGLang 的 v0.2 Llama-3 博客、上文 v0.4 的数字；vLLM 自己的基准套件）。这些是特定硬件、模型与版本下的官方声称——今天做对比的正道，是在自己的硬件上运行官方的基准工具（见下文）。

边界的实用小结：

带日期的演进时间线#

表 1 —— SGLang 里程碑，每项标注一手来源（论文、官方发布博客或文档）：

可复现性检查清单#

以下命令逐字取自官方快速入门、前端教程、结构化输出与 bench-serving 页面（docs.sglang.io，检索于 2026-08-09）。我们没有在本环境中执行它们——这份清单是复现本文所述内容的路径；前文各节的数字需要其引用的特定硬件与版本才能复现。

1. 安装（官方快速入门）：

   pip install --upgrade pip
   pip install uv
   uv pip install --prerelease=allow sglang
   

   （Docker 替代方案：Docker Hub 的 lmsysorg/sglang:latest。）

2. 启动服务器，等待 The server is fired up and ready to roll!：

   python3 -m sglang.launch_server --model-path qwen/qwen2.5-0.5b-instruct --host 0.0.0.0 --port 30000
   

3. 用 OpenAI 兼容 API 冒烟测试：

   curl http://localhost:30000/v1/chat/completions \
   -H "Content-Type: application/json" \
   -d '{"model": "qwen/qwen2.5-0.5b-instruct",
       "messages": [{"role": "user", "content": "What is the capital of France?"}]}'
   

   或原生端点：POST /generate，请求体 {"text": "...", "sampling_params": {"temperature": 0, "max_new_tokens": 32}}。

4. 离线引擎（无需服务器）：

   import sglang as sgl
   llm = sgl.Engine(model_path="qwen/qwen2.5-0.5b-instruct")
   outputs = llm.generate(["Hello, my name is"], sampling_params={"temperature": 0.8, "top_p": 0.95})
   llm.shutdown()
   

5. 吞吐基准（官方 bench-serving 指南），针对运行中的服务器：

   python3 -m sglang.bench_serving \
   --backend sglang --host 127.0.0.1 --port 30000 \
   --model meta-llama/Llama-3.1-8B-Instruct \
   --dataset-name random --random-input-len 1024 --random-output-len 1024 \
   --num-prompts 1000
   

   要在同一硬件上与 vLLM 对比，用 --backend vllm --base-url http://127.0.0.1:8000 运行同一工具（并加 --flush-cache，避免热缓存效应扭曲对比）。

6. 调度器 A/B 对照：加 --disable-overlap-schedule 重新启动，重复第 5 步。

7. 结构化输出（官方结构化输出页面）：

   client.chat.completions.create(
    model="meta-llama/Meta-Llama-3.1-8B-Instruct",
    messages=[{"role": "user", "content": "Give me the capital of France in JSON."}],
    temperature=0, max_tokens=128,
    response_format={"type": "json_schema",
                     "json_schema": {"name": "foo", "schema": {...}}},
   )
   

8. 前端 DSL：把前端教程中的 @function 示例（经 RuntimeEndpoint）对接到第 2 步启动的服务器上运行。

如果某个参数或端点在你的安装上不一致，请先锁定版本——命令行接口演进很快（例如 v0.4 博客用的是 --disable-overlap，2026 年文档已改为 --disable-overlap-schedule）。

注意事项：如何解读数字#

本文中每一个量化断言都是带日期基准的引用断言，来源见参考文献——而非独立测量：

• 论文（2024 年基准）：最高 6.4 倍吞吐；无命中时基数缓存开销低于 0.3%；DFS 调度下离线最优命中率（定理 3.1）。
• 2024 年发布博客：5 倍（RadixAttention，2024-01）、3 倍 JSON 解码（2024-02）、7 倍 DeepSeek MLA（v0.3，2024-09）、调度器 1.1 倍/1.3 倍、路由器 1.9 倍/3.8 倍、DP 注意力解码 1.9 倍、XGrammar JSON 10 倍（v0.4，2024-12）。
• 2025–2026 硬件博客：2.7 倍解码（GB200 第一部分，2025-06）、3.8 倍预填充 / 4.8 倍解码（GB200 第二部分，2025-09）、25 倍（GB300，2026-02）——每项都基于特定的 NVIDIA 硬件、模型与版本。
• XGrammar 论文：文法执行最高 100 倍加速（arXiv:2411.15100，2024-11）。

硬件、模型与软件版本跑得比文字快：请把这些数字当作方向性参考，并用自己的 GPU 按上面的清单重新测量。

参考文献#

1. Lianmin Zheng 等. SGLang: Efficient Execution of Structured Language Model Programs. arXiv:2312.07104（v2，2024-06-06）；NeurIPS 2024 海报（94872）。https://arxiv.org/abs/2312.07104
2. sgl-project/sglang——官方仓库（Apache-2.0）。https://github.com/sgl-project/sglang
3. SGLang 官方文档（docs.sglang.io），检索于 2026-08-09：快速入门；前端语言；结构化输出；会话感知基数缓存；HiCache 系统设计；服务器参数；Bench Serving 指南。https://docs.sglang.io/
4. The SGLang Team. SGLang v0.4: Zero-Overhead Batch Scheduler, Cache-Aware Load Balancer, Faster Structured Outputs. LMSYS 博客，2024-12-04。https://lmsys.org/blog/2024-12-04-sglang-v0-4/
5. SGLang 发布博客：RadixAttention（2024-01-17）、压缩 FSM（2024-02-05）、v0.2（2024-07-25）、v0.3（2024-09-04）、大规模 EP（2025-05-05）、GB200 第一/二部分（2025-06-16、2025-09-25）、HiCache（2025-09-10）、SGLang-JAX（2025-10-29）、GB300（2026-02-20）、DeepSeek-V4（2026-04-25）、DFlash/Spec V2（2026-06-15）、Kimi K3（2026-07-27）。https://lmsys.org/blog/
6. Woosuk Kwon 等. Efficient Memory Management for Large Language Model Serving with PagedAttention. arXiv:2309.06180（SOSP 2023）。https://arxiv.org/abs/2309.06180
7. vLLM RFC：Automatic Prefix Caching（issue #2614，2024-01-26）。https://github.com/vllm-project/vllm/issues/2614
8. Yixin Dong 等. XGrammar: Flexible and Efficient Structured Generation Engine for Large Language Models. arXiv:2411.15100（2024-11-22；MLSys 2025）。https://arxiv.org/abs/2411.15100
9. vllm-project/vllm——官方仓库（Apache-2.0）。https://github.com/vllm-project/vllm