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

课程导入：vLLM简介、批处理与吞吐量的核心概念、课程目标与学习路径

大语言模型（LLM）推理服务正从“能用”走向“用得省、跑得快”。当模型参数量从70亿跃升至数千亿，单次请求的显存占用和计算开销呈指数级增长，而GPU资源却始终是稀缺资产。vLLM作为当前最受关注的高性能LLM推理引擎，通过PagedAttention、Continuous Batching等机制，将推理吞吐量提升数倍至数十倍。本章作为课程起点，将厘清vLLM的核心设计动机、批处理与吞吐量的本质关系，并明确后续29章的学习路径。

1.1 vLLM的设计动机与核心价值

核心原理：为什么传统推理框架难以满足大规模部署需求？

传统LLM推理服务（如基于HuggingFace Transformers的朴素实现）存在两个致命瓶颈：显存碎片化与静态批处理。在自回归生成过程中，每个请求都需要维护一份KV Cache（键值缓存），其大小随序列长度动态增长。朴素实现会为每个请求预分配最大可能长度的连续显存空间，导致大量显存浪费——实际使用率往往不足40%。同时，传统框架采用“等待批满再执行”的静态策略，当请求到达速率不均匀时，GPU算力频繁空闲，吞吐量极低。

vLLM的核心创新在于PagedAttention技术，它借鉴操作系统虚拟内存的分页思想，将KV Cache划分为固定大小的块（Block），按需分配、动态映射。这一设计将显存利用率提升至90%以上，并允许更多请求同时驻留GPU，为高吞吐批处理奠定基础。此外，vLLM实现了Continuous Batching（连续批处理），在迭代级别动态调整批大小——当一个请求生成完毕，立即插入新请求，无需等待整个批次完成。

  关键数据对比：在A100-80G GPU上，使用LLaMA-7B模型，vLLM的吞吐量可达HuggingFace Transformers的14倍，而显存占用仅为后者的1/3。这一差距在长序列场景下进一步拉大。

判断方法：何时应该选择vLLM？

场景特征	推荐框架	原因
高并发在线推理（>50 QPS）	vLLM	连续批处理最大化GPU利用率
长文本生成（>2K tokens）	vLLM	PagedAttention避免长序列显存爆炸
离线批量处理（非实时）	vLLM / TensorRT-LLM	两者均可，vLLM更易用
多模型混合部署	vLLM	支持多LoRA适配器动态加载
低延迟单请求（<100ms）	vLLM + 流式输出	需配合调度策略优化

案例拆解：从“显存危机”到“吞吐量翻番”

某互联网公司需要部署一个70B参数的对话模型，使用2张A100-80G GPU。初始采用Transformers + 静态批处理，遇到以下问题：

显存溢出：当并发请求数超过8个，单请求上下文长度达到4K tokens时，OOM频繁发生。
GPU利用率低：平均利用率仅35%，大量时间浪费在等待批满。
响应延迟抖动：批处理周期内，后加入的请求等待时间长达30秒。

切换到vLLM后，通过以下步骤完成优化：

将模型转换为vLLM支持的格式，设置--max-model-len 8192，启用PagedAttention。
配置--gpu-memory-utilization 0.92，允许vLLM使用92%的显存用于KV Cache。
启用Continuous Batching，设置--max-num-seqs 256，允许最多256个序列同时生成。

结果：并发请求数从8提升至64，吞吐量从120 tokens/s提升至1,850 tokens/s，P95延迟稳定在2.8秒以内。显存利用率从40%提升至88%。

注意：盲目调大--max-num-seqs可能导致单个请求的生成速度变慢（TPOT上升）。需要根据业务SLA平衡吞吐量与单请求延迟。

1.2 批处理与吞吐量的核心概念

核心原理：吞吐量的数学定义与影响因素

在LLM推理语境下，吞吐量通常定义为每秒生成的Token数（tokens/s）或每秒完成的请求数（requests/s）。其计算公式可简化为：

吞吐量 = (GPU计算能力 × 批大小 × 平均序列长度) / (单Token生成延迟 × 总开销)

批处理（Batching）是提升吞吐量的最直接手段。当多个请求共享一次模型前向传播时，权重矩阵的加载成本被摊薄，GPU的并行计算能力得到充分利用。但批处理并非越大越好——批大小受限于显存容量（KV Cache占用）和计算延迟（批内最长序列决定迭代时间）。

vLLM中的批处理粒度是迭代级（Iteration-level），而非传统的请求级。每个解码步骤（Decode Step）都会重新计算最优批组合，这意味着：

短请求与长请求可以混合批处理，互不阻塞。
请求完成时立即腾出显存空间，新请求可即时加入。
批大小在每次迭代中动态变化，始终逼近显存上限。

判断方法：吞吐量瓶颈定位

当吞吐量不达标时，需要从以下维度排查：

瓶颈类型	典型症状	诊断工具	优化方向
显存瓶颈	OOM、KV Cache命中率低	`nvidia-smi`、vLLM日志	增大`gpu-memory-utilization`、减少max-model-len
计算瓶颈	GPU利用率>95%，但吞吐量低	Nsight Compute	减少批大小、使用更小精度（FP8/INT8）
调度瓶颈	GPU利用率波动大	vLLM metrics	调整调度策略、启用抢占
数据加载瓶颈	GPU等待数据	CPU利用率、网络IO	增加prefetch、优化tokenizer

实战场景：理解TTFT与TPOT

吞吐量优化不能只看单一指标。两个关键延迟指标必须同时关注：

TTFT（Time To First Token）：从请求发出到收到第一个Token的时间。受排队等待和Prefill阶段影响。
TPOT（Time Per Output Token）：生成每个后续Token的平均时间。受Decode阶段计算效率和批大小影响。

在vLLM中，Prefill和Decode阶段可以重叠执行（Chunked Prefill），进一步降低TTFT。但过度追求低TTFT会牺牲吞吐量，需要根据业务SLA设置优先级。

经验建议：对于聊天机器人等交互式应用，TTFT应控制在1秒内；对于离线批处理任务，可以接受5秒以上的TTFT以换取更高吞吐量。vLLM提供了--max-prefill-tokens参数控制Prefill阶段的最大Token数，用于平衡两者。

1.3 课程目标与学习路径

核心原理：从“会用”到“会调优”的能力进阶

本课程的目标不是简单教会你运行vLLM，而是培养三种核心能力：

诊断能力：通过监控指标和日志，快速定位吞吐量瓶颈。
调优能力：掌握批处理策略、调度参数、显存配置的联合优化方法。
架构能力：能够设计满足不同业务场景（低延迟/高吞吐/混合负载）的推理架构。

学习路径：30章知识地图

阶段	章节范围	核心能力
基础篇	第1-5章	vLLM架构、PagedAttention原理、安装部署、基础API使用
批处理篇	第6-12章	Continuous Batching、动态批大小、请求调度、抢占策略
吞吐量调优篇	第13-22章	显存优化、量化、并行策略（TP/PP/DP）、性能分析工具
生产实战篇	第23-30章	高可用部署、监控告警、多模型管理、故障排查、容量规划

案例拆解：一个典型的学习闭环

假设你负责一个文档摘要服务的性能优化，初始吞吐量为200 tokens/s，目标为800 tokens/s。按照课程路径，你将经历以下过程：

第3章：学会使用vllm serve部署模型，并通过/metrics端点获取吞吐量、延迟、显存使用等指标。
第7章：理解Continuous Batching的工作机制，发现当前批大小仅为16，远低于显存允许的64。
第9章：调整--max-num-seqs至64，并启用--enable-prefix-caching，吞吐量提升至450 tokens/s。
第15章：应用FP8量化，将模型显存占用降低30%，进一步增大批大小至96，吞吐量达到700 tokens/s。
第21章：使用性能分析工具发现Prefill阶段存在计算浪费，启用Chunked Prefill后，吞吐量最终稳定在850 tokens/s。

常见误区：不要一开始就追求“最大批大小”。批大小增加会线性提升TPOT，当TPOT超过业务容忍阈值（如5秒）时，即使吞吐量再高也无意义。正确的做法是：先确定延迟SLA，再反推最大批大小。

总结复盘：本章核心要点

vLLM通过PagedAttention解决显存碎片化，通过Continuous Batching实现迭代级动态批处理。
吞吐量优化是系统工程，需要同时关注显存、计算、调度、数据加载四个维度。
TTFT与TPOT是衡量用户体验的关键指标，与吞吐量存在权衡关系。
本课程按“基础→批处理→调优→实战”四阶段递进，每章均包含原理、方法、案例、误区四个模块。