SGLang 基本原理

SGLang 和 vLLM 都是高性能 LLM 推理框架；SGLang 最有代表性的设计是利用 RadixAttention，更主动地复用不同请求之间相同前缀的 KV Cache。

---

RadixAttention

SGLang 与 vLLM 最显著的区别在于 SGLang 的 RadixAttention。

假设有两个请求：

请求 A：你是一名 Kubernetes 专家，请解释 Pod
请求 B：你是一名 Kubernetes 专家，请解释 Service

两个请求都有相同的前缀：

你是一名 Kubernetes 专家，请解释

SGLang 会使用 Radix Tree 记录这些 Token 及其 KV Cache：

你是一名 Kubernetes 专家，请解释
├── Pod
└── Service

处理请求 B 时，共同前缀的 KV Cache 可以直接复用，只需要计算后面的 Service。

因此 RadixAttention 适合：

• 多轮对话。
• 相同 System Prompt。
• RAG 中重复查询同一篇长文档。
• Agent 反复携带相同工具描述。
• 一个 Prompt 生成多个分支。

---

与 vLLM PagedAttention 的区别

两者解决的问题不同：vLLM 的 PagedAttention 解决 KV Cache 在显存里怎么存的问题，SGLang 的 RadixAttention 解决不同请求之间哪些 KV Cache 可以复用的问题。

---

Cache-aware Scheduling

SGLang 的调度器在选择下一个请求时，会考虑它能复用多少 KV Cache。

思路是：

前缀匹配
    ↓
找到可复用 KV Cache
    ↓
只计算未命中的 Token
    ↓
加入动态 Batch

RadixAttention 负责找到缓存，调度器负责利用缓存。

---

与普通调度器的区别

假设当前 GPU 保存了下面这段 Prompt 的 KV Cache：

你是一名 Kubernetes 专家，请根据下面的文档回答问题：
[一篇很长的文档，共 8000 Token]

此时等待队列里有两个请求：

请求 A：
你是一名 Kubernetes 专家，请根据下面的文档回答问题：
[相同文档]
Pod 是什么？

请求 B：
请写一篇关于 Kubernetes 的文章。

假设：

• 请求 A 总长度是 8020 Token。
• 其中 8000 Token 已经存在于缓存。
• 请求 B 长度是 2000 Token，没有缓存。

实际需要计算的 Token 数是：

请求 A：只需计算 20 Token
请求 B：需要计算 2000 Token

虽然请求 A 看起来更长，但因为命中了大量 KV Cache，处理成本反而更低。

对于普通调度器

普通的先来先服务调度器主要看请求到达顺序：

请求 B 先到 → 先处理 B
请求 A 后到 → 后处理 A

不关心哪个请求可以复用缓存。

对于 Cache-aware Scheduling

Cache-aware Scheduler 会先检查：

请求 A：缓存命中 8000 Token
请求 B：缓存命中 0 Token

因此可能优先处理请求 A：

先处理 A：只计算 20 Token
再处理 B：计算 2000 Token

这样可以减少 GPU 计算，提高整体吞吐量。

---

SGLang 与 vLLM 的简化对比

方面	vLLM	SGLang
主要目标	高吞吐通用推理服务	高吞吐、低延迟及高效前缀复用
KV Cache 存储	分页管理	分页管理
连续批处理	支持	支持
前缀缓存	使用 Block Hash 查找相同前缀	使用 Radix Tree 组织相同前缀
代表性技术	PagedAttention	RadixAttention
PD 分离	支持	支持
投机解码	支持	支持
API	OpenAI-compatible API	OpenAI-compatible API
适合场景	通用模型部署	通用部署，尤其适合大量共享前缀的请求

vLLM 通过分页解决 KV Cache 如何高效存储，SGLang 在分页基础上进一步强调不同请求的 KV Cache 如何高效复用。