本地跑开源模型的人，基本都绕不开 Ollama：一条命令拉模型，一条命令对话，写代码都省了。但只要你想把服务开放给别人用，或者一次要处理成百上千个请求，Ollama 就开始吃力了。
这不是 Ollama 的锅。它本来就是为「个人在自己电脑上跑模型」设计的，一次服务一个对话，省心优先。真要做并发服务，业界常见的做法是换一个专门的推理引擎。这一类引擎里名气最大的，叫 vLLM。
这篇文章讲三件事：vLLM 为什么快，怎么把它跑起来，以及什么时候你其实不需要它。
vLLM 是什么
vLLM 是 UC Berkeley 团队在 2023 年开源的大模型推理引擎，现在由 vLLM 项目维护，Apache 2.0 协议，GitHub 上已有 94000 多颗星，是目前开源社区里引用最广的高吞吐推理方案之一。
它解决的问题可以用一句话概括：让一张 GPU 同时服务尽可能多的请求，而不是一个请求占住整张卡。
瓶颈出在显存上。大模型在生成每个 token 时都要用到 KV 缓存（KV cache，上篇文章刚写过它的原理），随着对话变长，这块缓存会越涨越大。传统推理系统给每个请求预留一块「按最长对话算」的连续显存，结果大部分空间被白白浪费。vLLM 团队在官方博客里给出的数字是：已有系统浪费 60% 到 80% 的显存，碎片化和超额预留是两大主因。
vLLM 的解法叫 PagedAttention。名字透露了思路：像操作系统管理内存那样，把 KV 缓存切成固定大小的块，按需分配，用多少给多少。这个设计来自 2023 年的论文（arXiv 编号 2309.06180），论文里的结论是显存浪费接近于零，相同延迟下吞吐提升 2 到 4 倍。官方博客的说法更激进：对比 HuggingFace Transformers 最高 24 倍吞吐，对比当时的 TGI 也有 3.5 倍。数字都是论文和博客里写的实测条件下的结果，实际收益取决于你的负载，但量级是可信的。
安装：一条命令的事
vLLM 官方主推 Linux 加 NVIDIA 显卡的组合，Python 要求 3.11 到 3.14。推荐用 uv 建环境：
uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm download-kernels最后一条命令是新版加入的：提前下载预编译的运算内核，避免启动时现场编译在 Hopper 等新卡上多花几分钟。不用 uv 的话，pip install vllm 一样能装。
没有 N 卡也别急着关页面。vLLM 支持 AMD ROCm、Intel XPU、Google TPU，苹果芯片用户可以看 vLLM-Metal 项目（用 MLX 做计算后端，需要 mlx-community 的模型）。国内网络环境拉 HuggingFace 模型不方便的，vLLM 也支持 ModelScope：启动前 export VLLM_USE_MODELSCOPE=True 即可。
两种用法：离线批量和在线服务
vLLM 有两种打开方式，对应两种场景。
第一种是离线批量。你有一堆提示词要处理，不要求实时回来，比如给三千篇文章打标签、批量做摘要。这种用 Python 接口最省事：
from vllm import LLM, SamplingParams
prompts = ["总结这段话的意思", "把这句翻成英文", "检查这段代码的 bug"]
llm = LLM(model="Qwen/Qwen2.5-7B-Instruct")
params = SamplingParams(temperature=0.8, top_p=0.95)
outputs = llm.generate(prompts, params)
for out in outputs:
print(out.outputs[0].text)把提示词列表丢进去，引擎自动排队、自动凑批，GPU 利用率拉满。一个小提醒：llm.generate 不自动套对话模板，如果你用的是对话模型，要么用 llm.chat 方法，要么自己先用 tokenizer 把消息套上模板，否则模型可能答非所问。
第二种是在线服务，这也是 vLLM 最常用的姿势：
vllm serve Qwen/Qwen2.5-7B-Instruct就这一条命令。模型从 HuggingFace 自动下载，服务起在 http://localhost:8000。关键在于：这个服务实现了 OpenAI 的 API 协议。验证一下：
curl http://localhost:8000/v1/models返回的是标准 OpenAI 格式的模型列表。也就是说，任何支持 OpenAI 接口的客户端，把地址指到 localhost:8000 就能用。你在上一篇文章里学的 OPENAI_BASE_URL 环境变量，在这里直接复用：
export OPENAI_BASE_URL="http://localhost:8000/v1"
export OPENAI_API_KEY="EMPTY"密钥填 EMPTY 是 vLLM 官方示例里的写法，本地服务不校验；如果你要对外开服务，启动时加 --api-key 参数或设 VLLM_API_KEY 环境变量，服务就会校验请求头里的密钥，还能传多个 key 用于轮换。
Ollama 和 vLLM 怎么选
两个工具定位不同，不冲突：
Ollama 适合：个人电脑上的日常对话、开发调试、原型验证。装完就能用，模型管理方便，配置要求低。
vLLM 适合：多人共用的服务、高并发场景、批量离线任务、生产环境部署。它在乎的是把硬件吃干榨净，代价是只支持 Linux 为主的服务器环境，安装和显存配置都比 Ollama 讲究。
一个务实的路线：前期用 Ollama 验证想法，等真有用户进来、并发上来了，再把服务迁到 vLLM 上。两者都兼容 OpenAI 接口，切换成本几乎只有改一个环境变量。
写在最后
记住三个数就够了解 vLLM：显存浪费 60% 到 80% 是它的出发点，PagedAttention 是它的核心算法，吞吐 2 到 4 倍是论文给的典型收益。GPU 很贵，推理引擎的意义就在于让每一分显存都干活。
相关阅读：KV 缓存的原理能帮你理解 PagedAttention 到底在优化什么；Ollama 部署教程适合还没跑过本地模型的同学；如果你打算用 vLLM 跑量化模型，先看这篇 GGUF 量化入门搞清楚显存够不够。