1. 课程导入

欢迎来到《TensorRT-LLM 模型推理性能基准测试实战》课程。在正式开始动手测试之前，我们需要先回答三个关键问题：为什么要做基准测试？如何科学地做基准测试？需要准备哪些环境？本章作为全课程的基石，将帮助你建立正确的性能评估框架，避免在后续实验中走入“只测数字、不懂含义”的误区。

1.1 学习目标与课程结构

完成本章学习后，你将能够：

  • 准确描述 TensorRT-LLM 在推理性能优化中的定位与核心价值；
  • 区分延迟（Latency）、吞吐量（Throughput）、首 Token 延迟（TTFT）与Token 生成速率（ITL）等关键指标；
  • 独立完成基准测试环境的软硬件准备，包括 NVIDIA 驱动、CUDA、TensorRT-LLM 安装验证；
  • 理解基准测试的通用方法论，包括预热、并发控制、统计口径等核心概念。

本课程共 30 章，整体结构分为四大模块：

模块章节范围核心内容
基础入门第 1-5 章环境搭建、TensorRT-LLM 架构、引擎构建流程
性能指标与测试方法第 6-12 章延迟/吞吐/并发指标、官方 benchmark 工具、自定义压测脚本
高级优化与对比第 13-24 章FP8/INT4 量化、KV Cache、动态形状、多卡部署、vLLM 对比
实战案例与排障第 25-30 章生产环境案例、性能瓶颈定位、参数调优复盘
学习建议：每章均配有可复现的实验命令与预期结果区间。建议准备一张 GPU 显卡（NVIDIA Ampere 或更新架构，显存 ≥ 16GB），并按照章节顺序逐步操作，不要跳跃式学习，因为后续章节的对比结论依赖前序章节建立的测试基线。

1.2 基准测试基本概念与核心指标

基准测试（Benchmark）的本质是在受控条件下，用可量化的指标评估系统性能。对于 LLM 推理，我们需要同时关注“快不快”和“多不多”两个维度。下图展示了 TensorRT-LLM 推理性能测试的核心概念关系：

输入请求 并发数 / 提示词长度 TensorRT-LLM 推理引擎 批处理调度 KV Cache 管理 量化 / 并行策略 输出响应 生成 Token 数 核心性能指标 延迟 (Latency) 端到端响应时间 吞吐量 (Throughput) Tokens / 秒 TTFT 首 Token 延迟 ITL Token 间延迟 TTFT = Time To First Token | ITL = Inter-Token Latency

上图中的四个指标构成了 LLM 推理性能评估的核心四维。在实际测试中，它们往往相互制约：盲目提升吞吐量可能导致单请求延迟恶化，而过分追求低延迟又会降低整体吞吐。因此，基准测试的目标不是追求单一指标的最大化，而是找到符合业务场景的最佳平衡点。

1.3 环境准备与验证

在开始任何基准测试之前，必须确保软硬件环境正确。以下是推荐的环境配置清单：

组件推荐版本/配置验证命令
GPU 驱动≥ 535.104.05nvidia-smi
CUDA12.2 或 12.4nvcc --version
TensorRT-LLM≥ 0.9.0python -c "import tensorrt_llm; print(tensorrt_llm.__version__)"
Python3.10 或 3.11python --version
显存≥ 16GB（推荐 24GB+）nvidia-smi --query-gpu=memory.total --format=csv

安装 TensorRT-LLM 推荐使用 Docker 镜像，以获得一致的运行环境：

# 拉取官方镜像（以 0.9.0 版本为例）
docker pull nvcr.io/nvidia/tensorrt-llm:0.9.0

# 启动容器并挂载工作目录
docker run --gpus all -it --shm-size=2g \
  -v /home/user/benchmark:/workspace/benchmark \
  nvcr.io/nvidia/tensorrt-llm:0.9.0

# 容器内验证安装
python -c "import tensorrt_llm; print(f'TensorRT-LLM 版本: {tensorrt_llm.__version__}')"
常见环境坑点：如果 nvidia-smi 显示驱动正常但 TensorRT-LLM 导入失败，通常是因为 CUDA 版本与 PyTorch 不匹配。请务必使用官方 Docker 镜像，避免在宿主机上直接安装导致依赖冲突。另外，容器启动时务必添加 --shm-size=2g，否则多进程数据并行时会因共享内存不足而崩溃。

1.4 基准测试方法论与常见误区

一个科学的基准测试流程应遵循以下步骤：

  1. 明确测试目标：是测在线延迟还是离线吞吐？是单卡还是多卡？
  2. 固定模型与精度：例如 Llama-2-7B + FP16，不可中途更换。
  3. 预热引擎：丢弃前 10-20 个请求的结果，让 CUDA kernel 完成加载与显存分配。
  4. 控制并发：从 1 到 64 逐步增加并发数，记录每个并发档位的指标。
  5. 多次重复取均值：至少 3 轮，每轮 100+ 请求，避免偶然波动。
  6. 记录完整配置：包括 batch size、输入/输出长度、量化方式、GPU 型号。

以下是初学者最容易犯的四个错误，务必引以为戒：

  • 误区一：不做预热直接测。首次推理包含 CUDA 上下文初始化、显存分配等开销，会严重拉高延迟数据。正确做法是先发送 10~20 个请求“热身”，再开始正式记录。
  • 误区二：混淆 TTFT 与整体延迟。TTFT 只衡量从发送请求到收到第一个 Token 的时间，而整体延迟包含所有 Token 的生成时间。在流式输出场景下，两者差异巨大。
  • 误区三：忽略输入/输出长度的影响。LLM 的延迟与序列长度呈近似线性关系。测试时必须固定输入长度（如 512 tokens）和输出长度（如 128 tokens），否则数据无法横向对比。
  • 误区四：只测一个并发数。单并发下的延迟不能代表真实生产环境。生产系统通常有数十甚至数百并发请求，必须测试不同并发下的吞吐曲线，才能找到系统的饱和点。
← 上一章 📖 返回目录 下一章 →