状态：草稿 (2026-10-27)，包含部分实测数据。 功能列表与参数基于 vLLM 0.32.0 的官方文档（仓库
docs/)以及 0.8.0 到 0.32.0 的发布说明，于 2026-10-27 直接查阅确认。实测使用 0.31.0 (2026-10-05 发布) 官方容器进行。由于 0.32.0 镜像需要重新下载故未采用，两版文档存在差异的地方已在各文章中注明。 2026-10-27 补充。 获得批准后，我们拉取了 vLLM 0.32.0 镜像以及 Qwen3-0.6B、Qwen3-0.6B-GPTQ-Int8、Qwen3-4B-AWQ、Qwen3-VL-2B-Instruct 进行了重新测试。我们在 3.1 节中加入了两版对比，并在各篇中增设了「2026-10-27 重新测算」小节。0.31.0 的数据予以保留。 编写规则：以实测数据为基础，无法测量的标为「未实测」，未确认的标为「未确认」。
目录
1. 本系列涵盖内容
vLLM 是一个大语言模型推理服务引擎。虽然它以 PagedAttention (Kwon et al., SOSP 2023) 起家，但现在它拥有非常多的功能，涵盖调度器、缓存、解码加速、输出强制、量化、多 GPU 以及运维工具。本站已经有多篇关于 vLLM 的文章。
- 「LLM KV 缓存解剖」：KV 缓存原理、PagedAttention、连续批处理、前缀缓存、LMCache、NVIDIA Dynamo
- 「Toss ML/AI Infra 筹备」：vLLM 内部架构（第 4 篇）、与 SGLang 对比（第 5 篇）、1.7B 模型负载测试（第 14 篇）、LoRA（第 15 篇）、Dynamo 实战（第 24 篇）、OpenTelemetry（第 25 篇）
本系列专注于填补这些文章未涵盖的功能。重叠的功能将简要总结并链接至先前的文章。
| 篇 | 涵盖功能 | 实测 |
|---|---|---|
| 1 | 功能地图、版本变化 | 汇总 |
| 2 | 连续批处理、chunked prefill、前缀缓存、cache_salt | 重复测量、关闭功能的基准线 |
| 3 | 投机解码（n-gram、EAGLE、MTP、suffix） | n-gram 两种实现、草稿长度、并发度 |
| 4 | 结构化输出（xgrammar、guidance） | 正确性、首次请求成本、每个 Token 成本 |
| 5 | 工具调用（解析器、tool_choice、strict） | Schema 遵循率 |
| 6 | 量化（FP8、AWQ、GPTQ、KV FP8） | 在线 FP8、困惑度 |
| 7 | KV 卸载与分离服务 | CPU 卸载 |
| 8 | 休眠模式、启动时间、/metrics、认证 | 休眠、编译缓存、按路径认证 |
| 9 | 并行化、多模态、池化、LoRA | 仅限嵌入与重排序 |
2. 功能地图
「节省开销」指该功能减少的成本，「划算条件」指在实测或文档中表现出效果的条件。
| 功能 | 原理（论文） | 开启参数（0.31·0.32） | 默认 | 节省开销 | 划算条件 | 不划算条件 |
|---|---|---|---|---|---|---|
| PagedAttention | 将 KV 分块（Kwon et al., SOSP 2023） | 始终 | 开启 | KV 内存浪费 | 请求长度各不相同时 | 不适用 |
| 连续批处理 | 步级调度（Yu et al., OSDI 2022） | --max-num-seqs |
256 | 批处理中的空闲槽位 | 并发请求较多时 | 只有一个请求时 |
| chunked prefill | 拆分 Prefill 并与 Decode 混合（Sarathi） | --max-num-batched-tokens |
开启，2,048（适用于小于 70GB 的 GPU 服务器） | Decode 停顿时间 | 长输入与 Decode 混合时 | 只有短输入到来时 |
| 前缀缓存 | 通过块哈希复用 KV | --enable-prefix-caching |
开启 | Prefill 计算 | 公共前缀较长且频繁到来时 | 前缀每次都不同时 |
| cache_salt | 对首个块哈希加盐 | 请求的 cache_salt |
无 | 租户间时序泄漏 | 多客户共用一个引擎时 | 单用户 |
| 投机解码 | 一次性验证草稿（Leviathan et al., ICML 2023） | --speculative-config |
关闭 | Decode 步数 | 并发较低且输出可预测时 | 高并发、随机输出 |
| 结构化输出 | Token 掩码（XGrammar, MLSys 2025） | response_format, structured_outputs |
auto | 格式错误 | 机器可读的输出 | 自由文本 |
| 工具调用 | 解析器 + 结构标签 | --enable-auto-tool-choice --tool-call-parser |
关闭 | 调用解析错误 | 智能体 | 不具备工具调用能力模型 |
| 权重量化 | FP8、AWQ、GPTQ | --quantization |
无 | 权重内存与读取 | 低并发、大模型 | 大批处理 |
| KV 量化 | KV FP8 | --kv-cache-dtype fp8 |
auto（模型精度） | KV 内存 | KV 不足时 | KV 充足时 |
| 多 LoRA | 适配器批处理计算（Punica、S-LoRA） | --enable-lora --max-loras |
关闭 | 模型数量 | 存在多个适配器时 | 只有一个适配器时 |
| KV 卸载 | KV 连接器，CPU 层 | --kv-offloading-size |
关闭 | 重新计算被挤出的前缀 | GPU KV 不足且存在复用时 | 无复用时 |
| 分离式服务 | Prefill 与 Decode 分离（DistServe, OSDI 2024） | --kv-transfer-config（NIXL 等） |
关闭 | 尾部 ITL | 快速的 GPU 间互联 | 慢速连接，吞吐量目标 |
| 并行化 TP·PP·DP·EP | Megatron-LM 等 | --tensor-parallel-size 等 |
1 | 单张 GPU 的极限 | 模型放不下时 | 模型能放下时 |
| 睡眠模式 | CuMem 分配器 | --enable-sleep-mode + 开发模式 |
关闭 | 重启时间 | 轮流使用 GPU 时 | 常驻服务 |
| 多模态·池化 | 编码器，LAST/CLS 池化 | 依模型而定， --runner pooling |
依模型而定 | 独立服务器 | 使用相同引擎统一 | 当专用引擎更快时 |
兼容 OpenAI 的 API（/v1/completions, /v1/chat/completions, /v1/embeddings, /v1/responses 等）与 /metrics 与其说是一个功能，不如说是所有这一切的入口，因此将其从表中移除了。本系列的所有测量都是通过此 API 进行的，指标汇总在第 8 篇中。
某些功能之间可能无法同时使用。在 0.32.0 文档的兼容性表中，投机解码无法与 LoRA、池化以及提示词嵌入输入一起使用（❌）。在实际测量期间，0.31.0 在开启 n-gram 投机解码时发出了警告：“关闭异步调度”、“Model Runner V2 尚不支持 ngram，将回退到 V1 执行器”。
3. 实测值汇总
全部在单张 8GB 级别笔记本 GPU（Ada 架构）、vLLM 0.31.0、Qwen3-Reranker-0.6B（bf16，针对重排微调的 0.6B 因果语言模型）、容器内存限制 4GiB 或 4.5GiB 的环境下测得。相同条件重复三到四次并取中位数，启动服务器后的第一批次作为预热予以剔除。
| 功能 | 条件 | 结果（中位数） |
|---|---|---|
| 连续批处理 | 并发 16，输入 256·输出 128 | 单任务 174.6 tok/s → 基础 1,683.1 tok/s（9.6倍） |
| 分块预填充（chunked prefill） | 解码期间输入 3,700 个 Token | 解码最大暂停 512 Token 分块 35.6ms，基础 109.8ms，关闭分块 197.6ms |
| 前缀缓存 | 3,200 个 Token 公共部分 | 首 Token 174.7ms → 18.9ms，关闭时 173.8ms |
| cache_salt | 相同前缀，不同 salt | 不同 salt 的缓存为 0 Token，173.7ms |
| n-gram 投机解码 | 并发 1，文本复制 | 176.4 → 704.1 tok/s（4 个建议，4.0 倍），8 个建议 1,117.0 tok/s（6.3 倍），接受率 96% 以上 |
| n-gram 投机解码 | 并发 1，随机输出 | 提示词集中接受率较低的一个变慢 10%（171.4 → 153.6 tok/s）。并发 32 时吞吐量下降 14% |
| 结构化输出 | JSON Schema，并发 16 | 正确 JSON 46/48（错误的 2 个是因为长度超限），无此功能则为 0/48。首次请求 446ms（xgrammar） |
| 工具调用 | required，无/有 strict | 符合 Schema 0/5 → 5/5，但值不正确 |
| FP8 在线量化 | 并发 1/16/64 | 吞吐量 1.36/1.24/1.08 倍，权重 1.12 → 0.71GiB |
| KV CPU 卸载 | 被挤出的 1,600 个 Token 前缀 | 重新计算 77.3ms → CPU 中 35.1ms（GPU 命中 14.0ms） |
| 睡眠模式 | 阶段 2，阶段 1 | 阶段 2：GPU 6,168 → 606MiB，唤醒 0.39 秒（重启 32 秒），输出相同。阶段 1：容器 OOM 两次 |
| 启动时间 | 相同配置重启 | 65 秒 → 32 秒（编译缓存） |
| 认证 | --api-key |
/v1/* 401, /invocations 200（执行生成） |
| 嵌入·重排 | 64 个句子，32 个文档 | 371.8ms，33.9ms |
未能测量的是张量并行、流水线并行、数据并行、专家并行（单张 GPU）、分离式服务（同理），以及 EAGLE、MTP、suffix 投机解码。EAGLE 因包含草稿权重（采用自有许可证的 pickle 格式）、suffix 需要额外软件包，故决定放弃测试。初版中未测量的多模态输入以及 AWQ·GPTQ 已在第 3-1 节的重新测量中完成。
3-1. 2026-10-27 重新测量：0.32.0 与对话模型
| 功能 | 2026-10-27 0.31.0 测量（重排 0.6B） | 0.32.0 重新测量 |
|---|---|---|
| 连续批处理·分块·前缀缓存 | 9.6 倍，109.8ms，174.7 → 18.9ms | 使用相同模型，差异在 1.5% 以内（1,683.6 tok/s，108.2ms，175.2 → 18.9ms） |
认证(/invocations) |
无密钥 200 | 无密钥 200（保持不变） |
| 睡眠模式阶段 2·阶段 1 | 唤醒 0.39 秒，阶段 1 容器 OOM | 唤醒 0.41 秒，阶段 1 再次 OOM |
| n-gram 投机解码 | 复制 4.0 倍，贪婪输出 10/12 相同，KV 减少 23% | Qwen3-0.6B：复制 3.7 倍，返回代码 3.1 倍， 解释说明 0.97 倍（接受率 3%），贪婪输出 12/12 相同，KV 减少 2%（V2 执行器） |
| 结构化输出 | 无强制时正确 JSON 0/48 | Qwen3-0.6B：即使没有强制，数值也 18/18 正确，但由于代码围栏导致无法直接读取 0/18，强制后为 18/18 |
| 工具调用 | 无 strict 时符合 Schema 0/5 | Qwen3-0.6B·GPTQ·4B AWQ：包括 auto 在内，36/36 城市与单位全部正确 |
| 量化 | FP8 1.36倍 | Qwen3-0.6B: FP8 1.37倍，GPTQ 8-bit 1.40倍（困惑度 -1.4%·+1.6%）。4B AWQ 在 8GB 上达每秒 80 Token |
| 多模态 | 未实测 | VL-2B 默认配置因 KV -0.07GiB 启动失败，大小提示 KV 2.13GiB。896px 图像 808 Token·首 Token 238ms，同图再次 32.7ms。默认配置会实际拉取内部地址 |
本次测量的局限性
- 首次测量的模型无法对话。 由于决定不重新下载、只使用已有的权重，最初将 Qwen3-Reranker-0.6B 用作生成模型（第 3.1 节的重新测量使用的是对话用的 Qwen3-0.6B）。由于它是针对重排（「yes/no」判定）微调的模型，通过聊天询问时几乎只会回答「No.」，如果要求长文本输出，往往会重复相同的话。虽然这对吞吐量、延迟、内存等与内容无关的测量没有问题，但工具调用和结构化输出的「内容」、推测解码的接受率可能会与通用对话模型有所不同。我们在文章各处都记录了这一点。
- 小模型，小 GPU。 0.6B 模型在耗时中固定成本（内核执行、调度）占比很大，在大模型中这一比例会有所不同。
4. 各版本变更
vLLM 大约每两周发布一个版本。阅读旧文或迁移旧配置时，我们仅挑选了需要注意的变化（在发行说明中确认）。
| 版本 | 变更内容 |
|---|---|
| 0.8.0 | V1 引擎成为默认 |
| 0.10.0 | 开始清理 V0 引擎代码（移除 V0 的推测解码 worker 等） |
| 0.11.0 | 完全移除 V0 引擎。引入 CPU KV 换页卸载（LRU）。前缀缓存哈希默认改为 sha256（文档标准） |
| 0.12.0 | guided_json 等 guided_* 请求字段移除， structured_outputs 统一为 |
| 0.14.0 | 异步调度（重叠引擎调度与 GPU 执行）成为默认 |
| 0.19.0 | 通用 CPU KV 卸载（策略可替换） |
| 0.21.0 | 使用 xgrammar 结构标签进行 strict 工具调用 |
| 0.28.0 | 大 GPU 的 max_num_batched_tokens 默认 8,192 → 16,384 |
| 0.29.0 | Model Runner V2 成为所有模型的默认 |
| 0.31.0 | 在线量化 --quantization fp8 迁移至 fp8_per_tensor （实测中确认了警告） |
| 0.32.0 | max_tokens 不再从上下文中预先剔除（长 Prompt 不再被拒绝）。默认 CORS 为「无允许」。移除了级联注意力。结束支持 Python 3.10。拒绝嵌套超过 64 层的 JSON Schema。MRV2 引入 GPU n-gram 提案器 |
从 V0 过渡到 V1 时也有一些功能消失了。0.32.0 的 V1 指南将 best_of、按请求的 Logit 处理器、GPU↔CPU KV 交换（抢占时换页）、按请求的结构化输出后端标记为「已移除」。V1 的抢占默认不是换页，而是重新计算（RECOMPUTE）。
5. 从哪里开始看
- 如果吞吐量不足：第 2 篇（批处理与 Chunk）、第 6 篇（量化）、第 7 篇（卸载）
- 如果单人响应速度重要：第 3 篇（推测解码）、第 6 篇（量化）
- 如果要构建智能体：第 4 篇（结构化输出）、第 5 篇（工具调用）
- 如果要运维服务器：第 8 篇（休眠、启动、指标、认证）
- 如果模型放不进 GPU：第 9 篇（并行化）、第 6 篇（量化）
参考
- vLLM 文档 (0.32.0)：https://docs.vllm.ai/en/latest/ ，仓库中的
docs/features/,docs/configuration/,docs/usage/ - vLLM 发行说明 0.8.0~0.32.0：https://github.com/vllm-project/vllm/releases
- Kwon 等人，“Efficient Memory Management for Large Language Model Serving with PagedAttention”，SOSP 2023. https://arxiv.org/abs/2309.06180
- Yu 等人，“Orca: A Distributed Serving System for Transformer-Based Generative Models”，OSDI 2022.
- Leviathan 等人，“Fast Inference from Transformers via Speculative Decoding”，ICML 2023. https://arxiv.org/abs/2211.17192
- Dong 等人，“XGrammar”，MLSys 2025. https://arxiv.org/abs/2411.15100
- Zhong 等人，“DistServe”，OSDI 2024. https://arxiv.org/abs/2401.09670
- 往期系列：LLM KV 缓存剖析、Toss ML/AI Infra 准备工作