2、vLLM核心架构与工作原理：PagedAttention、Continuous Batching、KV Cache管理、调度器机制

在生产环境中部署大语言模型（LLM）时，我们面对的核心矛盾是：GPU显存有限，而模型权重、KV Cache、中间激活值都在争夺显存；同时，在线服务要求低延迟与高吞吐并存。vLLM之所以能在众多推理框架中脱颖而出，正是因为它从操作系统虚拟内存管理中借鉴了分页思想，并配合连续批处理与精细化的调度器，将显存利用率与请求吞吐推向了新的高度。本章将深入拆解vLLM的四大核心支柱——PagedAttention、Continuous Batching、KV Cache管理以及调度器机制，为后续的高并发优化方案奠定坚实的原理基础。

上图展示了vLLM各核心模块之间的协作关系。调度器接收并发请求，通过连续批处理机制动态组织计算批次；KV Cache管理器负责物理显存块的分配与回收；PagedAttention则实现了在非连续显存块上的高效注意力计算。下面我们逐一深入剖析每个模块的原理与工程实现。

2.1 PagedAttention：非连续显存中的注意力机制

核心原理：从操作系统分页到注意力计算

传统推理框架（如HuggingFace Transformers）在计算注意力时，需要为每个请求预先分配连续的KV Cache显存空间。由于无法预知生成序列的最大长度，通常按最大序列长度（如2048或4096 tokens）进行预分配，这导致显存浪费高达60%-80%。PagedAttention的灵感来源于操作系统的虚拟内存分页：将KV Cache划分为固定大小的物理块（Block），每个块可存储若干个token的Key和Value向量。逻辑上连续的KV Cache可以映射到物理上不连续的显存块中，从而彻底消除内部碎片和外部碎片。

判断方法：如何识别PagedAttention带来的收益

在生产环境中，我们可以通过以下指标判断PagedAttention是否生效：

• 显存利用率：使用nvidia-smi观察显存占用，对比同等并发下的峰值显存。vLLM通常能将KV Cache显存利用率提升至90%以上。
• 吞吐量：在相同GPU型号下，vLLM的吞吐量（tokens/s）通常是HF Transformers的2-4倍。
• 块命中率：通过vLLM的监控接口（/metrics）查看vllm:num_blocks_lookup_hits等指标，高命中率说明块复用良好。

案例拆解：并行采样场景下的显存节省

假设我们使用GPT-3 175B模型（每token KV Cache约2MB），生成最大长度1024 tokens。传统方式预分配1024个token的连续显存，即2GB。而实际平均生成长度可能只有256 tokens，浪费了75%的显存。使用PagedAttention后，系统按需分配物理块，实际仅占用512MB。更极端的情况是并行采样（n=5），5个序列共享相同的前缀Prompt，PagedAttention通过写时复制（Copy-on-Write）技术，让所有序列共享前缀部分的物理块，仅在分叉点复制新块，显存节省可达5倍。

2.2 Continuous Batching：迭代级动态调度

核心原理：从静态批处理到迭代级调度

传统的静态批处理（Static Batching）将多个请求组成一个批次，直到批次内所有序列生成完毕才释放资源。这会导致两个问题：一是短请求被长请求阻塞，产生大量等待；二是批次内已完成的序列占用的显存无法及时释放。Continuous Batching（连续批处理）将调度粒度从“请求级”细化为“迭代级”（即每个decode步骤）。在每个解码迭代中，调度器都会检查当前批次中是否有序列已完成生成，并立即将其移出批次，同时从等待队列中调入新的请求。这样GPU始终在处理活跃的序列，计算资源利用率大幅提升。

操作流程：连续批处理的调度循环

1. 初始化：从等待队列中选取若干请求，组成初始批次（prefill阶段）。
2. 迭代循环：对批次内所有序列执行一次前向传播，生成下一个token。
3. 完成检测：检查是否有序列生成<EOS>或达到最大长度，若有则释放其KV Cache块。
4. 动态补充：从等待队列中选取新请求，加入当前批次（需满足显存与算力约束）。
5. 重复步骤2-4，直到所有请求处理完毕。

实战场景：混合负载下的吞吐提升

在一个典型的RAG应用中，用户查询长度差异巨大：有的查询只有10个token，有的则包含2000个token的上下文。使用静态批处理时，一个长查询会阻塞后续所有短查询。采用Continuous Batching后，短查询可以在长查询的prefill阶段结束后立即插入批次，平均响应时间（TTFT）降低约40%，整体吞吐提升2.3倍。下表展示了不同批处理策略的对比：

指标	静态批处理	Continuous Batching
GPU利用率	60%-70%	85%-95%
平均TTFT	850ms	420ms
吞吐量 (tokens/s)	1,200	2,800
长请求阻塞短请求	严重	几乎无

2.3 KV Cache管理：块分配、引用计数与写时复制

核心原理：显存即资源池

vLLM将KV Cache视为一个统一的显存资源池，由BlockManager统一管理。每个Block包含固定数量的token槽位。BlockManager维护三类数据结构：物理块表（记录所有物理块的状态）、逻辑块表（每个序列的逻辑块到物理块的映射）、引用计数（每个物理块被多少个序列引用）。当序列需要新的KV Cache空间时，BlockManager从空闲块列表中分配；当序列完成时，递减引用计数，计数归零的块归还空闲列表。

写时复制（Copy-on-Write）机制

在并行采样或beam search场景中，多个序列共享相同的前缀。vLLM不会为每个序列复制前缀的物理块，而是让它们共享同一物理块，并将引用计数加1。只有当某个序列需要修改共享块中的内容（即生成不同的token）时，才分配新的物理块并复制原块内容。这一机制在保证正确性的同时，极大节省了显存。

案例拆解：beam search的显存优化

假设beam width=4，序列长度为512 tokens，其中前256 tokens为共享前缀。传统方式需要4×512=2048个token的KV Cache。使用写时复制后，前缀部分仅需256个token的物理块（共享），分叉部分需要4×256=1024个token，总计1280个token，节省37.5%显存。在长序列场景（如代码生成）中，节省效果更为显著。

2.4 调度器机制：抢占、排队与优先级

核心原理：多级调度策略

vLLM的调度器采用分层设计：请求级调度决定哪些请求进入候选池；序列级调度决定候选池中哪些序列参与当前迭代的计算。调度器需要平衡多个目标：最大化吞吐、最小化延迟、保证公平性、避免显存溢出。其核心策略包括：

• FCFS（先来先服务）：默认策略，保证公平性。
• 优先级调度：支持按请求优先级（如VIP用户）或按序列长度（短序列优先）进行排序。
• 抢占机制：当显存不足时，调度器会抢占低优先级序列的物理块，将其KV Cache换出到CPU内存（swap），腾出空间给高优先级请求。

操作流程：调度决策路径

每个迭代步骤：
1. 检查等待队列 → 是否有新请求可加入
2. 检查运行队列 → 是否有序列已完成
3. 计算当前显存余量 → 是否可容纳新请求
4. 若显存不足 → 触发抢占策略（swap out低优先级序列）
5. 确定最终批次 → 执行前向传播

实战场景：高并发下的调度策略调优

在一个在线客服场景中，高峰期并发请求达到200 QPS，平均生成长度150 tokens。默认FCFS策略下，长文档问答请求（生成500 tokens）会阻塞短回复请求（生成30 tokens），导致P95延迟飙升至3秒。通过配置--priority-policy为short-first，并设置--max-num-seqs为64，短请求优先执行，P95延迟降至800ms，整体吞吐提升18%。

调度策略	适用场景	优势	劣势
FCFS	通用负载	公平、实现简单	长请求阻塞短请求
Shortest First	混合负载	降低平均延迟	长请求可能饿死
Priority-based	多租户/付费分级	保障高优用户	需额外维护优先级

2.5 总结复盘：核心要点与常见误区

本章我们系统梳理了vLLM的四大核心机制。PagedAttention解决了显存碎片化问题，Continuous Batching提升了计算利用率，KV Cache管理实现了显存的高效复用，调度器机制则保障了多请求场景下的服务质量。在实际优化过程中，需要避免以下常见误区：

• 误区一：盲目增大--max-num-seqs。过大的批次会导致显存溢出或延迟飙升，应根据模型大小和显存容量动态调整。
• 误区二：忽略--gpu-memory-utilization参数。该参数控制KV Cache可用的显存比例，默认0.9，但若模型权重较大，应适当降低至0.8-0.85，避免OOM。
• 误区三：将vLLM的调度器与Kubernetes的HPA混淆。vLLM调度器是进程内请求调度，而HPA是实例级扩缩容，两者需要配合使用。