深度研究笔记 · SGLang vs vLLM

SGLang 架构设计与 vLLM 选型对比

这份笔记基于 SGLang 与 vLLM 最新主分支源码、README、设计文档和高级特性文档整理。重点不是复述功能清单，而是回答：SGLang 的系统设计到底抓住了哪些推理瓶颈，它与 vLLM 的主战场有何不同，生产选型时该如何判断。

阅读日期2026-05-09
研究范围README、docs、server args、scheduler、radix cache、engine entrypoint、gateway、PD/EP/HiCache/RL 文档
SGLang commit50ed01674ea1b80eb9e2a224c7b889652adda5a9
vLLM commita43bc34baf2a2e367cdbbdaec44de8cf5de92d1a

一页结论

SGLang 和 vLLM 都是高性能 LLM serving 框架，但它们的设计重心不完全一样。vLLM 更像“默认可靠的通用推理底座”：生态大、模型覆盖广、文档和 API 入口清晰。SGLang 更像“围绕真实大规模推理流量做持续榨干的系统工程包”：缓存命中、调度、PD 解耦、MoE/EP、Gateway、RL rollout 等都被推进到生产形态。

SGLang 的强项

缓存优先、调度优先、集群优先

SGLang 的核心味道是把“前缀复用”变成系统中心。RadixAttention/RadixCache 用 radix tree 管理 prefix KV 复用；HiCache 把 KV 从 GPU 延伸到 host memory 和分布式后端；SGLang Model Gateway 再把 cache-aware routing 放到多副本入口。对于长上下文、共享 system prompt、agent/RAG、RL rollout、DeepSeek/MoE 这类 workload，它的设计非常有针对性。

vLLM 的强项

通用默认、生态默认、兼容默认

vLLM 的 PagedAttention、continuous batching、OpenAI server、广泛 Hugging Face 模型兼容和 200+ 架构覆盖，使它成为很多团队的第一选择。它的 V1 架构把 API Server、Engine Core、GPU Worker、DP Coordinator 分清楚，适合作为通用部署基线。

我的选型结论：如果只是要一个通用 OpenAI-compatible serving engine，优先从 vLLM 起步；如果 workload 有明显共享前缀、长上下文、多副本 cache routing、DeepSeek/MoE 大规模部署、PD 解耦或 RL rollout 控制需求，SGLang 值得直接进入候选甚至优先测试。

SGLang 架构：从 runtime 到 gateway 的分层

SGLang Runtime，简称 SRT，不只是一个 Python HTTP server。它把请求入口、模板和 tokenizer、scheduler、model worker、detokenizer、KV cache、分布式执行、gateway 以及若干通信后端拆成独立职责。

SGLang 单实例内部

HTTP / Engine APIFastAPI/uvicorn/uvloop；OpenAI、Anthropic、Ollama 风格 endpoint；Python Engine API。
TokenizerManager模板解析、chat template、reasoning/tool parser 自动检测、多模态输入处理。
Scheduler subprocess请求队列、batch 构造、prefix matching、prefill/decode 调度、overlap、LoRA、grammar、metrics。
Model Worker模型加载、attention backend、CUDA graph、MoE runner、TP/PP/EP/DP 执行。
DetokenizerManager输出 token detokenize、streaming 返回、finish reason 汇总。
KV / MemoryRadixCache、memory pool、HiCache、GPU/CPU/L3 KV 迁移与回写。

生产集群外层

SGLang Model GatewayRust router，支持普通路由、PD 路由、gRPC 路由、OpenAI 外部 provider 路由。
Control PlaneWorker Manager、Job Queue、Load Monitor、Health Checker、Tokenizer Registry。
Reliability重试、jitter、circuit breaker、token bucket、排队、health check。
ObservabilityPrometheus metrics、OpenTelemetry tracing、结构化日志。
DisaggregationPrefill/Decode 分离，Mooncake、NIXL、MoRI 等传输和 EP 后端。
RL / Refitsleep/wake、release/resume memory、pause/continue generation、disk/tensor/distributed 权重更新。

源码里的 Engine 类明确说明单实例由三个核心组件组成：主进程里的 TokenizerManager、scheduler 子进程、detokenizer 子进程，进程间用 ZMQ IPC。Scheduler 再通过 mixin 组合出权重更新、profiling、metrics、prefill/decode disaggregation、multiplex、pipeline parallel、DP attention、overlap schedule 等能力。这个设计看起来复杂，但复杂性对应的是“推理服务真实需要被调度的维度”。

请求链路：一次生成如何流过 SGLang

1. 接入HTTP/OpenAI API 或 Engine API 接收请求，读取 sampling 参数、工具调用、结构化输出和多模态字段。
2. 预处理TokenizerManager 应用 chat template、tokenize、处理 multimodal payload，并把请求发给 scheduler。
3. 排队调度Scheduler 将请求放入 waiting/running 队列，按 FCFS、LPM、DFS-weight、priority 等策略排序。
4. 缓存匹配RadixCache 对 prompt prefix 做 radix tree match，找到可复用 KV，估算 token 预算。
5. 执行prefill/decode batch 进入 model worker；attention backend、MoE runner、CUDA graph、quant kernels 执行。
6. 回传DetokenizerManager 解码并 stream 返回；KV 插入、淘汰或写回 HiCache。

这个链路的关键点是：SGLang 不是等请求进入 GPU 后才优化，它在 CPU scheduler、routing、cache match、batch shape、KV placement 上都提前做决策。对共享前缀 workload，这些前置决策会直接改变 TTFT、吞吐和 GPU 利用率。

SGLang 核心机制拆解

RadixAttention / RadixCache

用 radix tree 管理 prefix KV，节点记录 key/value、lock ref、host value、hit count、priority、eviction 状态。相比只看块 hash，它更直接服务“最长前缀匹配”。

Cache-aware Scheduling

支持 lpm、dfs-weight、fcfs、lof、priority 等策略。lpm 优先最长 prefix match，请求过多时会回退以控制 CPU 开销。

HiCache

把 KV cache 分成 L1 GPU、L2 host memory、L3 distributed storage。HiRadixTree 记录 KV 所在层级，支持 prefetch、write-through/write-back、page-first transfer。

PD Disaggregation

将 compute-heavy 的 prefill 和 memory-heavy 的 decode 拆到不同 worker。SGLang 文档把 Mooncake/NIXL、router、异构 TP staging buffer 都写成可操作方案。

Expert Parallelism

MoE forward 被拆成 dispatch、pre-permute、runner、post-permute、combine。All-to-all 后端包括 DeepEP、Mooncake、NIXL、MORI、FlashInfer、Ascend FuseEP。

DPA / MLA 友好

Data Parallelism Attention 面向 MLA 模型降低 KV cache 复制，尤其适合 DeepSeek、Kimi、MiniMax 等单 KV head 或 MLA 场景。

Model Gateway

Rust 网关把 cache-aware routing、健康检查、限流、重试、可观测性、PD routing 放到多副本入口，而不是只依赖单进程 DP。

RL Lifecycle

release/resume memory、pause/continue generation、update weights from disk/tensor/distributed group，目标是让 rollout 与训练循环共存。

结构化输出与工具调用

支持 constrained decoding、reasoning parser、tool-call parser、OpenAI compatible API，服务 agent 和函数调用场景。

最值得注意的设计取舍

SGLang 把一些原本可以外包给负载均衡器或平台层的事情收回到推理系统内：比如 cache-aware routing、prefill/decode worker 角色、KV 层级迁移、RL 权重更新。这会增加系统表面积，但好处是调度决策更懂 KV、batch、prefix 和 GPU。对于高规模场景，这通常比“通用网关 + 通用 serving engine”更容易打到性能上限。

vLLM 画像：为什么它仍是默认基线

vLLM 的核心资产是 PagedAttention 和围绕它建立的成熟 serving 生态。README 明确强调：PagedAttention、continuous batching、chunked prefill、prefix caching、CUDA/HIP graphs、量化、speculative decoding、disaggregated prefill/decode/encode、OpenAI/Anthropic/gRPC、multi-LoRA、200+ Hugging Face model architectures。

vLLM V1 进程架构

API ServerHTTP 接入、tokenization、多模态加载、streaming；与 engine core 通过 ZMQ 通信。
Engine Corescheduler、KV cache management、model execution coordination；每个 DP rank 一个。
GPU Worker每张 GPU 一个，负责权重加载、forward execution、GPU memory。
DP CoordinatorDP 大于 1 时做负载均衡与 MoE forward 同步。

vLLM 核心机制

PagedAttention以 block/page 方式管理 KV cache，降低碎片并提升显存利用。
Prefix Caching基于 parent hash、block tokens、LoRA/multimodal/cache salt 等 extra hash 缓存完整块。
Disaggregated Prefill文档标为 experimental，提供 Connector/LookupBuffer/Pipe 抽象和多种 connector。
DBODual Batch Overlap 面向 DP+EP MoE，重叠 all-to-all 通信和计算。

vLLM 的优势不只是“快”，而是非常适合作为组织内默认推理抽象：模型覆盖、社区、插件、文档、OpenAI server、Hugging Face 兼容和用户规模都足够大。对于大多数没有极端 cache/routing/PD 需求的服务，vLLM 的工程风险更低。

逐项对比矩阵

维度 SGLang vLLM 判断
定位 高性能 serving 框架，特别强调低延迟、高吞吐、prefix reuse、多模态、MoE、PD、Gateway、RL rollout。 高吞吐、显存高效、易用的通用 LLM inference/serving engine。 SGLang 更“系统工程特化”，vLLM 更“通用默认底座”。
KV cache RadixAttention/RadixCache，以 radix tree 做 prefix matching；HiCache 扩展到 GPU/CPU/L3。 PagedAttention block 管理；prefix caching 使用 block hash，只缓存完整块。 共享前缀、长上下文和跨副本 cache routing 场景，SGLang 的语义更直接。
调度 公开可选 lpm、dfs-weight、fcfs、priority 等；包含 chunked prefill、dynamic chunking、prefill delayer、radix eviction。 Engine Core 负责 scheduler 与 KV 管理；continuous batching、chunked prefill、prefix caching 是主路径能力。 SGLang 暴露更多 cache-aware 策略；vLLM 更像稳定默认调度器。
PD 解耦 文档和示例覆盖 Mooncake/NIXL、router、DeepSeek 多节点、异构 TP staging buffer；与 SMG 结合。 disaggregated prefill 文档标注 experimental；提供 Connector 抽象，并明确说明该模式主要调 TTFT/ITL，不必然提升吞吐。 若生产上认真做 PD，SGLang 更像现成方案；vLLM 更适合 connector/实验框架。
MoE / EP EP 框架拆分 dispatch、runner、permute/combine；支持 DeepEP、Mooncake、NIXL、MORI、FlashInfer、Ascend；EPLB、TBO/SBO。 支持 DP/EP、DeepEP、DBO、优化 MoE kernels、CUTLASS/TRTLLM/CuTeDSL 等。 两者都强。DeepSeek/MLA/DPA/大规模 EP 组合上，SGLang 文档更激进也更细。
网关和多副本 SGLang Model Gateway 是独立 Rust 系统，支持 cache-aware routing、PD routing、health check、circuit breaker、metrics、tracing。 主要由 API server、engine core 和 DP coordinator 组成；外部网关通常由用户平台承担。 需要“懂 KV 的网关”时 SGLang 优势明显。
结构化输出 constrained decoding、grammar manager、tool/reasoning parser，与模板检测和 OpenAI API 打通。 structured outputs 支持 xgrammar/guidance，OpenAI API extra fields 成熟。 两者都可用；具体看所需 grammar、parser 和 API 兼容细节。
生态 GitHub 页面读取约 27.5k stars；LMSYS 背书，文档强调数十万 GPU 和海量 token/day 生产使用。 GitHub 页面读取约 79.4k stars；README 强调 2000+ contributors 和 200+ HF model architectures。 vLLM 社区和默认选择势能更强；SGLang 生产性能叙事更集中。
硬件 NVIDIA GB/H/A/Spark/5090、AMD MI、Intel CPU、TPU、Ascend 等；README 和新闻集中展示 GB200/GB300、AMD、TPU。 NVIDIA、AMD、CPU，并列出 TPU、Gaudi、Ascend、Apple Silicon、MetaX 等插件。 二者覆盖都广；具体硬件要看对应 backend 的成熟度。
操作复杂度 能力多，调参面也大：TP/PP/DP/EP/DPA、PD、HiCache、gateway、transfer backend 都要理解。 默认路径更平滑，CLI/API/文档示例更适合快速落地。 小团队先 vLLM；有专门 serving infra 能力再深入 SGLang 高阶功能。

选型建议与测试清单

优先选 SGLang
  • 请求存在大量共享 system prompt、few-shot、RAG 前缀、agent 历史或长上下文复用。
  • 需要多副本 cache-aware routing，而不是简单 round-robin。
  • 目标模型是 DeepSeek、Kimi、MiniMax 等 MLA/MoE，且要做 DPA/EP/DeepEP。
  • 计划上 PD disaggregation，并希望 gateway、prefill/decode worker、KV transfer 有完整路径。
  • RL rollout 与训练循环需要 sleep/wake、权重热更新、pause/resume generation。
优先选 vLLM
  • 需求是通用 OpenAI-compatible serving，模型覆盖和生态稳定性优先。
  • 团队希望用最少调参启动生产基线，然后逐步做性能优化。
  • 模型来自 Hugging Face，且希望最大概率直接跑通。
  • 平台层已有成熟 gateway、routing、限流、观测系统，不需要 serving engine 自带完整网关。
  • 当前瓶颈还没有精确定位到 prefix cache、PD、EP 或 KV 层级迁移。

建议的 benchmark 方法

不要只看 README 或博客数字。两者都应该用自己的 prompt 长度分布、输出长度、并发曲线、共享前缀比例、模型、量化、GPU 拓扑和网络条件来压测。至少要分开看 TTFT、ITL、tokens/s、GPU utilization、KV cache hit rate、P99 延迟、队列等待、OOM 边界以及多副本路由下的 cache 命中变化。

短 prompt / 高并发

更考验 continuous batching、decode throughput、kernel 和调度开销。

长 prompt / 共享前缀

更考验 prefix cache、radix/hash 命中、cache-aware routing 和 prefill 策略。

MoE / DeepSeek

更考验 EP、all-to-all、EPLB、DPA、prefill/decode 分工和网络。

我的实践判断

如果今天要给团队定一条默认路线，我会把 vLLM 作为 baseline，把 SGLang 作为性能上限候选。先用相同模型和相同 workload 做 A/B：当 SGLang 的 cache-aware 机制、PD、EP 或 gateway 能证明带来清晰收益时，再接受它更大的调参面和系统复杂度。反过来，如果 workload 很普通，vLLM 的维护成本通常更低。

阅读来源

以下链接是本报告直接参考的主要材料。仓库源码使用 2026-05-09 拉取的主分支快照；GitHub 页面元数据以打开页面时显示为准。