KV Cache（键值缓存）

Transformer 的自注意力计算：Attention(Q, K, V) = softmax(QK^T / √d_k) · V。在自回归生成中，位置 t 的输出只依赖位置 0 到 t 的 Token。因此，每生成一个新 Token：

(1) 计算新 Token 的 Q_t、K_t、V_t（通过线性投影 W_Q、W_K、W_V）

(2) 将 K_t、V_t 追加到 KV Cache

(3) 用 Q_t 与所有缓存的 K_{0:t} 计算注意力权重

(4) 加权求和所有缓存的 V_{0:t} 得到输出

这样，每个历史 Token 的 K/V 只计算一次，后续直接复用缓存。计算量从 O(n²) 降为 O(n)——每步只需计算新 Token 与所有历史 Token 的注意力。

显存占用公式：KV 大小 = 2 × n_layers × n_kv_heads × d_head × seq_len × batch_size × dtype_bytes。以 Llama 3.1 70B 为例（80 层、8 KV 头、128 维、FP16），单个 128K 请求：2 × 80 × 8 × 128 × 128K × 1 × 2 = 约 40GB。

KV Cache 管理面临三个核心挑战，在传统内存管理方案中几乎无解：

(1) 内部碎片：为保证连续内存访问性能，传统方案预分配最大序列长度的连续显存。但实际序列长度远小于预分配大小，导致大量浪费。例如预分配 128K 但实际只用 4K，浪费 97%。

(2) 外部碎片：多个请求的 KV Cache 动态分配和释放后，显存中留下大量不连续的空洞，无法被新请求复用。这类似于操作系统的内存碎片问题。

(3) 动态增长：序列长度在生成前不可预测（取决于生成停止条件），无法提前规划内存布局。传统方案只能按最大可能长度预分配，进一步加剧碎片。

这三个挑战的根源是：KV Cache 的大小由序列长度和并发数决定，而 GPU 显存是固定的。当上下文从 4K 扩展到 128K 甚至 1M，KV Cache 从「可以忽略」变成「不可能放下」。

2026 年的 KV Cache 管理已形成多层次解决方案：

(1) PagedAttention（vLLM）：借鉴操作系统虚拟内存的分页思想，将 KV Cache 分割为固定大小的 Block（通常 16 Token），通过 Block Table 将逻辑块映射到非连续物理显存。消除内部碎片和外部碎片，显存利用率接近 100%。支持 Copy-on-Write 共享（并行采样、Beam Search）。

(2) RadixAttention（SGLang）：通过基数树（Radix Tree）索引共享前缀的 KV Cache，在聊天机器人、RAG、Agent 系统等场景中缓存命中率达 75-95%，TTFT 降低 30-50%。

(3) KV Cache 量化：将 KV Cache 从 FP16 量化为 FP8 或 INT8，显存占用减半。vLLM 和 TensorRT-LLM 均支持 FP8 KV Cache。量化精度损失通常 <1%（在注意力分数上影响很小）。

(4) 三级存储层次：GPU HBM（热数据）→ CPU DRAM（温数据）→ NVMe SSD（冷数据）。对于长上下文但注意力稀疏的场景，大部分 KV Cache 可以卸载到 CPU 或 SSD，只在需要时加载回 GPU。

(5) 动态驱逐策略：类似缓存替换算法（LRU、LFU），当显存不足时驱逐最久未使用的 KV 块。SnapKV 等方法通过注意力分数识别重要 Token，只保留关键 KV 对。