大模型应用上线后，第一个撞上的墙往往不是模型效果，而是推理成本和吞吐。原生 Hugging Face 推理一次一个请求、KV 缓存整块预留显存，GPU 利用率低得可怜。vLLM 就是为解决这个问题生的：它用 PagedAttention 和连续批处理把吞吐拉高了一个量级，同时对外暴露 OpenAI 兼容的 HTTP 接口，业务侧几乎不用改代码。目前该项目 Star 约 93k，已经是开源推理引擎的事实标杆。本文按「定位、安装、离线推理、在线服务、生产注意事项」的顺序展开。
1、项目概述
vLLM 的官方定位是「快速且易用的 LLM 推理与服务库」，宣传语是 Easy, fast, and cheap LLM serving for everyone。许可证 Apache 2.0，Star 约 93k，Fork 约 23k，社区活跃度在大模型基础设施项目里名列前茅。
它解决的核心痛点是服务吞吐。传统推理框架为每个请求预留连续大块显存放 KV 缓存，碎片和浪费严重；vLLM 借鉴操作系统虚拟内存的分页思想，把 KV 缓存切成块按需分配，这就是论文里著名的 PagedAttention。配合连续批处理（请求随到随拼批，不必等整批完成）和前缀缓存，同样一张 A100 的 token 吞吐能到原生实现的数倍。
支持能力可以归为四类：
- 量化：FP8、INT8、INT4、GPTQ、AWQ、GGUF、NVFP4 等
- 注意力内核：FlashAttention、FlashInfer、FlashMLA、Triton
- 解码算法：并行采样、beam search、推测解码（EAGLE 等）
- 并行策略：张量、流水线、数据、专家、上下文并行
2、安装与环境
官方推荐用 uv 建独立虚拟环境，NVIDIA GPU 环境的安装方式如下。
uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
--torch-backend=auto 会根据本机 CUDA 版本自动选择 PyTorch 后端变体，省去手动对齐 CUDA 与 PyTorch 版本的麻烦。普通 pip install vllm 也可用，但依赖解析更慢。包体较大（含编译好的 CUDA 内核），首次下载几个 GB 属于正常。
硬件支持远不止 NVIDIA：AMD、Intel GPU，x86/ARM CPU，TPU、Gaudi、华为昇腾、Apple Silicon 都在支持列表里，只是 NVIDIA 生态最成熟、文档最全。
3、离线批量推理
离线场景（批量评估、数据集生成）用 LLM 类，不需要起服务。官方快速上手的示例如下。
from vllm import LLM, SamplingParams
prompts = [
"Hello, my name is",
"The president of the United States is",
"The capital of France is",
"The future of AI is",
]
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)
llm = LLM(model="facebook/opt-125m")
outputs = llm.generate(prompts, sampling_params)
for output in outputs:
prompt = output.prompt
generated_text = output.outputs[0].text
print(f"Prompt: {prompt!r}, Generated text: {generated_text!r}")
结构分三块：LLM(model=...) 加载模型，权重直接从 Hugging Face Hub 拉，无需转换；SamplingParams 独立控制温度、top_p、最大 token 数等采样参数，与模型解耦；llm.generate 内部自动做连续批处理，几百条 prompt 一次性传入也能高效调度。对话模型用 llm.chat(messages_list, sampling_params)，它会自动套用 tokenizer 的 chat template，省掉手动拼模板。
4、OpenAI 兼容服务
线上服务用一条命令把模型变成 OpenAI API 的替换品。
vllm serve Qwen/Qwen2.5-1.5B-Instruct
默认监听 http://localhost:8000，一次加载一个模型。用标准 OpenAI 客户端或 curl 即可调用。
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen/Qwen2.5-1.5B-Instruct",
"messages": [
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Who won the world series in 2020?"}
]
}'
这一点是 vLLM 扩散快的关键：业务代码只要把 base_url 从 OpenAI 换成本地地址就完成迁移。除 OpenAI 风格外还提供 Anthropic Messages API 和 gRPC 接口；需要鉴权时加 --api-key 或设环境变量 VLLM_API_KEY。
服务化能力还包括流式输出、结构化输出（xgrammar/guidance 约束 JSON schema）、工具调用、多 LoRA 热插拔——一个基座模型同时服务几十个微调适配器，显存只多占一份。
5、模型支持与选型对比
vLLM 支持 200 多种模型架构，覆盖面基本等于开源模型清单：
- 仅解码器 LLM：Llama、Qwen、Gemma
- MoE：Mixtral、DeepSeek-V3、GPT-OSS
- 状态空间模型：Mamba
- 多模态：LLaVA、Qwen-VL、Pixtral
- 嵌入与排序：E5-Mistral、GTE、ColBERT
和同类方案对比：Hugging Face Transformers 的 pipeline 适合单机验证但吞吐低；TensorRT-LLM 极致性能但工程复杂、硬件绑定；SGLang 强项在结构化输出与前沿调度策略，社区规模小于 vLLM。vLLM 的位置是性能、生态、易用三者的平衡点，对大多数团队是默认起点。
6、生产注意事项
上生产前有几件事要盯紧。显存方面，KV 缓存默认吃掉权重之外的剩余显存，gpu_memory_utilization 参数控制占比，长上下文多并发场景要预留余量防止 OOM。吞吐方面，batch 大小不必手动调，引擎自动按负载拼批，真正要调的是 max_model_len 和量化格式——70B 级模型用 FP8 能把所需卡数砍半。升级方面，vLLM 迭代很快，CUDA 内核与驱动、PyTorch 的版本耦合紧，升级前在灰度环境完整回归。
另外注意它是推理引擎不是训练框架，微调请走 Transformers 加 LoRA 生态，练好的适配器再挂回 vLLM 服务。
7、总结
vLLM 用 PagedAttention 和连续批处理重写了大模型服务的经济学，93k Star、Apache 2.0、200 多种架构支持和 OpenAI 兼容接口，构成了当前开源推理的默认选项。对于要把大模型从 demo 推向生产、面对并发和成本压力的团队，建议先用 vllm serve 起单卡服务压测基线，再按量级决定量化格式与并行策略；对于追求极限延迟或非主流硬件的场景，建议再评估 TensorRT-LLM 与 SGLang，避免过早绑定。
