3、vLLM核心原理：PagedAttention、Continuous Batching、投机解码等关键技术如何提升推理吞吐与效率

大语言模型（LLM）推理服务面临的核心矛盾在于：模型权重巨大、显存带宽昂贵，而在线服务的延迟与吞吐指标又相互制约。传统推理框架（如简单的FasterTransformer流水线或Naive HF Transformers）在长序列、高并发场景下，显存利用率低、GPU计算空闲率高，导致单位成本产出Token数远低于硬件理论峰值。vLLM之所以能在工业界迅速普及，并非因为它改变了Transformer的计算数学，而是它在显存管理、请求调度和计算流水三个层面做了系统性的工程创新。本章将深入拆解PagedAttention、Continuous Batching与投机解码（Speculative Decoding）三大核心技术的原理、适用边界与落地调优方法。

vLLM 三大核心引擎协同架构 并发请求流 多用户/多轮对话 Continuous Batching 迭代级调度 动态批大小/抢占 PagedAttention KV Block 分页管理 物理块映射/共享前缀 显存碎片消除 GPU 计算核心 Prefill + Decode 投机解码加速 投机解码（Speculative Decoding） 小模型草稿 + 大模型验证 → 单次前向生成多个Token 降低串行解码次数，提升单请求延迟与吞吐 核心收益指标 吞吐 ↑ 2-10x 显存利用率 ↑ 90%+ 首Token延迟 ↓

上图展示了vLLM三大核心技术的协同关系：请求流首先进入Continuous Batching调度器，由它决定哪些序列的哪些Token参与本轮迭代计算；调度器向PagedAttention显存管理器申请或释放KV Cache物理块；最终由GPU执行注意力计算。投机解码则是在Decode阶段引入的加速策略，它不改变调度与显存管理的基本逻辑，而是改变Token生成的计算模式。下面逐一深入剖析。

3.1 PagedAttention：从连续显存到分页式KV Cache

核心原理：为什么传统KV Cache是显存杀手？

在自回归生成中，每个请求都需要缓存历史Token的Key和Value矩阵，即KV Cache。假设模型维度为d，层数为L，序列长度为s，则单请求KV Cache大小为2 * L * s * d * sizeof(dtype)。以LLaMA-13B为例（L=40, d=5120），FP16精度下，每Token需约2*40*5120*2 = 819,200字节 ≈ 0.8MB。若并发处理100个请求，每个请求生成1024 Token，则仅KV Cache就需要约80GB显存——这远超单张A100 80GB的容量。传统框架（如HF Transformers）为每个请求预分配最大长度（如2048）的连续显存，导致两个严重问题：内部碎片（请求实际生成短，但预留长）和外部碎片（不同请求的KV Cache大小不一，显存空洞无法利用）。

PagedAttention借鉴操作系统虚拟内存分页思想，将KV Cache划分为固定大小的物理块（Block），每个Block可存储固定数量Token的KV数据（如16个Token）。逻辑上，一个请求的KV Cache是连续的Token序列；物理上，这些Block可以分散在显存任意位置，通过块表（Block Table）映射。注意力计算时，GPU kernel通过块表索引直接访问分散的物理块，无需数据搬移。

关键设计要点：
  • 块大小（Block Size）：典型值为16或32。块越小，显存碎片越少，但块表开销和kernel调度开销增大；块越大，管理效率高，但浪费可能增加。生产环境建议从16开始测试。
  • 共享前缀（Prefix Caching）：当多个请求共享相同系统提示词（如Few-shot示例或System Prompt）时，PagedAttention允许这些请求的物理块指向同一份KV数据，极大节省显存。实测在RAG场景下，前缀命中率可达60%-80%。
  • Copy-on-Write：当请求需要修改共享块时（如不同采样参数），vLLM会复制该块，保证隔离性。

判断方法：如何评估PagedAttention是否生效？

在vLLM启动日志中，观察GPU KV cache size和Maximum concurrency。如果显存利用率（通过nvidia-smi观察）从传统框架的40%-50%提升至85%以上，说明分页机制有效。更精确的指标是vllm:num_requests_running与vllm:gpu_cache_usage_perc。当gpu_cache_usage_perc接近0.9且无OOM时，说明显存管理高效。

案例拆解：长上下文场景下的显存节省

某金融文档问答系统，输入文档平均长度8000 Token，并发用户50人。使用传统HF框架时，每请求预分配12000 Token的连续显存，实际平均生成300 Token，显存浪费率高达97.5%。切换vLLM后，设置--max-model-len 16384，--gpu-memory-utilization 0.9，块大小16。实际显存占用从约120GB（需2张A100）降至约45GB（单张A100 80GB即可）。同时，由于共享了系统提示词（约500 Token），前缀缓存命中率约70%，额外节省约15%显存。最终吞吐从12 requests/s提升至38 requests/s。

常见误区：不要盲目调大--max-model-len。过大的max-len会导致vLLM预留过多显存给KV Cache，挤压模型权重和激活内存。应根据业务P99序列长度+20%余量设置。另外，PagedAttention对短请求（<100 Token）的优化收益有限，因为块表管理开销占比上升。

3.2 Continuous Batching：迭代级调度的威力

核心原理：从静态批处理到动态调度

传统推理框架采用静态Batching：收集一批请求，等所有请求都生成完毕（或达到最大长度）后才释放资源。这导致两个问题：一是气泡（Bubble）——批中短请求先结束，但GPU必须等待长请求，造成计算空闲；二是排队延迟——新到达请求必须等待当前批次完全结束才能进入。Continuous Batching（又称Iteration-level Scheduling）将调度粒度从“请求”细化为“迭代（Token）”。在每个解码步骤，调度器检查所有运行中请求的状态：已完成的请求立即释放显存并返回结果，同时从等待队列中拉入新请求，填充空闲的Batch Slot。这样GPU始终处理尽可能多的活跃序列，计算吞吐接近硬件峰值。

vLLM的调度器还支持抢占（Preemption）：当新请求优先级更高或显存不足时，可将低优先级请求的KV Cache换出到CPU内存（Swap），腾出GPU显存给高优先级请求。这类似于操作系统的进程调度。

操作流程：配置与监控

# 启动vLLM服务时，关键参数
--max-num-seqs 256          # 最大并发序列数，决定Batch上限
--max-num-batched-tokens 8192  # 单次迭代最大Token数，防止单步计算过重
--swap-space 16             # CPU换出空间（GB），用于抢占
--enable-prefix-caching      # 开启前缀缓存

监控指标：vllm:num_requests_waiting（等待队列长度）、vllm:num_requests_running（运行中序列数）、vllm:gpu_cache_usage_perc。理想状态是running接近max-num-seqs，且waiting不为0（说明GPU饱和）。若waiting持续增长而running未满，说明调度器未及时填充，需检查max-num-batched-tokens是否过小。

实战场景：混合负载下的调度策略

某在线客服机器人，请求分为两类：简单问答（平均生成50 Token）和文档摘要（平均生成500 Token）。若使用静态Batching，简单请求需等待摘要请求完成，P95延迟高达8秒。启用Continuous Batching后，调度器在每个迭代步骤将完成的简单请求移出，立即插入新请求。实测P95延迟降至1.2秒，吞吐提升4倍。进一步调优：设置--max-num-seqs 128，但发现GPU利用率仅70%，原因是max-num-batched-tokens默认值4096限制了单步计算量。调整为8192后，利用率提升至92%。

经验提醒：Continuous Batching对长尾请求（个别超长序列）敏感。若某个请求生成超过2000 Token，它会持续占用Batch Slot，导致其他请求饥饿。建议设置--max-model-len上限，并在应用层对超长生成任务进行截断或拆分。

3.3 投机解码：以小博大的计算加速

核心原理：草稿模型 + 并行验证

自回归解码的瓶颈在于串行性：每生成一个Token需要一次完整前向传播，而GPU的并行计算能力未被充分利用（Decode阶段是Memory-Bound）。投机解码的核心思想是：使用一个轻量级草稿模型（Draft Model，通常比目标模型小2-10倍）快速生成K个候选Token，然后目标模型（Large Model）对这K个Token进行一次前向传播，并行验证其概率分布。如果草稿模型的预测与目标模型一致（即目标模型对草稿Token的概率高于采样阈值），则这K个Token全部被接受，一次前向传播生成了K个Token；如果不一致，则从分歧点重新生成。数学上，投机解码保证输出分布与目标模型完全一致（无偏性），因为接受/拒绝遵循Metropolis-Hastings准则。

vLLM从0.4.2版本开始支持投机解码，支持两种模式：N-gram草稿（无需额外模型，基于历史Token匹配）和模型草稿（如LLaMA-68M作为LLaMA-7B的草稿）。

判断方法：何时该用投机解码？

场景特征推荐策略预期收益
Batch Size较小（<8），延迟敏感启用投机解码，草稿模型为1/10大小单请求延迟降低30%-50%
Batch Size较大（>32），吞吐优先谨慎使用，可能无收益甚至下降吞吐变化-5%~+10%
序列长度长，且重复Token多（如代码生成）使用N-gram草稿，k=5加速比可达2-3x
目标模型已量化（如INT8）不建议，草稿模型收益被量化抵消收益微弱

判断依据：如果GPU在Decode阶段的利用率低于30%（通过nvidia-smi观察），且Batch Size小于16，投机解码大概率有效。如果GPU利用率已高于70%，说明计算已饱和，投机解码的额外前向传播反而增加开销。

案例拆解：代码生成场景的加速实践

某AI编程助手，使用CodeLlama-7B，平均生成序列长度256 Token，并发请求数约10。初始P95延迟为3.2秒，吞吐为15 req/s。启用投机解码：草稿模型为CodeLlama-68M（约1/100大小），--speculative-model code-llama-68m，--num-speculative-tokens 5。实测接受率约0.6（即平均每次接受3个Token），单请求延迟降至1.8秒（-44%），吞吐提升至22 req/s（+47%）。但显存占用增加约1.2GB（草稿模型权重）。进一步调优：将--num-speculative-tokens从5调至8，接受率降至0.45，总收益反而下降，因为草稿模型在长序列预测后期准确率下降。最终确定最优值为5。

风险提示：投机解码不适用于所有模型。若目标模型本身很小（<1B），草稿模型难以找到更小的合适选择，收益为负。另外，投机解码会增加首Token延迟（因为需要草稿模型先跑一轮），对TTFT（Time To First Token）敏感的场景需权衡。vLLM中可通过--speculative-draft-tensor-parallel-size控制草稿模型的并行度，避免与主模型争抢GPU资源。

3.4 三者的协同与调优总结

三大技术并非孤立，而是层层递进：PagedAttention解决“显存放不下”的问题，是基础；Continuous Batching解决“GPU闲不住”的问题，是调度核心；投机解码解决“计算不够快”的问题，是锦上添花。在实际部署中，建议按以下顺序调优：

  1. 第一步：配置PagedAttention，设置合理的gpu-memory-utilization（0.85-0.95），确保显存利用率最大化。
  2. 第二步：调整Continuous Batching参数，观察gpu_cache_usage_perc和num_requests_running，使GPU计算单元饱和。
  3. 第三步：若延迟仍不达标，且Batch Size较小，引入投机解码，从num_speculative_tokens=3开始网格搜索。
最终复盘：某企业级推理集群，8×A100，部署LLaMA-70B。初始配置（HF框架）吞吐为80 req/s，显存利用率45%。经过三步调优后：PagedAttention使显存利用率达92%，Continuous Batching使吞吐提升至320 req/s，投机解码（草稿模型LLaMA-7B）在保持吞吐不变的情况下，将P95延迟从2.1秒降至1.4秒。最终综合收益：吞吐提升4倍，延迟降低33%，单卡成本下降60%。

需要强调的是，vLLM的调优是一个持续迭代的过程，没有一劳永逸的配置。建议建立监控看板，跟踪TTFT、TPOT（Time Per Output Token）、吞吐、显存利用率四个核心指标，根据业务流量特征动态调整参数。当并发模型版本更新时，需重新验证投机解码的接受率，因为草稿模型与目标模型的分布对齐程度会变化。

← 上一章 📖 返回目录 下一章 →