KV Cache 内存层次结构：从预填充到解码的分层缓存策略

大型语言模型的推理优化正在经历一场从 "计算密集" 向 "内存层次管理" 的范式转移。KV Cache—— 这个原本用于避免重复计算注意力权重的缓存机制 —— 正在演变为现代推理系统的核心内存层次结构。理解这一转变，对于构建高吞吐、低延迟的生产级推理服务至关重要。

从优化手段到内存体系

在 Transformer 架构中，每个生成步骤都需要访问之前所有 token 的 Key 和 Value 张量。如果每次重新计算，时间复杂度将随序列长度呈平方增长。KV Cache 通过存储这些中间结果，将自注意力计算从 O (n²) 降至 O (n)。

然而，随着上下文长度从 4K 扩展到 128K 甚至更长，KV Cache 的内存占用已成为首要瓶颈。以 Llama 3.1 70B 为例，处理 128K 上下文时，单个请求的 KV Cache 可达数十 GB。这迫使推理系统必须像 CPU 的 L1/L2/L3 缓存那样，建立显式的内存层次结构来平衡容量与访问速度。

预填充与解码的内存特征差异

理解 KV Cache 层次结构的前提是区分推理的两个阶段：

预填充（Prefill）阶段：模型并行处理整个输入 prompt，逐层计算并存储 KV Cache。这一阶段是计算密集的，决定了首 token 延迟（Time-to-First-Token, TTFT）。预填充完成后，完整的 KV Cache 张量被写入内存层次的最热层。

解码（Decode）阶段：模型自回归地生成 token，每步只需读取已存储的 KV Cache 并追加新的 KV 对。这一阶段是内存带宽密集的，其延迟直接影响用户体验的流式感受。

两个阶段对内存层次的需求截然不同：预填充需要一次性写入大量数据，而解码需要低延迟的随机读取。这种差异驱动了分层缓存策略的设计。

四层内存 hierarchy 的设计原理

现代推理系统通常采用四级 KV Cache 层次结构：

L1 层存放当前正在生成 token 的活跃会话的 KV Cache。vLLM 的 PagedAttention 机制通过将 KV Cache 划分为固定大小的块（通常 128-256 tokens / 块），实现 GPU 内存的高效利用和动态分配。

当 GPU 内存压力增大或会话进入空闲等待状态时，L2 层作为溢出缓冲区接管。将 KV Cache 从 GPU 卸载到 CPU 内存的决策通常基于会话空闲时间和预估的后续访问概率。

L3 层解决的是 prefix 复用问题。当多个请求共享相同的系统 prompt 或对话前缀时，预计算并持久化这些共享 KV Cache 可以显著减少重复预填充的开销。LMCache 等系统专门优化了这一层的检索效率。

L4 层面向多节点部署场景，允许跨实例共享 KV Cache。这在多轮对话的负载均衡场景中尤为重要 —— 当用户的后续请求被路由到不同节点时，可以从共享存储恢复会话状态。

工程实现：vLLM 与 LMCache 的协同

vLLM 作为当前主流的高吞吐推理引擎，提供了 KV Cache 管理的基础能力。其核心创新 PagedAttention 将 KV Cache 组织为逻辑块到物理块的映射表，支持非连续的内存分配和块级别的交换（swap）。

然而，vLLM 原生的 KV Cache 管理局限于单节点 GPU 内存和 CPU offload。LMCache 在此基础上扩展了外部缓存层，实现了真正的多层级持久化。其架构包含三个关键组件：

检索器（Retriever）：在请求到达时，计算输入 prompt 与存储缓存的相似度，识别可复用的 KV Cache 前缀。匹配策略通常采用滑动窗口哈希或基于 token 的精确匹配。

存储后端（Storage Backend）：支持 Redis、Ceph 等分布式存储系统作为 L3/L4 层。LMCache 采用自定义的序列化格式压缩 KV Cache，平衡存储效率与加载速度。

调度器（Scheduler）：协调 GPU 内存、CPU 内存和远程存储之间的数据流动，决定何时预取（prefetch）、何时卸载（offload）、何时驱逐（evict）。

两者的协同工作流如下：请求首先经过 LMCache 检索器，若命中缓存则直接从存储层加载 KV Cache 到 GPU，跳过完整的预填充阶段；若未命中则进入 vLLM 进行标准预填充，完成后 LMCache 将新生成的 KV Cache 异步写入持久化层。

预填充 / 解码分离架构

2024 年以来，业界开始广泛采用预填充与解码分离（Disaggregated Prefill/Decode）的架构设计。这一趋势进一步强化了 KV Cache 作为内存层次的核心地位。

分离架构的动机在于两个阶段截然不同的资源需求特征：预填充是计算密集且内存写入密集，适合高算力但不一定需要大显存的配置；解码是内存带宽密集且读取密集，需要高显存带宽和容量。

在分离架构中，预填充节点（Prefill Pod）负责处理输入 prompt 并生成完整 KV Cache，然后通过高速互联（如 NVLink 或 RDMA）将 KV Cache 传输到解码节点（Decode Pod）。解码节点专注于自回归生成，无需承担预填充的计算负担。

这种架构对 KV Cache 的传输效率提出了极高要求。Mooncake 等系统专门优化了 KV Cache 的序列化、压缩和传输协议，目标是将跨节点传输延迟控制在毫秒级，使其相对于解码延迟可忽略。

可落地的参数与监控清单

在生产环境中部署分层 KV Cache 系统时，以下参数和监控点至关重要：

缓存块大小：vLLM 中--block-size参数通常设置为 16、32 或 128。较小的块提高内存利用率但增加管理开销；较大的块减少碎片化但可能浪费内存。对于长上下文工作负载，建议从 128 开始测试。

GPU 内存分配比例：--gpu-memory-utilization控制 vLLM 可使用的 GPU 显存比例，默认 0.9。若需为 KV Cache 预留更多空间用于长序列，可适当降低至 0.8 或 0.85。

交换空间配置：--swap-space定义 CPU 内存中可用于 KV Cache 交换的 GB 数。建议设置为 GPU 显存容量的 2-4 倍，以支持更多并发会话的溢出。

关键监控指标：

• KV Cache 命中率：复用缓存的请求比例，目标 > 30% 对于多轮对话场景
• 预填充延迟 P99：长上下文请求的首 token 延迟
• GPU 内存碎片化率：通过vllm.engine.metrics暴露
• 跨层级传输带宽：LMCache 层的加载 / 存储吞吐量
• 会话驱逐率：因内存压力被迫中断的会话比例

故障排查信号：当观察到 TTFT 随并发数线性增长而吞吐量不增时，通常表明 KV Cache 内存压力导致频繁的块交换或驱逐；当解码延迟出现周期性尖峰时，可能是跨层级缓存加载阻塞了生成流水线。

结语

KV Cache 从简单的优化技巧演变为复杂的内存层次结构，反映了 LLM 推理系统从 "能跑" 到 "跑得高效" 的成熟度演进。理解预填充与解码阶段的差异化需求，设计合理的 L1-L4 分层策略，并配合 vLLM 与 LMCache 等工具的协同使用，是构建生产级推理服务的关键能力。

随着上下文长度继续扩展和 Agent 工作负载的兴起，KV Cache 管理将成为推理优化的核心战场。提前建立对这一内存层次的系统性认知，将帮助团队在技术选型时做出更准确的判断。

参考来源

• Touchdown Labs: "KV Cache Is Becoming the Memory Hierarchy of Inference" (2026-05-13)
• vLLM Documentation: PagedAttention and Memory Management
• LMCache Technical Report: "An Efficient KV Cache Layer for Enterprise-Scale LLM Inference"

ai-systems