把一个大模型跑起来不难，难的是让它「跑得快、扛得住并发、显存不浪费」。很多团队都有这样的经历：用原生 Transformers 库部署一个 7B 模型，单卡只能支撑几路并发对话，显存明明还剩一半却开不了新请求。vLLM 的出现几乎颠覆了这种局面——它成了目前生产环境部署开源大模型的事实默认选择。
项目主页在 vllm.ai，代码在 GitHub vllm-project/vllm，都是 Apache 2.0 协议。
一、vLLM 是什么
vLLM 是加州大学伯克利分校 Sky Computing Lab 主导开发的开源大模型推理引擎，由社区持续维护，Apache 2.0 协议。它支持 200+ 模型架构，从 Llama、Mistral、Qwen、DeepSeek 到 Gemma、Phi、Falcon 都能跑，并原生提供 OpenAI 兼容的 API（/v1/chat/completions、/v1/completions），这意味着现有调用 OpenAI 接口的代码几乎不用改就能切换过来。
它快的原因有两个核心技术：PagedAttention（分页注意力）和连续批处理（Continuous Batching）。
二、PagedAttention：把显存当虚拟内存管
先看痛点。大模型推理时，除了固定的模型权重，每一路对话还会动态生成一份 KV Cache（键值缓存）——记录已生成 token 的注意力信息，随对话增长不断膨胀。原生推理框架给每条对话预分配一段连续显存，但对话长短不一：如果按最大长度 4096 token 预分配，而平均请求只有 512 token，就有 87% 的显存被白白浪费；短对话结束释放后，留下的碎片又无法被新请求利用。实测中传统方式显存利用率普遍不足 30%。
PagedAttention 借鉴了操作系统「虚拟内存分页」的思想：把 KV Cache 切成固定大小的块（常见 256 或 512 token 一页），需要多少分配多少，通过链表把不连续的页逻辑串联成完整上下文。这样：
- 显存零碎片：页面用完即回收，循环复用，显存浪费减少 55%-80%；
- 支持共享：多条对话拥有相同前缀（比如同一个 system prompt）时可以共用同一组页面，多轮对话场景收益明显；
- 长上下文友好：128K、256K 超长上下文按页分配，不再担心显存暴涨。
代价是页表查找的寻址开销，但 vLLM 通过深度 CUDA 算子融合把分页计算放进了 GPU 内核并行执行，实测几乎无性能损耗。
三、连续批处理：让 GPU 一刻不闲
传统静态批处理要等整批请求全部生成完才开始下一批——请求长短不一，短请求早结束了也只能干等。连续批处理（Continuous Batching）在每一步解码时动态调度：哪个序列生成了结束符就立刻移除，等待队列里的新请求马上补位，GPU 全程保持高负载。实测中这项机制平均降低延迟 30%-50%，吞吐提升 2-3 倍。
四、真实性能数据
几个有代表性的公开数据：
- DeepSeek-V4-Pro 单卡 H100：传统方式约 8 req/s，vLLM 提升到约 25 req/s（维持相近的每请求延迟）；张量并行到 2 张 H100 后约 45 req/s；
- Llama 2 70B 4×A100：256 并发下达到 2200 tokens/s，比 TGI 快 2.3 倍、比原生 PyTorch 推理快 3.1 倍；
- 生产实践反馈：相比 Hugging Face Transformers 原生推理，吞吐提升 10-20 倍、延迟降低 50% 以上；
- H100 公开基准（Llama 3.3 70B FP8）：100 并发下约 2400 tokens/s，处于开源引擎第一梯队。
换算到成本上：同等 7B/13B 模型，原生框架单卡只能撑几路并发，vLLM 能撑几十上百路——单张高端显卡就能搭起一个商用 API 服务，硬件成本下降一个量级。
五、部署实战
部署 vLLM 非常简单，核心就两步：
- 安装：
pip install vllm（需要 CUDA 12.1+、Python 3.8+、NVIDIA 驱动 530+，包约 2GB 含 PyTorch 依赖）； - 起服务：
vllm serve Qwen/Qwen2.5-7B-Instruct --tensor-parallel-size 1 --gpu-memory-utilization 0.9，即可获得一个 OpenAI 兼容的本地 API，端口默认 8000。
关键参数速记：
--gpu-memory-utilization：显存利用率，生产建议 0.90-0.95；--tensor-parallel-size：张量并行卡数，等于 GPU 数量（大模型跨卡必备）；--max-model-len：最大上下文长度；--max-num-seqs：最大并发序列数，高吞吐场景调大；--enable-prefix-caching：开启前缀缓存，多轮对话/长文档场景显著省算力；--swap-space：显存不够时借用 CPU 内存做缓冲。
生产环境建议加一层 Nginx 负载均衡 + Prometheus/Grafana 监控（vLLM 原生暴露 tokens/s、延迟分位、KV Cache 用量等指标），K8s 部署时按队列深度而非 CPU 使用率做自动扩缩容。
六、量化与进阶优化
vLLM 的量化支持非常全面，主要三档：
- FP8 量化：NVIDIA Hopper/Ada 显卡原生支持，显存减半、吞吐提升 1.5-2 倍，精度损失极小，是 2026 年的推荐默认；
- INT4（AWQ/GPTQ）：显存减到 1/4，吞吐提升 2-3 倍，适合显存紧张场景；
- 推测解码（Speculative Decoding）：用小模型当草稿模型并行生成候选 token，再交给大模型验证，吞吐可再提升 1.5-2.5 倍。
实际上官方支持的量化格式远不止这三档——除了 FP8、INT8、INT4（GPTQ/AWQ），还涵盖了 MXFP8/MXFP4、NVFP4、GGUF、compressed-tensors、ModelOpt、TorchAO 等一长串格式，覆盖从极致精度到极致压缩的各种需求。注意力内核方面，它集成了 FlashAttention、FlashInfer、TRTLLM-GEN、FlashMLA 与 Triton 等多种实现，GEMM/MoE 内核则针对不同精度用 CUTLASS、TRTLLM-GEN、CuTeDSL 做了优化。
七、官方功能全景：远不止”快”
除了速度，vLLM 在 2026 年的功能版图已经相当完整，官方文档列出的关键能力包括：
- 五种并行策略：张量并行、流水线并行、数据并行、专家并行、上下文并行，超大模型跨多卡、多节点部署都支持；
- 前缀缓存与分块预填：
--enable-prefix-caching自动复用相同前缀的 KV Cache；chunked prefill 把长 prompt 的预填拆成小块，降低首字延迟； - 分离式架构：把预填（prefill）、解码（decode）、编码（encode）阶段解耦，可部署在不同硬件上，是新一代分离式推理的基础；
- 结构化输出：通过 xgrammar 或 guidance 生成严格符合 JSON Schema / 正则约束的输出，工具调用与推理解析器开箱即用；
- 多接口兼容：除了 OpenAI 兼容 API，还支持 Anthropic Messages API 与 gRPC 接口，流式输出原生支持；
- Multi-LoRA：对 Dense 层和 MoE 层都能高效挂载多个 LoRA 适配器，一个基础模型同时服务多种微调版本。
硬件支持也很宽：NVIDIA GPU、AMD GPU、x86/ARM/PowerPC CPU 都能跑，此外还有 Google TPU、Intel Gaudi、IBM Spyre、华为昇腾、Rebellions NPU、Apple Silicon、沐曦（MetaX）GPU 等硬件插件。这也解释了为什么它社区庞大——由数十家学术机构和公司、超过 2000 名贡献者共同维护，是当下最活跃的开源 AI 项目之一。
八、适用场景
- 高并发在线 API 服务（智能客服、AI 助手、批量文本生成）；
- 长上下文任务（法律文书、长文档总结、知识库问答）；
- 私有化部署 + OpenAI 兼容接口迁移。
九、工具入口
vLLM 面向「服务端高并发」，那没有好显卡、甚至只有一台普通电脑的用户怎么办？下一篇介绍 llama.cpp——用 CPU 也能跑大模型的量化部署方案。
