📚 课程目录第2章 vLLM基础

2. vLLM基础：vLLM架构、核心特性、与常见推理框架对比

2.1 为什么多GPU场景下需要重新审视vLLM

在单卡推理时代，吞吐优化的核心往往围绕算子融合、显存复用和批处理策略展开。但当我们将视野扩展到多GPU集群时，问题发生了质变：吞吐瓶颈不再单纯由单卡算力决定，而是由跨卡通信效率、KV Cache分布策略、负载均衡机制以及调度器的全局视野共同决定。vLLM之所以成为当前生产环境中最主流的推理框架之一，正是因为它从架构层面为这些问题提供了系统性的解决方案。

理解vLLM的架构，不能停留在“它是一个推理加速库”的层面。我们需要拆解其核心组件——PagedAttention 显存管理、Continuous Batching 动态调度、分布式张量并行与数据并行——并厘清它们如何协同工作，才能在多GPU场景下定位吞吐失衡的根因。

学习提示：本节内容是多GPU调优的“地基”。如果你对vLLM的架构理解停留在“显存省了一半”的层面，后续排查吞吐瓶颈时会缺乏全局判断力。建议结合官方文档中关于分布式推理的架构图进行对照阅读。

2.2 vLLM核心架构：从单卡到多卡的演进逻辑

vLLM的架构设计围绕一个核心矛盾展开：KV Cache的显存碎片化与动态增长特性。传统推理框架预先为请求分配固定大小的显存块，导致显存利用率低且无法支持超长序列。vLLM借鉴操作系统虚拟内存分页思想，提出了PagedAttention机制，将KV Cache划分为固定大小的块（默认16个token/块），按需分配，逻辑上连续、物理上可离散。

这一设计在多GPU场景下产生了深远影响：

显存利用率提升：块级管理使得显存碎片减少，单卡可容纳更多并发请求，为高吞吐奠定基础。
KV Cache迁移成本：当请求在分布式执行中需要跨设备访问KV Cache时，块级粒度反而增加了通信开销——这是多卡调优中容易忽视的“隐性成本”。
调度器复杂度上升：全局调度器需要同时管理多个设备的空闲块列表，块分配的均衡性直接影响各GPU的负载。

在分布式维度，vLLM支持两种并行策略的叠加：

张量并行（Tensor Parallelism, TP）：将单个Transformer层的权重矩阵按行/列切分到多张GPU，每张卡只计算部分矩阵乘法，通过AllReduce同步结果。适用于单模型过大或单卡算力不足的场景。
数据并行（Data Parallelism, DP）：每张卡持有完整模型副本，处理不同的请求批次，通过调度器协调负载。适用于请求量巨大、单卡吞吐已饱和的场景。

实际部署中，两者常组合使用（如TP=4, DP=2），形成二维并行网格。吞吐均衡调优的核心，就是在这个网格中寻找通信开销与计算利用率的最佳平衡点。

2.3 核心特性：吞吐优化的三大支柱

vLLM的吞吐优势并非来自单一技术，而是三项核心特性的协同效应。理解它们之间的依赖关系，是后续调优的前提。

2.3.1 PagedAttention：显存效率的质变

传统推理框架（如FasterTransformer）为每个请求预分配最大序列长度的KV Cache，实际利用率往往不足40%。PagedAttention将显存管理粒度从“序列级”细化为“块级”，使得显存利用率可提升至90%以上。但需要注意：块大小（--block-size）是调优参数。块过小增加管理开销，块过大则重新引入内部碎片。在多GPU场景下，块大小还影响KV Cache传输的粒度——块越小，跨卡传输的调度越灵活，但通信次数也越多。

2.3.2 Continuous Batching：动态请求合并

静态批处理必须等待批次中最慢的请求完成才能释放资源。vLLM的Continuous Batching允许在token生成间隙动态插入新请求、移除已完成请求，使GPU始终处于满负荷计算状态。这一特性对吞吐提升贡献显著，但也带来了新的问题：调度器的抢占策略和优先级队列设计会直接影响各GPU的请求分布，进而导致吞吐不均衡。

2.3.3 分布式并行：张量并行与数据并行

vLLM通过--tensor-parallel-size和--pipeline-parallel-size参数控制并行策略。在多GPU吞吐调优中，最常见的失衡场景是：TP组内通信开销过大导致计算等待，或DP组间请求分配不均导致部分GPU空闲。下表对比了两种并行策略的适用场景与调优关注点：

维度	张量并行 (TP)	数据并行 (DP)
模型切分方式	权重矩阵按行/列切分到多卡	每卡持有完整模型副本
通信模式	每个Transformer层内AllReduce	仅调度器分发请求，无层间通信
显存需求	单卡显存需求降低	每卡需容纳完整模型+KV Cache
吞吐瓶颈	通信带宽、AllReduce效率	调度器负载均衡、请求队列深度
典型调优参数	--tensor-parallel-size, NCCL环境变量	--max-num-seqs, 调度策略

2.4 与常见推理框架的对比：定位vLLM的适用边界

多GPU吞吐调优的第一步，是确认vLLM是否适合当前场景。下表从吞吐、显存效率、易用性和多卡支持四个维度进行对比：

框架	吞吐表现	显存管理	多GPU支持	核心优势	主要局限
vLLM	极高（Continuous Batching）	PagedAttention块级管理	TP/DP/PP，成熟	显存效率高，吞吐领先	调度器配置复杂
TensorRT-LLM	高（图优化+内核融合）	显存池化，但需预分配	TP/PP，需编译	延迟极低，适合生产	编译时间长，灵活性差
FasterTransformer	中高	静态分配，碎片多	TP支持有限	轻量，易于集成	无动态批处理，显存浪费
HuggingFace TGI	中	简单缓存	基础TP	生态好，易上手	吞吐优化空间有限

选型建议：如果目标是最大化多GPU吞吐且请求长度波动大，vLLM是首选；如果追求极致延迟且模型固定，TensorRT-LLM可能更合适；如果只是快速验证，TGI足够。本课程后续调优均基于vLLM展开。

2.5 常见误区与复盘：多GPU吞吐调优的认知陷阱

在开始调优之前，先厘清几个容易误导方向的认知误区，能帮你少走弯路。

误区一：GPU利用率高 = 吞吐高
GPU利用率（如nvidia-smi显示的100%）只代表计算单元忙碌，不代表有效token产出高。可能大量算力消耗在等待通信、无效计算或过度抢占上。调优时应关注端到端吞吐（tokens/s）而非GPU利用率。

误区二：TP越大越好
TP=8时，每个Transformer层需要8次AllReduce通信。当模型较小或请求并发不足时，通信开销可能超过并行收益。经验法则：TP大小不超过单节点GPU数，且模型参数量/TP值应大于单卡显存的1/3。

误区三：忽略调度器配置
很多调优者只关注并行参数，却忽略了--max-num-seqs、--max-model-len等调度器参数。这些参数决定了Continuous Batching的队列深度和KV Cache预留策略，对多GPU负载均衡影响巨大。

复盘案例：某团队在8×A100上部署70B模型，初始配置TP=8，发现GPU利用率波动剧烈（30%~95%），吞吐仅1200 tokens/s。排查后发现：TP=8导致AllReduce通信占每次迭代时长的40%；且--max-num-seqs设置过小（64），无法填满通信间隙的计算。调整为TP=4 + DP=2，并将--max-num-seqs提升至256后，吞吐提升至3800 tokens/s，且各GPU利用率稳定在85%左右。