Prefill 与 Decode 阶段算力剖析：KV Cache 对显存的吞噬机制

Prefill 与 Decode 阶段算力剖析KV Cache 对显存的吞噬机制在大模型LLM推理与应用性能优化中“显存VRAM”永远是决定并发上限和硬件成本的最核心瓶颈。很多工程师在私有化部署一个 70B 参数的模型时算了一笔账70B 模型在 FP16 精度下占用约 140GB 显存我们配置了 2 张 80GB 的 A100 显卡总计 160GB 显存看似还剩下 20GB 空余然而当并发请求数稍微上涨到 10 个且上下文达到 4k 长度时显卡瞬间爆出CUDA Out of Memory错误整个推理服务直接崩溃。那多出来的几十上百 GB 显存到底被谁吃掉了答案正是大模型自回归生成的核心组件——KV Cache键值缓存。深入剖析推理的Prefill预填充与 Decode自回归解码两个阶段的计算特性是搞懂大模型算力瓶颈与显存规划的根本前提。一、大模型推理的两大阶段计算特性深度剖析┌────────────────────────────────────────────────────────┐ │ 第一阶段Prefill 阶段 (Prompt 预填充) │ │ 输入用户输入的全部 Prompt (例如 2000 个 Token) │ │ 计算特征计算密集型 (Compute-Bound) - 并行矩阵乘法 (GEMM)│ │ 动作一次性并行计算所有 Prompt Token 的注意力矩阵 │ │ 并将生成的 Key 和 Value 矩阵存入显存 (KV Cache) │ │ 决定指标首字延迟 (TTFT) │ └──────────────────────────┬─────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────┐ │ 第二阶段Decode 阶段 (Token 逐字自回归解码) │ │ 输入上一步生成的单个 Token 之前缓存的全部 KV Cache │ │ 计算特征访存密集型 (Memory-Bound) - 矩阵向量乘法 (GEMV)│ │ 动作每生成 1 个新 Token必须把历史所有的 KV Cache 从 │ │ 显存全量搬运到 GPU 核心计算并把新 Token 的 KV 写入│ │ 决定指标生成吞吐量 (TPS / Tokens Per Second) │ └────────────────────────────────────────────────────────┘二、KV Cache 显存占用的精确数学换算公式为什么 KV Cache 会如此疯狂地吞噬显存我们可以进行精确的数学推导假设模型的架构参数为$L$Transformer 模型的层数Layers如 70B 模型通常 $L 80$$H$Key/Value 的注意力头数KV Heads在 GQA 机制下通常为 8$D$每个注意力头的维度Head Dimension通常为 128$P$数据精度占用的字节数FP16 为 2 字节$S$当前会话的总上下文长度Prompt Tokens Generated Tokens例如 4096$B$系统并发请求数Batch Size例如 32 个并发单请求单 Token 的 KV Cache 显存大小每个 Token 在每一层都需要存储一个 Key 向量和一个 Value 向量$$\text{Size per Token} 2 \times L \times H \times D \times P \text{ Bytes}$$以Llama-3-70B$L80, H8, D128, P2$为例$$\text{Size per Token} 2 \times 80 \times 8 \times 128 \times 2 327,680 \text{ Bytes} \approx 320 \text{ KB}$$当并发与长度上升时的总显存占用$$\text{Total KV Cache RAM} B \times S \times 320 \text{ KB}$$当单个请求上下文达到$S 4096$时单连接仅 KV Cache 就独占$$4096 \times 320 \text{ KB} \approx 1.31 \text{ GB}$$当系统承受$B 32$ 个并发连接时KV Cache 将直接吃掉$$32 \times 1.31 \text{ GB} \approx 41.9 \text{ GB 显存}$$这就是为什么 20GB 的显存空余在真实并发流量面前瞬间被击穿的根本原因。三、显存碎片化与 PagedAttention 革命在早期的推理框架如 HuggingFace 原生 Transformers中KV Cache 是在显存中申请连续物理内存空间的。由于无法预知用户到底会生成多少字系统必须预先为每个请求分配最大长度如 4096的显存导致大量显存被虚占但实际未使用显存有效利用率不足 30%。vLLM 引入的PagedAttention技术借鉴了操作系统的“虚拟内存分页Virtual Memory Paging”思想将 KV Cache 切分为固定大小的内存页Pages如 16 个 Token 一页物理显存无需连续通过页表Block Table动态映射显存利用率从 30% 暴升至 95% 以上相同硬件下的并发吞吐量直接提升 4~8 倍。[ 逻辑 Token 序列: 0 ~ 47 ] │ ▼ ┌────────────────────────────────────────────────────────┐ │ PagedAttention 动态页表 (Block Table) │ ├────────────────────────────────────────────────────────┤ │ Page 0 (Token 0~15) ──► 映射至物理显存块 Block #102 │ │ Page 1 (Token 16~31) ──► 映射至物理显存块 Block #45 │ │ Page 2 (Token 32~47) ──► 映射至物理显存块 Block #89 │ └────────────────────────────────────────────────────────┘四、生产架构优化指南在构建私有化推理集群与 Agent 后端时牢记三大原则拥抱 GQA分组查询注意力架构模型优先选型采用 GQA 机制的模型如 Llama-3、Qwen-2.5其 KV 头数大幅压缩KV Cache 体积仅为传统 MHA 模型的 1/8。强制使用 PagedAttention 推理引擎vLLM / TensorRT-LLM / SGLang坚决杜绝在生产环境使用原生单机脚本直接推理。结合 Prompt Caching对高频重复的公共系统提示词System Prompt在显存中实现跨请求的 KV Cache 共享复用彻底省去 Prefill 阶段的重复计算与显存占用。深刻理解计算与显存的微观流转才能在百舸争流的 AI 基建浪潮中做到心中有数、算力尽其用。