很多同学刚开始接触大模型推理时都会遇到一个奇怪的现象模型生成回答不是一次性给出全文而是像打字机一样“一个字一个字往外蹦”。你问它“11等于几”它先输出“2”然后停下来再继续输出“。”。这背后除了生成策略之外还有一个非常核心的机制在支撑就是本文的主角——KV Cache。如果你准备过大模型方向的面试或者正在做推理性能优化KV Cache 几乎是绕不开的高频考点。它决定了你的推理服务能承载多少并发、能支持多长的上下文、显存会不会爆。很多人在部署开源大模型时遇到“显存不足”“推理越来越慢”的问题本质上都和 KV Cache 的增长有关。本文将用尽量通俗的方式把 KV Cache 的工作原理、token 复用逻辑、内存占用计算、面试常见考点和工程优化思路一次性讲清楚。1. 背景与核心概念先从“一字一句生成”说起大模型尤其是以 Transformer 为底座的生成式模型在推理阶段本质上是一个**自回归Autoregressive**的过程。所谓自回归可以简单理解为模型每生成一个 token都会把“已经生成的所有内容”作为输入再预测下一个 token。举个具体的例子。假设用户输入了这样一句话请用一句话介绍北京。模型实际处理的过程大致是这样的第1次输入 [请, 用, 一, 句, 话, 介, 绍, 北, 京] → 预测出 [是] 第2次输入 [请, 用, 一, 句, 话, 介, 绍, 北, 京, 是] → 预测出 [中] 第3次输入 [请, 用, 一, 句, 话, 介, 绍, 北, 京, 是, 中] → 预测出 [国] 第4次输入 [请, 用, 一, 句, 话, 介, 绍, 北, 京, 是, 中, 国] → 预测出 [的] ……表面上看模型每次都在“重新读一遍所有token”然后预测下一个词。这里就产生了一个很明显的问题每一次都从头计算一遍前面的内容不是非常浪费吗没错如果没有特殊处理模型确实会在每一步重复计算前面所有 token 的中间结果。而且注意这里的“中间结果”并不是普通意义上的缓存数据而是包含每个 token 经过多层注意力计算之后得到的Key键和Value值向量。这就是 KV Cache 中KV两个字母的来源。所以KV Cache 可以这样理解在自回归生成过程中缓存已经计算过的 token 对应的 Key 向量和 Value 向量避免后续生成步骤中重复计算这些 token 的注意力信息。而每次新生成 token 时只需要计算当前最新 token的 Key 和 Value再把它和缓存中的历史 KV 拼接起来一起参与注意力计算即可。这一机制极大地减少了推理时的重复计算是大模型高效推理的基石之一。2. 没有 KV Cache 会怎样重复计算到底有多浪费要真正理解 KV Cache 的价值我们需要看一下 Transformer 的注意力机制到底在算什么。在一个多头注意力Multi-Head Attention模块中核心公式是Attention(Q, K, V) softmax(Q * K^T / sqrt(d)) * V这里的 Q、K、V 分别来自输入序列的三个线性投影。当输入序列长度为 n 时K 和 V 的形状通常为[n, d]其中 d 是每个 token 的特征维度。在没有 KV Cache 的情况下每生成一个新 token模型都会对整个 token 序列重新计算一次前向传播。假设已经生成了 n 个 token下一步要预测第 n1 个 token这时候它会把已有的 n 个 token 全部重新输入 Transformer。第 1 层到第 L 层逐层计算。每一层都重新计算这 n 个 token 的 Q、K、V。完成注意力计算最终预测第 n1 个 token。但问题是前 n 个 token 的 K 和 V 向量在生成第 1、2、3……n 个 token 的时候其实已经被计算过了。它们的值并不会因为接下来要预测哪个 token 而发生改变。重复计算这些历史 token 的 K、V本质上是纯粹的浪费。这个浪费有多大呢可以从时间和空间两个维度来看。时间维度注意力计算中每个新 token 都需要与所有历史 token 计算点积注意力分数。没有缓存时每一步的输入序列都在变长计算量会随序列长度二次增长。举个例子生成第 100 个 token 时要重新计算 100 个 token 的注意力生成第 200 个 token 时又要重新计算 200 个 token 的注意力。每一步都比上一步更慢随着生成长度增加推理会变得越来越卡。空间维度虽然没有 KV Cache 时不显式存储历史 K/V但前向传播过程中每一层仍然需要为完整输入序列生成 K/V 矩阵这些矩阵在计算时同样会占据显存。所以如果没有 KV Cache大模型生成一个几百 token 的回答计算消耗会成倍增加在线服务的时延和吞吐都完全不可接受。这就像你写论文时每次要写下一句话都要把前面已经写完的内容重新手抄一遍。很明显这种方式非常低效。3. KV Cache 的工作原理两块核心工作区KV Cache 的实现思路并不复杂。大体上我们可以把一次完整的生成过程划分为两个阶段这两个阶段也是面试里最容易考到的基础划分。3.1 Prefill 阶段把用户的输入先算一遍当用户输入一段 prompt 时模型需要完整地处理这段输入得到对每个 token 的注意力表示。这个阶段通常被称为Prefill预填充阶段。在 Prefill 阶段输入是完整的用户 prompt假设长度为 m。模型对 prompt 中的每个 token 进行完整的前向传播计算每一层的 K 和 V然后将最后一层的输出作为预测基础预测第一个新 token。将每一层计算得到的 K 和 V 存入缓存供后续使用。PreFill 阶段的特点是一次处理很多 token并行度高计算密集。这个阶段的耗时主要取决于 prompt 的长度和模型的层数。3.2 Decode 阶段逐个生成 token 并复用历史 KV从生成第一个 token 开始进入Decode解码阶段。在这个阶段每轮只生成一个 token。假设现在要生成第 m1 个 token模型只需要只对最新的这一个 token 计算 Q、K、V。从缓存中取出历史 token 的 K、V。用最新 token 的 Q 与历史所有 K 做点积得到注意力分数。用注意力分数加权历史所有 V得到当前 token 的输出向量。预测下一个 token。将当前 token 的 K、V 追加写入缓存。为什么要同时保留 K 和 V而不是只保留一个这需要回到注意力公式。Q 要和 K 做点积得到 token 之间的相关性分数然后再用这个分数去加权 V。两者缺一不可所以在缓存时必须同时缓存 K 和 V。下面是一段核心思路的伪代码示例方便你快速理解“带缓存”和“不带缓存”的区别# 示例思路仅演示逻辑结构实际实现需按框架 API 调整 def generate_without_kv_cache(model, input_ids): # 每一次生成都拼接历史 token整段重新前向 for step in range(max_new_tokens): logits model(input_ids) next_token sample(logits[-1]) input_ids torch.cat([input_ids, next_token], dim-1) def generate_with_kv_cache(model, input_ids): # 第一步Prefill缓存完整 prompt 的 K/V past_key_values None logits, past_key_values model(input_ids, past_key_valuespast_key_values) next_token sample(logits[:, -1, :]) # 后续步骤Decode每次只输入最新 token for step in range(max_new_tokens): logits, past_key_values model(next_token, past_key_valuespast_key_values) next_token sample(logits[:, -1, :])注意看第二次循环模型每次只接收next_token这一个 token而不是拼接后的全部序列。历史 token 的信息全部存放在past_key_values中。这样每生成一个 token 的计算量只和“当前 token 的 Q 与历史 K/V 的交互”有关避免了重复的整段前向计算。4. token 复用逻辑为什么能加快推理速度了解了 KV Cache 的基本流程后我们可以从更底层的计算角度分析它到底省掉了哪些计算。在没有 KV Cache 时假设当前已经生成了 n 个 token要预测第 n1 个 token。输入序列长度是 n每一层的注意力计算复杂度可以粗略看作 O(n²)因为序列中每两个 token 之间都要计算注意力分数。有 KV Cache 时情况完全不同Prefill 阶段一次性处理 n 个 prompt token计算复杂度 O(n²)但只会执行一次。Decode 阶段每一步只对 1 个新 token 和 n 个历史 token 做注意力交互计算复杂度大约 O(n)并且这里的 n 也在逐渐增长。也就是说KV Cache 将原来“每一步 O(n²)”的重复计算变成了“一次 O(n²) 每步 O(n)”的增量计算。当生成长度较大时节省的计算量非常可观。举一个直观的例子。假设用户输入 100 个 token模型需要生成 900 个 token最终序列长度为 1000。没有 KV Cache 时平均每一步都需要重新计算已生成序列的注意力总计算量大致接近所有序列长度平方的累加。有 KV Cache 时只有第一轮 Prefill 对 100 个 token 做完整计算后续 900 步每一步都只做增量计算。后者的总计算量比前者低了一个数量级。这就是为什么 KV Cache 能显著提升推理速度。5. 显存开销KV Cache 的两面性KV Cache 虽然省了算力但它并不免费。它最大的代价是显存占用。在实际推理服务中KV Cache 经常是显存消耗的大头甚至超过模型权重本身。5.1 KV Cache 占多少显存我们可以通过一个公式来估算单条请求的 KV Cache 大小单条请求KV Cache字节数 2 × 层数 × 每层KV头数 × 注意力头维度 × 序列长度 × 数据类型字节数解释一下公式里的每个部分乘以 2因为同时缓存 K 和 V。层数Transformer 有多少层每层都有自己的 K 和 V。每层 KV 头数在 GQA/MQA 等注意力机制下KV 头数通常小于 Q 头数。注意力头维度每个注意力头的向量维度。序列长度当前已经生成的 token 数。数据类型字节数FP16 占 2 字节FP32 占 4 字节INT8 占 1 字节。假设一个 7B 规模的模型层数为 32每层 KV 头数为 32头维度为 128数据类型为 FP162 字节。当序列长度为 4096 时单条请求每层需要的 KV Cache 大小为2 × 32 × 128 × 4096 × 2 67,108,864 字节 ≈ 64 MB再乘以 32 层单条请求的 KV Cache 总量大约是 2 GB。这还只是单条请求。如果你的推理服务需要同时处理 16 个并发请求那这部分显存开销会达到 32 GB 左右。此时即使模型本身只占 14 GB 显存KV Cache 也可能直接掏空整张卡。这也是很多人在部署开源模型时输入一长显存就蹭蹭上涨的原因。KV Cache 的大小和序列长度呈线性关系序列越长显存占用越大。5.2 常见的显存优化手段KV Cache 既然这么占显存工业界自然有一整套优化方案。下面列出几种最常见的思路。第一使用 GQA / MQA 减少 KV 头数。标准的多头注意力MHA中每个 Q 头都有自己的 K 和 V 头。GQA分组查询注意力让多个 Q 头共享同一组 K/V 头MQA多查询注意力更进一步让所有 Q 头共享一组 K/V。这样可以成倍降低 KV Cache 大小。第二降低 KV Cache 的数据精度。例如使用 FP8、INT8 甚至 INT4 来存储 KV Cache虽然会带来一定的精度损失但可以大幅降低显存占用。第三采用 PagedAttention 之类的显存管理策略。把 KV Cache 拆分成固定大小的块像操作系统管理内存分页一样按需分配减少显存碎片。vLLM 等推理框架已经实现了这种能力。第四使用 StreamingLLM 或窗口注意力限制缓存长度。在超长上下文中只缓存最近的若干 token并对初始 token 做特殊保留控制 KV Cache 无限增长。第五批量管理 KV Cache。在服务端把多条请求的 KV Cache 合并成连续张量提高显存利用率和计算效率。6. 面试笔试高频考点这些问题你能答上来吗KV Cache 是当前大模型面试笔试中非常喜欢考察的知识点。下面整理几类出现频率很高的问题并附上回答思路。6.1 为什么生成阶段要缓存 K 和 V而不是缓存 Q、K、V回答思路因为在自回归生成过程中当前 token 的 Q 只会参与当前步的计算而 K 和 V 会在未来每一步都被反复使用。历史 token 的 K 和 V 不会变化但新的 token 的 Q 需要与所有历史 K 计算注意力分数因此必须保留历史 K同时注意力分数还要加权历史 V因此也必须保留历史 V。缓存全部 Q 没有意义因为历史 token 的 Q 不会再被用到。6.2 Prefill 和 Decode 阶段有什么不同回答思路Prefill 阶段处理完整输入序列并行度高属于计算密集型会一次性缓存输入中所有 token 的 K/VDecode 阶段每次只处理一个 token属于访存密集型读取 KV Cache 的带宽往往成为瓶颈。两个阶段的优化侧重点不同Prefill 更看重计算效率Decode 更看重 KV Cache 的读取效率和显存容量。6.3 KV Cache 会导致结果不一致吗回答思路理论上 KV Cache 只是把已经算过的 K/V 存下来复用数学上不应该改变最终结果。但在实际使用中如果因为显存不足或优化策略比如量化 KV Cache、滑动窗口改变了缓存内容可能会产生精度差异。FP16 等浮点数值经过不同累加顺序也可能出现微小差异但通常可以忽略。6.4 在长文本生成场景下KV Cache 面临什么挑战回答思路主要挑战是显存占用会随生成长度线性上涨。当上下文越来越长时KV Cache 越来越大可能导致显存不足或推理速度下降。同时超长序列下注意力缓存读取的带宽压力也很大。工程上通常使用 GQA、KV 量化、PagedAttention、窗口注意力等方式缓解。6.5 如果让你手写一个带 KV Cache 的推理循环你会怎么写回答思路这是一个偏代码的面试题。核心逻辑是先做 Prefill把输入 token 的 K/V 缓存起来然后进入循环每次只输入前一步生成的那个 token更新 past_key_values。关键点是理解模型在 Decode 阶段只输入一个 token而不是整个序列。6.6 KV Cache 能跨请求复用吗回答思路在特定场景下可以。比如多轮对话中前面的历史对话已经计算过 KV可以继续缓存使用又比如系统提示词system prompt相同的情况下可以提前算好提示词的 KV作为公共前缀供多个用户请求共享。这种前缀复用机制在 RAG 和 Agent 场景中很有价值。7. 常见问题排查推理变慢、显存爆了怎么办在实际使用中很多人会遇到与 KV Cache 相关的异常现象。下面给出几个典型问题与排查思路。7.1 现象随着生成长度增加推理越来越慢这是最直观的现象。虽然 KV Cache 已经避免了重复计算但随着序列变长每一步需要读取的缓存越来越多矩阵乘法的规模也在增大。Decode 阶段会出现明显的“越生成越慢”现象。排查思路先确认是否真的启用了 KV Cache。可以参考代码实现看看每步输入的是完整序列还是单个 token。检查是否为 Decode 阶段的显存带宽瓶颈比如 KV Cache 过大导致频繁地从显存读取。如果是超长上下文场景考虑窗口注意力或 StreamingLLM 限制缓存长度。7.2 现象显存占用随对话轮数不断增长多轮对话系统里每轮都会把用户输入和模型输出追加到上下文中KV Cache 也会随之增长。一旦超过显存上限进程可能直接被 OOM 杀掉。排查思路设定最大上下文长度超出部分进行截断或摘要。缩短 max_new_tokens限制单轮生成的 token 数。释放不再使用的请求的 KV Cache在服务端及时清理缓存。对 KV Cache 做量化或者切换到使用 GQA 的模型。7.3 现象开了 KV Cache 后输出质量变差这种情况通常不是 KV Cache 本身导致的而是缓存相关优化带来的副作用。比如 KV Cache 量化导致精度损失或者滑动窗口丢弃了过多历史信息。排查思路先关闭 KV Cache用完整序列推理确认基线输出质量。再打开 KV Cache逐步对比中间结果确认哪个环节出现精度变化。如果确实是因为量化可以尝试提高缓存精度或换用更大的缓存。8. 工程实践建议与学习路线如果你正在做大模型推理相关的项目这里有一些实际工程中值得关注的建议。优先关注显存规划。部署模型前先根据模型参数、并发数、目标上下文长度估算 KV Cache 的峰值显存占用。不要只按模型权重大小来规划显存给 KV Cache 留出充足空间。学会利用推理框架的能力。vLLM、SGLang、TensorRT-LLM 等主流推理框架都内置了 KV Cache 管理和优化能力。比如 vLLM 的 PagedAttention 可以有效减少显存碎片SGLang 支持 RadixAttention 实现前缀缓存复用。与其自己造轮子不如优先研究这些框架的默认行为。关注显存和带宽的权衡。KV Cache 量化的核心思路是用精度换显存和带宽。在做技术选型时需要结合你的业务场景测试实际效果看看精度损失是否在可接受范围内。多思考系统提示词复用。在 Agent、RAG 等场景中用户的 system prompt 通常是固定的。可以在服务初始化时提前把 prompt 编码并缓存 KV用户请求到达时只需要计算新增的那部分内容能有效降低首 token 延迟。面试和笔试的复习路线。按下面的顺序递进学习理解 Transformer 的注意力机制和自回归生成流程。理解 Prefill 和 Decode 两个阶段的区别。动手写一个简单的带 KV Cache 的推理循环用伪代码或小模型实验验证。学习 GQA、MQA 等注意力变体理解它们如何压缩 KV Cache。了解 vLLM、SGLang 等框架的显存管理策略。在真实模型上做一次长上下文推理实验观察 KV Cache 的显存增长曲线。如果你现在已经开始接触大模型部署不妨在下一个实验中做一个简单测试把模型放到单卡上分别开启和关闭 KV Cache对比相同输入下的生成速度和显存变化。你会发现KV Cache 对推理性能的影响远比想象中更直观。再用一句话总结本文的核心KV Cache 的本质是用少量显存换取大量重复计算的时间。理解了这一句话再看相关的优化方案和面试题目思路就会清晰很多。 
长河君 · 2026/9/9 16:47:17 · 阅读 1.2k KV Cache原理与工程优化：大模型推理提速的关键机制
很多同学刚开始接触大模型推理时都会遇到一个奇怪的现象模型生成回答不是一次性给出全文而是像打字机一样“一个字一个字往外蹦”。你问它“11等于几”它先输出“2”然后停下来再继续输出“。”。这背后除了生成策略之外还有一个非常核心的机制在支撑就是本文的主角——KV Cache。如果你准备过大模型方向的面试或者正在做推理性能优化KV Cache 几乎是绕不开的高频考点。它决定了你的推理服务能承载多少并发、能支持多长的上下文、显存会不会爆。很多人在部署开源大模型时遇到“显存不足”“推理越来越慢”的问题本质上都和 KV Cache 的增长有关。本文将用尽量通俗的方式把 KV Cache 的工作原理、token 复用逻辑、内存占用计算、面试常见考点和工程优化思路一次性讲清楚。1. 背景与核心概念先从“一字一句生成”说起大模型尤其是以 Transformer 为底座的生成式模型在推理阶段本质上是一个**自回归Autoregressive**的过程。所谓自回归可以简单理解为模型每生成一个 token都会把“已经生成的所有内容”作为输入再预测下一个 token。举个具体的例子。假设用户输入了这样一句话请用一句话介绍北京。模型实际处理的过程大致是这样的第1次输入 [请, 用, 一, 句, 话, 介, 绍, 北, 京] → 预测出 [是] 第2次输入 [请, 用, 一, 句, 话, 介, 绍, 北, 京, 是] → 预测出 [中] 第3次输入 [请, 用, 一, 句, 话, 介, 绍, 北, 京, 是, 中] → 预测出 [国] 第4次输入 [请, 用, 一, 句, 话, 介, 绍, 北, 京, 是, 中, 国] → 预测出 [的] ……表面上看模型每次都在“重新读一遍所有token”然后预测下一个词。这里就产生了一个很明显的问题每一次都从头计算一遍前面的内容不是非常浪费吗没错如果没有特殊处理模型确实会在每一步重复计算前面所有 token 的中间结果。而且注意这里的“中间结果”并不是普通意义上的缓存数据而是包含每个 token 经过多层注意力计算之后得到的Key键和Value值向量。这就是 KV Cache 中KV两个字母的来源。所以KV Cache 可以这样理解在自回归生成过程中缓存已经计算过的 token 对应的 Key 向量和 Value 向量避免后续生成步骤中重复计算这些 token 的注意力信息。而每次新生成 token 时只需要计算当前最新 token的 Key 和 Value再把它和缓存中的历史 KV 拼接起来一起参与注意力计算即可。这一机制极大地减少了推理时的重复计算是大模型高效推理的基石之一。2. 没有 KV Cache 会怎样重复计算到底有多浪费要真正理解 KV Cache 的价值我们需要看一下 Transformer 的注意力机制到底在算什么。在一个多头注意力Multi-Head Attention模块中核心公式是Attention(Q, K, V) softmax(Q * K^T / sqrt(d)) * V这里的 Q、K、V 分别来自输入序列的三个线性投影。当输入序列长度为 n 时K 和 V 的形状通常为[n, d]其中 d 是每个 token 的特征维度。在没有 KV Cache 的情况下每生成一个新 token模型都会对整个 token 序列重新计算一次前向传播。假设已经生成了 n 个 token下一步要预测第 n1 个 token这时候它会把已有的 n 个 token 全部重新输入 Transformer。第 1 层到第 L 层逐层计算。每一层都重新计算这 n 个 token 的 Q、K、V。完成注意力计算最终预测第 n1 个 token。但问题是前 n 个 token 的 K 和 V 向量在生成第 1、2、3……n 个 token 的时候其实已经被计算过了。它们的值并不会因为接下来要预测哪个 token 而发生改变。重复计算这些历史 token 的 K、V本质上是纯粹的浪费。这个浪费有多大呢可以从时间和空间两个维度来看。时间维度注意力计算中每个新 token 都需要与所有历史 token 计算点积注意力分数。没有缓存时每一步的输入序列都在变长计算量会随序列长度二次增长。举个例子生成第 100 个 token 时要重新计算 100 个 token 的注意力生成第 200 个 token 时又要重新计算 200 个 token 的注意力。每一步都比上一步更慢随着生成长度增加推理会变得越来越卡。空间维度虽然没有 KV Cache 时不显式存储历史 K/V但前向传播过程中每一层仍然需要为完整输入序列生成 K/V 矩阵这些矩阵在计算时同样会占据显存。所以如果没有 KV Cache大模型生成一个几百 token 的回答计算消耗会成倍增加在线服务的时延和吞吐都完全不可接受。这就像你写论文时每次要写下一句话都要把前面已经写完的内容重新手抄一遍。很明显这种方式非常低效。3. KV Cache 的工作原理两块核心工作区KV Cache 的实现思路并不复杂。大体上我们可以把一次完整的生成过程划分为两个阶段这两个阶段也是面试里最容易考到的基础划分。3.1 Prefill 阶段把用户的输入先算一遍当用户输入一段 prompt 时模型需要完整地处理这段输入得到对每个 token 的注意力表示。这个阶段通常被称为Prefill预填充阶段。在 Prefill 阶段输入是完整的用户 prompt假设长度为 m。模型对 prompt 中的每个 token 进行完整的前向传播计算每一层的 K 和 V然后将最后一层的输出作为预测基础预测第一个新 token。将每一层计算得到的 K 和 V 存入缓存供后续使用。PreFill 阶段的特点是一次处理很多 token并行度高计算密集。这个阶段的耗时主要取决于 prompt 的长度和模型的层数。3.2 Decode 阶段逐个生成 token 并复用历史 KV从生成第一个 token 开始进入Decode解码阶段。在这个阶段每轮只生成一个 token。假设现在要生成第 m1 个 token模型只需要只对最新的这一个 token 计算 Q、K、V。从缓存中取出历史 token 的 K、V。用最新 token 的 Q 与历史所有 K 做点积得到注意力分数。用注意力分数加权历史所有 V得到当前 token 的输出向量。预测下一个 token。将当前 token 的 K、V 追加写入缓存。为什么要同时保留 K 和 V而不是只保留一个这需要回到注意力公式。Q 要和 K 做点积得到 token 之间的相关性分数然后再用这个分数去加权 V。两者缺一不可所以在缓存时必须同时缓存 K 和 V。下面是一段核心思路的伪代码示例方便你快速理解“带缓存”和“不带缓存”的区别# 示例思路仅演示逻辑结构实际实现需按框架 API 调整 def generate_without_kv_cache(model, input_ids): # 每一次生成都拼接历史 token整段重新前向 for step in range(max_new_tokens): logits model(input_ids) next_token sample(logits[-1]) input_ids torch.cat([input_ids, next_token], dim-1) def generate_with_kv_cache(model, input_ids): # 第一步Prefill缓存完整 prompt 的 K/V past_key_values None logits, past_key_values model(input_ids, past_key_valuespast_key_values) next_token sample(logits[:, -1, :]) # 后续步骤Decode每次只输入最新 token for step in range(max_new_tokens): logits, past_key_values model(next_token, past_key_valuespast_key_values) next_token sample(logits[:, -1, :])注意看第二次循环模型每次只接收next_token这一个 token而不是拼接后的全部序列。历史 token 的信息全部存放在past_key_values中。这样每生成一个 token 的计算量只和“当前 token 的 Q 与历史 K/V 的交互”有关避免了重复的整段前向计算。4. token 复用逻辑为什么能加快推理速度了解了 KV Cache 的基本流程后我们可以从更底层的计算角度分析它到底省掉了哪些计算。在没有 KV Cache 时假设当前已经生成了 n 个 token要预测第 n1 个 token。输入序列长度是 n每一层的注意力计算复杂度可以粗略看作 O(n²)因为序列中每两个 token 之间都要计算注意力分数。有 KV Cache 时情况完全不同Prefill 阶段一次性处理 n 个 prompt token计算复杂度 O(n²)但只会执行一次。Decode 阶段每一步只对 1 个新 token 和 n 个历史 token 做注意力交互计算复杂度大约 O(n)并且这里的 n 也在逐渐增长。也就是说KV Cache 将原来“每一步 O(n²)”的重复计算变成了“一次 O(n²) 每步 O(n)”的增量计算。当生成长度较大时节省的计算量非常可观。举一个直观的例子。假设用户输入 100 个 token模型需要生成 900 个 token最终序列长度为 1000。没有 KV Cache 时平均每一步都需要重新计算已生成序列的注意力总计算量大致接近所有序列长度平方的累加。有 KV Cache 时只有第一轮 Prefill 对 100 个 token 做完整计算后续 900 步每一步都只做增量计算。后者的总计算量比前者低了一个数量级。这就是为什么 KV Cache 能显著提升推理速度。5. 显存开销KV Cache 的两面性KV Cache 虽然省了算力但它并不免费。它最大的代价是显存占用。在实际推理服务中KV Cache 经常是显存消耗的大头甚至超过模型权重本身。5.1 KV Cache 占多少显存我们可以通过一个公式来估算单条请求的 KV Cache 大小单条请求KV Cache字节数 2 × 层数 × 每层KV头数 × 注意力头维度 × 序列长度 × 数据类型字节数解释一下公式里的每个部分乘以 2因为同时缓存 K 和 V。层数Transformer 有多少层每层都有自己的 K 和 V。每层 KV 头数在 GQA/MQA 等注意力机制下KV 头数通常小于 Q 头数。注意力头维度每个注意力头的向量维度。序列长度当前已经生成的 token 数。数据类型字节数FP16 占 2 字节FP32 占 4 字节INT8 占 1 字节。假设一个 7B 规模的模型层数为 32每层 KV 头数为 32头维度为 128数据类型为 FP162 字节。当序列长度为 4096 时单条请求每层需要的 KV Cache 大小为2 × 32 × 128 × 4096 × 2 67,108,864 字节 ≈ 64 MB再乘以 32 层单条请求的 KV Cache 总量大约是 2 GB。这还只是单条请求。如果你的推理服务需要同时处理 16 个并发请求那这部分显存开销会达到 32 GB 左右。此时即使模型本身只占 14 GB 显存KV Cache 也可能直接掏空整张卡。这也是很多人在部署开源模型时输入一长显存就蹭蹭上涨的原因。KV Cache 的大小和序列长度呈线性关系序列越长显存占用越大。5.2 常见的显存优化手段KV Cache 既然这么占显存工业界自然有一整套优化方案。下面列出几种最常见的思路。第一使用 GQA / MQA 减少 KV 头数。标准的多头注意力MHA中每个 Q 头都有自己的 K 和 V 头。GQA分组查询注意力让多个 Q 头共享同一组 K/V 头MQA多查询注意力更进一步让所有 Q 头共享一组 K/V。这样可以成倍降低 KV Cache 大小。第二降低 KV Cache 的数据精度。例如使用 FP8、INT8 甚至 INT4 来存储 KV Cache虽然会带来一定的精度损失但可以大幅降低显存占用。第三采用 PagedAttention 之类的显存管理策略。把 KV Cache 拆分成固定大小的块像操作系统管理内存分页一样按需分配减少显存碎片。vLLM 等推理框架已经实现了这种能力。第四使用 StreamingLLM 或窗口注意力限制缓存长度。在超长上下文中只缓存最近的若干 token并对初始 token 做特殊保留控制 KV Cache 无限增长。第五批量管理 KV Cache。在服务端把多条请求的 KV Cache 合并成连续张量提高显存利用率和计算效率。6. 面试笔试高频考点这些问题你能答上来吗KV Cache 是当前大模型面试笔试中非常喜欢考察的知识点。下面整理几类出现频率很高的问题并附上回答思路。6.1 为什么生成阶段要缓存 K 和 V而不是缓存 Q、K、V回答思路因为在自回归生成过程中当前 token 的 Q 只会参与当前步的计算而 K 和 V 会在未来每一步都被反复使用。历史 token 的 K 和 V 不会变化但新的 token 的 Q 需要与所有历史 K 计算注意力分数因此必须保留历史 K同时注意力分数还要加权历史 V因此也必须保留历史 V。缓存全部 Q 没有意义因为历史 token 的 Q 不会再被用到。6.2 Prefill 和 Decode 阶段有什么不同回答思路Prefill 阶段处理完整输入序列并行度高属于计算密集型会一次性缓存输入中所有 token 的 K/VDecode 阶段每次只处理一个 token属于访存密集型读取 KV Cache 的带宽往往成为瓶颈。两个阶段的优化侧重点不同Prefill 更看重计算效率Decode 更看重 KV Cache 的读取效率和显存容量。6.3 KV Cache 会导致结果不一致吗回答思路理论上 KV Cache 只是把已经算过的 K/V 存下来复用数学上不应该改变最终结果。但在实际使用中如果因为显存不足或优化策略比如量化 KV Cache、滑动窗口改变了缓存内容可能会产生精度差异。FP16 等浮点数值经过不同累加顺序也可能出现微小差异但通常可以忽略。6.4 在长文本生成场景下KV Cache 面临什么挑战回答思路主要挑战是显存占用会随生成长度线性上涨。当上下文越来越长时KV Cache 越来越大可能导致显存不足或推理速度下降。同时超长序列下注意力缓存读取的带宽压力也很大。工程上通常使用 GQA、KV 量化、PagedAttention、窗口注意力等方式缓解。6.5 如果让你手写一个带 KV Cache 的推理循环你会怎么写回答思路这是一个偏代码的面试题。核心逻辑是先做 Prefill把输入 token 的 K/V 缓存起来然后进入循环每次只输入前一步生成的那个 token更新 past_key_values。关键点是理解模型在 Decode 阶段只输入一个 token而不是整个序列。6.6 KV Cache 能跨请求复用吗回答思路在特定场景下可以。比如多轮对话中前面的历史对话已经计算过 KV可以继续缓存使用又比如系统提示词system prompt相同的情况下可以提前算好提示词的 KV作为公共前缀供多个用户请求共享。这种前缀复用机制在 RAG 和 Agent 场景中很有价值。7. 常见问题排查推理变慢、显存爆了怎么办在实际使用中很多人会遇到与 KV Cache 相关的异常现象。下面给出几个典型问题与排查思路。7.1 现象随着生成长度增加推理越来越慢这是最直观的现象。虽然 KV Cache 已经避免了重复计算但随着序列变长每一步需要读取的缓存越来越多矩阵乘法的规模也在增大。Decode 阶段会出现明显的“越生成越慢”现象。排查思路先确认是否真的启用了 KV Cache。可以参考代码实现看看每步输入的是完整序列还是单个 token。检查是否为 Decode 阶段的显存带宽瓶颈比如 KV Cache 过大导致频繁地从显存读取。如果是超长上下文场景考虑窗口注意力或 StreamingLLM 限制缓存长度。7.2 现象显存占用随对话轮数不断增长多轮对话系统里每轮都会把用户输入和模型输出追加到上下文中KV Cache 也会随之增长。一旦超过显存上限进程可能直接被 OOM 杀掉。排查思路设定最大上下文长度超出部分进行截断或摘要。缩短 max_new_tokens限制单轮生成的 token 数。释放不再使用的请求的 KV Cache在服务端及时清理缓存。对 KV Cache 做量化或者切换到使用 GQA 的模型。7.3 现象开了 KV Cache 后输出质量变差这种情况通常不是 KV Cache 本身导致的而是缓存相关优化带来的副作用。比如 KV Cache 量化导致精度损失或者滑动窗口丢弃了过多历史信息。排查思路先关闭 KV Cache用完整序列推理确认基线输出质量。再打开 KV Cache逐步对比中间结果确认哪个环节出现精度变化。如果确实是因为量化可以尝试提高缓存精度或换用更大的缓存。8. 工程实践建议与学习路线如果你正在做大模型推理相关的项目这里有一些实际工程中值得关注的建议。优先关注显存规划。部署模型前先根据模型参数、并发数、目标上下文长度估算 KV Cache 的峰值显存占用。不要只按模型权重大小来规划显存给 KV Cache 留出充足空间。学会利用推理框架的能力。vLLM、SGLang、TensorRT-LLM 等主流推理框架都内置了 KV Cache 管理和优化能力。比如 vLLM 的 PagedAttention 可以有效减少显存碎片SGLang 支持 RadixAttention 实现前缀缓存复用。与其自己造轮子不如优先研究这些框架的默认行为。关注显存和带宽的权衡。KV Cache 量化的核心思路是用精度换显存和带宽。在做技术选型时需要结合你的业务场景测试实际效果看看精度损失是否在可接受范围内。多思考系统提示词复用。在 Agent、RAG 等场景中用户的 system prompt 通常是固定的。可以在服务初始化时提前把 prompt 编码并缓存 KV用户请求到达时只需要计算新增的那部分内容能有效降低首 token 延迟。面试和笔试的复习路线。按下面的顺序递进学习理解 Transformer 的注意力机制和自回归生成流程。理解 Prefill 和 Decode 两个阶段的区别。动手写一个简单的带 KV Cache 的推理循环用伪代码或小模型实验验证。学习 GQA、MQA 等注意力变体理解它们如何压缩 KV Cache。了解 vLLM、SGLang 等框架的显存管理策略。在真实模型上做一次长上下文推理实验观察 KV Cache 的显存增长曲线。如果你现在已经开始接触大模型部署不妨在下一个实验中做一个简单测试把模型放到单卡上分别开启和关闭 KV Cache对比相同输入下的生成速度和显存变化。你会发现KV Cache 对推理性能的影响远比想象中更直观。再用一句话总结本文的核心KV Cache 的本质是用少量显存换取大量重复计算的时间。理解了这一句话再看相关的优化方案和面试题目思路就会清晰很多。