KV Cache管理架构演进：从连续分配到统一混合内存架构

在生产环境部署过LLM的人都知道模型权重只是问题的一半，另一半是KV cache：存储注意力状态的运行时内存，让模型在生成token时不必从头开始重算。能不能管好这块内存决定了系统是一个卡顿的demo还是一个可用的推理服务。

本文梳理KV cache管理经历的5个时代，从它根本不存在的阶段，到今天正在成型的统一内存架构。文中会结合多个模型的部署经验，对比vLLM、SGLang和TensorRT-LLM在各阶段的应对思路。读完后应当能建立一套判断框架，为具体场景选择合适的方案。

先从KV cache本身说起。

背景：Prefill、Decode与KV Cache

LLM推理分两个阶段。Prefill阶段并行处理全部输入token，在每个注意力层为每个token计算Key和Value向量，属于计算密集型，GPU并行度越高越好。Decode阶段则以自回归方式逐token生成，每个新token都要对先前所有Key-Value对做注意力计算；GPU大部分时间花在从HBM读取KV cache而非运算上，瓶颈在内存带宽。

KV cache的作用就是把已经算过的Key和Value向量缓存下来，避免每个decode步骤重复计算。没有它每生成一个token就得对整个序列重跑一遍注意力，推理速度完全无法接受。

以Llama-3–70B、8K上下文为例：

1. KV cache per token = 2 (K+V) x 80 layers x 8 KV heads x 128 head_dim x 2 bytes (FP16)
2. = 2 x 80 x 8 x 128 x 2 = 327,680 bytes ≈ 320 KB per token
4. For 8K tokens: 320 KB x 8,192 = 2.56 GB per request
5. For 32 concurrent requests: 2.56 GB x 32 = 81.9 GB

81.9 GB：一块A100 80GB的全部显存都装不下留给模型权重的空间是零。KV cache管理重要正是因为这一点。

Era 0：Pre-GenAI（2017年之前）

Transformer出现之前深度学习的主力是ResNet、YOLO、VGG、Inception这些无状态前馈架构。每次推理独立处理一个输入步骤之间没有任何持久状态，KV cache的概念自然无从谈起。

ONNX Runtime、TensorRT等推理框架也是为这类无状态负载设计的：加载模型，跑前向传播，返回结果。

如果今天仍然只是服务传统视觉或表格模型，后面这些复杂度都不需要关心。

 

https://avoid.overfit.cn/post/6272647e7bc24c8084545ec3f5ca7972