vLLM大模型推理部署实战：从单卡到多卡 Serving 全流程

vLLM大模型推理部署为什么成为工程首选

大模型从实验阶段走向生产环境，推理部署是绕不开的工程环节。vLLM作为目前社区活跃度最高的LLM推理框架，凭借PagedAttention内存管理和Continuous Batching调度策略，在吞吐量和延迟之间取得了工程上的最优平衡。对比原生Transformers推理，vLLM在相同硬件条件下吞吐量可提升2-4倍，这个差距在多并发场景下更加明显。

环境准备与依赖安装

部署vLLM前需要确认GPU驱动和CUDA版本兼容性。当前vLLM 0.6.x要求CUDA 12.1+，NVIDIA驱动525+。在Ubuntu 22.04环境下执行以下操作：

# 检查驱动与CUDA版本
nvidia-smi
nvcc --version

# 创建虚拟环境
conda create -n vllm python=3.10 -y
conda activate vllm

# 安装vLLM（指定CUDA版本）
pip install vllm==0.6.3 --extra-index-url https://download.pytorch.org/whl/cu121

# 验证安装
python -c "import vllm; print(vllm.__version__)"

如果环境存在多个CUDA版本冲突，建议使用Docker方式部署：

docker pull vllm/vllm-openai:v0.6.3
docker run --gpus all -v /data/models:/models   -p 8000:8000   vllm/vllm-openai:v0.6.3   --model /models/Qwen2.5-72B-Instruct   --tensor-parallel-size 4   --max-model-len 8192

单卡部署7B模型：快速验证推理链路

在单张A100-80G或RTX 4090上部署7B参数模型是入门级的验证方案。vLLM的OpenAI兼容API服务让调用方式与OpenAI API保持一致，降低业务适配成本：

# 单卡启动vLLM API Server
python -m vllm.entrypoints.openai.api_server   --model Qwen/Qwen2.5-7B-Instruct   --served-model-name qwen2.5-7b   --host 0.0.0.0.0   --port 8000   --max-model-len 4096   --gpu-memory-utilization 0.9   --dtype auto

启动后通过curl验证服务可用性：

# 健康检查
curl http://localhost:8000/health

# 发送推理请求
curl http://localhost:8000/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "qwen2.5-7b",
    "messages": [
      {"role": "user", "content": "解释PagedAttention的工作原理"}
    ],
    "max_tokens": 512,
    "temperature": 0.7
  }'

多卡张量并行：72B模型部署方案

72B级别的大模型需要多卡协作推理。vLLM通过tensor-parallel-size参数控制张量并行度，将模型权重均匀切分到多张GPU上。以4卡A100-80G部署Qwen2.5-72B为例：

# 4卡张量并行部署
python -m vllm.entrypoints.openai.api_server   --model Qwen/Qwen2.5-72B-Instruct   --tensor-parallel-size 4   --max-model-len 8192   --gpu-memory-utilization 0.92   --max-num-seqs 64   --enable-prefix-caching   --host 0.0.0.0.0   --port 8000

关键参数说明：

• tensor-parallel-size：张量并行度，必须等于可用GPU数量
• gpu-memory-utilization：GPU显存利用率上限，0.92意味着预留给KV Cache和临时张量8%的显存空间
• max-num-seqs：最大并发序列数，受限于KV Cache容量
• enable-prefix-caching：开启前缀缓存，对多轮对话和系统提示词重复场景提升显著

PagedAttention内存管理与KV Cache调优

vLLM的核心性能优势来自PagedAttention。传统推理框架为每个序列预分配固定长度的KV Cache，导致大量显存浪费。PagedAttention将KV Cache按固定大小的block管理，类似操作系统的虚拟内存分页机制，按需分配和回收block。

在实际部署中，KV Cache容量直接决定了最大并发数。可以通过以下方式估算和调优：

# 计算单GPU可用KV Cache显存
# 公式: 可用KV显存 = GPU总显存 × gpu-memory-utilization - 模型权重显存
# 示例: A100-80G, 模型权重占16G (7B FP16)
# 可用KV显存 ≈ 80 × 0.9 - 16 = 56G
# 单序列KV Cache ≈ 2 × num_layers × head_dim × num_kv_heads × seq_len × 2bytes
# 7B模型约1.1G/8192tokens → 可支持约50个并发序列

# 通过API查看当前KV Cache使用情况
curl http://localhost:8000/stats

当并发请求超出KV Cache容量时，vLLM会执行preemption（抢占），将低优先级序列的KV Cache换出到CPU内存。这个机制保证了服务不会OOM，但会引入额外的延迟抖动。生产环境建议通过监控preemption频率来调整max-num-seqs参数。

Continuous Batching调度策略解析

传统static batching需要等待一个batch中所有序列完成生成才能处理下一个batch，短序列被迫等待长序列，GPU利用率低。Continuous Batching在每次iteration粒度上做调度：已完成的序列立即释放资源，新请求即时加入执行，GPU利用率接近理论峰值。

在高并发场景下，Continuous Batching配合PagedAttention的动态内存管理，让vLLM的吞吐量相比static batching提升3-5倍。这也是vLLM在Serving场景下远超Transformers原生推理的根本原因。

生产环境监控与故障排查

vLLM生产部署需要关注三个核心指标：请求延迟P99、KV Cache利用率、preemption频率。部署Prometheus + Grafana监控方案：

# vLLM暴露Prometheus指标
# 访问 http://localhost:8000/metrics

# 关键指标:
# vllm:num_requests_running        当前运行中请求数
# vllm:num_requests_waiting         等待队列长度
# vllm:gpu_cache_usage_perc          KV Cache使用率
# vllm:num_preemptions               抢占次数
# vllm:avg_generation_throughput     平均生成吞吐

# 常见问题排查
# 1. OOM: 降低gpu-memory-utilization或max-model-len
# 2. 延迟抖动: 检查preemption次数，增大KV Cache或降低并发
# 3. 吞吐不足: 检查GPU利用率(nvidia-smi)，确认是否IO瓶颈

量化部署与成本优化

对于显存受限场景，vLLM支持AWQ和GPTQ量化模型加载，4-bit量化可将7B模型的显存需求从14G降至约5G：

# 加载AWQ量化模型
python -m vllm.entrypoints.openai.api_server   --model Qwen/Qwen2.5-7B-Instruct-AWQ   --quantization awq   --max-model-len 4096   --gpu-memory-utilization 0.85

量化带来的精度损失在大多数业务场景中可接受，MMLU评测下降约1-2个百分点，但推理吞吐量提升30%以上。在成本敏感的生产环境，量化部署是性价比最高的方案。