vLLM 深度实战：2026 年生产级 LLM 推理引擎完全指南

TL;DR 2026 年，vLLM 已迭代至 v0.24.0，累计超过 2000 名贡献者。本文从 PagedAttention 核心原理到生产部署的每一个细节，带你完整掌握这个开源 LLM 推理的事实标准。

---

📋 目录

1. [为什么 vLLM 是 2026 年的默认选择](#为什么 vLLM 是 2026 年的默认选择 "#%E4%B8%80%E4%B8%BA%E4%BB%80%E4%B9%88-vllm-%E6%98%AF-2026-%E5%B9%B4%E7%9A%84%E9%BB%98%E8%AE%A4%E9%80%89%E6%8B%A9")
2. [PagedAttention：把 OS 虚拟内存搬进 GPU](#PagedAttention：把 OS 虚拟内存搬进 GPU "#%E4%BA%8Cpagedattention%E6%8A%8A-os-%E8%99%9A%E6%8B%9F%E5%86%85%E5%AD%98%E6%90%AC%E8%BF%9B-gpu")
3. [2026 年 vLLM 重大更新一览](#2026 年 vLLM 重大更新一览 "#%E4%B8%892026-%E5%B9%B4-vllm-%E9%87%8D%E5%A4%A7%E6%9B%B4%E6%96%B0%E4%B8%80%E8%A7%88")
4. [5 分钟快速上手](#5 分钟快速上手 "#%E5%9B%9B5-%E5%88%86%E9%92%9F%E5%BF%AB%E9%80%9F%E4%B8%8A%E6%89%8B")
5. [生产级 Docker Compose 配置](#生产级 Docker Compose 配置 "#%E4%BA%94%E7%94%9F%E4%BA%A7%E7%BA%A7-docker-compose-%E9%85%8D%E7%BD%AE")
6. 性能调优三板斧
7. [监控与告警：Prometheus 指标详解](#监控与告警：Prometheus 指标详解 "#%E4%B8%83%E7%9B%91%E6%8E%A7%E4%B8%8E%E5%91%8A%E8%AD%A6prometheus-%E6%8C%87%E6%A0%87%E8%AF%A6%E8%A7%A3")
8. [Kubernetes 部署 7 个生产模式](#Kubernetes 部署 7 个生产模式 "#%E5%85%ABkubernetes-%E9%83%A8%E7%BD%B2-7-%E4%B8%AA%E7%94%9F%E4%BA%A7%E6%A8%A1%E5%BC%8F")
9. [vLLM vs SGLang vs TensorRT-LLM：选型指南](#vLLM vs SGLang vs TensorRT-LLM：选型指南 "#%E4%B9%9Dvllm-vs-sglang-vs-tensorrt-llm%E9%80%89%E5%9E%8B%E6%8C%87%E5%8D%97")
10. 常见问题排雷
11. 总结

---

一、为什么 vLLM 是 2026 年的默认选择

如果你在生产环境部署过 LLM，一定经历过这个噩梦：

模型权重占 26GB，A100 80GB 还剩 54GB。一个 2048 token 的序列 KV Cache 就要 1.7GB，理论上能跑 30 个并发。但实际上，传统引擎预分配最大长度，60-80% 的 KV Cache 内存被白白浪费 。

vLLM 的 PagedAttention 把这个浪费从 60-80% 压到了 4% 以下 ，配合 Continuous Batching，吞吐量比原生 Transformers 高出 14-24 倍 。

到 2026 年，vLLM 已经成为开源生产推理的事实标准 。TGI 已于 2025 年底进入维护模式，新项目不建议使用 。

---

二、PagedAttention：把 OS 虚拟内存搬进 GPU

2.1 问题本质：KV Cache 是内存碎片化的重灾区

LLM 推理时，每个 token 都要存储 Key 和 Value 向量，这就是 KV Cache。传统做法是为每个请求预分配一块连续的、最大长度的 GPU 内存：

请求 A: 实际输出 50 token，预分配 2048 token → 浪费 97.5%
请求 B: 实际输出 100 token，预分配 2048 token → 浪费 95.1%
请求 C: 实际输出 2000 token，预分配 2048 token → 浪费 2.4%

三个请求之间还产生外部碎片------中间的空隙无法被其他请求利用。

2.2 PagedAttention 的解法

vLLM 团队从操作系统虚拟内存中偷师，把 KV Cache 拆成固定大小的 Block（默认 16 个 token）：

OS 概念	vLLM 等价物	存储内容
虚拟页	逻辑 Block	连续的 token 位置（如 0-15）
物理帧	物理 Block	GPU 内存：[num_kv_heads, block_size, head_dim]
页表	Block Table	每个序列的逻辑 Block → 物理 Block 映射

核心优势：

1. 按需分配：请求只占用实际用到的 Block，没有预分配浪费
2. 非连续存储：Block 可以散落在 GPU 内存的任何位置，消除外部碎片
3. Copy-on-Write：Beam Search 或多个输出共享前缀时，共用物理 Block，引用计数为 1 时才复制

2.3 内核实现

PagedAttention CUDA 内核在计算 Attention 时：

1. 查询序列的 Block Table 找到物理 Block 位置
2. 从可能非连续的物理 Block 中读取 K 向量
3. 计算 Attention Score 并 Softmax
4. 加权求和 V 向量

有两个版本的内核：

• V1：每个 Block 一个线程组，适合小 batch
• V2：两阶段计算，先按 Block 算局部 Softmax，再全局归约，适合大 batch

---

三、2026 年 vLLM 重大更新一览

截至 2026 年 6 月，vLLM 已发布 v0.24.0，以下是几个改变游戏规则的更新 ：

3.1 Model Runner V2 成为所有 Dense 模型的默认执行路径

MRv2 替代了旧的执行引擎，带来了：

• 量化模型原生支持
• 实时 Embedding 推理
• Mamba 混合模型的前缀缓存
• 动态推测解码兼容完整 CUDA Graphs

3.2 PagedAttention 被移除

是的，你没看错。旧的 PagedAttention 实现已被删除，V1/MRv2 后端成为标准路径 。

3.3 Transformers 建模后端与原生 vLLM 一样快

2026 年的一个重要里程碑：通过 Transformers 后端加载的模型，推理速度与原生 vLLM 实现持平 。这意味着新模型架构的支持速度将大幅提升。

3.4 多层 KV Cache Offloading

vLLM 现在支持将 KV Cache 卸载到 CPU 内存、磁盘，甚至对象存储（如 S3），让长上下文推理不再受限于单卡显存 。

3.5 Rust 前端

实验性的 Rust 前端已支持多模态视频和音频输入，以及 vllm-bench 原生端口 。

---

四、5 分钟快速上手

4.1 环境检查

# 确认 NVIDIA Container Toolkit 已安装
docker run --rm --gpus all nvidia/cuda:12.1-base nvidia-smi

4.2 单 GPU 启动

docker run -d \
  --name vllm-server \
  --runtime nvidia \
  --gpus all \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HF_TOKEN=hf_你的Token \
  vllm/vllm-openai:v0.24.0 \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --gpu-memory-utilization 0.90

⚠️ 必须加 --ipc=host：vLLM 的多进程通信（尤其是 NCCL 张量并行）需要共享内存。如果不加，多卡场景会直接崩溃 。

4.3 测试 API

curl http://localhost:8000/health

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3.1-8B-Instruct",
    "messages": [{"role": "user", "content": "你好，介绍一下 vLLM"}],
    "max_tokens": 256
  }'

4.4 多 GPU 张量并行

当单卡放不下模型时（如 Llama-3-70B），使用 --tensor-parallel-size：

docker run -d \
  --name vllm-70b \
  --runtime nvidia \
  --gpus '"device=0,1,2,3"' \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:v0.24.0 \
  --model meta-llama/Llama-3-70B-Instruct \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.90

📝 注意 --gpus '"device=0,1,2,3"' 的引号转义是 Docker 的 JSON 字符串要求，不能省略 。

---

五、生产级 Docker Compose 配置

以下是一份可直接用于生产的配置，包含健康检查、资源限制和自动重启 ：

version: "3.8"

services:
  vllm:
    image: vllm/vllm-openai:v0.24.0
    container_name: vllm-server
    ports:
      - "8000:8000"
    volumes:
      - model-cache:/root/.cache/huggingface
    environment:
      - HF_TOKEN=${HF_TOKEN}
    ipc: host
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    command: >
      --model mistralai/Mistral-7B-Instruct-v0.3
      --max-model-len 4096
      --tensor-parallel-size 1
      --gpu-memory-utilization 0.90
      --max-num-seqs 256
      --host 0.0.0.0
      --port 8000
      --disable-log-requests
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 300s   # 模型加载可能需要几分钟

volumes:
  model-cache:

启动：

# 将 Token 写入 .env 文件（权限 600）
echo "HF_TOKEN=hf_你的Token" > .env
chmod 600 .env

docker compose up -d

🔒 安全提示 ：生产环境永远不要将 Token 直接写在 docker run 命令里，它会暴露在 docker inspect 和进程列表中。使用 .env 文件或 Docker Secrets 。

---

六、性能调优三板斧

6.1 第一板斧：量化

量化方式	位宽	显存节省	质量损失	推荐 GPU
AWQ	4-bit	~75%	极低	通用
GPTQ	4-bit	~75%	低	通用
FP8	8-bit	~50%	极低	Hopper/Ada (H100/A100)
NVFP4	4-bit	~75%	低	Blackwell

AWQ 在 vLLM 中的 CUDA 内核优化更成熟，通常比 GPTQ 表现更好 。

# AWQ 量化模型部署
docker run -d \
  --runtime nvidia --gpus all \
  --ipc=host -p 8000:8000 \
  vllm/vllm-openai:v0.24.0 \
  --model TheBloke/Llama-2-70B-AWQ \
  --quantization awq \
  --gpu-memory-utilization 0.95

# FP8 量化 ------ 需 Hopper/Ada 架构
docker run -d \
  --runtime nvidia --gpus all \
  --ipc=host -p 8000:8000 \
  vllm/vllm-openai:v0.24.0 \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --quantization fp8 \
  --dtype float16

实测数据：RTX 4090 上 Qwen2.5-7B AWQ 量化后吞吐 85.1 tok/s ，是 FP16 基线（37.2 tok/s）的 2.3 倍，显存从 17.3GB 降到 9.4GB 。

6.2 第二板斧：前缀缓存（Prefix Caching）

如果你的流量有大量重复前缀（如相同的 System Prompt、RAG 的固定上下文、多轮对话），开启前缀缓存可复用 KV Cache，减少 30-60% 的计算 。

--enable-prefix-caching

实测：在重复上下文的聊天场景中，前缀缓存减少了约 30% 的计算量 。

6.3 第三板斧：推测解码（Speculative Decoding）

用一个小的 Draft 模型预测多个 token，主模型并行验证。当 Draft 模型的接受率 ≥ 0.7 时，可获得 1.3-2 倍 的加速 。

--speculative-model TinyLlama/TinyLlama-1.1B-Chat-v1.0 \
--num-speculative-tokens 5

2026 年 vLLM 还新增了 MTP（Multi-Token Prediction）推测解码 和 DSpark/DFlash 等新的 Draft 模型后端，支持更广泛的模型架构 。

---

七、监控与告警：Prometheus 指标详解

vLLM 原生暴露 Prometheus 指标，接入 Grafana 即可可视化 。

7.1 四大黄金指标

指标	含义	告警阈值
vllm:time_to_first_token_seconds (P99)	首 Token 延迟	> 5s
vllm:time_per_output_token_seconds (P99)	流式输出延迟	> 200ms
vllm:gpu_cache_usage_perc	KV Cache 使用率	> 95%
vllm:num_requests_waiting	排队请求数	> 100

7.2 Prometheus 配置

# prometheus.yml
scrape_configs:
  - job_name: 'vllm'
    static_configs:
      - targets: ['vllm:8000']
    metrics_path: /metrics
    scrape_interval: 10s

7.3 关键洞察

num_requests_waiting 持续增长说明容量不足。此时水平扩容 （加实例）比垂直扩容（换更大 GPU）更有效，因为每个 vLLM 实例都会加载一份完整模型权重 。

---

八、Kubernetes 部署 7 个生产模式

8.1 核心问题：HPA 对 LLM 推理无效

标准的 Kubernetes HPA 基于 CPU 和内存扩缩容。但 LLM 推理时：

• CPU 利用率很低（计算在 GPU 上）
• GPU 内存恒定（vLLM 预分配给 KV Cache）

结果：高负载时 K8s 认为节点空闲，请求却在引擎内部排队，延迟持续恶化 。

8.2 正确做法：KEDA + 自定义指标

使用 KEDA 配合 Prometheus 触发器，基于 vllm:num_requests_waiting 和 vllm:gpu_cache_usage_perc 扩缩容 。

8.3 Probe 超时必须够长

模型加载可能需要 3-5 分钟，Probe 的 initialDelaySeconds 不能太小：

livenessProbe:
  httpGet:
    path: /health
    port: 8000
  initialDelaySeconds: 300   # 给足加载时间
  periodSeconds: 30
readinessProbe:
  httpGet:
    path: /health/ready
    port: 8000
  initialDelaySeconds: 300

8.4 冷启动优化

将模型权重预缓存到 PVC 上，避免每次 Pod 重启都重新下载。2026 年 5 月 NVIDIA 发布的 Dynamo Snapshot 可将单 GPU vLLM 冷启动降至接近零 。

8.5 节点策略

• 推理：使用 On-Demand GPU 节点（保证稳定性）
• 训练/批处理：使用 Spot 节点（节省成本）

---

九、vLLM vs SGLang vs TensorRT-LLM：选型指南

2026 年，三个引擎的表面功能已趋同（都支持 Continuous Batching、Paged KV Cache、FP8 量化），差异在于架构假设与运营成本的匹配度 。

9.1 性能对比（H100，Llama 3.3 70B FP8）

并发数	vLLM v0.18	SGLang v0.59	TensorRT-LLM v1.2
1	120 tok/s	125 tok/s	130 tok/s
10	650 tok/s	680 tok/s	710 tok/s
50	1,850 tok/s	1,920 tok/s	2,100 tok/s
100	2,400 tok/s	2,460 tok/s	2,780 tok/s

数据来源：2026 年 3 月 Spheron 独立测试 。

9.2 前缀重叠场景（Llama 3.1 8B）

引擎	吞吐	说明
vLLM	~12,500 tok/s	基线
SGLang	~16,200 tok/s	+29%，RadixAttention 前缀复用
TensorRT-LLM	~14,500 tok/s	编译内核优势，但无跨请求前缀缓存

数据来源：PremAI 2026 测试 。

9.3 选型决策树

你的场景是什么？
├── 模型更新频繁 / 多硬件（AMD/Intel/NVIDIA）
│   └── ✅ vLLM（默认选择，覆盖 80% 场景）
├── 高前缀重叠（RAG、多轮 Agent、固定 System Prompt）
│   └── ✅ SGLang（RadixAttention 带来 20-30% 提升）
├── 模型稳定 / 高并发 / NVIDIA 独占 / 能接受编译成本
│   └── ✅ TensorRT-LLM（吞吐领先 15-30%，但编译需 28 分钟）
└── 本地原型 / 个人使用
    └── ✅ Ollama

⚠️ TensorRT-LLM 的隐藏成本：每次模型更新需要 28 分钟的编译。对于每周发布多次的团队，这个成本会累积成巨大的流水线延迟 。

---

十、常见问题排雷

❌ No CUDA-capable device detected

• 检查 NVIDIA Container Toolkit 是否安装
• 确认命令里带了 --gpus all
• 验证：docker run --rm --gpus all nvidia/cuda:12.1-base nvidia-smi

❌ CUDA out of memory

• 降低 --gpu-memory-utilization（0.9 → 0.8）
• 缩短 --max-model-len（如从 8192 降到 4096）
• 启用量化（--quantization awq）
• 增加张量并行度（--tensor-parallel-size）

❌ 多卡启动失败 / NCCL 错误

• 必须加 --ipc=host，这是最常见的原因
• 或者使用 --shm-size=16gb 作为替代

❌ 模型加载后 API 无响应

• 查看容器日志：docker logs -f vllm-server
• 确认端口映射正确
• 检查 --max-model-len 是否超过模型实际支持长度

❌ 量化模型报错

• AWQ/GPTQ 需要使用预量化 的 Checkpoint，不能对原始 FP16 模型直接加 --quantization awq
• FP8 需要 Hopper/Ada 架构 GPU（H100/A100），RTX 3090 不支持

---

十一、总结

维度	建议
引擎选择	默认 vLLM；前缀重叠高选 SGLang；极致性能且模型稳定选 TensorRT-LLM
部署方式	开发用 Docker Run，生产用 Docker Compose / Kubernetes
GPU 利用率	0.85-0.90 是甜点，超过 0.95 容易 OOM
最大上下文	按实际需求设，不要直接用模型理论最大值
监控	盯紧 TTFT P99、KV Cache 使用率、排队深度
扩缩容	用 KEDA + 自定义指标，不要用 CPU/内存 HPA

2026 年的 vLLM 已经是一个成熟、稳定、高性能的生产级推理引擎。从 PagedAttention 的内存革命，到 Model Runner V2 的执行效率提升，再到多层 KV Offloading 的长上下文支持，vLLM 持续引领着开源 LLM 推理的边界。

---

如果这篇文章对你有帮助，别忘了点赞 👍 + 收藏 ⭐ + 关注 🔔，你的支持是我持续输出的动力！