vLLM 部署大模型：高吞吐推理服务实战

把大模型跑成稳定、高吞吐的在线推理服务，是 AI 应用落地的关键一步。vLLM 是当前最流行的开源推理引擎，它通过 PagedAttention 显存管理与连续批处理，让单机 GPU 的吞吐提升 2–10 倍。本文带你从零部署 vLLM 推理服务，打通 OpenAI 兼容接口并落到生产。

一、传统部署为什么慢：显存碎片与静态批处理

很多团队一开始用 Hugging Face Transformers 直接 model.generate() 起服务，跑通逻辑很快，但压测一上来就露馅：GPU 利用率常年不到 30%，显存却频频爆满，QPS 怎么都上不去。根因有两点。

其一是 KV Cache 显存碎片。自回归模型每生成一个 token 都要缓存历史 Key/Value，这些 KV Cache 占用显存的大头。传统实现为每个请求预留一块连续、且按”最长可能长度”申请的显存，请求长短不一，空隙无法复用，显存浪费常常超过 50%。

其二是 静态批处理（Static Batching）。一个 batch 必须等所有请求都生成完才一起返回，短请求被长请求”拖死”，GPU 在等待时空转。vLLM 正是为这两件事而生的。

二、vLLM 的核心：PagedAttention 与连续批处理

2.1 PagedAttention：像操作系统一样管 KV Cache

vLLM 把 KV Cache 切成固定大小的”页（block）”，请求按需申请、用满再申请下一页，释放的页回到池子里给其他请求复用。这就像操作系统用虚拟内存分页管理物理内存——不同请求的 KV Cache 可以非连续存放，显存利用率从 50% 左右提升到 90% 以上，意味着同样一张卡能同时服务的并发数翻倍。

2.2 连续批处理（Continuous Batching）

vLLM 在 token 级别做调度：只要有请求生成完，立刻把新请求填进空闲槽位，而不是等整个 batch 结束。短请求不必再等长请求，GPU 几乎时刻有活干。配合 PagedAttention，吞吐通常能比原生 Transformers 提升数倍，在长上下文、高并发场景下差距更夸张。

2.3 原生量化：AWQ / GPTQ / FP8

vLLM 内置多种量化后端，可以在几乎不掉点的情况下把 7B/13B/70B 模型压到更小显存占用，进一步拉升并发。常见选项有 AWQ、GPTQ（训练后权重量化）和 FP8（Hopper 架构原生低精度）。想要本地量化与 llama.cpp 路线对比的，可参考我们另一篇 本地大模型量化部署：GGUF 与 llama.cpp 调优。

三、Docker 一键拉起 vLLM 服务

最简方式是直接用官方镜像启动 OpenAI 兼容服务。下面以 Qwen2.5-7B-Instruct 为例，把 8000 端口暴露出来：

docker run --gpus all -p 8000:8000 \
  --ipc=host \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen2.5-7B-Instruct \
  --dtype auto \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 \
  --enable-prefix-caching

启动后访问 http://localhost:8000/docs 能看到完整的 Swagger 接口文档；/v1/models 返回当前加载的模型。如果模型不在本地，vLLM 会自动从 Hugging Face 拉取（需联网或提前 hf download 缓存）。

四、用 OpenAI 兼容接口调用

vLLM 最大的便利是接口与 OpenAI 完全对齐，存量代码只需改 base_url 即可无缝迁移。下面是 Python 调用示例：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY",          # vLLM 默认不校验 key
)

resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[
        {"role": "system", "content": "你是一个严谨的技术助手。"},
        {"role": "user", "content": "用一句话解释什么是连续批处理。"},
    ],
    temperature=0.7,
    max_tokens=512,
)
print(resp.choices[0].message.content)

不想写代码时，直接用 curl 验证服务是否存活：

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2.5-7B-Instruct",
    "messages": [{"role": "user", "content": "你好"}],
    "max_tokens": 64
  }'

关于推理引擎的横向对比（vLLM、llama.cpp、Ollama、TensorRT-LLM 等），我们整理过一篇 大模型推理引擎选型与部署，可以作为选型前的速查。

五、多卡与张量并行：从单卡到生产集群

当模型放不进单张卡，或单卡吞吐到顶时，就要用并行。vLLM 支持张量并行（Tensor Parallelism）把一层权重切到多张卡，也支持流水线并行处理超长模型。最常见的多卡启动方式如下：

docker run --gpus all -p 8000:8000 \
  --ipc=host \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen2.5-72B-Instruct \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.92 \
  --max-model-len 4096 \
  --enable-prefix-caching

--tensor-parallel-size 设为 GPU 数量即可，vLLM 会自动做权重切分与 all-reduce 通信。注意张量并行要求多卡间 NVLink/PCIe 带宽充足，否则通信开销会吃掉并发收益。若要把 vLLM 接到企业知识库前端，可参考 Dify + Ollama 搭建团队 AI 助手 的接入思路，把后端模型换成 vLLM 的 OpenAI 端点。

六、关键启动参数与调优

下面是影响吞吐和显存最关键的几个参数，建议在压测时逐一调：

参数	默认值	说明与建议
–max-model-len	模型原生	最大上下文长度，调小可省显存、提并发
–gpu-memory-utilization	0.90	显存占用上限，OOM 时先降到 0.85
–tensor-parallel-size	1	多卡张量并行数，等于 GPU 数
–max-num-seqs	256	最大并发序列数，吞吐上不去就调大
–dtype	auto	auto / half / float8，按卡能力选
–enable-prefix-caching	关	相同系统提示复用 KV，显著降低首 token 延迟
–quantization	无	awq / gptq / fp8，省显存提并发

七、vLLM 与 llama.cpp / TGI / TensorRT-LLM 怎么选

推理引擎没有唯一答案，看场景：

引擎	定位	优势	适用场景
vLLM	高吞吐服务端	连续批处理、生态成熟、OpenAI 兼容	线上高并发 API 服务
llama.cpp	本地/CPU 推理	GGUF 量化、跨平台、内存占用低	笔记本、边缘、个人部署
TGI	生产级服务	Hugging Face 官方、算子优化好	HF 生态重度用户
TensorRT-LLM	极致性能	NVIDIA 深度优化、延迟最低	有 NVIDIA 工程力的团队

八、生产常见坑与排查

8.1 显存 OOM

报错 CUDA out of memory 时，依次调小 --gpu-memory-utilization（如 0.85）、--max-model-len、--max-num-seqs。若仍 OOM，说明模型超出单卡能力，需要开 --tensor-parallel-size 多卡。

8.2 吞吐上不去

先确认 --enable-prefix-caching 已开（很多系统提示是重复的），再把 --max-num-seqs 调大并观察 GPU 利用率。若利用率仍低，多半是请求方没并发压上来，而非 vLLM 瓶颈。

8.3 首 token 延迟高

长提示场景下首 token 慢，开启 --enable-chunked-prefill 把 prefill 分块与 decode 交错，避免长请求阻塞短请求。同时确认批量请求里没有出现超长上下文把 KV 池占满的情况。

九、生产落地检查清单

检查项	建议
接口兼容	确认上游代码仅改 base_url 即可切换
显存水位	gpu-memory-utilization 留 5–10% 余量
并发上限	压测确定 max-num-seqs 与真实 QPS 匹配
前缀缓存	系统提示固定时务必开启 prefix caching
健康检查	用 /health 接入 K8s liveness 探针
成本观测	接入 Langfuse 等追踪 token 与延迟

vLLM 把”大模型推理”从能跑变成了”跑得稳、跑得快”。掌握 PagedAttention、连续批处理与几个关键启动参数，你就能用同样的硬件撑起数倍流量。下一步可以把它接进 RAG 或 Agent 框架，让高吞吐底座真正服务于业务。