vLLM

vLLM 是一个用于快速且内存高效的大语言模型推理和服务的开源库。它由 Woosuk Kwon、Zhuohan Li、Siyuan Zhuang 及其合作者于 2023 年在加州大学伯克利分校 Sky Computing Lab 创建，现已捐赠给 PyTorch Foundation 以确保中立的治理。它解决的核心问题是 LLM 服务期间的 GPU 内存碎片化：在 vLLM 出现之前，推理服务器通过为每个序列分配连续的内存块，浪费了 60-80% 的预留 KV 缓存内存。vLLM 的 PagedAttention 算法借鉴了操作系统的虚拟内存分页技术，将 KV 缓存存储在非连续的页面中，将浪费降至接近零，并允许在相同硬件上运行多得多的并发序列。

该库自带兼容 OpenAI 的 REST API 服务器，支持迭代级别（而非请求级别）的连续批处理（continuous batching）、用于多 GPU 和多节点部署的张量与流水线并行、投机解码（speculative decoding），并原生支持 GPTQ、AWQ、INT8 和 FP8 等量化格式。通过集成 HuggingFace Transformers，它支持数百种模型：Llama 3.x、Mistral、Mixtral、Qwen、DeepSeek、Gemma、Phi，以及 LLaVA 和 Pixtral 等视觉语言模型。2025 年 1 月的 v1 架构重写将调度器与工作循环解耦，带来了更清晰的内部结构和更好的生产部署性能分析工具。vLLM 可在 NVIDIA、AMD ROCm、Intel Gaudi 和 AWS Trainium 硬件上运行。

2026 年 4 月的 vLLM 实际表现

vLLM 的任务是以使生产部署在经济上可行的吞吐量水平来提供开源 LLM 服务。其核心机制是 PagedAttention 加上连续批处理。PagedAttention 将 KV 缓存存储划分为固定大小的“页面”，并通过块表进行管理，从而消除了为每个序列的最大可能长度预分配连续内存区域所带来的碎片化。连续批处理意味着引擎会在一个序列完成时立即将新请求插入到活动批次中，从而保持较高的 GPU 利用率，而不是等待整个批次排空后再开始下一个批次。

正如 SOSP 2023 论文中所记录的，其结果是，与相同硬件上原生的 HuggingFace Transformers 服务循环相比，吞吐量提高了高达 24 倍。在实际应用中：单张 A100 80GB 运行 Llama 3.1 8B 可以在可接受的延迟下处理大约 200 个并发流式用户，而原生循环可能在 10-20 个用户时就会饱和。

启动服务器只需一条命令：vllm serve meta-llama/Llama-3.1-8B-Instruct --tensor-parallel-size 1。随后，服务器会暴露符合 OpenAI API 规范的 /v1/chat/completions 和 /v1/completions 端点。任何使用 OpenAI Python 客户端的现有应用程序只需更改基础 URL 和 API 密钥，即可重定向到 vLLM 服务器，无需进行其他代码更改。平台工程师将这种兼容性视为最大的采用驱动力，因为它消除了从原型到自托管生产环境的迁移障碍。

除了服务器之外，vLLM 还为批处理作业提供了离线推理 API。处理 100,000 个分类补全的数据科学团队可以加载一次模型，并对提示列表运行 LLM.generate() 调用，实现比顺序 API 调用高 5-10 倍的吞吐量。Together AI 的团队在延迟不如每 Token 成本重要的大规模批量推理作业中使用了这种途径。

“切换到 vLLM 后，我们在相同的硬件上从服务大约 20 个并发用户增加到了 200 多个。连续批处理确实彻底改变了我们的推理成本。” - u/ml_infra_eng，Reddit r/LocalLLaMA，2023 年 11 月

“vLLM 是 Together AI 大部分推理技术栈的动力源泉。仅 PagedAttention 一项就将我们在长上下文请求上的 KV 缓存内存使用量减少了约 55%，而这正是我们利润空间被挤压得最严重的地方。” - Tim Dettmers，推理团队，Together AI 工程博客，2024 年 2 月

vLLM 与 TGI 和 SGLang 的定位对比

2026 年部署最广泛的三大开源推理引擎是 vLLM、HuggingFace TGI 和 SGLang。它们有着共同的目标，但在机制上的差异对特定工作负载至关重要。

vLLM vs. TGI (Text Generation Inference)：HuggingFace TGI 拥有更简单的 Docker 优先入口点。标准部署只需一条带有模型 ID 的 docker run 命令。TGI 在 2024 年的 v2 版本中添加了对 PagedAttention 的支持，缩小了吞吐量差距。然而，vLLM 的连续批处理在更细的粒度上运行：它在每个解码步骤将新 Token 插入活动批次，而 TGI 在某些配置下的批处理级别较粗。在 Llama 3 70B 4 位量化的社区基准测试中（r/LocalLLaMA，2024 年 11 月），在高并发工作负载下，vLLM 的输出 Token 吞吐量通常比 TGI 高 15-25%。TGI 的优势在于 HuggingFace Hub 集成、具有较低 Python 开销的 Rust 后端服务器，以及需要较少配置的部署流程。对于已经深入 HuggingFace 生态系统的团队来说，TGI 是自然的首选。对于在大规模下优化原始吞吐量的团队，vLLM 通常胜出。

vLLM vs. SGLang：来自 LMSYS 团队的 SGLang 引入了 RadixAttention：在共享公共前缀的请求之间共享 KV 缓存。在实践中，这意味着 1,000 个并发用户使用的 2,000 个 Token 的系统提示只需计算和缓存一次，而不是 1,000 次。在智能体（Agentic）工作负载、多轮对话和具有共享前缀的批量推理中，与 vLLM 相比，SGLang 的 RadixAttention 可以将首个 Token 延迟（time-to-first-token）减少 50-80%。vLLM 添加了自己的前缀缓存以缩小这一差距，但 SGLang 的实现仍然更加成熟。vLLM 拥有明显优势的地方在于：模型支持的广度（数百种对比较窄的列表）、多节点流水线并行工具、量化格式覆盖范围，以及围绕它的生产运维社区的规模。特别是对于智能体 AI 工作负载，请考虑 SGLang；对于需要最大模型兼容性的通用服务，vLLM 仍然是默认选择。

第三个竞争对手是 NVIDIA 的 TensorRT-LLM，它将模型编译为优化的 CUDA 图，并在 NVIDIA 硬件上实现更高的峰值吞吐量。代价是运维成本：TensorRT-LLM 模型编译每种 GPU 类型每个模型需要 30-60 分钟。而 vLLM 在不到一分钟内即可从磁盘加载模型。对于运行许多模型或频繁迭代的团队来说，vLLM 的运维简便性具有决定性优势。只有在大规模固定模型上压榨峰值每秒 Token 数时，TensorRT-LLM 的编译成本才值得。vLLM 还在 AMD ROCm、Intel Gaudi 和 AWS Trainium 上运行；而 TensorRT-LLM 仅限 NVIDIA。

部署的实际情况

典型的生产部署包括选择 GPU 实例（较小模型使用 A10G，70B+ 模型使用 A100/H100），通过 pip 安装 vLLM，并运行 serve 命令。对于 4 张 A100 上的 70B 模型，命令中需添加 --tensor-parallel-size 4。首次运行时，模型权重会从 HuggingFace Hub 下载，然后缓存在本地。70B 模型的冷启动需要 3-8 分钟，具体取决于存储速度。对于需要缩容到零的服务来说，这种延迟是一个真正的限制。

多节点部署（跨多台服务器的流水线并行）需要 Ray 或自定义的分布式后端。大多数团队报告在 Ray 集群设置上耗费了数小时。vLLM 文档对此有充分的介绍，但故障模式（网络配置、NCCL 错误、Ray 仪表板混乱）的记录并不完善。成功完成部署的工程师建议首先运行单节点设置，验证模型行为，并在基线稳定后再添加节点。

对于希望完全避免基础设施管理的团队，可以在 Modal、Replicate 和 Together AI 上使用基于 vLLM 的托管端点，它们都提供相同的兼容 OpenAI 的 API，按 Token 计费且无需服务器管理。代价是成本和数据驻留：在您自己的 GPU 上自托管在大规模下更便宜，并且可以将数据保留在本地。

2025 年 1 月的 v1 架构带来了更清晰的内部结构，但也引入了一些自定义模型注册方面的破坏性更改。运行修改后的注意力层或非标准架构的团队在从 v0.x 升级时遇到了阻力。维护者发布了迁移指南，但拥有高度定制部署的团队还是花了几天时间进行调试。尽管如此，对于标准模型服务，社区反馈对 v1 升级普遍持积极态度。

vLLM 适合哪些人

vLLM 是基础设施软件，而不是面向用户的产品。它是为拥有 GPU 硬件访问权限、熟悉 Python 和 Linux 环境，并且需要以能够证明基础设施成本合理的吞吐量来提供开源语言模型服务的机器学习工程师和平台团队构建的。

最适合的用例：构建供内部使用的私有 LLM API 的企业（数据保留在本地，无供应商依赖）；发现商业 API 推理成本过高，希望转而运行较小的微调模型的团队；需要对大批量文本进行推理以进行实验的研究实验室；在开源模型之上构建产品，且利润空间要求自托管的初创公司。

对于已经通过 GUI 在本地使用开源模型的团队来说，将 vLLM 与聊天界面配对非常简单。AnythingLLM 和类似的前端可以指向本地 vLLM 服务器。对于希望获得开箱即用的本地模型体验而无需配置服务器的用户，Ollama 是更好的起点。一旦吞吐量和并发性成为首要关注点，而不是首次运行的便捷性，vLLM 就是合适的工具。以商业规模部署开源模型权重的团队（例如那些可能已经在 Llama 系列架构上运行模型的团队）会发现 vLLM 是最成熟的生产选项。

vLLM 不是什么

vLLM 不原生支持 Windows。用户必须使用 WSL2 或 Docker，这增加了本地开发的阻力。它不是 GUI 应用程序、聊天界面，也不是 LM Studio 风格的模型管理工具。它不微调模型。它不提供内置的速率限制、身份验证或计费功能：这些需要像 LiteLLM 这样的代理层。它不是托管服务；该项目本身没有“vLLM Cloud”。需要完全托管的推理 API 且不承担基础设施责任的团队应考虑 Replicate 或 Together AI（其内部运行 vLLM）。对于评估是自托管还是使用托管 API 的工程师来说，一旦流量达到 GPU 实例成本低于按 Token 计费的 API 费用的规模（通常在每天 100 万到 1000 万个 Token 之间，具体取决于模型大小和云提供商），vLLM 就会使天平向自托管倾斜。