SGLang 深拆：vLLM 赢了内存管理之后，它接着打的下一仗

2026 年的 LLM 推理引擎市场有一个耐人寻味的格局：vLLM 以 93,365 GitHub stars 遥遥领先（2026-10-08 查询），但给 xAI 服务 Grok 3、给 Azure 在 MI300X 上跑 DeepSeek R1 的，是另一个项目——SGLang（sgl-project/sglang，36,854 stars）。它出身 UC Berkeley Sky Computing 实验室与 LMSYS 社区，2025 年 9 月正式加入 PyTorch 生态，官方支持机构名单里排着 AMD、NVIDIA、Cursor、美团、科大讯飞、LinkedIn。它凭什么？一句话：vLLM 的 PagedAttention 赢下了「KV 内存怎么分页」的战争，SGLang 接着打的是「相同前缀为什么还要重算」——而在 agent 与多轮对话主导负载的 2026 年，后一场战争恰好更值钱。

RadixAttention：把缓存复用从手工优化变成自动机制

SGLang 的核心资产是 2023 年 12 月论文里提出的 RadixAttention（arXiv:2312.07104）。当时推理引擎的共识是 PagedAttention 式的分页内存管理，但跨请求的 KV 复用还是应用层的手工戏法。RadixAttention 的做法是把 KV cache 组织成一棵 radix tree（基数树）：树的 key 是 token 序列、value 是对应的 KV 张量，任何两个请求只要共享前缀——同一个 system prompt、同一组 few-shot 示例、多轮对话的历史——公共部分的 KV 就只算一次，命中即复用，逐出用 LRU。树的边可以挂任意长度的 token 序列（比逐字符 trie 紧凑），KV 以分页布局放显存、树结构放 CPU 维护，论文口径下相比当时方案最高 6.4 倍吞吐（对照 vLLM 早期版本的博客口径为 5 倍，基线不同，数字注明）。

这个设计有个工程上的聪明之处：无命中时零额外开销，所以它恒常开启——不存在「要不要开缓存」的决策成本。而分叉场景是它对简单前缀哈希的真正优势：一万条对话从同一个 system prompt 出发各自延伸，radix tree 让公共主干只存一份、分叉各自生长。

从 DSL 到推理引擎：一段研究产品的演化史

回看论文标题会注意到一个细节——《Efficient Execution of Structured Language Model Programs》：SGLang 最初的主打其实是前端 DSL，用 gen、select 等原语把「生成、分支、并行调用」写成结构化程序，RadixAttention 只是配套的运行时优化。此后两年剧本反转：前端 DSL 逐渐淡出、后端 runtime 成为主战场——2024 年它抢先支持 DeepSeek 系列的推理需求，2025 年又把结构化输出的老本行翻新（早期以压缩 FSM 领先，v0.4 集成 xgrammar 后，JSON 受约束解码最高比其他开源方案快 10 倍）。这段「DSL 起家、引擎立身」的演化，是研究项目如何产品化的教科书案例：论文里的卖点未必是市场的卖点，保留下来的往往是最工程化的那一层。

从单机到集群：调度、路由与 DeepSeek 特调

2024 年 12 月的 v0.4 是架构上的分水岭，一次交付了三件武器：

零开销批调度器：调度、内存分配、前缀匹配原本都跑在 CPU 上，GPU 在等 CPU。新调度器把下一批的元数据准备与 GPU 计算重叠，用 CUDA event 精细编排，官方用 Nsight 验证连续多个解码批次 GPU 零空闲，实测吞吐 1.1 倍；
缓存感知负载均衡：多副本部署时随机路由会让每个副本各自缓存不同的前缀、命中率稀烂。SGLang 用 Rust 写了一个独立路由器，在路由侧维护每副本的「近似 radix tree」（懒更新、近零开销），把请求发给最可能命中的副本——8 卡 A100 长前缀负载实测吞吐从 8,266 提到 15,859 tok/s，缓存命中率从 20% 拉到 75%；
DP attention：DeepSeek 的 MLA 架构只有 1 个 KV head，8 路 tensor parallel 会让 KV 缓存重复 8 份。SGLang 对 attention 部分改用数据并行、在 MoE 层前做 all-gather，KV 缓存大幅缩减，DeepSeek 解码吞吐 1.9 倍——这是它成为「DeepSeek 事实标准服务引擎」的关键一役。

2025 年 9 月的 HiCache 把战线延伸到显存之外：radix tree 的缓存体系扩展为「GPU 显存 → 主机内存 → 外部存储（Mooncake、LMCache、NVIDIA Dynamo、阿里云 Tair）」三级，逐出的 KV 不再是重算而是降级。官方数据最高 6 倍吞吐、TTFT 降低 80%；v0.5.20 又针对共享系统提示场景加入 SWA 分支点缓存，命中率 43.8% 提到 60.8%，平均 TTFT 从 1.57 秒降到 1.07 秒。

2026 年的节奏：双周一版，冷启动成为新战场

看它的发版记录能读出 2026 年推理引擎的竞争焦点已经变了。v0.5.18（2026-08-22，单版本 710 个 PR、212 位贡献者）主打冷启动：权重加载与 CUDA graph 捕获重叠，MoE 大模型的加载时间从 35 分钟压到 6 分 20 秒——这是 serverless 与自动扩缩容时代「实例拉起速度」的竞赛。v0.5.19（09-05）发布了 SGLang Simulator：不用 GPU、在 CPU 上模拟真实的调度器与缓存行为做容量规划，TTFT 预测误差约 6%。v0.5.20（09-18）把统一 radix tree 转为默认；v0.5.21（2026-10-02，779 个 PR、227 位贡献者）把前缀缓存迁入 Rust 核心，并支持 prefill/decode 分离部署的实例在线切换角色。项目边界也在外扩：SGLang Diffusion 覆盖扩散模型、SGLang Omni 覆盖语音。

硬件地图是它另一张底牌：NVIDIA 全线（A100 到 B300/GB300）、AMD MI300X–MI355X、Google TPU（经 SGL-JAX）、Intel、Apple Silicon（Metal/MLX）、华为昇腾、摩尔线程均有支持或推进中。官方口径是「每天生成数万亿 token」。软硬协同的深度也值得单独一看：对 DeepSeek 系有 MLA 专属内核与多 token 预测（MTP）、集成 DeepGemm；v0.5.20 甚至在 Blackwell 上反向集成了 NVIDIA TensorRT-LLM 的内核（官方口径 prefill 约 1.2 倍、decode 约 1.45 倍）——社区项目吸收厂商内核库，在开源推理引擎里是不多见的姿态。

冷静看：快与稳的权衡

SGLang 不是没有代价。社区的长期吐槽集中在可靠性：Hacker News 上的典型评论是「确实快，但有可靠性问题」；双周发版的节奏也出过事故——v0.5.6.post2（2025-12）因一次变更破坏 CI 而紧急回滚。版本间默认行为变化大（v0.5.20 一举移除了 prefill CP v1、宣布 CUDA 12 路线退役），升级需要跟着 changelog 走。第三方对比机构的意见同样值得列出来：有的指出它的用户基数仍小于 vLLM、简单文本生成场景用它有「杀鸡用牛刀」之嫌、前 DSL 时代的语法残留带来学习曲线。性能对比则要警惕单一答案：2026 年的几份独立评测结论互相矛盾——PremAI（2026-02）测得 SGLang 与 LMDeploy 并列最快（H100 上约 16,200 tok/s，vLLM 约 12,500）；Deploybase（2026-03）认为 vLLM 批量吞吐仍快 15–20%、SGLang 胜在延迟；winder.ai（2026-09）的结论是高负载下只有这两家扩展性良好、其余都慢。把它们放在一起读，合理的结论是：workload 决定引擎——批量离线吞吐、超多模型种类，vLLM 的生态位依然稳固；前缀密集（agent、多轮对话、共享长 system prompt）、低延迟敏感、DeepSeek 系部署，SGLang 更对味。

顺带一提这个社区的运作风格：README 里长期挂着一条福利——活跃贡献者可以申请 Cursor、Claude Code 或 OpenAI Codex 的使用赞助。让贡献者用最顺手的 agent 工具来给 agent 时代的推理引擎写代码，这个循环本身就很 2026。

两家的选择困难，用一张表收拢最直观（star 数为 2026-10-08 的 GitHub API 查询值）：

维度	vLLM	SGLang
起家技术	PagedAttention（内存分页）	RadixAttention（前缀复用树）
社区规模	93,365 stars	36,854 stars
优势负载	批量离线吞吐、模型覆盖广	前缀密集、低延迟、DeepSeek/MLA
缓存形态	块哈希链（APC）+ 分级缓存	显式 radix tree + HiCache 三级
生产标杆	开源社区事实标准	xAI Grok 3、Azure DeepSeek R1
发版节奏	高频、稳健	双周、默认行为变化大

上手要点

安装与启动（官方文档当前口径，推荐 Python 3.12 + uv）：

uv venv --python 3.12
source .venv/bin/activate
uv pip install --prerelease=allow sglang
sglang serve Qwen/Qwen3-0.6B --host 0.0.0.0 --port 30000

服务起来后就是 OpenAI 兼容端点，客户端把 base_url 指向 http://127.0.0.1:30000/v1 即可，启动成功的标志输出是「The server is fired up and ready to roll!」。容器化路径同样是官方推荐位——一行拉起并自动挂 GPU：

docker run --rm --gpus all --ipc=host -p 30000:30000 \
  lmsysorg/sglang:latest \
  sglang serve MODEL_PATH --host 0.0.0.0 --port 30000

两个实用提醒：其一，大量既有教程写的启动命令还是 python -m sglang.launch_server——它仍然可用（大参数场景常见 --tp 8 张量并行），但新文档已主推 sglang serve，照旧命令排错前先确认版本；其二，上生产前值得读官方的超参数文档，--mem-fraction-static 决定预留给 KV 缓存的显存比例，是调优的第一站，也是前缀缓存命中率与批大小之间那个核心权衡的旋钮。

结语

SGLang 的故事线是开源推理引擎竞争的缩影：第一代引擎解决了「内存怎么省」（PagedAttention），它证明了「计算怎么省」（RadixAttention）同样是一座金矿，然后沿着这条主线把缓存做成三级存储、把缓存亲和做进路由、把容量规划做成模拟器。它没有正面挑战 vLLM 的社区规模，而是在「agent 时代的前缀密集负载」这个细分战场上拿到了生产级的冠军证明。下一个要回答的问题是所有推理引擎共同的：当 prefill 已经便宜到可以忽略，竞争会转向哪里——从 Simulator 与冷启动这两个新战场看，答案大概是「实例的生命周期成本」。想看这棵缓存树在应用层怎么折算成账单，可以对照本站的《一篇读懂 Prefix Caching》——一篇讲引擎里的树，一篇讲账单上的倍率。

参考资料

sgl-project/sglang — GitHub：项目主仓库与硬件支持表（star 数 2026-10-08 查询为 36,854）。
SGLang: Efficient Execution of Structured Language Model Programs — arXiv:2312.07104：RadixAttention 原始论文。
Fast and Expressive LLM Inference with RadixAttention — LMSYS 博客（2024-01）：radix tree 设计与首篇官方解读。
SGLang v0.4: Zero-Overhead Batch Scheduler, Cache-Aware Load Balancing — LMSYS 博客（2024-12）：调度器、路由器与 DP attention 的实测数据。
SGLang Joins the PyTorch Ecosystem — PyTorch 官方博客（2025-09）：xAI/Azure 生产采用与支持机构名单。
SGLang Releases — GitHub：v0.5.18–v0.5.21 发版记录（2026-08-22 至 2026-10-02，日期经 GitHub API 核对）。
SGLang Quickstart — 官方文档：安装与 sglang serve 新版命令。
一篇读懂 Prefix Caching — 本站：本文 RadixAttention 一节的应用层视角姊妹篇。