SGLang 与 vLLM 全面对比：架构差异、性能边界与选型建议

本文来源： Tiny点（公众号：Tiny点）
原文链接： https://mp.weixin.qq.com/s/U62WRblKY6Njoo-0II1k7g
发布时间： 2026-09-03 10:21

作者： Tiny点　　发布时间： 2026-09-03 10:21

在大模型推理服务领域，vLLM 和 SGLang 是目前最受关注的两个开源框架。它们都支持 Continuous Batching、前缀缓存、Chunked Prefill、量化、推测解码、多卡并行、结构化输出以及 OpenAI 兼容 API，也都在向超大规模 MoE、长上下文、多模态和 Prefill/Decode 分离部署演进。

因此，如果仍然把两者概括成 “vLLM 使用 PagedAttention，SGLang 使用 RadixAttention”，很容易得出过时甚至错误的结论。PagedAttention 和 RadixAttention 并不是互斥方案：前者主要解决 KV Cache 的物理内存管理，后者主要解决跨请求前缀的组织、查找与复用。当前的 SGLang 同样具有分页式 KV Cache，当前的 vLLM 也已经支持自动前缀缓存。

两者真正的差异，更多体现在设计起点、缓存组织、调度策略、模型适配节奏和工程生态上。

本文依据 2026 年 9 月的公开项目状态整理。SGLang 与 vLLM 更新速度很快，具体模型、硬件和功能支持应以使用版本的官方文档为准。

一、先给结论

如果希望快速做出选择，可以先参考下面的概括。

对比维度	SGLang	vLLM
设计起点	结构化语言模型程序与高性能运行时	通用、高吞吐的大模型推理引擎
代表性技术	RadixAttention、缓存感知调度、重叠调度	PagedAttention、块式 KV Cache、通用调度引擎
前缀复用	以 Radix Tree 表达不同长度、不同分支的共享前缀	以 KV Block 哈希实现自动前缀缓存
通用服务能力	很强	很强，生态和第三方集成通常更广
重复前缀与 Agent 工作负载	是重点优化方向	已具备完整能力，需要结合版本实测
新模型专项优化	通常跟进很快，尤其重视新型 MoE、MLA 和 RL Rollout	覆盖面广，新模型和新硬件适配同样活跃
结构化生成	项目早期核心能力之一	已支持基于 xgrammar、guidance 等方案的结构化输出
分布式推理	TP、PP、DP、EP、上下文并行及分离式部署	TP、PP、DP、EP、上下文并行及分离式部署
硬件生态	NVIDIA、AMD、TPU、CPU、Ascend 等	NVIDIA、AMD、Intel GPU、CPU、TPU 及多种硬件插件
扩散模型	提供 SGLang Diffusion，用于图像与视频生成	核心定位仍以语言和多模态理解模型推理为主
更适合优先考虑的场景	Agent、多轮会话、共享长前缀、RL Rollout、前沿模型专项优化	通用模型服务、广泛模型兼容、成熟生态、低迁移风险

这张表不是性能排行榜。对于同一个模型，最终结果可能因为 GPU 型号、输入输出长度、并发量、量化方式、Attention Backend、前缀重复率和调度参数而完全不同。框架选型应以实际业务流量回放为准。

二、两者解决的是同一个问题，但出发点不同

2.1 vLLM：从显存利用率出发构建通用推理引擎

vLLM 最具代表性的设计是 PagedAttention。传统推理系统通常为每个请求预留连续的 KV Cache 空间，但请求的实际输出长度无法提前准确预测，容易造成内部碎片、外部碎片和过度预留。

vLLM 将 KV Cache 划分为固定大小的 Block。一个请求在逻辑上连续的 Token，可以映射到物理上不连续的显存块。请求增长时按需分配新块，结束后再把块归还给空闲池。这种思路类似操作系统的分页内存管理，其核心目标是把有限显存变成可动态分配、回收和共享的资源池。

在此基础上，vLLM 逐步形成了完整的通用服务系统，包括请求预处理、Continuous Batching、Chunked Prefill、前缀缓存、抢占、CUDA Graph、推测解码、分布式执行和多种服务协议。今天的 vLLM 已经远不只是一个 Attention Kernel，而是一套覆盖模型加载、调度、缓存、执行和 API 服务的推理平台。

2.2 SGLang：从语言模型程序与跨请求复用出发

SGLang 最初面向的是结构化语言模型程序。Agent、RAG、多轮对话、Tree-of-Thought 和结构化生成往往不是一次独立调用，而是一系列具有共同前缀、分支关系和约束条件的模型调用。

例如，一个 Agent 可能在每轮请求中都携带相同的系统提示词、工具定义和历史消息；一组 RAG 请求可能共享同一份长文档，只在末尾追加不同问题。如果每次都重新执行完整 Prefill，会产生大量重复计算。

SGLang 的代表性技术 RadixAttention 使用 Radix Tree，也就是压缩前缀树，组织 Token 序列与 KV Cache 之间的映射关系。它不只判断 “两个完整 Prompt 是否相同”，还可以表达公共系统提示词、公共文档和不同问题之间的多层前缀关系。新请求到达时，运行时执行最长前缀匹配，只对没有命中的后缀进行 Prefill。

随着项目发展，SGLang Runtime（SRT）已经成为可以独立使用的生产级推理引擎。即使完全不使用早期的前端 DSL，也可以通过 OpenAI 兼容 API、原生接口或离线 Engine 使用它。

三、PagedAttention 与 RadixAttention 到底有什么区别

这是比较两者时最容易混淆的地方。

PagedAttention 主要回答：KV Cache 在显存里怎样放置和分配？

RadixAttention 主要回答：哪些请求拥有相同前缀，这些前缀缓存怎样查找、共享、保留和淘汰？

可以把 KV Cache 系统粗略分成两个层次：

Token 前缀与请求关系
        │
        │  Radix Tree 或 Block Hash 等索引机制
        ▼
逻辑 KV Cache 映射
        │
        │  分页、块表、引用计数和空闲池
        ▼
GPU / CPU / SSD 中的物理 KV 数据

SGLang 的 Radix Tree 更擅长显式表示不同长度和不同分支的共享前缀；vLLM 的自动前缀缓存则通常按 KV Block 计算内容哈希，逐块查找可复用的最长前缀。两种实现都能避免重复 Prefill，只是索引粒度、缓存组织、淘汰方式以及它们与调度器的结合方式不同。

这也意味着，不能简单地说 “有 RadixAttention 才支持前缀缓存”，也不能说 “有 PagedAttention 就自动解决了跨请求复用”。分页管理和前缀索引属于两个相关但不同的问题。

四、调度与请求执行差异

4.1 两者都采用 Continuous Batching

传统静态批处理要求同一批请求一起开始、一起结束。由于各请求的输出长度不同，短请求完成后会留下空闲计算位置。

Continuous Batching 会在每个调度周期重新组织批次：已结束的请求立即退出，新请求可以补入，未结束请求继续 Decode。SGLang 和 vLLM 都把它作为提升 GPU 利用率的基础能力。

两者也都支持 Chunked Prefill，将超长 Prompt 拆成多个片段执行，以免一次大 Prefill 长时间阻塞正在 Decode 的请求。实际体验取决于 Token Budget、最大并发、块大小、Chunk 大小和 Prefill/Decode 调度策略，不能只看功能列表。

4.2 SGLang 更强调缓存感知与 CPU—GPU 重叠

SGLang 会把前缀命中情况纳入调度考虑。假设等待队列中有多条请求共享一个长系统提示词，让它们在缓存仍然存在时相邻执行，可以提高命中率；如果它们被大量无关请求隔开，公共缓存可能已经被淘汰。

SGLang 还长期强调 Overlap Scheduling：GPU 执行当前批次时，CPU 并行准备后续批次，包括解析结果、分配缓存和构造元数据，以减少两个 GPU 批次之间的调度空隙。

4.3 vLLM 更强调通用调度与模块化扩展

vLLM 的 Scheduler、KV Cache Manager、Model Runner 和 Executor 分工清晰。调度器以 Token Budget 和 KV Block 为核心管理 waiting、running、preempted 等请求状态，并通过可扩展的执行后端支持单卡、多卡和多节点部署。

近年来 vLLM 也在持续降低 CPU 调度开销，并引入异步调度、Rust 前端、分离式推理和新的 Model Runner。因此，“SGLang 调度快、vLLM 调度慢” 并不是长期成立的结论。对于短输出、高并发、GPU 计算很快的场景，CPU 开销确实可能成为瓶颈，但需要用目标版本和目标模型测量。

五、功能和生态对比

5.1 模型覆盖

vLLM 的优势之一是模型覆盖面和 Hugging Face 生态兼容性。其官方项目说明列出了 200 多种模型架构，范围包括 Decoder-only LLM、MoE、混合 Attention/状态空间模型、多模态模型、Embedding、Reranker、Reward 和分类模型。

SGLang 同样支持主流的 Llama、Qwen、DeepSeek、Kimi、GLM、Gemma、Mistral 等模型，并且对新型 MoE、MLA、线性 Attention 和超大规模模型投入了大量专项优化。对于刚发布的前沿模型，SGLang 经常把 Day-0 支持和特定硬件性能作为重点方向。

如果使用的是常见主流模型，两者往往都能运行；如果使用冷门架构、自定义模型或刚发布的新模型，应直接检查对应版本的 Supported Models、Release Notes 和已知限制，而不是仅依据项目总模型数做判断。

5.2 结构化输出、工具调用和推理模型

SGLang 从项目早期就关注 JSON、正则表达式和 Grammar 约束生成，并在原始设计中引入了用于加速结构化生成的压缩有限状态机。它也提供用于表达复杂语言模型程序的前端能力。

vLLM 目前同样支持结构化输出、Tool Calling 和 Reasoning Parser，并可以结合 xgrammar、guidance 等后端工作。对于普通的 JSON Schema 输出，两者的功能差距已经明显缩小。真正需要验证的是目标模型的 Chat Template、工具调用格式、推理内容解析器以及流式输出行为是否符合业务协议。

5.3 多模态与扩散模型

两者都支持视觉语言模型等多模态推理，并对图像预处理、视觉编码器缓存和多模态批处理进行优化。

SGLang 还提供 SGLang Diffusion，覆盖部分图像与视频生成模型。它使 SGLang 的项目边界从自回归语言模型服务扩展到了扩散模型服务。不过，语言模型运行时和扩散模型运行时的计算模式并不相同，选型时应分别测试，不能因为品牌相同就假定二者拥有相同的性能特征。

5.4 分布式与超大模型

两者都已经覆盖 Tensor Parallel、Pipeline Parallel、Data Parallel、Expert Parallel 和 Context Parallel 等多种并行方式，也都支持 Prefill/Decode 分离及更复杂的分离式架构。

SGLang 在大规模 MoE、DeepSeek 系列、Expert Parallel、分层 KV Cache、RL Rollout 和机架级系统上非常活跃；vLLM 则拥有广泛的分布式部署用户、硬件插件和上下游平台集成。到了多节点规模，框架名称通常不是唯一决定因素，网络拓扑、NCCL/RDMA、Expert Placement、KV 传输、容错和监控能力同样重要。

5.5 部署和工程生态

两者都提供 OpenAI 兼容服务，因此基础 Chat Completions 或 Completions 应用迁移成本通常不高。但只要业务使用了 Tool Calling、LoRA、多模态输入、Prompt Logprobs、Embedding、并行采样或特殊解码参数，就需要逐项验证协议细节。

vLLM 出现更早，用户规模、教程、第三方集成和运维经验通常更丰富，许多云平台、模型平台和 Kubernetes 推理方案会首先提供 vLLM 模板。SGLang 的社区增长很快，并在前沿模型推理、RL 后训练和高重复前缀负载中形成了很强的影响力。

六、谁的性能更好

最准确的答案是：取决于模型、硬件、流量形态和指标，没有对所有场景都成立的赢家。

6.1 SGLang 可能更有优势的负载

大量请求共享长系统提示词、工具定义或固定文档；
多轮 Agent 会话具有稳定且不断增长的历史前缀；
Tree-of-Thought、并行分支、RAG 或 RL Rollout 中存在大量前缀分叉；
使用 SGLang 已深度优化的前沿 MoE、MLA 或特定硬件组合；
需要把缓存感知调度、分层缓存和会话生命周期结合起来。

这些场景更容易发挥 RadixAttention 和相关缓存策略的价值，但收益仍然取决于缓存能否在下一次复用前保留下来。如果前缀几乎不重复，或者缓存因显存压力频繁被淘汰，优势会明显下降。

6.2 vLLM 可能更适合的负载

希望以较低工程风险部署常见 Hugging Face 模型；
业务请求差异较大，前缀复用不是主要性能来源；
依赖现有云平台、网关、监控系统或 Kubernetes 生态集成；
需要广泛的模型架构、量化格式和硬件插件支持；
团队已经积累了 vLLM 参数调优与生产运维经验。

需要注意的是，vLLM 已支持自动前缀缓存、分层 KV Cache 和分离式推理。如果业务共享前缀很多，也不能仅凭“RadixAttention”这个名称就直接判定 SGLang 一定更快。

6.3 吞吐领先不等于用户体验更好

推理服务至少需要同时观察以下指标：

TTFT（Time to First Token）：从提交请求到收到首个 Token 的时间；
TPOT（Time per Output Token）或 ITL：生成阶段相邻 Token 的平均间隔；
端到端延迟：完整请求完成时间；
吞吐量：每秒请求数或每秒 Token 数；
尾延迟：P95、P99 等高分位延迟；
Goodput：满足既定 TTFT 和 TPOT 服务等级的有效吞吐；
显存占用与缓存命中率：决定系统能承载的并发和复用效果；
稳定性：长时间压测中是否出现 OOM、请求饥饿、超时或吞吐抖动。

某个配置可能拥有最高 Token 吞吐，却让低并发请求等待更久；也可能拥有很低的平均延迟，但在长 Prompt 混入后出现严重 P99 抖动。线上系统不应只依据单一吞吐数字选型。

七、怎样做一次公平的对比测试

如果要为实际项目选型，建议使用相同请求集做流量回放，并严格控制以下变量：

使用完全相同的模型仓库和 Revision；
使用相同精度、量化方式和 KV Cache 数据类型；
使用相同 GPU、驱动、CUDA/ROCm 和网络拓扑；
对齐 Tensor Parallel、Pipeline Parallel 等并行配置；
记录 Attention Backend、GEMM/MoE Kernel 和 CUDA Graph 配置；
使用相同的输入长度、输出长度和请求到达分布；
分别测试无共享前缀、固定系统提示词、共享长文档和多轮会话；
同时测试低并发延迟、饱和吞吐和过载后的尾延迟；
先完成模型预热和 Kernel 编译，再进入正式统计；
检查输出正确性，避免把异常结束或少生成 Token 误算成性能提升。

建议至少设计四组测试流量：

流量类型	目的
随机独立 Prompt	测试通用 Continuous Batching 和模型执行效率
相同 System Prompt + 不同问题	测试基础前缀缓存能力
长文档 + 多问题	测试长前缀命中、TTFT 和缓存淘汰
多轮 Agent/工具调用	测试会话增长、结构化输出和复杂协议行为

只有当测试数据接近真实生产流量时，结果才具有决策价值。

八、选型建议

如果团队需要一个覆盖面广、资料丰富、第三方集成成熟的通用推理后端，vLLM 通常是稳妥的默认起点。它适合从标准 OpenAI API 服务开始，再逐步扩展量化、多卡部署、LoRA 和分离式推理。

如果业务天然包含大量重复前缀，例如长系统提示词、固定知识库、多轮 Agent、树状搜索或 RL Rollout，SGLang 值得优先进入候选名单。它围绕前缀复用和语言模型程序形成的设计，对这类工作负载具有很强的针对性。

如果目标是刚发布的超大 MoE、多模态或新硬件，应放弃抽象层面的“框架站队”，直接比较两边在该模型、该硬件和该版本上的官方支持状态、正确性与 Benchmark。新模型的最优实现经常随着版本更新而改变。

对于重要生产系统，一个更现实的策略是保留统一的 OpenAI 兼容接入层，把 vLLM 和 SGLang 都视为可替换后端。通过模型路由或独立 Deployment，让不同模型和流量使用更合适的引擎，比要求所有业务统一到一个框架更灵活。

结语

vLLM 和 SGLang 正在快速吸收彼此以及整个推理社区的优秀设计。vLLM 不再只有 PagedAttention，SGLang 也不只是 RadixAttention；前缀缓存、连续批处理、推测解码、分离式推理和多种并行方式已经逐渐成为双方共有的基础能力。

两者最值得关注的区别，不是“谁拥有某个功能”，而是该功能与调度器、缓存系统、模型实现和硬件 Kernel 结合得有多深，以及这种组合是否适合自己的业务流量。

简而言之：通用部署与生态兼容可以优先评估 vLLM；共享前缀、Agent、RL 和前沿模型专项优化可以重点评估 SGLang；最终选择则应由真实流量下的 TTFT、TPOT、Goodput、显存效率和稳定性共同决定。

参考资料

SGLang 官方文档
SGLang GitHub
SGLang: Efficient Execution of Structured Language Model Programs
vLLM 官方文档
vLLM GitHub
Efficient Memory Management for Large Language Model Serving with PagedAttention

本文转载自微信公众号「Tiny点」，仅供学习交流使用。