4、PagedAttention：显存管理、分页机制、块大小选择

核心原理：为什么传统显存管理会“卡脖子”

在深入了解 PagedAttention 之前，我们先看传统推理框架（如 HuggingFace Transformers 原生实现）的显存分配方式。对于每个请求，系统会预先为整个序列的 KV 缓存分配一块连续且固定大小的显存。假设最大序列长度为 2048，无论当前实际生成了多少 token，都会按最大长度预留空间。这种方式的直接后果是：

  • 内部碎片：实际生成 200 个 token 时，剩余 1848 个 token 的缓存空间被白白占用，无法被其他请求复用。
  • 外部碎片：不同请求的 KV 缓存大小不一，频繁申请与释放导致显存出现大量不连续空洞，即使总空闲显存充足，也可能因找不到连续大块而失败。
  • 过度预留：为了应对长尾请求，系统被迫按最大可能长度分配，导致显存利用率通常只有 20%～40%。

PagedAttention 借鉴操作系统虚拟内存的分页思想，将 KV 缓存划分为固定大小的块（Block），每个块存储固定数量 token 的键值向量。逻辑上连续的序列，在物理显存中可以不连续存放，通过块表（Block Table）建立映射关系。这样，显存分配以块为粒度按需进行，彻底消除了连续内存的约束。

关键类比：传统方式好比去图书馆一次性借走一整排书架（哪怕只看一本书），而 PagedAttention 是按需借阅单个书格，读到哪里借到哪里，归还后其他读者可立即使用该书格。

分页机制：块表与物理块的组织方式

PagedAttention 的核心数据结构包含两部分：逻辑块（对应序列的逻辑位置）与物理块（对应显存中的实际地址）。每个请求维护一张块表，记录其逻辑块到物理块的映射。当生成新 token 时，系统检查当前逻辑块是否还有空位；若已写满，则从显存分配器申请一个新的物理块，并在块表中追加一条映射记录。

逻辑块序列 逻辑块 0 token 0~3 逻辑块 1 token 4~7 逻辑块 2 token 8~11 逻辑块 3 （尚未分配） 块表（Block Table） 逻辑块 ID 物理块 ID 0 7 1 3 2 1 3 — 逻辑块 3 尚未映射 物理显存块 物理块 1 ← 逻辑块 2 物理块 2 空闲 物理块 3 ← 逻辑块 1 物理块 4 空闲 物理块 5 其他请求 物理块 6 空闲 物理块 7 ← 逻辑块 0 物理块 8 其他请求 物理块 9 空闲 逻辑上连续，物理上离散 块表记录映射关系，按需分配物理块 空闲块可被任意请求复用，消除碎片 逻辑块 已映射物理块 未分配逻辑块

上图展示了一个序列长度为 12（块大小=4）的 KV 缓存映射关系。逻辑块 0、1、2 分别映射到物理块 7、3、1，而物理块 2、4、6、9 仍处于空闲状态，可被其他并发请求使用。当逻辑块 3 产生新 token 时，系统会从空闲块列表中选取一个（如物理块 2）完成映射。

块大小选择：权衡碎片与调度开销

块大小（block_size）是 PagedAttention 中最核心的调优参数，直接影响显存利用率和计算效率。vLLM 默认使用 block_size=16（即每个块存储 16 个 token 的 KV 向量），但实际部署中需要根据场景调整。

块大小 显存碎片率 调度开销 适用场景
8 较低（细粒度分配） 较高（块表更长） 短请求为主、延迟敏感
16（默认） 中等 中等 混合负载、通用场景
32 较高（粗粒度浪费） 较低（块表更短） 长文本生成、高吞吐离线批处理
64 很高（尾部浪费明显） 极低 超长序列、追求极致吞吐

选择块大小时需要理解一个关键权衡：块越小，内部碎片越少，但块表条目越多，每次访问需要更多的地址转换开销。此外，GPU 的并行计算特性决定了块大小最好与注意力计算的数据并行粒度对齐。例如，当使用 16 头注意力且每个头处理 128 维时，一个块存储 16 个 token 的 KV 向量恰好能充分利用 Tensor Core 的矩阵乘单元。

案例：块大小对吞吐量的实际影响

我们在一台 8×A100（80GB）服务器上，使用 Llama-2-7B 模型进行离线批处理测试。输入为 1000 条平均长度 500 token 的提示词，输出长度限制为 1024 token。分别设置 block_size=8/16/32/64，记录显存峰值与吞吐量：

# vLLM 启动参数示例
python -m vllm.entrypoints.api_server \
    --model meta-llama/Llama-2-7b-hf \
    --max-num-seqs 256 \
    --block-size 16   # 可切换为 8/32/64 对比

# 测试结果（吞吐量：requests/s）
# block_size=8  → 12.4 req/s，显存峰值 71.2 GB
# block_size=16 → 13.8 req/s，显存峰值 68.5 GB
# block_size=32 → 13.1 req/s，显存峰值 74.3 GB
# block_size=64 → 11.2 req/s，显存峰值 79.8 GB

结果显示，block_size=16 在此场景下表现最优。块大小为 8 时，虽然碎片更少，但块表长度翻倍，地址转换和调度开销抵消了碎片收益；块大小为 32/64 时，由于部分请求输出长度不是块大小的整数倍，尾部浪费显著增加，导致显存峰值上升，吞吐量下降。

调参建议：如果请求长度分布集中（如聊天场景大多在 200~400 token），可尝试将块大小设为 32 以减少块表开销；如果请求长度差异极大（如混合短查询与长文档生成），保持 16 或降至 8 更稳妥。务必通过 A/B 测试对比实际吞吐量，而非仅看理论碎片率。

误区与复盘：PagedAttention 使用中的常见问题

  • 误区一：块大小越小越好。实际上，块大小过小会导致块表膨胀，增加显存访问次数和调度器压力。当块大小从 16 降至 8 时，块表条目数翻倍，GPU 需要更多指令处理地址映射，可能抵消碎片优化带来的收益。
  • 误区二：忽略“最后一块”的浪费。即使块大小设置合理，每个序列的最后一个块通常只有部分填充。对于大量短请求（平均长度远小于块大小），这种尾部浪费占比很高。此时应优先考虑动态块分配或更小的块大小。
  • 误区三：只关注显存总量，忽略带宽。PagedAttention 的离散物理块可能导致注意力计算时访问不连续的显存地址，增加显存带宽压力。实测中，当块大小小于 8 时，即使显存充足，吞吐量也可能因带宽瓶颈而下降。
  • 误区四：所有模型使用相同块大小。不同模型的 head_dim、层数、KV 通道数不同，最优块大小也随之变化。例如，7B 模型与 70B 模型的 KV 缓存单 token 大小差异显著，需要重新测试。
复盘提醒：在一次生产环境优化中，我们将块大小从 16 调整为 8，期望降低碎片率，结果吞吐量反而下降 6%。分析发现，该场景平均请求长度仅 120 token，块大小 8 时每个请求平均浪费 4 个 token 的块空间，碎片率从 12% 降至 9%，但块表查询耗时增加了 35%，最终得不偿失。这提醒我们：碎片率不是唯一指标，端到端吞吐量才是最终标准。

PagedAttention 通过分页机制将显存利用率从传统方案的 20%~40% 提升至 90% 以上，同时支持更灵活的批处理调度。理解块表映射原理、掌握块大小选择方法，是充分发挥 vLLM 性能的基础。在实际部署中，建议结合请求长度分布、模型结构和 GPU 特性进行系统性测试，找到最适合自身负载的配置组合。

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