课程导入：学习目标、课程结构、vLLM在生产环境中的重要性

为什么需要关注生产环境中的vLLM吞吐性能

大语言模型（LLM）从实验原型走向生产服务，吞吐量（Throughput）与延迟（Latency）成为决定服务成本、用户体验和系统稳定性的核心指标。vLLM 凭借 PagedAttention 显存管理、Continuous Batching 连续批处理等机制，已成为业界部署 LLM 的主流推理引擎之一。然而，“能跑起来”与“跑得高效”之间存在巨大鸿沟——同样的模型、同样的 GPU，不同的配置与压测方法可能带来数倍的吞吐差异。

在生产环境中，吞吐压测并非简单地发送请求并记录 QPS（每秒查询数）。它涉及请求并发模型、输入/输出 Token 长度分布、批处理策略、显存利用率、KV Cache 命中率、调度延迟等多个相互耦合的变量。若缺乏系统化的压测方法与优化思路，很容易出现“压测数据好看，上线后性能崩塌”的典型问题。

本节定位：本课程不讨论模型训练，也不深入 CUDA 底层优化，而是聚焦于生产环境 vLLM 服务的吞吐压测方法论、性能瓶颈定位与可落地的优化手段。你将学会用数据驱动的方式回答：“当前配置下，我的服务最大能承受多少并发？吞吐瓶颈在 GPU 算力、显存带宽、调度器还是网络？”

学习目标：完成本章节后你将能够

  • 理解 vLLM 吞吐压测的核心指标（吞吐量、TTFT、TPOT、端到端延迟）及其在生产决策中的意义；
  • 掌握生产级压测的完整流程：场景定义 → 脚本编写 → 数据采集 → 瓶颈分析 → 参数调优；
  • 识别 vLLM 配置参数（--max-num-seqs、--gpu-memory-utilization、--enable-prefix-caching 等）对吞吐的实际影响；
  • 能够区分吞吐瓶颈来自 GPU 计算、显存容量、CPU 调度还是客户端并发不足；
  • 建立一套可复用的压测基线模板，用于后续章节的对比实验。

课程结构概览

本课程共 30 章，按“基础 → 方法 → 实战 → 进阶”四个阶段递进。前 5 章夯实压测理论与环境准备；第 6～15 章深入吞吐压测的各类场景（静态/动态请求、长/短序列、多模型复用等）；第 16～25 章聚焦优化手段（调度参数、量化、前缀缓存、多卡并行）；最后 5 章为综合案例与故障复盘。每章均包含可执行的压测命令、参数解析与结果判读方法。

阶段章节范围核心主题关键产出
基础1～5压测指标、vLLM 架构、环境搭建压测基线模板
方法6～15不同负载模型下的压测设计场景化压测脚本库
优化16～25吞吐调优参数与架构调整优化决策树
实战26～30综合案例、故障排查、容量规划生产验收清单

vLLM 吞吐压测的核心概念模型

为了后续章节讨论有统一语境，这里先建立吞吐压测的三层观察模型：客户端层（并发连接数、请求速率）、服务层（vLLM 调度器、批处理窗口、队列长度）、资源层（GPU SM 占用、显存带宽、KV Cache 容量）。压测的本质是改变客户端层输入，观察服务层行为，最终度量资源层的效率边界。

vLLM 吞吐压测三层观察模型 客户端层 • 并发连接数 • 请求到达速率 • 输入/输出 Token 分布 • 超时与重试策略 压测工具：wrk / Locust / 自研 服务层 (vLLM) • 调度器排队长度 • Continuous Batching • 最大批处理窗口 • Prefill / Decode 阶段 关键参数：--max-num-seqs 等 资源层 (GPU) • SM 计算占用率 • 显存带宽利用率 • KV Cache 容量 • 显存碎片率 监控：nvidia-smi / DCGM 反馈：调整并发 / 参数 / 资源 核心度量指标 吞吐量: tokens/s TTFT: 首Token延迟 TPOT: 每Token输出时间 端到端延迟 压测目标：在满足延迟SLA前提下最大化吞吐

上图展示了贯穿全课程的分析框架。后续章节中，每次压测实验都会明确改变哪个层的哪个变量，并观察其对另外两层的影响。例如：增加客户端并发数（客户端层）→ 观察调度器队列是否堆积（服务层）→ 检查 GPU 利用率是否饱和（资源层）。这种分层思维能避免盲目调参。

生产环境中的典型吞吐挑战

在真实业务中，vLLM 吞吐压测常面临以下四类挑战，本课程后续章节将逐一展开应对方法：

  1. 请求特征高度动态：线上请求的输入长度、输出长度、主题分布随时间变化，静态压测脚本难以模拟真实负载；
  2. 多租户/多模型干扰：生产环境往往多个模型共享 GPU 资源，吞吐压测需考虑隔离性与公平性；
  3. 长尾延迟与超时：平均吞吐达标但 P99 延迟超标，导致上游服务超时重试，进一步加剧负载；
  4. 显存碎片与 OOM：长时间运行后 KV Cache 碎片化，有效吞吐下降，甚至触发 OOM 重启。
常见误区：许多团队用 ab 或 wrk 直接对 vLLM 的 /generate 接口发压，仅统计 HTTP 请求数/秒。这种做法忽略了 LLM 推理的生成式特性——每个请求的输出 Token 数不同，导致“请求 QPS”无法反映真实的 token 吞吐。本课程统一采用 tokens/s 作为吞吐主指标，并辅以 TTFT/TPOT 作为延迟约束。

压测前的环境准备清单

在进入具体压测方法之前，请确认以下环境要素已就绪。后续章节的示例均基于此标准环境：

  • GPU：NVIDIA A100/A800 或 H800（显存 40GB/80GB），驱动版本 ≥ 525；
  • 推理引擎：vLLM ≥ 0.4.2（建议使用最新稳定版）；
  • 模型：以 Qwen2.5-7B-Instruct 或 Llama-3.1-8B-Instruct 为主要测试对象；
  • 压测工具：Python 3.10+，安装 openai、aiohttp、numpy、pandas；
  • 监控工具：nvidia-smi dmon 或 DCGM exporter，用于采集 GPU 实时利用率。
# 验证 vLLM 服务是否正常启动（示例）
curl -X POST http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen2.5-7B-Instruct",
    "prompt": "什么是吞吐压测？",
    "max_tokens": 64,
    "temperature": 0
  }'
← 上一章 📖 返回目录 下一章 →