3. 环境准备：硬件要求、软件依赖、部署方式（Docker/K8s）

3.1 硬件要求：先算清“显存账”，再谈吞吐

vLLM 的吞吐压测结果高度依赖 GPU 显存容量与带宽。压测前必须明确：模型权重 + KV Cache + 激活值 + CUDA 上下文 四部分共同占用显存。其中 KV Cache 是动态增长的部分，直接决定最大并发序列数（max_num_seqs）。

硬件项 最低要求 推荐配置（生产压测） 说明
GPU NVIDIA Ampere 架构（A100/A30） A100 80G / H100 80G / L40S FP16/BF16 算力与显存带宽决定吞吐上限
显存 ≥ 模型权重的 2 倍 权重 + 预留 30%~50% 给 KV Cache 7B 模型 FP16 约 14GB，建议 40GB 以上
CPU 16 核 32 核以上 用于 tokenization、调度、张量并行通信
内存 64GB 128GB~256GB 加载权重、数据集缓存、多进程压测
网络 单机无需特殊要求 多机需 RDMA/InfiniBand 或 25GbE 以上 张量并行跨节点时通信开销显著
压测前必查：使用 nvidia-smi 确认 GPU 驱动版本 ≥ 525，且 nvidia-smi -pm 1 开启持久化模式，避免压测过程中时钟频率波动影响数据稳定性。
GPU 显存分配 A100 80G 示例 模型权重 ~14GB KV Cache 动态增长 max_num_seqs 决定 激活值 + CUDA 上下文 显存预算计算流程 模型参数量 P 权重 = P × 2B KV Cache 可用 KV = 总显存 − 权重 − 激活 − 上下文 max_num_seqs = 可用 KV ÷ (每序列 KV 占用) 压测时监控：nvidia-smi --query-gpu=memory.used 若显存溢出 → 降低 max_num_seqs 或启用 PagedAttention

3.2 软件依赖：CUDA、PyTorch 与 vLLM 版本匹配

vLLM 对 CUDA 和 PyTorch 版本有严格约束。生产环境建议使用 Docker 镜像 锁定版本，避免因系统库升级导致推理结果异常。核心依赖如下：

  • CUDA Driver：≥ 12.4（推荐 12.4+），驱动向下兼容
  • PyTorch：2.1~2.3，需与 CUDA 12.x 配套
  • vLLM：≥ 0.4.2（生产推荐 0.5.x 以上，支持 PagedAttention v2）
  • Python：3.9~3.11
  • 其他：transformers、tokenizers、fastapi、uvicorn（用于 OpenAI 兼容服务）
推荐安装方式（Docker）： 
# 拉取官方镜像（已内置 CUDA + PyTorch + vLLM）
docker pull vllm/vllm-openai:latest

# 验证 GPU 可见性
docker run --gpus all --rm vllm/vllm-openai:latest \
  python -c "import vllm; print(vllm.__version__)"

3.3 部署方式：Docker 与 K8s 的选型与配置

3.3.1 Docker 单机部署（压测首选）

吞吐压测阶段推荐 Docker 部署，原因在于：启动快、资源隔离清晰、便于反复调整参数。压测时需将宿主机 GPU 直通容器，并设置共享内存以避免数据加载瓶颈。

docker run -d --name vllm-serve \
  --gpus '"device=0,1"' \
  --shm-size=16g \
  -p 8000:8000 \
  -v /data/models:/models \
  vllm/vllm-openai:latest \
  --model /models/Qwen2.5-7B-Instruct \
  --tensor-parallel-size 2 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.9 \
  --enforce-eager
注意：压测时不要加 --enforce-eager（它会关闭 CUDA Graph 优化），上例仅为快速验证部署。正式压测应去掉该参数，以测得真实吞吐。

3.3.2 Kubernetes 部署（生产环境）

K8s 部署适合多副本弹性伸缩场景。核心在于 GPU 资源声明 与 调度策略。需提前安装 NVIDIA Device Plugin，使 Pod 能申请 GPU 资源。

# vllm-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-qwen2-5-7b
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args: ["--model", "/models/Qwen2.5-7B-Instruct", "--tensor-parallel-size", "1"]
        resources:
          limits:
            nvidia.com/gpu: 1
        volumeMounts:
        - name: model-storage
          mountPath: /models
        ports:
        - containerPort: 8000
      volumes:
      - name: model-storage
        persistentVolumeClaim:
          claimName: model-pvc

3.4 部署验证与常见误区

部署完成后，必须进行 功能验证 与 基础性能冒烟，确认服务正常后再进入正式压测流程。

  1. 健康检查：curl http://localhost:8000/health 返回 {"status": "ok"}
  2. 单请求验证：发送一次 chat completion 请求，确认输出质量
  3. 并发冒烟：用 10 并发 × 20 请求快速测试，观察是否 OOM 或超时
压测环境检查清单：
  • GPU 驱动与容器内 CUDA 版本匹配（nvidia-smi 在容器内可执行）
  • 模型路径正确，tokenizer 与模型权重版本一致
  • 共享内存 ≥ 16GB（否则大数据集加载会卡死）
  • 关闭宿主机其他 GPU 任务，避免显存争抢

常见误区复盘

误区 后果 正确做法
忽略 gpu-memory-utilization 设置 KV Cache 空间不足，并发上不去 设为 0.85~0.95，预留少量显存给 CUDA 上下文
K8s 中未设置 nvidia.com/gpu 资源限制 Pod 调度失败或 GPU 共享冲突 必须声明 limits，且与 tensor-parallel-size 匹配
使用 CPU 版 PyTorch 镜像 vLLM 无法加载 CUDA 内核，直接报错 使用官方 vLLM 镜像或自行构建 CUDA 版本
压测时开启 --enforce-eager 吞吐下降 30%~50% 压测必须使用默认 CUDA Graph 模式

环境准备的核心目标是：让 vLLM 在 GPU 上以最优状态运行，且压测结果可复现。建议将部署配置（Docker 命令或 K8s YAML）纳入版本管理，每次压测前记录 GPU 驱动版本、vLLM 版本、模型路径和关键启动参数，确保不同批次压测数据具有可比性。完成上述环境验证后，即可进入下一阶段的压测工具选型与脚本编写。

← 上一章 📖 返回目录 下一章 →