SGLang

3 秒看懂

SGLang（Structured Generation Language） 是一个面向大语言模型（LLM）推理的高效服务框架，核心创新是 RadixAttention（基于基数树的 KV Cache 复用）和压缩有限状态机（Compressed FSM）约束解码。它能在多轮对话、共享前缀、结构化输出等场景下实现显著的吞吐量提升，是当前开源 LLM 推理优化的重要竞争者之一，与 vLLM 形成直接对标。

3 分钟产业解释

为什么需要 SGLang？

大模型落地的核心瓶颈已经从”训练能不能跑”转向”推理能不能用得起”。一个中等规模的聊天应用可能面临：

• 每秒数千并发请求，每个请求都可能包含长系统提示（system prompt）
• 多轮对话中，前几轮的 KV Cache 不断重复计算
• 结构化输出需求（JSON、SQL、代码），约束解码效率低下

传统推理框架（如 HuggingFace TGI、vLLM）在这些场景下存在优化空间。SGLang 通过系统级的 KV Cache 管理和批处理调度，针对性地解决这些痛点。

产业定位

┌─────────────────────────────────────────────────────────┐
│                    LLM 推理服务层                         │
├─────────────┬─────────────┬─────────────┬───────────────┤
│   vLLM      │   SGLang    │  TensorRT-  │   DeepSpeed   │
│  (PagedAttn)│(RadixAttn)  │    LLM      │    -Inference  │
├─────────────┴─────────────┴─────────────┴───────────────┤
│                 CUDA / ROCm / 自研算子                     │
├─────────────────────────────────────────────────────────┤
│              GPU 硬件 (NVIDIA / AMD / ...)                │
└─────────────────────────────────────────────────────────┘

关键差异

15 分钟专家深入

架构全貌

SGLang 的推理引擎可以分为几个关键模块：

┌──────────────────────────────────────────────────────────────┐
│                    SGLang Runtime                             │
├──────────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │
│  │  Scheduler   │  │  RadixCache │  │  Constrained Decode │  │
│  │  (批处理调度) │  │ (KV Cache)  │  │   (FSM 引擎)        │  │
│  └──────┬──────┘  └──────┬──────┘  └──────────┬──────────┘  │
│         │                │                     │             │
│         ▼                ▼                     ▼             │
│  ┌──────────────────────────────────────────────────────┐   │
│  │              CUDA Kernel 层 (FlashInfer)              │   │
│  └──────────────────────────────────────────────────────┘   │
└──────────────────────────────────────────────────────────────┘

RadixAttention 机制详解

这是 SGLang 的核心技术突破。传统 PagedAttention 的问题是：它不感知请求之间的前缀共享关系。

问题场景：100 个请求共享同一个 2000 token 的系统提示

请求 A: [系统提示 2000t] + [用户问题 100t]
请求 B: [系统提示 2000t] + [用户问题 150t]
请求 C: [系统提示 2000t] + [用户问题 80t]
...

传统方案：每个请求独立计算系统提示的 KV Cache → 重复计算 100 次

RadixAttention 方案：使用基数树（Radix Tree / Trie）索引 token 序列的前缀

                    [root]
                       │
                 [系统提示前缀...]
                       │
              ┌────────┼────────┐
              ▼        ▼        ▼
           [A的后缀] [B的后缀] [C的后缀]
              ↓        ↓        ↓
           KV_A      KV_B      KV_C
           (仅后缀)  (仅后缀)  (仅后缀)

关键机制：

1. 前缀匹配：新请求到来时，先在基数树中查找最长公共前缀（Longest Common Prefix）
2. Cache 复用：命中前缀的 KV Cache 直接复用，跳过计算
3. 动态管理：支持 LRU 淘汰、引用计数、Copy-on-Write 等策略

量化收益估算（基于公开基准，具体数字可能因场景而异）：

• 多轮对话场景：吞吐量提升约 1.5-3 倍（vs 原始 vLLM）
• 共享系统提示场景：首 token 延迟（TTFT）显著降低

压缩有限状态机（Compressed FSM）

结构化输出是企业级应用的刚需（返回 JSON、SQL 等）。SGLang 的约束解码方案：

传统约束解码问题：

• 每次生成 token 后，需要遍历 FSM 状态转移
• 对于复杂 schema，FSM 可能有数千状态，转移表巨大

SGLang 的压缩 FSM：

1. 状态压缩：合并等价状态，减小 FSM 规模
2. 批量转移：一次计算多个 token 的合法集合
3. 与 RadixCache 集成：约束解码的中间结果也能被缓存复用

JSON Schema 示例: {"name": string, "age": int}

FSM 状态转移（简化）:
  state_0 --'{'--> state_1 --'"'--> state_2 --[a-z]--> state_3 ...
                                          --'n'--> state_4 (匹配 "name")
                                          --'a'--> state_5 (匹配 "age")

压缩后: 合并相同前缀路径，减少状态数

批处理调度器

SGLang 实现了连续批处理（Continuous Batching），但增加了前缀感知的调度策略：

• Preempt 策略：当显存不足时，优先抢占前缀较短的请求（因为重新计算成本低）
• 调度优先级：共享长前缀的请求被调度到同一 batch，最大化 Cache 命中

FlashInfer 内核

SGLang 依赖 FlashInfer 库提供高效的注意力计算内核：

• 支持多种注意力变体：MHA、GQA、MQA
• 支持 Paged KV Cache 的高效访问
• 针对不同 GPU 架构优化（A100、H100 等）

技术原理

KV Cache 基数树实现

┌─────────────────────────────────────────────────────┐
│                   RadixCache 内部结构                 │
├─────────────────────────────────────────────────────┤
│                                                     │
│   Token 序列: [t1, t2, t3, t4, t5, t6, t7, t8]    │
│                                                     │
│   基数树节点:                                        │
│                                                     │
│   Node(root)                                        │
│     └── Node([t1,t2,t3])  ← 前缀节点               │
│           ├── Node([t4,t5])  ← 请求A的后缀          │
│           │     └── [KV Cache: K_A, V_A]            │
│           └── Node([t4,t6])  ← 请求B的后缀          │
│                 └── [KV Cache: K_B, V_B]            │
│                                                     │
│   节点元数据:                                        │
│   - token_ids: 该节点对应的 token 序列              │
│   - kv_cache: 对应的 K, V 张量                      │
│   - ref_count: 引用计数（用于淘汰策略）              │
│   - last_access: LRU 时间戳                         │
│                                                     │
└─────────────────────────────────────────────────────┘

Cache 复用的数学表示

对于请求 $R$，其 token 序列为 [t_1, t_2, ..., t_n]

设基数树中已缓存的最长前缀长度为 $p$，则：

• 可复用的 KV Cache：对应 [t_1, ..., t_p]
• 需要计算的部分：[t_{p+1}, ..., t_n]
• 计算量节省比：\frac{p}{n}（理想情况）

约束解码的 FSM 原理

JSON Schema: {"key": string}

对应的正则表达式（简化）:
  {"key":"[a-zA-Z]*"}

FSM 构建:
┌─────┐   '{'   ┌─────┐   '"'   ┌─────┐   'k'   ┌─────┐
│ q0  │ ------→ │ q1  │ ------→ │ q2  │ ------→ │ q3  │
└─────┘         └─────┘         └─────┘         └─────┘
                                                   │ 'e'
                                                   ▼
                                                ┌─────┐
                                                │ q4  │
                                                └─────┘
                                                   │ 'y'
                                                   ▼
                                                ┌─────┐
                                                │ q5  │
                                                └─────┘
                                                   │ '"'  (键结束引号)
                                                   ▼
                                                ┌─────┐
                                                │ q6  │
                                                └─────┘
                                                   │ ':'  (冒号)
                                                   ▼
                                                ┌─────┐
                                                │ q7  │
                                                └─────┘
                                                   │ '"'  (值开始引号)
                                                   ▼
                                                ┌─────┐
                                                │ q8  │
                                                └─────┘
                                         (接受 [a-zA-Z]*)

每个状态对应一个合法 token 集合（vocab mask）
解码时，logits 只在合法 token 上取 argmax

SGLang 核心参数与指标

技术演进史

时间线

2023.06   vLLM 发布，PagedAttention 成为主流方案
          ↓
2023.12   SGLang 初始版本，提出结构化生成语言概念
          ↓
2024.01   SGLang 推出 RadixAttention，性能大幅改进
          ↓
2024.Q1   FlashInfer 集成，内核优化
          ↓
2024.Q2   压缩 FSM 约束解码优化
          ↓
2024.H2   持续迭代，扩展模型支持（Mixtral MoE、Gemma 等）
          ↓
至今       与 vLLM 形成双雄竞争格局

关键里程碑

技术路线对比

推理框架技术路线对比

性能对比基准（参考值，具体数字因场景/硬件/模型而异）

注：以上数字为基于公开基准的估算范围，实际结果依赖具体配置。

上下游

产业链位置

上游（算力/硬件层）
┌─────────────────────────────────────────────┐
│  GPU 硬件: NVIDIA A100/H100, AMD MI250/MI300  │
│  互联: NVLink, PCIe, InfiniBand              │
│  显存: HBM2e, HBM3 (容量/带宽是关键)         │
└─────────────────────┬───────────────────────┘
                      │
                      ▼
中游（框架/引擎层）
┌─────────────────────────────────────────────┐
│  推理框架: SGLang, vLLM, TensorRT-LLM, TGI   │
│  内核库: FlashInfer, FlashAttention, Triton   │
│  编译优化: CUDA, ROCm, TensorRT              │
└─────────────────────┬───────────────────────┘
                      │
                      ▼
下游（应用/服务层）
┌─────────────────────────────────────────────┐
│  云服务: AWS Bedrock, Azure AI, GCP Vertex    │
│  API 服务: OpenAI, Anthropic, 自建服务        │
│  应用: 聊天机器人, 代码助手, 结构化数据抽取   │
└─────────────────────────────────────────────┘

关键依赖

关键指标

推理性能关键指标

资源效率指标

供需与市场数据

推理框架市场格局（定性）

开源推理框架市场份额（估算）

vLLM         ████████████████████████  (~40-50%)  ← 当前领导者
TensorRT-LLM ████████████████          (~25-30%)  ← NVIDIA 生态绑定
SGLang       ████████                  (~10-15%)  ← 快速增长
TGI          ██████                    (~8-12%)   ← HuggingFace 生态
Others       ████                      (~5-10%)

注：以上为基于社区活跃度、部署案例的粗略估算，非精确市场调研数据。

SGLang 的应用场景需求

代表公司与产业映射

核心团队与组织

资本/商业化映射

注：SGLang 是开源项目，暂无直接独立融资记录。其价值体现在降低推理成本、推动生态发展。

产业逻辑

为什么关注 SGLang？

核心逻辑：LLM 推理成本是落地的关键瓶颈，推理框架是降本增效的核心抓手。

大模型落地成本拆解（简化）

┌──────────────────────────────────────────┐
│           总拥有成本 (TCO)                │
├──────────────────────────────────────────┤
│  训练成本        │  推理成本（持续）      │
│  (一次性)        │  (随请求量线性增长)    │
│                  │                       │
│  注：推理成本    │  ← 这是长期主要成本   │
│  通常远大于训练  │     优化空间巨大       │
└──────────────────────────────────────────┘

产业影响梳理

风险与不确定性

常见误读纠偏

误读 1：SGLang 的性能提升都是”免费”的

纠偏：SGLang 的性能提升依赖于特定场景。在没有共享前缀的场景下，RadixAttention 的优势不明显。核心收益来自：

• 多轮对话（历史 KV 复用）
• 共享系统提示（前缀 KV 复用）
• 结构化输出（FSM 约束解码优化）

对于单轮、无共享的简单请求，SGLang 与 vLLM 性能差距不大。

误读 2：RadixAttention 完全替代了 PagedAttention

纠偏：RadixAttention 和 PagedAttention 解决的是不同层面的问题：

• PagedAttention：解决 KV Cache 的显存碎片化问题（将连续显存分页管理）
• RadixAttention：解决 KV Cache 的跨请求复用问题（基于前缀索引）

SGLang 的 RadixCache 底层仍然使用分页管理（类似 PagedAttention 的思想），上层增加了基于基数树的前缀索引。两者是互补关系，不是替代关系。

误读 3：SGLang 是 vLLM 的”改进版”

纠偏：虽然 SGLang 和 vLLM 都是 LLM 推理框架，但它们的设计哲学和技术创新点不同：