vLLM：从 PagedAttention 长出来的开源服务栈，200+ 模型架构与五维并行

把显存当虚拟内存管：PagedAttention 之后的一整套服务栈

vLLM 起步于 UC Berkeley 的 Sky Computing Lab，核心论文是 SOSP 2023 的 Efficient Memory Management for Large Language Model Serving with PagedAttention（arXiv:2309.06180）。它解决的问题很具体：自回归解码时每个请求的 KV cache 尺寸事先未知，传统实现按最大长度预留连续显存，于是内部碎片、外部碎片和预留浪费一起吃掉大半容量，能同时驻留的请求数被压低，吞吐随之被压低。PagedAttention 借鉴操作系统分页，把 KV cache 切成固定大小的块、用块表做逻辑到物理的映射，非连续的物理块也能拼出一个请求的上下文，浪费收敛到最后一个块。

这件事的意义不在于「省了显存」，而在于它把服务引擎的调度问题变成了可以真正做批处理的问题：块可以共享（前缀缓存）、可以换出、可以在 prefill 与 decode 之间搬迁。此后 vLLM 的几乎所有能力都是在这个内存模型上长出来的——连续批处理、分块 prefill、前缀缓存、P/D 分离，缺了分页这一层都要重新设计。

吞吐从哪来：调度、图、算子三层同时压

README 把性能来源列得很直白，可以按三层读：

层	手段	它省掉的是什么
调度	连续批处理、分块 prefill、前缀缓存、prefill/decode/encode 分离	GPU 空转与重复计算：长 prefill 不再一次性阻塞整批 decode，命中前缀的请求直接跳过重算
执行图	piecewise 与 full CUDA/HIP graph、torch.compile 自动算子生成与图级变换	Python 与 kernel launch 的每步开销，小 batch 下尤其致命
算子	注意力核：FlashAttention、FlashInfer、TRTLLM-GEN、FlashMLA、Triton；GEMM/MoE 核：CUTLASS、TRTLLM-GEN、CuTeDSL	访存与算术强度上的浪费；MoE 的分组 GEMM 单独优化

值得单独点出的是「注意力核可插拔」这件事。vLLM 不再坚持一套自研核，而是把 FlashInfer、TRTLLM-GEN、FlashMLA 都接进来按模型与硬件选路——这等于承认推理栈的算子层已经分化成多个专业项目，引擎的价值在编排而不在独占。投机解码同样给了四条路：n-gram、suffix、EAGLE、DFlash，前两条零训练成本（从上下文里猜），后两条要草稿模型或多 token 预测头。

精度与并行：把「便宜」做成可选项

量化支持列表几乎覆盖了当前所有主流方案：FP8、MXFP8/MXFP4、NVFP4、INT8、INT4、GPTQ/AWQ、GGUF、compressed-tensors、ModelOpt、TorchAO。GGUF 在列意味着 llama.cpp 生态的量化权重可以直接被服务引擎吃下，两条原本分开的路线（本地推理与集群服务）在权重格式上打通了。

并行维度给到五个：张量、流水线、数据、专家、上下文并行。专家并行（EP）是 MoE 时代的必需品——DeepSeek-V3 这类模型的专家数远超单卡可容纳的规模，没有 EP 就没法在集群上摊开；上下文并行则服务于长上下文，把序列切开分到多卡。分布式推理的这五个旋钮，加上 P/D 分离，构成 vLLM 在机架级部署上的完整答案。

接口与生态：兼容层做得比功能层还宽

服务端提供 OpenAI 兼容 API，另加 Anthropic Messages API 与 gRPC。同时兼容两家协议是务实的选择：agent 框架的客户端代码通常按其中一家写死，引擎多支持一种协议，迁移成本就少一层。结构化输出走 xgrammar 或 guidance，工具调用与推理内容各有专门的 parser，多 LoRA 支持覆盖 dense 与 MoE 层。

模型架构支持 200+，README 按类别列了：decoder-only（Llama、Qwen、Gemma）、MoE（Mixtral、DeepSeek-V3、Qwen-MoE、GPT-OSS）、混合注意力与状态空间模型（Mamba、Qwen3.5）、多模态（LLaVA、Qwen-VL、Pixtral）、embedding 与检索（E5-Mistral、GTE、ColBERT）、奖励与分类模型（Qwen-Math）。奖励模型在列不是顺手加的——它是 RL 后训练闭环里的打分器，说明 vLLM 把自己定位成训练与推理共用的那一层。

硬件覆盖面同样是清单式的：NVIDIA、AMD、Intel GPU 与 x86/ARM/PowerPC CPU 为一等公民，另有插件支持 Google TPU、Intel Gaudi、IBM Spyre、华为昇腾、Rebellions NPU、Apple Silicon、沐曦 GPU。贡献者超过 2000 人，来自数十家学术机构与公司。

它在 LLM 栈里的位置

按本站 llm 域的判据——「换掉它，模型的智力或每 token 成本会变」——vLLM 属于后者，而且是当前开源服务栈里默认被拿来对比的那一个。它与 SGLang 的差异更多在重心：SGLang 把 RadixAttention 的前缀复用与大规模专家并行做成招牌，vLLM 的强项是架构兼容面、硬件插件生态与作为 RL rollout 后端的通用性。两者都在给对方的设计做补充实现，谁也没有把对方甩开。

需要注意的是，README 里的「state-of-the-art serving throughput」是项目自述，没有给出统一的对比条件；跨引擎的吞吐数字高度依赖模型、并行配置、批大小与输入输出长度分布。本站只把它标为厂商/项目宣称，真实选型应在自己的负载上跑 benchmarkserving。