SGLang 详解：为 Agent 打造的低延迟推理引擎

TL;DR — SGLang 是 UC Berkeley/LMSYS 出品的高性能推理框架，攻击角度和 vLLM 不同：它不只是做内存分页，而是用基数树（RadixAttention）自动发现并复用请求间的共享前缀。对于 Agent 工作负载——同一 system prompt 和对话历史不断重复并微调——这意味着可测量的延迟降低和更少的重复计算。它同时也是多个前沿模型 RL 训练的 rollout 后端。

SGLang 是什么

SGLang 既是推理框架，也是结构化 LLM 交互的编程语言。名字代表 “Structured Generation Language”——从设计之初就面向模型不只生成自由文本、还要遵循 schema、调用工具、产出结构化输出的场景。

我是从 vLLM 转过来试 SGLang 的，本来以为顶多算个平替。让我改观的是一个 coding agent 的负载：每个请求都共享一段 3K token 的 system prompt 和越滚越长的对话历史。在 vLLM 上，历史一长 TTFT 就往上爬；换 SGLang 之后稳住了，因为它不再重算已经见过的部分。这就是它全部的卖点，但对 Agent 来说，这事不小。

2026 年关键数据：

指标	数值
GitHub stars	30K+
OpenRank（2026年5月）	455.39
活跃贡献者	415
硬件支持	NVIDIA GB200/H100/A100、AMD MI300/MI355、Intel Xeon、TPU、Ascend NPU
驱动 GPU 集群	全球 400,000+ 张
许可证	Apache 2.0

“400,000+ GPU” 这个数字不是营销——SGLang 是多个组织训练前沿模型的 rollout 后端，也在规模化生产推理中运行。

核心创新：RadixAttention

vLLM 的 PagedAttention 问的是”每个请求怎么高效分配内存”，SGLang 的 RadixAttention 问的是”已经算过的前缀 KV cache，怎么避免重复计算”。

机制：SGLang 维护一棵基数树（trie），存储所有已计算的 KV cache 片段。新请求到达时，引擎沿树查找最长匹配前缀——不需要应用层给任何提示。

基数树（KV Cache）：

Root
├── "You are an AI assistant that..." (system prompt，已缓存)
│   ├── "User: analyze this code..." (第1轮，已缓存)
│   │   ├── "Assistant: The code has..." (第1轮响应)
│   │   │   └── "User: fix the bug in..." (第2轮 → 新的，只算这段)
│   │   └── "User: now write tests..." (第2轮分支 → 新的)
│   └── "User: deploy to prod..." (不同对话 → 从这里开始新算)
└── "You are a code reviewer..." (不同 system prompt)

对 Agent 来说这是变革性的。典型 coding agent 会话中：

每轮共享同样的 system prompt（2-4K tokens）
对话历史逐轮递增（每轮加 ~500 tokens）
Agent 经常用略微修改的 prompt 重试
工具调用结果追加到同样的前缀后面

vLLM 的 block 级前缀缓存只在新请求开头精确对齐已缓存 block 时才能复用。RadixAttention 在对话树的任何深度、任何共享前缀片段都自动复用。结果：在前缀重叠超过 60% 的工作负载上，TTFT（首 token 时间）最高降低 40%。

Agent 为什么特别受益

Agent 工作负载有独特的访问模式，正好打中 RadixAttention 的优势：

带分支的多轮对话 — Agent 尝试方案 A 失败，回退，尝试方案 B。两个分支共享同样的前缀直到决策点。RadixAttention 把共享部分只缓存一次。

多会话共享 system prompt — 100 个 Agent 会话用同样的指令，system prompt KV cache 只算一次并跨会话共享。不是 block 级别——是完整前缀级别。

结构化生成 — Agent 工具调用需要 JSON。SGLang 的压缩有限状态机（FSM）在解码时就知道每个位置哪些 token 合法，跳过不可能的路径。这不是事后约束——集成在解码循环里。

分支上的投机执行 — SGLang 可以投机预计算可能的后续。如果 Agent 编辑文件后通常跑 pytest，引擎可以在还在流式输出当前结果时就开始生成下一个 action。

架构概览

SGLang 是三层架构：

┌──────────────────────────────────────────┐
│  前端（Python DSL）                        │
│  gen(), select(), fork(), join()          │
├──────────────────────────────────────────┤
│  编译器 / 追踪器                           │
│  从程序构建数据流图                         │
├──────────────────────────────────────────┤
│  运行时（SGVM）                            │
│  RadixAttention + 调度器 + Workers         │
│  Prefill-Decode 分离                       │
│  Multi-LoRA 批处理                         │
└──────────────────────────────────────────┘

前端提供 Python 原语来表达结构化生成程序。编译器追踪执行构建数据流图。运行时带着全部优化执行它。

你不必用 DSL 前端。SGLang 也暴露标准 OpenAI 兼容 API——可以作为 vLLM 的直接替代品，只享受推理性能而不用学编程模型。

Benchmark：SGLang 赢在哪里

基于 Llama 3.3 70B 在 H100 上的公开 benchmark：

场景	SGLang	vLLM	优势方
p95 延迟（streaming，小 batch）	~48ms	~85ms	SGLang
吞吐（batch 128+）	接近	略高	vLLM
有 60%+ 前缀重叠时的 TTFT	快约 40%	基线	SGLang
Blackwell FP4（batch 1）	比 vLLM 快 1.32x	基线	SGLang
结构化输出（JSON）	更快（FSM 原生）	语法引导	SGLang
冷启动（模型加载）	相当	相当	平手

模式很清楚：SGLang 赢延迟和前缀密集工作负载；vLLM 在超大 batch 时保持吞吐优势。对交互式 Agent 会话（小 batch、高前缀重叠、结构化输出），SGLang 有优势。

RL 训练连接

大多数推理框架对比忽略了这点：SGLang 同时是主要的 RL rollout 后端。AReaL、verl、Slime、Miles 等框架用 SGLang 在强化学习训练中生成 rollout。

对 Agent 开发者为什么重要？因为你在用的模型很可能训练时就有 SGLang 参与。SGLang 对结构化生成和工具调用模式的优化直接影响模型在 RL 中学这些行为的效果。这是正反馈：更好地服务结构化 Agent 交互 → 更好的训练数据 → 更好的 Agent 模型。

快速启动

# 安装
pip install "sglang[all]"

# 启动服务（OpenAI 兼容）
python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.3-70B-Instruct \
  --tp 2 \
  --port 8000

# 像调 OpenAI API 一样用
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3.3-70B-Instruct",
    "messages": [{"role": "user", "content": "Hello"}],
    "max_tokens": 100
  }'

或用 DSL 做结构化 Agent 交互：

import sglang as sgl

@sgl.function
def agent_step(s, history, tools):
    s += sgl.system("You are a coding agent. Respond with a JSON action.")
    s += history
    s += sgl.gen("action", max_tokens=500, regex=r'\{"action": "\w+", "args": \{.*\}\}')

# regex 约束在解码时强制执行——不会有事后解析失败

Prefill-Decode 分离

对 Agent 越来越重要的架构决策：SGLang 支持把 prefill（处理输入 prompt）和 decode（生成输出 token）拆到不同 GPU 池。

为什么重要：Agent 请求往往有很长的 prompt（对话历史 + 工具结果）但很短的输出（下一个 action）。Prefill 是算力密集的；decode 是内存密集的。跑在同一 GPU 上会互相抢资源。分离后可以独立扩缩容。

SGLang 路线图（issue #21846: “Distributed KVCache System For Agentic Workload”）明确指出——agentic workloads 正在推动 KV cache 体量超出简单 PD 分离的承载极限，需要新的分布式存储和传输架构。

级联故障问题（一个真实事故）

营销页面不会告诉你的事，记录在 SGLang issue #20252。某团队在 H20 集群上跑 qwen3-32b-fp8：90 个 prefill 节点 + 30 个 decode 节点，PD 分离。高 QPS 下，部分 prefill 节点重启或迁移。decode 节点不断重试失败的连接，健康检查开始失败，router 把这些 worker 移出轮转，流量集中到剩余节点——然后这些节点也被压垮。结果：级联故障，整个集群 503 洪水。

这个教训适用于任何分离式部署，包括 vLLM：**引擎跑起来是简单的部分；集群的故障传播行为是难的部分。**当你分离 prefill 和 decode，你引入了一个分布式系统，带着它所有的故障模式。一个节点打嗝就能通过路由和健康检查涟漪成全局宕机，如果你没有：

prefill 和 decode 池之间的熔断器（快速停止重试死节点）
调好的健康检查（瞬时重启不触发移除）
负载卸除（过载时尽早拒绝而不是无限排队）
余量（丢一个节点不会把其余的压垮）

如果你单节点跑 SGLang，这些都不适用——你拿到 RadixAttention 的好处，没有分布式复杂度。故障模式只在你扩到多节点分离时才出现。在单节点真的扛不住你的负载之前，别上 PD 分离。

调优 SGLang：重要的参数

python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.3-70B-Instruct \
  --tp 2 \
  --port 8000 \
  --mem-fraction-static 0.88 \
  --chunked-prefill-size 8192 \
  --max-running-requests 128 \
  --schedule-conservativeness 0.3

--mem-fraction-static 0.88 — 给基数树 KV cache 预留多少 GPU 内存。越高缓存复用越多，但太高会在加载权重时 OOM。80GB 卡上 0.88 是安全上限。
--chunked-prefill-size 8192 — 每个调度步处理多少 prefill token。值越低，长 prompt 来时越保护 decode 延迟；越高 prefill 吞吐越好。8192 对 Agent 流量两者平衡。
--schedule-conservativeness 0.3 — 值越低调度器越激进地接纳请求（更高吞吐，更高抢占风险）。默认 1.0 保守；有 cache 余量时 0.3 榨出更多吞吐。

基数树是自动的——你不配置前缀匹配。但命中率取决于流量模式。盯服务器日志里的 cache hit rate：有共享 system prompt 的 Agent 集群应该 60%+。如果低，说明你的请求没有按你假设的方式共享前缀，你在为一个没用上的功能买单。

什么时候选 SGLang

选 SGLang：

Agent 会话有高前缀重叠（同 system prompt、递增历史）
需要交互式 Agent 的低 p95 延迟
结构化输出（JSON 工具调用）是核心用例
你想用 DSL 做复杂生成程序（分支、选择）
你想推理和 RL 训练用同一个引擎

选 vLLM：

优化目标是大 batch 最大吞吐
需要最大社区和最广模型支持
工作负载主要是独立请求（低前缀重叠）
想要最经战考验、部署指南最多的选项

很多生产环境两个都用——SGLang 跑延迟敏感的 Agent 路径，vLLM 跑批处理。网关根据请求特征路由。

FAQ

SGLang 生产就绪了吗？

是的。它驱动着总计 400,000+ GPU 的推理集群。NVIDIA 在深度学习框架发布中包含它。成熟度和 vLLM 同级，只是社区更小（但增长快）。

不学 DSL 能用 SGLang 吗？

完全可以。OpenAI 兼容 API 开箱即用。不碰编程模型也能享受 RadixAttention 的好处。DSL 是在需要更精细控制结构化生成时用的。

SGLang 支持多模型推理吗？

一个 SGLang 实例跑一个模型（和 vLLM 一样）。多模型场景跑多实例挂 router。Multi-LoRA 批处理功能可以从一个实例服务同一 base model 的多个 fine-tune 变体。

RadixAttention 和 vLLM 的前缀缓存有什么区别？

vLLM 做 block 级前缀缓存——新请求开头和之前请求的 token block 完全对齐时才复用。SGLang 的基数树更灵活：在任何粒度发现共享前缀，处理多个请求在不同位置分叉的分支对话。优势随对话深度和重试模式增长。

和 LMSYS 什么关系？

SGLang 由 LMSYS 团队开发（就是做 Chatbot Arena 的那帮人）。它是他们跑 Arena 评估的推理引擎。

核心要点

SGLang 的 RadixAttention 用基数树自动发现并复用请求间的共享 KV cache 前缀——无需手动配置。
对高前缀重叠的 Agent 工作负载（共享 system prompt、递增对话、重试），SGLang 延迟可测量地低于 block 级缓存。
它也是训练前沿模型的 RL rollout 后端，在推理优化和模型能力之间形成正反馈。
延迟敏感的交互式 Agent 会话用 SGLang；吞吐密集的批处理挂 vLLM，中间放路由层。