📋 编辑总结
vLLM 是一个高吞吐、内存高效的大语言模型推理与服务引擎，最初由加州大学伯克利分校 Sky Computing Lab 开发，采用 Apache-2.0 协议开源。它的核心创新是 PagedAttention——像操作系统管理虚拟内存一样对 KV Cache 分页管理，大幅减少显存碎片，配合连续批处理和前缀缓存显著提升吞吐。项目已有 2000 多位贡献者，支持 200+ 模型架构，并可一行命令启动 OpenAI 兼容的 API 服务。最新稳定版 v0.31.0（2026-10-05 发布，717 个提交 / 307 位贡献者）：DeepSeek-V4.1-Flash 性能强化（FlashMLA mega attention + V4.1 NVFP4 压缩 KV cache 成为 SM100 默认、DeepGEMM 稀疏 MQA logits、Mega-…（完整更新记录见下方「版本记录」） 定价：完全免费，Apache-2.0 开源协议，无授权费用；实际成本取决于你自己的 GPU 硬件或云算力支出。编辑评分：⭐ 4.8。

vLLM 是什么？

先说一个很多人踩过的坑：你有一张 24GB 的显卡，跑一个模型，明明显存看着还剩十几个 G，却直接报 Out of Memory。原因不是显存真的不够，而是被切得七零八落——早期的推理实现会为每个请求预留一整块连续显存，用户可能只生成了 50 个 token，系统却按 2000 个 token 的量把空间锁死了。业界统计这种做法会浪费掉 60%~80% 的显存。

vLLM 就是冲着这个问题来的。它最初在加州大学伯克利分校的 Sky Computing Lab 诞生，核心创新叫 PagedAttention——思路直接借鉴操作系统的虚拟内存分页：把 KV Cache 拆成一个个小块（页），按需分配，允许存放在不连续的显存里。结果是显存浪费接近于零，同样的硬件能塞进两到四倍的并发用户。

如今 vLLM 早已不只是一篇论文的实现。它是 Apache-2.0 协议的开源项目，有 2000 多位来自数十家学术机构和公司的贡献者，支持 Hugging Face 上 200+ 种模型架构，并且从 NVIDIA GPU 一路支持到 AMD、Intel GPU、CPU，还通过插件覆盖 Google TPU、Intel Gaudi、华为昇腾、Apple Silicon 等硬件。在很多团队眼里，它已经是「自己部署大模型」的默认答案。

核心功能

1. PagedAttention 显存管理

这是 vLLM 的立身之本。KV Cache 被分页存储在非连续显存中，按实际生成长度动态分配。实际使用中最直观的感受是：以前跑不动的并发量现在跑得动了，以前动不动 OOM 的场景现在稳定了。对于要在有限显卡上服务多用户的团队，这个提升是决定性的。

2. 连续批处理（Continuous Batching）

传统做法是凑一批请求一起跑，跑完再收下一批，中间 GPU 会空转。vLLM 每一轮迭代都能把新到的请求插进正在运行的批次里。加上分块预填充（chunked prefill）和前缀缓存（prefix caching），在流量忽高忽低的真实场景下，吞吐能一直维持在高位。前缀缓存对有固定长系统提示词的应用尤其有用——重复的那部分不用反复算。

3. OpenAI 兼容 API 服务

一条命令就能起一个模拟 OpenAI 协议的服务器，默认监听 8000 端口，可用 --host 和 --port 调整。这个设计的战略意义比技术意义更大：你的应用代码用标准 openai 库写，原型阶段连公有云 API，上线时把 base_url 指向内网的 vLLM 服务，代码一行不改。没有厂商锁定，迁移路径始终开着。除了 OpenAI 协议，它还支持 Anthropic Messages API 和 gRPC。

4. 分布式并行推理

张量并行把一个模型切到同机多卡上，流水线并行再跨机器扩展，另外还有数据并行、专家并行、上下文并行。一个 70B 模型单卡装不下，用两到四张卡跑起来接近线性扩展。要跑更大的 MoE 模型，多节点方案也是现成的。

5. 量化与内核优化

量化支持得非常全：FP8、MXFP8/MXFP4、NVFP4、INT8、INT4、GPTQ/AWQ、GGUF、compressed-tensors 等。Attention 内核可选 FlashAttention、FlashInfer、TRTLLM-GEN、FlashMLA、Triton，还有投机解码（n-gram、EAGLE 等）和 torch.compile 自动生成内核。这些东西你不用全懂，但知道有这些开关，调优时就有的可调。

6. 结构化输出与工具调用

做 Agent 和函数调用离不开稳定的结构化输出。vLLM 内置基于 xgrammar 或 guidance 的受约束生成，能强制模型输出合法 JSON，另外还有工具调用解析器和推理内容解析器。多 LoRA 支持也是现成的，稠密层和 MoE 层都能挂。

值不值得用？

优点非常突出。 它是目前开源生态里吞吐能力最强、生态最完整的推理引擎之一，完全免费，社区活跃度高到几乎任何问题都能搜到讨论。模型和硬件覆盖面之广，让它在多数场景下都不会成为技术选型的瓶颈。OpenAI 协议兼容更是让它天然具备「反锁定」属性。

缺点同样明确。 首先它是基础设施而非成品——你得自己有 GPU、自己搞环境、自己做监控和运维，官方文档虽全但边缘场景仍有空白。其次它的优化重心是吞吐而不是单请求延迟，如果你只是一个人在本地跑模型玩，用 Ollama 或 LM Studio 会轻松得多。最后，项目迭代速度极快，新版本带来的性能提升很诱人，但 API 和行为的变动也频繁，生产环境必须锁版本、做回归。

结论： 要在自有硬件上服务多个用户或多个应用，vLLM 基本是首选，没有什么理由绕开它。但如果你的场景是单人本地体验，或者压根没有 GPU 资源，那它并不合适——先用托管 API 或云 GPU 更实际。

使用建议

  • 先用 Docker 镜像跑起来，别一上手就折腾源码编译。 CUDA、驱动、PyTorch 版本的匹配是新手最容易卡住的地方，官方镜像能省掉大半麻烦。
  • 从 OpenAI 兼容服务模式起步。 相比直接调 Python API，先起 API 服务能让你用熟悉的 openai 客户端快速验证，也方便前后端分离。
  • 显存吃紧就先上量化。 AWQ 或 GPTQ 的 4bit 权重能显著压低显存占用，多数业务场景下效果损失可以接受。先量化再考虑加卡，性价比更高。
  • 有固定系统提示词一定开前缀缓存。 RAG、客服、Agent 这类应用的 Prompt 前半段往往完全一样，缓存命中后省下的算力很可观。
  • 单卡装不下再考虑张量并行，不要盲目多卡。 并行会引入通信开销，模型能塞进单卡时单卡往往更快。
  • 生产环境锁定版本号并配好监控。 关注吞吐、显存占用、排队时长这几个指标。升级前在预发环境跑一遍完整回归，别直接上线新版本。
  • 压测要模拟真实并发形态。 vLLM 的优势在高并发下才显现，用单请求测出来的数字容易低估它的价值。

适合谁用？

推荐

  • 需要在自有 GPU 上对内提供大模型服务的平台团队和基础设施工程师
  • 面向多用户、多应用的 API 服务提供方，吞吐和并发是核心指标
  • 数据不能出内网、必须私有化部署的企业与机构
  • 有一定 Linux 与 GPU 运维能力，愿意换取完全可控和更低单位成本的团队
  • 需要跑批量推理、离线数据处理、大规模 Embedding 生成的场景

可考虑

  • 用云 GPU（如 RunPod、Modal）临时起推理服务的开发者：vLLM 是现成的容器模板，值得一试
  • 做模型微调后需要上线验证的研究团队：部署链路比自己写服务省事很多
  • 非 NVIDIA 硬件用户：AMD、Intel、昇腾等都有支持，但成熟度和调优资料相对少，需要预留试错时间

不推荐

  • 只想在个人电脑上跑模型聊聊天的用户：Ollama、LM Studio 更简单
  • 完全没有 GPU 资源、也不想租算力的人：直接用托管 API 平台更实际
  • 对延迟要求极致敏感的单请求场景：需要针对性调优，或考虑更偏低延迟的方案
  • 完全没有命令行和运维经验的团队：部署和排障成本会远超预期

版本记录

以下按时间倒序收录历次版本更新的完整说明（页面顶部简介只保留最新一版要点）。

最新稳定版 v0.31.0（2026-10-05 发布，717 个提交 / 307 位贡献者）：DeepSeek-V4.1-Flash 性能强化（FlashMLA mega attention + V4.1 NVFP4 压缩 KV cache 成为 SM100 默认、DeepGEMM 稀疏 MQA logits、Mega-Gate 融合门控 GEMM 与专家选择、解码器边界融合 TP all-reduce/输入准备/MoE finalize、MXFP8 wo_b 与序列并行 reduce-scatter 融合、Engram 表跨同位 DP 副本共享等）；新增 vllm preload CLI（权重缓存守护进程，跨引擎重启把量化后权重常驻显存，支持数据并行、MTP 草稿模型、/health 与就绪等待）与实验性 vllm snapshot create/restore（用 CRIU 恢复已初始化的 TP1 引擎）；Model Runner V2 支持草稿模型投机解码与自定义 logits 处理器并新增 LiLiCorr drafter；大规模服务新增 MoonEP 均衡 EP all2all 后端、prefill 上下文并行、DeepEPv2 序列并行、EPLB 共享专家重叠；调度新增 --max-num-active-seqs 与自适应 --long-prefill-token-threshold；安全上默认拒绝每请求的 mm_processor_kwargs/media_io_kwargs（需 --trust-request-mm-kwargs）。注意破坏性变更：tokenizer_mode="slow" 移除、--enable-mamba-fine-grained-prefix-cache 更名 --enable-mamba-shared-prefix-checkpoint、quantization="fp8" 在线量化改为 fp8_per_tensor 简写、AllSpark INT8 W8A16 后端移除、--enforce-eager 同时禁用 JIT kernel 预热、XPU graphs 默认开启。

前一版 v0.30.0（2026-09-22，762 个提交 / 315 位贡献者）：新增 DeepSeek-V4.1-Flash（KV 全量以 MXFP8 存储）、DeepSeek-V4-Flash-Vision-Exp、GLM-5.3-Flash、K2-Horizon、Cohere Compass 等模型支持；Fast Start 持久权重缓存让引擎重启经 CUDA IPC 直接映射显存、免读盘（--load-format ipc_cache）；新增 Gumbel-max 生成水印与检测、HiSparse 主机侧稀疏解码分层、Model Runner V2 双批重叠与自适应投机验证；量化支持在线定点量化与 AutoRound 2~7-bit。注意破坏性变更：scale-out 端点改为 --enable-scale-out 显式开启、GPTQ 激活排序 g_idx 移除、gRPC 启动改用 vllm serve --grpc、YaRN 与 Transformers 对齐。