📚 课程目录第1章课程导入

课程导入：吞吐调优为什么是LLM服务化绕不开的课题

学习目标与课程结构

欢迎进入《vLLM与TensorRT吞吐调优对比与选择》的第一章。在正式接触具体工具之前，我们需要先建立全局视野：这门课要解决什么问题，你将获得哪些能力，以及为什么“吞吐”这个指标在LLM推理服务中具有决定性意义。

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

准确描述吞吐（Throughput）与延迟（Latency）在LLM推理场景中的定义及权衡关系，理解二者为何不可兼得；
识别吞吐瓶颈的典型来源——从显存带宽、计算利用率到调度开销，建立系统性的性能分析框架；
理解vLLM与TensorRT-LLM在吞吐优化路径上的根本差异，为后续章节的深入对比打下认知基础；
掌握吞吐调优的通用方法论，包括基准测试、瓶颈定位、参数调整与验证的闭环流程。

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

模块	章节范围	核心内容
基础与原理	第1-6章	吞吐概念、GPU架构基础、KV Cache机制、连续批处理原理
vLLM深度调优	第7-14章	PagedAttention、调度策略、量化、并行配置、实测案例
TensorRT-LLM深度调优	第15-22章	图编译、显存池、In-flight Batching、引擎构建、实测案例
对比与选型	第23-30章	基准测试方法、成本模型、生产环境选型决策框架

吞吐调优的重要性：从用户体验到单位成本

在LLM服务化部署中，吞吐量（通常以tokens/s或requests/s衡量）直接决定了两个核心商业指标：服务容量与单位推理成本。假设你部署了一个7B参数的模型，单张A100 GPU在未优化时可能只能并发处理4个请求，而经过吞吐调优后，同样的硬件可以并发处理32个请求。这意味着在相同的硬件投入下，服务能力提升了8倍——每token的边际成本大幅下降。

然而，吞吐调优并非简单地“增大batch size”。它涉及一系列相互关联的决策：

批处理策略：动态批处理还是静态批处理？请求到达不均衡时如何处理？
KV Cache管理：显存中KV Cache如何分配、回收、复用？
计算优化：是否使用量化？算子融合到什么程度？
调度粒度：以request为单位还是以token为单位进行调度？

这些决策之间存在复杂的权衡关系。例如，增大batch size虽然能提高GPU利用率，但也会增加每个请求的排队延迟；使用连续批处理（Continuous Batching）能动态调整计算粒度，却对调度器提出了更高要求。理解这些权衡，正是本课程的核心价值所在。

实践提示：吞吐调优的收益往往超出直觉。一个经过系统调优的vLLM或TensorRT-LLM服务，相比默认配置通常能获得3-10倍的吞吐提升。这意味着在生产环境中，调优不是“锦上添花”，而是“生死攸关”。

吞吐与延迟：一对永恒的矛盾

在深入工具之前，必须先厘清吞吐与延迟的关系。假设一个推理服务当前吞吐为T tokens/s，平均每个请求的端到端延迟为L ms。当并发请求数增加时，吞吐会先上升（因为GPU利用率提高），但超过某个临界点后，排队延迟急剧增加，吞吐反而可能下降（因为显存溢出或调度开销过大）。

下图展示了LLM推理服务中吞吐、延迟与并发数之间的典型关系，以及调优介入的切入点：

这张图揭示了吞吐调优的本质目标：将吞吐曲线的峰值点向右推移。默认配置下，系统可能在并发数为20时就达到吞吐饱和；经过vLLM的PagedAttention优化或TensorRT-LLM的显存池管理后，同样的硬件可能支撑到并发数为80时才饱和。延迟曲线也随之右移——在相同的延迟预算（如SLO要求p99 < 500ms）下，系统能承载的负载大幅提升。

吞吐瓶颈的系统性来源

要有效调优，必须知道瓶颈在哪里。LLM推理的吞吐受限于多个层面，且不同场景下瓶颈位置不同。以下是需要建立的核心分析框架：

显存容量与带宽：KV Cache随并发线性增长，显存不足时只能降低batch size；同时，每个decode step都需要读取全部KV Cache，显存带宽往往成为最终物理瓶颈。
计算利用率：prefill阶段是计算密集型（GEMM），decode阶段是访存密集型（GEMV）。如果GPU的SM（流式多处理器）利用率不足50%，说明调度或批处理策略存在问题。
调度开销：每次迭代的调度决策、KV Cache分配、请求排队都会引入CPU开销。当GPU计算时间短于CPU调度时间时，GPU就会空闲等待。
框架运行时开销：Python解释器开销、张量拷贝、内存碎片化等，在高并发下会被放大。

常见误区：很多初学者认为“吞吐低就是GPU不够好”，于是盲目增加GPU数量。实际上，在未优化调度策略和KV Cache管理的情况下，增加GPU往往只能带来线性甚至亚线性的吞吐提升，而优化软件栈可能带来超线性的收益。先调优，再扩容，才是正确的成本策略。

vLLM与TensorRT-LLM：两条不同的调优路径

本课程对比的两个主角，代表了LLM推理优化的两种典型哲学：

vLLM：以PagedAttention为核心，从操作系统虚拟内存的分页机制获得灵感，将KV Cache划分为固定大小的块（block），通过块表实现非连续显存管理。其优势在于灵活的动态批处理和近乎零浪费的显存利用，特别适合请求到达模式不规则、并发波动大的在线服务场景。
TensorRT-LLM：以图编译与算子融合为核心，将整个模型编译为高度优化的CUDA内核，配合显存池（Memory Pool）和In-flight Batching实现极致性能。其优势在于确定性低延迟和峰值吞吐上限更高，但需要离线构建引擎，且对动态形状的适应性较弱。

一个直观的类比是：vLLM像是一个“智能调度中心”，擅长在复杂多变的交通流中动态分配车道；TensorRT-LLM则像是一条“预铺设的高速铁路”，一旦建成，列车能以固定高速度稳定运行，但改道或新增站点需要重新施工。理解这一本质差异，是后续章节中所有对比讨论的基础。

吞吐调优的通用方法论

尽管vLLM与TensorRT-LLM的优化手段不同，但调优流程遵循统一的方法论闭环：

1. 建立基准（Baseline）
   - 使用固定数据集（如ShareGPT或自定义混合负载）
   - 记录吞吐、延迟分布、GPU利用率、显存占用
   
2. 定位瓶颈（Profile）
   - 使用nvidia-smi、Nsight Systems、PyTorch Profiler等工具
   - 区分瓶颈类型：显存容量 / 显存带宽 / 计算 / 调度
   
3. 制定优化策略（Optimize）
   - 根据瓶颈选择对应手段（见下表）
   
4. 验证与回归（Validate）
   - 对比优化前后的吞吐-延迟曲线
   - 确保SLO（服务等级目标）不被破坏
   
5. 迭代（Iterate）
   - 每次只改变一个变量，避免混淆因素

下表总结了不同瓶颈对应的典型优化手段，这也是后续章节反复使用的决策参考：

瓶颈类型	典型现象	vLLM侧手段	TensorRT-LLM侧手段
显存容量不足	OOM或被迫降低并发	调整`gpu_memory_utilization`；启用PagedAttention块复用	配置`KV Cache显存池`；使用FP8/INT4量化
显存带宽受限	GPU利用率高但吞吐上不去	减少KV Cache碎片；增大块大小	使用`GEMV`专用内核；算子融合减少访存
调度开销大	GPU空闲等待，CPU占用高	启用`continuous batching`；调整最大并发数	使用`in-flight batching`；减少Python调用层
计算利用率低	SM占用率不足50%	增大batch size；使用`chunked prefill`	重新构建引擎；调整`max_batch_size`与`max_seq_len`

本章小结与课程预期

吞吐调优不是一组孤立的参数调整，而是对GPU硬件特性、LLM推理内存模式、调度算法和框架运行时开销的系统性理解与优化。vLLM与TensorRT-LLM分别从“显存管理”和“计算图优化”两个维度切入，殊途同归地指向同一个目标：在有限的硬件资源上，支撑尽可能多的并发请求，同时满足延迟约束。

在接下来的课程中，我们将逐一深入这些技术细节。你将看到：PagedAttention的块表如何运作、TensorRT-LLM的引擎构建过程如何影响运行时性能、两种框架在量化支持上的差异、以及如何通过科学的基准测试方法获得可信的对比数据。每一章都会配备可操作的代码示例和实测数据，帮助你不仅“听懂”，更能“上手”。

现在，让我们从GPU的硬件基础开始，逐步构建完整的吞吐调优知识体系。