SGLang

一句话定位

SGLang 是面向大语言模型及多模态模型的推理与服务系统。

运行时因果链

1
2
3
4
5
结构化 prompt / 多轮程序
→ 前端编排与状态复用
→ runtime 调度 token、KV 与批次
→ GPU kernel 执行
→ streaming response / tool result

它的价值不只是“另一个 HTTP server”：当工作负载包含共享前缀、结构化生成、分支或多轮调用时，前端程序与运行时可以共同减少重复计算。但如果只是简单单轮请求，收益仍由模型、硬件、batch 和 kernel 决定。

与 vLLM 的比较维度

维度 SGLang vLLM
主要抽象 结构化程序、状态与运行时 通用 serving engine 与请求调度
优势场景 prefix/state reuse、复杂生成流程 多租户高吞吐、生态与部署成熟度
必须实测 cache 命中、编排开销、约束解码 batch、KV、并发和模型支持

不要用单一 tokens/s 结论替代同 prompt、并发、输出长度、约束和失败率的矩阵评测。

SGLang 真正解决的请求形状

SGLang 的优势假设是“请求之间存在可表达的结构”，而不是所有请求都只是一次独立的 prompt → completion。例如一个系统提示被大量请求共享、同一份文档要生成摘要/分类/引用三个分支，或者一次调用中交替发生模型生成与工具调用；如果前端程序能显式描述这些共享前缀和分支，运行时才有机会复用状态、安排批次或避免重复生成。

可以把一次请求拆成两层状态：

1
2
程序状态：变量、分支、约束、tool result
模型状态：token 序列、prefix 命中、KV block、正在生成的位置

程序状态复用并不自动等于 KV 命中。只要 tokenizer、chat template、采样参数、位置编码或模型实例不同，逻辑上相同的前缀也可能无法共享；共享前缀后发生分支时，还要为分支后的 token 做 copy-on-write 或重新分配缓存。排查“声明了 cache 但 TTFT 没降”时，先看真实 token 前缀和命中长度，再看 scheduler 是否因为容量、优先级或跨副本路由放弃了复用。

结构化生成的代价

约束解码、正则/JSON grammar 和多轮程序会把普通的 token 采样变成“候选 token 过滤 + 状态机推进”。这通常提高输出可解析性，却可能增加 CPU 侧 grammar 状态维护、GPU batch 的形状分裂和缓存失配。一个简单 completion 变慢，不应归咎于 SGLang 的核心 kernel；应分别测无约束、固定 schema 和分支程序三种轨迹，并记录 grammar 过滤耗时、prefix hit length、每轮 batch size、TTFT/TPOT P99 与结构化失败率。

选型边界

若工作负载主要是异构租户的普通聊天请求，先比较 vLLM 的通用调度、生态和运维成本；若工作负载有大量共享前缀、程序化生成或多模型/多轮状态，SGLang 值得进入候选。最终结论必须绑定同一模型、同一 tokenizer/template、相同 cache 配置和相同请求轨迹；只比较官方 demo 的 tokens/s，测不到它真正的结构化收益。

尚需实证