vLLM 本地部署实战：给本地大模型换上生产级引擎，吞吐翻倍还兼容 OpenAI API
前阵子我写过 Ollama 的 REST A…
前阵子我写过 Ollama 的 REST API 实战，不少朋友在评论区问：有没有比 Ollama 更狠的本地推理引擎？答案是有的，而且答案非常明确——vLLM。Ollama 适合入门和桌面把玩，但一旦你要把模型做成服务、要扛并发、要给团队当 API 用，vLLM 就是那条绕不开的路。今天手把手带你把它搭起来。
一、为什么放着 Ollama 不用，非要上 vLLM
先说结论，vLLM 的杀手锏就三个：吞吐高、显存省、接口标准。它靠两样技术做到这件事：PagedAttention 和 Continuous Batching（连续批处理）。PagedAttention 把 KV 缓存像操作系统管理内存一样分页，不再为每条请求预留一整块显存；连续批处理则让新请求随时插进正在跑的批次里，GPU 不再因为等一个慢请求而空转。实测下来，同样的卡、同样的模型，vLLM 的并发吞吐普遍比原生 transformers 高 2~4 倍，比 Ollama 也明显更稳。
另一个关键点是它原生兼容 OpenAI API。这意味着你现有的 ChatGPT 客户端、LangChain、以及一堆现成的脚本，把 base_url 一改就能直接对接本地模型，几乎零迁移成本。
二、环境准备：先把显卡和 CUDA 对齐
vLLM 最大的坑在安装阶段，核心就一句：它和 PyTorch、CUDA 版本绑定得很死。我强烈建议用 Docker 跑，把版本地狱直接隔离掉。先确认宿主机显卡驱动版本：
nvidia-smi
# 看顶部 CUDA Version，驱动要 >= 535.xx（对应 CUDA 12.2+）如果驱动太老，先升级驱动再往下走，否则后面会报一堆莫名其妙的 CUDA 错误。Docker 这边记得装好 NVIDIA Container Toolkit，保证容器里能认到显卡。
三、Docker 一键启动，参数别乱填
官方镜像一条命令就能拉起服务：
docker run --runtime nvidia --gpus all \
-v ~/.cache/huggingface:/root/.cache/huggingface \
-p 8000:8000 \
--ipc=host \
vllm/vllm-openai:latest \
--model Qwen/Qwen2.5-7B-Instruct \
--gpu-memory-utilization 0.85 \
--max-model-len 8192几个参数必须说清楚，很多人就是栽在这里：
--gpu-memory-utilization：给推理预留的显存比例，默认 0.9 太激进，我建议 0.85，给系统和 KV 缓存波动留点余地，否则容易 OOM。--max-model-len：最大上下文长度，越大显存占用越高，7B 模型在 24G 卡上填 8192 比较稳妥，别一上来就填 32768。--ipc=host：这个容易被忽略，不加上共享内存，多 worker 会直接崩。
四、量化加速：显存不够就上 AWQ/GPTQ
一张 24G 的卡想跑 70B 模型？原版 FP16 想都别想，但 AWQ 量化能救你。AWQ 在精度几乎不损失的前提下把权重压到 4bit，显存占用砍掉一大半：
docker run --runtime nvidia --gpus all \
-p 8000:8000 --ipc=host \
vllm/vllm-openai:latest \
--model Qwen/Qwen2.5-72B-Instruct-AWQ \
--quantization awq \
--gpu-memory-utilization 0.85注意：量化类型必须和模型权重匹配。AWQ 的模型就用 --quantization awq，GPTQ 的模型就用 gptq，模型名字后面带 -AWQ、-GPTQ 后缀的基本都有对应版本，去 HuggingFace 上认准再下，别张冠李戴。
五、调用：curl 先试，Python 再上
服务起来后，先用 curl 验证 OpenAI 兼容接口通不通：
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen/Qwen2.5-7B-Instruct",
"messages": [{"role": "user", "content": "用一句话介绍 vLLM"}],
"max_tokens": 128
}'返回正常后，直接拿 openai 库对接，几乎零改动：
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
resp = client.chat.completions.create(
model="Qwen/Qwen2.5-7B-Instruct",
messages=[{"role": "user", "content": "你好"}],
)
print(resp.choices[0].message.content)六、多卡与多节点：往分布式走一步
如果你像我一样有多块卡甚至多台机器，vLLM 也给你留好了路。单机多卡用 张量并行，把模型切到多张卡上：
--tensor-parallel-size 2跨节点的分布式推理走 Ray 集群，配置要复杂一些，但思路一致：先把各节点的推理服务注册到 Ray，再让 vLLM 用 pipeline 并行调度。这属于进阶玩法，等你的单机吞吐真正跑满再折腾不迟——先榨干单卡，再谈分布式，顺序别反了。
七、避坑清单：这几个错误我替你踩过了
- CUDA/驱动不匹配：先
nvidia-smi确认驱动，再选对应镜像 tag，别用 latest 乱拉。 - OOM：优先降
--gpu-memory-utilization和--max-model-len，别急着加卡。 - 共享内存不足：Docker 一定加
--ipc=host，否则多进程直接崩。 - 量化不匹配：AWQ/GPTQ 权重必须和
--quantization参数对上。 - 模型下载慢：国内先配好 HuggingFace 镜像源，否则第一次拉权重能等哭你。
写在最后
Ollama 负责「玩得爽」，vLLM 负责「扛得住」。如果你只是自己在终端里聊聊天，Ollama 够了；但只要你想把本地模型变成团队共用的 API 服务，或者跑一个能接住几十个并发的生产应用，vLLM 就是那个正确答案。按今天的流程走一遍，从 docker run 到 Python 调用，半小时内你也能把生产级的本地推理服务架起来。
下期想聊什么？ComfyUI 本地出图、还是多节点分布式推理，评论区告诉我。
