在生产环境部署过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上下文为例：
KV cache per token = 2 (K+V) x 80 layers x 8 KV heads x 128 head_dim x 2 bytes (FP16)
= 2 x 80 x 8 x 128 x 2 = 327,680 bytes ≈ 320 KB per token
For 8K tokens: 320 KB x 8,192 = 2.56 GB per request
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等推理框架也是为这类无状态负载设计的：加载模型，跑前向传播，返回结果。
如果今天仍然只是服务传统视觉或表格模型，后面这些复杂度都不需要关心。
Era 1：连续KV Cache（2017年）
Transformer原始论文（2017）带来了自注意力机制，也带来了在decode步骤之间缓存Key和Value张量的需求。
早期推理引擎如HuggingFace Transformers用最简单的的方式实现KV cache：为每个请求预分配一个
max_seq_len
大小的连续张量，单个请求的存储量为
2 x num_layers x num_heads x head_dim x max_seq_len
。
好处是实现简单，相比每步重算注意力有很大的速度提升。
代价也很明显，内存占用按
max_seq_len x batch_size
线性增长而非跟随实际序列长度；大多数请求远短于最大长度，造成严重的内部碎片；并发batch大小因此受限，请求之间也无法共享内存。
性能分析的数据很直白：在这些系统中已分配的KV cache内存只有20–38%真正存储了有用的token状态，其余全部浪费在填充和碎片上。
Era 2：PagedAttention（2023年）
PagedAttention是真正改变规则的技术，UC Berkeley的vLLM团队从操作系统借来了一个基本思路：带分页的虚拟内存。
做法是把KV cache切分为固定大小的页（block），随着序列增长按需分配，而非一次性为每个请求开辟一大块连续内存。一个block table将逻辑页映射到物理内存，原理和操作系统页表将虚拟地址映射到物理RAM完全一致。
vLLM论文给出的数据相当惊人：吞吐量比FasterTransformer和Orca提升2–4倍；碎片率降到4%以下（之前是60–80%）内存浪费接近于零；并发请求数从几十跃升到数百乃至数千。
PagedAttention还打开了前缀缓存的大门：SGLang的RadixAttention正是基于此。多个请求如果共享同一前缀（系统提示词、共享文档等）对应的KV cache页可以直接复用而非重新计算。对多轮对话和RAG场景而言，这是一个巨大的吞吐量倍增器。
不过PagedAttention并非没有取舍：注意力kernel因为非连续内存访问变得更复杂，block大小需要调优，而且它默认假设KV cache是同构的：每层大小一致。
这些局限并不妨碍它成为事实标准。今天vLLM、SGLang、TensorRT-LLM全部以PagedAttention为底层基础。
实践比较：vLLM vs SGLang前缀缓存
两个框架都支持前缀缓存，实现路径不同。vLLM在block级别做基于哈希的前缀匹配；SGLang则用RadixAttention树在基数树结构中维护KV block的LRU缓存，支持跨多次生成调用的自动复用。
从实际部署看，SGLang的方案在复杂多调用场景（agent、思维树）中缓存命中率更高，vLLM的方案更简洁标准聊天场景下表现良好。
Era 3：异构KV Cache（2024年）
2024年模型架构和优化技术快速分化，推理系统需要管理形状、生命周期、访问模式各异的多种缓存状态。"KV cache"这个术语的外延已经远超原始定义。
投机解码用一个小型草稿模型一次提出多个候选token，再由大型目标模型批量验证，草稿模型和目标模型各自维护独立的KV cache。视觉语言模型（VLM）如QwenVL、InternVL的视觉编码器会产生大型图像嵌入，这些嵌入可以跨请求缓存复用，但尺寸与文本KV cache不同。量化KV Cache用FP8等低精度格式压缩存储，需要额外维护缩放因子。滑动窗口注意力（SWA）只关注最近
window_size
个token，KV cache管理需要判断哪些token在窗口内、哪些已过期可以淘汰。
Mamba / 状态空间模型则是另外一条完全不同的路：用循环状态替代注意力，每个新token更新一个固定大小的向量。这种状态无法在token粒度上共享也不容易回滚，和KV cache在本质上就不是一回事。
混合模型则在单个模型中组合多种层类型：
- 滑动窗口 + 全注意力（Gemma 2/3、Ministral）
- Mamba + 全注意力（Jamba、Bamba）
- 局部分块 + 全注意力（Llama 4）
Jenga论文给出了量化数据：Llama 3.2 11B Vision如果把所有层按统一方式管理，内存浪费达79.6%；Gemma-2为25%；Ministral为56.25%。
异构缓存带来的麻烦包括：多个独立缓存管理器之间的内存碎片、服务器启动时难以预测内存分配、前缀缓存按类型各自实现导致命中率下降，以及功能组合的复杂度急剧上升。
vLLM等框架在实践中走向了分离管理器的路线——普通KV cache一个管理器，视觉编码缓存一个，Mamba缓存又一个。能用，但脆弱，扩展性差。
Era 4：分布式KV Cache（2025+）
模型规模持续增长单GPU甚至单节点已不足以承载。KV cache管理正在变成一个多节点、数据中心级别的问题。
解耦推理
DistServe的核心提案是将prefill和decode阶段部署到不同的GPU实例上。prefill受计算约束，decode受内存约束，两者适合不同的硬件配置和并行策略——分开部署比混在一起更合理。
DistServe的实测数据：与共置系统相比请求处理量提升4.48倍（或在同等吞吐下收紧SLO 10.2倍）。这时候问题就变为了KV cache从prefill节点到decode节点的传输效率。
vLLM的Encoder Disaggregation将视觉编码器拆为独立可扩展服务，专门用于多模态场景，消除编码器与解码器之间的干扰后goodput提升2–2.5倍。
KV Cache感知的负载均衡
NVIDIA Dynamo引入了KV cache感知路由：请求路由器优先把请求转发到已经持有相关KV cache的实例上，在集群层面最大化前缀缓存命中率。这要求每个实例都能获取集群范围内的缓存状态视图。
分层KV Cache
Moonshot AI的Mooncake采用以KV cache为中心的解耦架构，冷KV页从GPU HBM溢出到CPU DRAM或SSD，热页留在GPU上，从而在不牺牲热数据访问速度的前提下扩展有效缓存容量。从低层级加载或写回一层KV的延迟可以和前一层的GPU计算重叠，从而被隐藏。
长上下文场景下Mooncake的吞吐量最高提升525%，同时满足SLO约束。在Kimi的真实负载中，请求处理量多出75%。
分布式时代的困难很实际：投机解码、VLM等不少优化手段和分布式推理还无法兼容；部署需要相当的专业知识和耐心；节点间网络（InfiniBand、RoCE）本身就是难题，NIXL一类的库还很不成熟；故障转移、落后者节点、硬件缺陷、自动扩缩容。每一项都在真实环境中带来额外的复杂度。
Kubernetes原生方案如NVIDIA Dynamo、vLLM Production Stack、llm-d、AIBrix正在试图收敛这些复杂度，但整体仍处于早期。
Era 5：统一混合KV Cache（2025+）
当前前沿工作的方向是构建统一内存系统：异构KV类型共享同一个内存池，而非各自维护独立的分配器。贯穿其中的主题是可组合性——每一项优化都应当能和其他任意优化叠加使用。
Jenga：大页 + LCM尺寸对齐
Jenga提出了两级内存分配器。核心思路是取不同嵌入尺寸的最小公倍数（LCM）作为"大页"尺寸，让不同KV形状在同一内存池中共存而不产生碎片。
举例来说，图像token的KV为256字节，文本token的KV为384字节，则取LCM(256, 384) = 768字节为大页尺寸。大页再按特定层类型细分为小页。
与原版vLLM相比，Jenga的GPU内存利用率最高改善79.6%，吞吐量最高提升4.92倍（平均1.80倍）。
SGLang：CUDA虚拟内存
SGLang则又用了另外一个方法：利用CUDA Virtual Memory API动态重映射设备内存，让KV页在虚拟地址空间中连续、物理上分散。弹性内存池可以在运行时动态调整不同池类型（如Mamba池与KV cache池）之间的分配比例。
SGLang 2026年Q1路线图明确把功能可组合性列为核心目标：在解耦部署中跨多节点对混合VLM执行投机解码。要达成这一目标，需要对引擎核心组件做长周期的架构重构。
比较表：各时代一览
不同场景下的选择
结合生产部署经验给出一些判断。
标准文本LLM服务（聊天、补全）：Era 2（PagedAttention）是基础，选vLLM或SGLang即可。有共享系统提示词的场景应开启前缀缓存。
多模态模型（VLM）：属于Era 3的范畴，需要关注框架对视觉嵌入的处理方式。图像密集型负载占比高时，可以评估vLLM的编码器解耦（Era 4）。
混合架构（Gemma 3、Jamba、Llama 4）：Era 5直接相关。SGLang的CUDA虚拟内存方案和Jenga的LCM分配器正是针对此类场景设计。
大规模高吞吐量生产：Era 4是重点。解耦prefill/decode配合KV感知路由对成本效率的改善非常可观，NVIDIA Dynamo和Mooncake是参考架构。
长上下文负载（100K+ token）：分层KV cache（Era 4）配合GPU到CPU的溢出机制不可或缺，否则GPU显存根本撑不住。
总结
KV cache才是真正的瓶颈，Llama-3–70B在32个并发8K token请求下的KV cache总量超过80GB，比一整块A100的显存还大。
KV cache管理的演进轨迹和操作系统内存管理的历史惊人地相似：从连续分配到虚拟内存、分页，再到分布式共享内存。区别在于操作系统花了40年走完的路，KV cache管理在8年内走完了，背后的驱动力是LLM负载的爆发式增长。对于正在构建LLM基础设施的工程团队来说，理解这些演进阶段没有可选项：后面所有工作都建立在这个基础之上。
https://avoid.overfit.cn/post/6272647e7bc24c8084545ec3f5ca7972
by Luv Bansal
