Skip to content

约 7 分钟阅读

18. vLLM 与 SGLang:引擎怎样组织这些技术 ​

前面十几篇逐个拆解了推理优化的技术。实际使用时,它们由一个推理引擎组织在一起。这一篇介绍最常用的两个开源引擎 vLLM 和 SGLang:它们的内部模块怎样分工,各自的特色在哪里,怎样启动一个最小服务。最后把它们和 TensorRT-LLM、llama.cpp 等其他方案放在一起,给出一个选型顺序和版本快照。读完你应该能看懂引擎的启动日志和主要参数,并为自己的场景列出候选方案。

vLLM:从 PagedAttention 起家的通用引擎 ​

vLLM 由 PagedAttention 的作者团队开发,现在是最通用的开源推理引擎之一,支持数百种模型架构,以及 NVIDIA、AMD 等多种硬件。当前的引擎架构叫 V1,旧的 V0 引擎已经从代码里移除。

vLLM 中一个请求在 API 服务、调度器、KV 管理、执行器和采样之间循环推进

一个请求在 vLLM 里经过这些模块:

模块职责对应章节
API 服务OpenAI 兼容接口、对话模板、分词与反分词、流式输出,在独立进程中运行第 7 篇
调度器统一的 token 预算,Decode 优先,抢占第 9、11 篇
KV 缓存管理分页块的分配、前缀哈希、引用计数、LRU 回收第 8、10 篇
模型执行器准备输入张量、选择注意力后端、CUDA Graph 与编译第 12 篇
采样与输出logits 处理、结构化输出约束、采样、停止判断第 7 篇

V1 的几个关键设计都在前面讲过:调度器不区分 Prefill 和 Decode,只记录“每个请求这一步推进多少 token”(第 11 篇);分块预填充和前缀缓存对生成模型默认开启;CUDA Graph 默认对纯 Decode 批录制完整图、对混合批分段录制(第 12 篇)。

另一个容易混淆的名词是 Model Runner V2(MRV2),它是 V1 引擎里模型执行器的新实现,不是“vLLM V2 引擎”。

最小启动方式(Linux + NVIDIA GPU,以 0.32.0 版本为例,需要 Python 3.11 或更新):

bash
python3.11 -m venv .venv-vllm && source .venv-vllm/bin/activate
python -m pip install 'vllm==0.32.0'

vllm serve Qwen/Qwen3-8B --max-model-len 8192

启动日志里值得看的几行:使用的数据类型和量化方法、选中的注意力后端、KV Cache 的容量(多少个 token)、CUDA Graph 录制了哪些批大小。服务默认监听 8000 端口,提供 /v1/chat/completions 等兼容接口。注意 vLLM 的兼容服务默认不做认证,对外提供服务时要在网关层加上鉴权(第 21 篇)。

SGLang:从前缀共享起家 ​

SGLang 最初的论文提出了 RadixAttention(第 10 篇)和一套描述复杂生成流程的前端语言。今天大多数人直接使用它的推理服务,不需要学习那套语言。它和 vLLM 一样支持连续批处理、分块预填充、量化、投机解码、多卡并行和 P/D 分离,在几个方面有自己的特色:

  • 基数树前缀缓存。 前缀共享粒度更细,适合多轮对话、Agent、共享长文档等前缀复用多的场景。
  • 重叠调度。 GPU 计算当前批的同时,CPU 提前准备下一批的调度和输入,减少两步之间 GPU 的空闲。单步很短的小模型、小批场景受益较大。
  • 分层 KV 缓存(HiCache)。 显存放不下的前缀缓存下沉到 CPU 内存和远端存储。
  • 结构化输出。 生成 JSON 或符合正则、语法的文本时,每一步把不合法的 token 屏蔽掉,这是它长期投入的方向。

最小启动方式(以 0.5.22 版本为例):

bash
python3.11 -m venv .venv-sglang && source .venv-sglang/bin/activate
python -m pip install 'sglang[all]==0.5.22'

python -m sglang.launch_server --model-path Qwen/Qwen3-8B --context-length 8192 --port 8000

结构化输出:每一步都在限制选择 ​

两个引擎都支持结构化输出,它直接作用在第 7 篇讲的采样这一步。

给定一个 JSON Schema 后,约束后端会跟踪“当前已经输出到语法的哪个位置”,每一步算出“下一个 token 允许是哪些”,把其他 token 的分数设为负无穷,再采样,然后更新语法状态。难点在于 token 不等于字符:一个 token 可能同时包含引号和逗号,跨越语法的多个部分。

text
已输出内容 + 语法状态 → 允许的 token 集合 → 屏蔽其余 token → 采样 → 更新语法状态

这个过程有成本:第一次使用某个 Schema 要编译语法,复杂 Schema 的每一步计算也更多。另外,格式合法不等于内容正确。一个完全合法的退款 JSON,金额和账户仍然要由业务代码校验;被长度截断的输出,要当作不完整的结果处理。

两者怎样比较 ​

维度vLLMSGLang
起点分页 KV,通用推理服务前缀树共享,生成程序运行时
前缀缓存完整块的哈希链基数树,粒度更细
默认调度先来先服务,可设优先级先来先服务,可选前缀匹配优先等策略
模型与硬件覆盖非常广广,对热门模型跟进很快
投机解码多种方法,0.32.0 按单链起草多种方法,支持树形草稿
P/D 分离多种 KV 连接器内置,默认 Mooncake 传输

两者的能力高度重叠,而且都在快速迭代。“vLLM 没有基数树所以不能复用前缀”“SGLang 有树所以一定更快”这类推论都不成立。哪个更快,要用你的模型、你的硬件、你的请求分布实测。

一个实用的学习顺序是:先用 vLLM 建立基线,再把同样的模型和请求切到 SGLang,对比时追问“差别来自哪个机制”,而不是只记两条启动命令。

其他方案的定位 ​

方案适合优先评估的场景需要注意的边界
TensorRT-LLMNVIDIA GPU 上固定模型与硬件的深度优化适配成本较高;注意区分正式版和预发布版
llama.cpp本地运行、CPU 与 GPU 混合、量化种类多(GGUF)多用户高并发不是主要目标
MLX-LMApple Silicon 上的本地推理与实验统一内存有容量和带宽上限
Ollama本地模型管理和简单的 API 封装先确认实际使用的后端和模型格式
LMDeploy已有成熟适配的模型与多模态两条引擎路线的支持范围不同
TGI只用于维护已有服务已进入维护模式,仓库已归档,新项目不再考虑
sherpa-onnx语音识别、语音合成等语音任务(第 19 篇)不是通用大模型服务的替代

Mooncake、LMCache、Dynamo 这类组件处在 KV 传输、缓存和分布式编排层,通常和上面的引擎组合使用,不应该和它们放在同一张跑分表里比较。

选型顺序 ​

选型的三道关:任务质量、模型与硬件支持、真实负载下的性能

按这个顺序筛选,比直接比跑分可靠:

  1. 任务质量:候选方案运行目标模型,回答质量是否达标?对话模板、停止条件是否正确?
  2. 模型与硬件支持:目标模型 × 引擎版本 × GPU 型号 × 需要的功能(量化格式、投机解码、结构化输出、多卡方式)这个组合是否被支持?各项“支持”单独成立,不代表组合起来能用。
  3. 真实负载下的性能:用业务的输入输出长度分布和并发,测 Goodput、TTFT 和 TPOT 的分位数,以及成本(第 20 篇)。

版本快照 ​

以下是 2026 年 10 月 26 日查询的各项目 GitHub 正式发布版本。推理引擎迭代很快,使用时以实际安装的版本为准。

项目最新正式版发布日期说明
vLLM0.32.02026-10-18需要 Python 3.11 及以上;gpu_memory_utilization 默认 0.92
SGLang0.5.222026-10-19需要 Python 3.11 及以上
TensorRT-LLM1.2.12026-04-20之后只有预发布版本,最新为 1.4.0rc1(2026-10-22)
llama.cpp0.7.02026-10-15开始使用语义化版本号,服务默认端口改为 9931
LMDeploy0.18.02026-09-28
Ollama0.40.112026-10-24
ExecuTorch1.5.12026-09-23端侧推理(第 22 篇)
sherpa-onnx2.0.02026-10-23语音框架;TTS 文本前端有不兼容变化(第 19 篇)

几条和升级相关的注意事项:vLLM 0.32.0 中 max_tokens 只表示输出上限、不再按旧语义预留上下文,默认的跨域设置也收紧了;SGLang 0.5.22 修复了混合模型在投机解码与结构化输出组合使用时的状态恢复问题,说明功能组合需要单独回归。

升级时保留这些信息,便于对比和回退:引擎版本、镜像摘要、模型版本、分词器与对话模板、量化配置、GPU 型号与驱动、CUDA 版本、启动参数,以及升级前后的质量和压测结果。先读发布说明里的不兼容变更和正确性修复,再看性能提升。

vLLM 以分页 KV 为基础,V1 引擎用统一的 token 预算调度,默认开启分块预填充和前缀缓存;SGLang 以基数树前缀缓存为特色,还有重叠调度、分层缓存和结构化输出。两者能力高度重叠,选择要依次过质量、支持和真实负载性能三道关。

文字问答之外,资料助手还要支持语音提问。下一篇看语音与多模态推理:从开口说话到听见回答,推理链路上多了哪些环节。

别急,先让缓存热一下。