vLLM基础架构：核心组件、推理流程与吞吐关键参数

核心原理：vLLM的三大支柱

vLLM之所以能在企业级吞吐优化中占据核心地位，并非因为它是一个简单的模型封装，而是因为它从系统层面重构了大模型推理的内存管理与调度逻辑。理解其基础架构，是后续所有调优动作的前提。vLLM的架构可抽象为三大核心支柱：PagedAttention 管理器、连续批处理调度器与分布式张量并行运行时。

• PagedAttention 管理器（BlockManager）：将KV Cache划分为固定大小的物理块（默认16个token/块），通过块表（Block Table）实现逻辑连续、物理离散的显存分配。它彻底消除了传统预分配带来的内部碎片与外部碎片，使显存利用率接近理论极限。
• 连续批处理调度器（Scheduler）：采用迭代级调度（Iteration-level Scheduling），在每个解码步（Decode Step）动态决定哪些序列进入本轮计算。它支持抢占（Preemption）与交换（Swapping），当显存不足时，将低优先级序列的KV块换出到CPU内存，而非直接报错。
• 分布式运行时（Ray/TP）：通过张量并行（Tensor Parallelism）将单个Transformer层的权重与计算拆分到多张GPU上，同时利用Ray或原生NCCL实现跨节点通信。吞吐优化必须考虑通信与计算的Overlap。

方法流程：一次请求的完整生命周期

理解吞吐优化，必须清楚一个请求从进入vLLM到返回结果经历了哪些阶段。整个流程以迭代为基本单位，而非以请求为基本单位。这意味着不同请求可以处于不同阶段（有的在Prefill，有的在Decode），它们被混合在同一个批次中计算。

1. 请求接入与序列初始化：客户端发送请求后，vLLM将其包装为Sequence对象，分配初始逻辑块，并放入Scheduler的等待队列。
2. Prefill阶段（预填充）：调度器将等待队列中的请求加入当前批次，GPU并行计算输入提示词的注意力。此阶段计算密集，生成首个token，同时产生该序列的KV Cache。
3. Decode阶段（自回归解码）：每个迭代步只生成一个token。调度器检查所有运行中序列的状态，决定哪些继续解码、哪些因显存不足被抢占、哪些已生成结束符。
4. 块分配与释放：随着解码推进，新KV Cache不断写入新分配的物理块。当序列终止时，其占用的块被释放回BlockManager的空闲列表。
5. 输出聚合与返回：当序列触发EOS或达到max_tokens限制时，vLLM将其从运行批次中移除，通过流式或一次性方式返回完整生成结果。

案例场景：显存碎片化 vs. 调度开销

某企业部署Llama-3-8B模型，单卡A100-80G。初始配置使用max_num_seqs=64，gpu_memory_utilization=0.9，但实测吞吐仅为1200 tokens/s。通过vLLM的/metrics端点观察，发现vllm:num_preemptions_total指标持续增长，说明系统频繁发生抢占。

进一步分析发现，由于max_model_len设置为8192，而实际请求平均长度仅800 tokens，导致每个序列预留的KV Cache空间远超实际需求。BlockManager虽然消除了碎片，但调度器仍按最大长度估算显存占用，造成大量保留块闲置。

# 优化前配置
--max-model-len 8192
--max-num-seqs 64
--gpu-memory-utilization 0.9

# 优化后配置
--max-model-len 2048
--max-num-seqs 128
--gpu-memory-utilization 0.95
--block-size 16

调整后，虽然max_model_len降低，但实际请求长度远未触及上限。调度器现在能更准确地估算显存需求，将批次大小从64提升到128，吞吐提升至2100 tokens/s，提升幅度达75%。此案例说明：吞吐优化不是单纯调大某个参数，而是让调度器的显存估算与实际负载匹配。

误区与复盘：吞吐优化的常见陷阱