深度介绍
官方把 vLLM 定位为「高吞吐、内存高效的大模型推理与服务引擎」，关键在于把 KV 缓存当作分页内存来管理：KV 缓存被切成固定大小的块（标准 Transformer 默认 16 个 token 一块），调度器通过块表记录每个请求占用了哪些块，请求结束后块会归还给空闲块池。这样既避免了为每条序列预留最大长度造成的显存浪费，也让不同长度的请求能共享同一片显存。配合连续批处理（continuous batching），新请求可以在老请求生成过程中随时插入，引擎把一次前向里的所有序列压平成一条「超级序列」，靠位置索引与注意力掩码保证各自只看自己的 token，从而不必右填充。
vLLM V1 的调度器可以在同一个引擎步里混合处理预填充（prefill）与解码（decode）请求，V0 时代则只能一次跑一种。官方文档描述的顺序是先处理 running 队列里已在解码的请求，再处理 waiting 队列里的新请求，每步都有 token 预算上限；当长提示词超过 long_prefill_token_threshold 时，预填充会被切成多个小块执行，避免一条超长请求独占整个引擎步、把其他请求全部推迟。显存不够时引擎会触发抢占，把优先级低或暂时无块可用的请求换出并回收其 KV 块。预填充算力受限、解码带宽受限，这两类负载的差异正是后面要讲的 PD 分离的动机。
前缀缓存默认开启：引擎把完整块内的 token 片段做哈希（可选用更慢但碰撞更少的 SHA-256），哈希链里带上上一块的哈希，命中即可直接复用已算好的 KV 块，不再重复计算共享的前缀。对 RAG、多轮对话、Agent 这类「同一段系统提示词反复出现」的场景，收益主要体现在首 token 延迟上。另一层优化在 GPU 侧：除非显式加上 --enforce-eager，引擎会在初始化时对若干预热批量做一次空跑并捕获 CUDA Graph，之后前向直接重放预录好的图，省掉大量内核启动开销，官方文档在 V1 说明中把 CUDA Graphs 与分块预填充列为与 V0 的主要差异之一。
vLLM 既可以在 Python 里离线批量推理（from vllm import LLM），也可以起一个与 OpenAI 接口兼容的服务端，让现有应用几乎不改代码就切换过来。官方文档里这块的覆盖很细：结构化输出（guided decoding，靠语法有限状态机约束 logits）、工具调用、推理内容输出、多模态输入、语音转文字都有专门章节与示例。集成方面官方单独列出了 Claude Code、Codex、LangChain、LlamaIndex 的接入方式，部署侧则给出 Docker、Kubernetes、Nginx、KServe、NVIDIA Triton、llm-d、Production Stack 等一整套路径，并配套 Prometheus / Grafana 与 OpenTelemetry 的指标方案。
推测解码用小模型或轻量结构先猜若干个 token，再由大模型一次性验证，接受部分候选，从而在一次前向里产出多个 token。官方博客在剖析文章里说明 V1 引擎没有沿用「外挂一个小的 draft 语言模型」的做法，而是实现了更快的方案：n-gram（在历史序列里找匹配片段续写）、EAGLE 式的模型手术、Medusa 式的多头并行预测。文档目录现在把推测解码拆得很细，包括 EAGLE 草稿模型、MLP 草稿模型、并行草稿模型、MTP 多 token 预测、N-gram 推测、后缀解码与自适应验证，另有独立的 Speculators 项目用于训练与共享草稿模型，并给出按请求统计的接受率指标。
量化是压低部署成本最直接的手段，官方文档给出的路径包括 LLM Compressor 的 FP8 W8A8、INT4 W4A16、INT8 W8A8 / W4A8，以及 AWQ、GPTQModel、BitsAndBytes、GGUF、TorchAO、AMD Quark、NVIDIA ModelOpt、Intel INC 等格式与后端；除权重量化外还支持量化 KV 缓存，官方另有一篇研究对比了 TurboQuant 系列 KV 量化与 BF16、FP8 的表现，结论是 FP8 仍是默认选择。显存管理上还有 KV 缓存分层卸载（主机内存、文件系统、对象存储）与休眠模式等机制。面向 MoE 模型，文档提供专家并行、弹性专家并行与注意力-FFN 分离（AFD）插件等方案，让大规模稀疏模型可以在多卡上按需扩缩。
官网的「通用兼容」一节把支持面列得很清楚：NVIDIA CUDA、AMD ROCm、Intel XPU / Gaudi / CPU、Google Cloud TPU、华为昇腾 NPU、AWS Neuron、IBM Spyre、Apple Silicon、百度昆仑芯与寒武纪 MLU 都在列，其中不少通过独立仓库（如 vllm-ascend、vllm-neuron、tpu-inference、vllm-metal）维护。扩展方式涵盖张量并行、流水线并行、数据并行、上下文并行与专家并行，长上下文场景下官方介绍过解码上下文并行能把 KV 缓存按序列维度切分、换来约 3 倍吞吐。推理与解码分离（PD 分离）通过连接器把预填充实例与解码实例拆开，官方文档列出的实现包括 NIXL、Mooncake、MORI-IO 等，适合对首 token 延迟与生成间隔都有硬指标的服务。
围绕引擎本体，官方列出了成体系的周边项目：AIBrix 负责 K8s 上的 AI 基础设施，Production Stack 提供生产部署参考实现，llm-d 是分布式推理栈的集成方案，LLM Compressor 管量化，Speculators 管草稿模型，GuideLLM 做性能评测，Semantic Router 做智能路由，vLLM Omni 覆盖图像、视频、语音等全模态模型，另有社区维护的 vLLM Playground 网页界面。官方还提供 recipes.vllm.ai 的示例配方、perf.vllm.ai 的性能仪表盘和 roadmap.vllm.ai 的路线图，版本上维持约两周一个发布的节奏，并按日产出 nightly wheel，便于先在小规模环境验证再升级生产。
产品特点
官方文档写明 vLLM 最初在加州大学伯克利分校 Sky Computing Lab 开发，如今由 2000 多名贡献者、数十家学术机构与企业共同维护，并被列为 PyTorch Foundation 旗下项目。官网把算力赞助方、现金捐赠方（含 a16z、红杉等）与 Slack 赞助方都单独列出，治理与资金结构相对透明，这也是它被大量生产环境采用的原因之一。
多数推理框架是「先跑通再说」，vLLM 的差异化在于把操作系统里的分页内存思想搬到 KV 缓存上：块表、空闲块队列、块哈希与引用计数共同支撑起前缀缓存与抢占逻辑，官方设计文档里对 Paged Attention、Hybrid KV Cache Manager、注意力后端特性矩阵都有成篇说明，工程细节可查、可复现。
V1 引擎替换了 V0（已标注废弃），把预填充与解码合并进统一调度器并默认启用分块预填充；2026 年 3 月官方又发布 Model Runner V2，重写执行核心的模型逻辑与输入准备，声称在不改动 API 的前提下提升吞吐。对使用者来说，这意味着升级能拿到性能红利，但也需要跟紧版本说明，避免踩到被移除的旧参数。
官方把性能数字放在博客与仪表盘里，而不是只写营销文案：例如 2026 年 5 月 11 日宣布在 Artificial Analysis 榜单上取得领先，8 月 6 日公布 Qwen3.5 在 GB200 NVL72 上达到每卡 25K 总 TPS，9 月 21 日给出 Qwen3.8-2.4T 在 GB300 NVL72 上的 PD 分离服务实践。这些文章都附了复现步骤与配置，便于按自己的硬件对照评估。
最近动态
PyPI 记录显示，2026 年 9 月 9 日 vLLM 发布 0.29.0；此前的节奏是 8 月 26 日 0.28.0、8 月 10 日与 11 日的 0.27.0 / 0.27.1、7 月 25 日 0.26.0。官方在 2026 年 7 月 16 日的博客里介绍过发布流程：多加速器 CI、夜间性能与精度基准，加上约两周一次的发版，是项目保证生产可用性的主要手段。
2026 年 9 月 21 日官方博客发布《PD Serving of Qwen3.8-2.4T》，介绍在 GB300 NVL72 上用预填充/解码分离的部署方式，在 2.4 万亿参数规模的混合 MoE 模型上取得官方所述 5K 级吞吐与 180 级交互性，并给出了自行复现的步骤。这类文章是判断「大模型能否在自己的集群上跑得动」的重要参考。
2026 年 9 月 13 日官方博客总结 Kimi K3 在 vLLM 中的一系列优化，涉及调度、KDA 前缀缓存、状态恢复、PD 分离、状态卸载、并行策略、MoE 与 GPU 内核等多个层面，官方给出的结论是吞吐提升至 2.8 倍。对关心长上下文与混合架构模型的团队，这篇属于直接可用的调优清单。
2026 年 8 月 6 日官方博客公布在 GB200 NVL72 上以 Qwen3.5-397B-A17B-NVFP4 达成每 GPU 25K 总 TPS，手段包括分离式服务、Blackwell 上的门控内核、混合内存分配器的缓存传输与异步调度修复，并提供了 srt-slurm 配方；同期还有 Qwen3.8、Kimi K3、Gemma 4 等模型的 Day-0 支持公告。
vLLM 是面向大语言模型的开源推理与服务引擎，官方定位为「简单、快速、低成本的 LLM 服务」，核心卖点是高吞吐与内存高效。它最初在加州大学伯克利分校 Sky Computing Lab 开发，如今由 2000 多名贡献者与数十家机构企业共同维护，采用 Apache-2.0 许可，属 PyTorch Foundation 项目。官网给出的安装命令是 uv pip install vllm --torch-backend auto，要求 Python 3.10 以上（推荐 3.12+），PyPI 上最新版本为 2026 年 9 月 9 日发布的 0.29.0。 技术核心是把 KV 缓存按固定大小的块管理（标准 Transformer 默认每块 16 个 token），用块表与空闲块池做类似操作系统分页的内存管理，避免为每条序列预留最大长度；连续批处理让新请求在生成过程中随时插入，同一个引擎步可混合预填充与解码。前缀缓存默认开启，长提示词会被切成小块执行，显存不足时触发抢占回收，GPU 侧靠捕获与重放 CUDA Graph 降低内核启动开销。再往上还有推测解码（n-gram、EAGLE、MTP 等）、LLM Compressor 的 FP8 / INT4 / INT8 等量化格式、量化 KV 缓存与 KV 分层卸载。 服务层面提供与 OpenAI 兼容的 API 服务端与 Python 离线推理，结构化输出、工具调用、多模态输入与语音转文字均有官方章节；部署覆盖 Docker、Kubernetes、KServe、NVIDIA Triton、llm-d 与 Production Stack。硬件支持除 NVIDIA、AMD 外还包括 Intel、Google TPU、华为昇腾、AWS Neuron、Apple Silicon 等；扩展方式涵盖张量、流水线、数据、上下文与专家并行，以及把预填充与解码拆开的 PD 分离。 官方把性能数字放在博客与 perf.vllm.ai 上：2026 年 5 月宣布在 Artificial Analysis 榜单领先，8 月公布 Qwen3.5 在 GB200 NVL72 达每卡 25K 总 TPS，9 月给出 Qwen3.8-2.4T 的 PD 分离实践。生态包含 AIBrix、LLM Compressor、Speculators、GuideLLM、Semantic Router 与 vLLM Omni，版本约两周发布一次。 使用时注意：软件免费但算力需自备，成本落在 GPU 上；自建服务要自行规划显存、并行策略与故障处理，运维门槛高于直接调用云 API；官方文档设有「用法统计收集」说明页，列明收集范围与退出方式；模型权重许可与引擎许可无关，商用前需分别核对；项目迭代快，升级前先看版本说明。整体适合需要自行部署开源大模型、并把吞吐与显存效率当作核心指标的工程团队。
核验信息
本页事实来自 vLLM 官方渠道：官网 vllm.ai（定位、安装命令、支持硬件与模型、生态项目与赞助方）、官方文档 docs.vllm.ai（V1 引擎中的分块预填充、CUDA Graphs 与调度说明，OpenAI 兼容服务器、量化、推测解码、部署集成、用法统计收集页，以及首页关于起源于伯克利与 2000 多名贡献者的表述）、官方博客（各性能里程碑与发布节奏）与 PyPI 项目页（0.29.0 及历史版本发布日期）。核验时间为 2026 年 9 月 22 日。版本号、性能数字与硬件支持矩阵变化较快，请以官方最新文档为准。
vLLM介绍页面对您是否有帮助？
