理解 KV-Cache 的物理本质与优化路径，是大模型长文本推理优化的关键。
核心内容：
1. KV-Cache 的物理本质与必要性
2. 长上下文下的显存占用与核心瓶颈
3. 两大主流优化技术路径

KV Cache 到底在缓存什么——大模型推理的物理基础

全文速览

KV Cache 是 transformer 推理时 attention 层产生的 K/V 张量缓存，是模型架构决定的物理存在，不是某个厂商的优化技巧。它的显存占用随 context 长度线性增长，1M token context window 下能比模型权重本身还大。优化路径有两条：减少每 token 的 KV 体积（MHA→MQA→GQA→MLA），和提升显存利用率（PagedAttention）。这篇讲清 KV Cache 的物理本质、显存账、优化技术演进，以及为什么长 context 时代它成了核心瓶颈。

聊 LLM 推理优化离不开 KV Cache 这个词，但很多人对它到底在缓存什么、为什么必须缓存、占多少显存，其实没真搞清楚。这篇就讲这个，不绕弯子。

01   KV Cache 是 transformer 推理的物理副产品 

先说一个常见误解：KV Cache 不是某个厂商的优化技巧，是 transformer 架构本身决定的物理存在。

transformer 的 self-attention 机制是这样的：每个 token 在每一层会做三次线性投影，得到 Q（query）、K（key）、V（value）三个向量。新 token 的 Q 去和所有历史 token 的 K 做点积，softmax 出权重，再加权所有历史 token 的 V。这就是「注意力」的本质——新 token 通过 Q 在历史 token 的 K/V 里找相关信息。

关键问题来了：每次生成一个新 token，都要拿它的 Q 去算和所有历史 token 的 K 的点积。如果每生成一个 token 都重新算所有历史 token 的 K 和 V，复杂度是 O(n²)，长 context 下根本跑不动。

所以推理时必须把历史 token 的 K 和 V 缓存下来。新 token 进来只需要算它自己的 Q/K/V，然后用 Q 去匹配缓存里的所有 K，加权缓存里的所有 V。这就是 KV Cache，复杂度从 O(n²) 降到 O(n)。

物理上 KV Cache 就是一堆浮点张量。每个 token 在每一层都有一对 K 和 V 向量，存起来供后续 token 的 attention 使用。OpenAI 官方 cookbook 里说得很直白：「The KV cache just holds the model's key/value tensors (linear projections of the hidden-states) so we can reuse them on the next inference step. It's essentially just a bunch of numbers internal to the model.」

推理过程因此分成两个阶段：

• prefill 阶段：处理输入 prompt，算出每个 token 的 K/V 存入 cache。这一步是计算密集型，因为要一次性算完所有 prompt token
• decode 阶段：逐 token 生成，每生成一个就把它加进 cache。这一步是显存带宽密集型，因为每步都要读整个 cache

02   KV Cache 的显存账：长 context 下能比模型权重还大 

这是 KV Cache 现在被高度重视的根本原因——它的显存占用随 context 长度线性增长，长 context 场景下能吃掉一大半显存。

算账公式很直接：

每个变量的含义：

• 2：K 和 V 各一份，所以乘 2
• n_layers：transformer 层数
• n_kv_heads：KV head 数量（注意不是 query head 数量，后面会讲 GQA/MQA）
• d_head：每个 head 的维度
• seq_len：当前 context 长度
• bytes_per_param：FP16/BF16 是 2 字节，FP32 是 4 字节

拿 Llama 3 70B 算一笔真实账。它用 GQA，64 个 query head 但只有 8 个 KV head，80 层，每 head 128 维，FP16：

Llama 3 70B 模型权重本身大概 140GB（FP16），128K context 下 KV cache 占 40GB，差不多是模型权重的 28%。听着不算多？切到没用 GQA 的老模型看看：GPT-3 在 128K context 下 KV cache 单独就要 460GB，比模型权重还大几倍。这就是为什么 GQA 在 2024 年后成了大模型标配。

460 GB

GPT-3 在 128K context 下的 KV cache 显存

context 越长，KV cache 占总显存比例越高。8K 的时候只占 2%，128K 的时候占 23%，1M context 下能占一半以上。长 context 时代，KV cache 优化不再是「锦上添花」，是「能不能跑起来」的生死问题。

03   优化路径一：减少每 token 的 KV 体积 

第一条优化路径是从模型架构本身下手，让每个 token 存的 K/V 更少。 这条路径走过了 MHA → MQA → GQA → MLA 四代。 

MHA（Multi-Head Attention）：原始架构，每个 head 各存一份

2017 年《Attention Is All You Need》提出的原始架构。每个 query head 都有自己的 K head 和 V head。假设 32 个 head，每个 token 每层就要存 32 份 K 和 32 份 V。表达力最强，但 KV cache 体积最大。

MQA（Multi-Query Attention）：所有 head 共享一份 KV

2019 年 Noam Shazeer 提出。所有 query head 共享一个 K head 和一个 V head。KV cache 体积直接砍到 1/N（N 是 head 数）。但代价是质量明显下降——一份 KV 学不了 32 份能学的模式。PaLM 用过，但大多数模型没用，因为质量损失太大。

GQA（Grouped-Query Attention）：折中方案，业界标配

2023 年 5 月 Google 提出 GQA，介于 MHA 和 MQA 之间。把 query head 分成 G 组，每组共享一份 K/V。GQA-1 就是 MQA，GQA-H（组数等于 head 数）就是 MHA，GQA 是这两端的连续光谱。

GQA 论文的关键结论：uptrained GQA 能在质量接近 MHA 的同时，速度接近 MQA。所以它成了 2024 年后大模型的标配。Llama 3 70B 用 8 个 KV head（64 query head 分 8 组），Mistral 7B 用 8 个 KV head（32 query head 分 8 组）。

GQA 的本质是「让 KV cache 体积随模型变大保持比例缩小」——大模型 head 多，GQA 的相对节省更显著。业界共识：7B 以下用 MHA 没问题，13B 以上基本标配 GQA。

MLA（Multi-head Latent Attention）：DeepSeek 的低秩潜变量方案

2024 年 DeepSeek-V2 提出 MLA，思路完全不同。不是减少 KV head 数量，而是根本不存完整的 K 和 V，只存一个低维潜变量。

原理：把输入先投影到一个 512 维的潜向量 c_kv，缓存里只存这个潜向量。需要算 K 和 V 的时候，通过两个矩阵 W_uk 和 W_uv 临时解压出来。更狠的是，推理时还可以把 W_uk 吸收进 query 的投影矩阵里，根本不显式算出 K。

✓ 核心观点

DeepSeek-V3 的维度下，标准 MHA 要存 32K floats/token，MLA 只存 512 floats/token，64 倍压缩。带宽节省约 32 倍（因为潜变量要读两次）。代价是计算量增加约 4 倍，但 attention 在 decode 阶段通常是显存带宽瓶颈不是计算瓶颈，所以这个权衡划算。DeepSeek-V3 能做到比同类模型便宜一大截，MLA 是核心原因之一。

04   优化路径二：提升显存利用率 

第二条优化路径不动模型架构，从显存管理下手。 代表作是 vLLM 的 PagedAttention。 

传统推理框架管理 KV cache 的方式很傻：每个请求预先分配一整块连续显存，按最大可能生成长度预留。这导致两个问题：

• 内部碎片：请求实际只生成 100 token，但预留了 2048 token 的空间，浪费一半
• 外部碎片：请求之间留下的空隙没法被新请求利用

2023 年 9 月，UC Berkeley 团队发表论文《Efficient Memory Management for Large Language Model Serving with PagedAttention》，借鉴操作系统的虚拟内存分页思想，把 KV cache 切成固定大小的 block（默认 16 token 一块）。逻辑上连续的 KV cache，物理上可以分散在不连续的 block 里，通过 block table 做映射。

效果立竿见影：显存浪费从 60-80% 降到 4% 以下，同样显存能跑的 batch size 提升 2-4 倍。vLLM 就是基于 PagedAttention 搭建的推理引擎，2023 年后成了开源 LLM serving 的事实标准。

PagedAttention 还带了一个意外好处：KV cache 共享变得自然。多个请求共享同一个 system prompt 时，对应的 KV block 可以直接复用，不需要复制。这是后面 Prefix Caching 能落地的基础。

05   KV Cache 为什么现在这么火 

核心原因是长 context 和 Agent 场景的爆发。

2023 年前 LLM 主流 context 是 4K-8K，KV cache 占显存比例不高，优化优先级也低。2024 年后趋势彻底变了：

• 长 context 成标配：Gemini 2.5/3.x 支持 1M token，Claude Opus 4.x 支持 200K，GPT-5.x 支持 400K+。context 一长，KV cache 体积暴涨
• Agent 场景天然吃 context：Agent Loop 每轮要把完整历史重传，多轮下来 context 轻松破 100K。Agent 工具（codex、Claude Code、Cursor）的火爆直接拉高了 KV cache 优化的优先级
• 推理成本成了商业模式关键：大模型 API 价格战越打越凶，谁能把推理成本压下来谁就能赚钱。KV cache 占推理显存的大头，自然成了优化焦点

工业界的应对路线也清晰：

1. 模型架构层面：GQA 成标配，MLA 被 DeepSeek 验证可行，新一代模型基本都会用类似压缩方案
2. 推理框架层面：vLLM PagedAttention 成事实标准，SGLang RadixAttention 进一步做前缀复用
3. 显存扩展层面：KV cache offloading 到 CPU 内存或磁盘（DeepSeek 的 Disk Cache 就是这种思路），用时间换空间
4. 量化层面：KV cache 从 FP16 量化到 INT8/FP8，直接砍一半体积

06   实操：选模型时怎么算 KV cache 账 

讲了这么多原理，落到选型上就一个问题：我这个场景，KV cache 吃多少显存？

几个常见场景的 KV cache 估算（FP16，GQA 配置）：

几个判断要点：

• batch size 越大，KV cache 占总显存比例越高。因为权重是共享的，KV cache 是每个请求各一份
• Agent 场景必看 128K context 的 KV cache。Llama 3 70B 跑 Agent，每个 session 128K context 就要 40GB KV cache，单卡 A100 80GB 跑不了几个并发
• DeepSeek MLA 的实际显存占用比公式算的更复杂，因为它不存完整 K/V 只存潜变量，但 RoPE 部分还是要单独存。粗略估算按 GQA 的 1/8 算差不多
• 如果场景是长文档多轮查询，优先选 GQA/MLA 优化的模型 + vLLM/SGLang 这类支持 PagedAttention 的推理框架，能省一大半显存

KV cache 不是玄学，账算清楚就知道自己的场景能不能跑、能跑多少并发、瓶颈在哪。下一篇讲推理框架层在这基础上做的 Prefix Caching，那是另一个维度的优化。

一 句 话 总 结

KV Cache 是 transformer 架构决定的物理副产品，不是优化技巧——长 context 时代它的显存占用能比模型权重还大，所以 GQA、MLA、PagedAttention 这些优化才成了大模型推理的必修课。

#KVCache #Transformer #大模型推理 #LLM #PagedAttention #GQA #MLA #DeepSeek #Llama3 #Attention  

     觉得有用？扫码关注「昕悦技术栈」
持续输出实战干货

长按识别二维码，关注我！

登录查看剩余 70% 内容