vLLM 是一个高吞吐、内存高效的大语言模型推理与服务引擎，最初由加州大学伯克利分校 Sky Computing Lab 开发，采用 Apache-2.0 协议开源。它的核心创新是 PagedAttention——像操作系统管理虚拟内存一样对 KV Cache 分页管理，大幅减少显存碎片，配合连续批处理和前缀缓存显著提升吞吐。项目已有 2000 多位贡献者，支持 200+ 模型架构，并可一行命令启动 OpenAI 兼容的 API 服务。 定价：完全免费，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 平台更实际
- 对延迟要求极致敏感的单请求场景：需要针对性调优，或考虑更偏低延迟的方案
- 完全没有命令行和运维经验的团队：部署和排障成本会远超预期
