什么是 KV Cache？为什么它会影响 LLM 推理速度

当用户与大语言模型对话时，模型通常会一个 Token 接一个 Token 地生成回答。每生成一个新的 Token，Transformer 都需要重新执行 Attention 计算。如果模型每次都从头计算此前所有 Token，那么随着上下文越来越长，大量已经完成的计算会被反复执行，推理效率也会明显下降。

KV Cache（Key-Value Cache）就是为减少这种重复计算而设计的缓存机制。 它会保存 Attention 中此前 Token 已经计算出的 Key 和 Value，使模型生成下一个 Token 时可以直接复用，而不必重新计算整个历史序列。

因此，KV Cache 已成为现代 LLM 推理中的关键技术之一。它能够显著提高自回归文本生成效率，但也会占用大量内存或 GPU 显存。上下文越长、并发请求越多，需要保存的 KV Cache 通常也越大，这使它成为影响 LLM 延迟、吞吐量和推理基础设施设计的重要因素。

什么是 KV Cache？

KV Cache 是 Transformer 推理过程中用于缓存 Attention Key 和 Value 的机制。它的主要作用是保存此前 Token 已经完成的部分 Attention 计算结果，让模型生成后续 Token 时可以直接复用这些结果。

在 Transformer 的 Attention 机制中，每个 Token 的隐藏表示会进一步生成三组表示：

• Query（Q）：当前 Token 想要查找什么信息；
• Key（K）：已有 Token 提供什么可匹配的信息；
• Value（V）：匹配后真正用于计算输出的信息。

当 LLM 生成下一个 Token 时，新的 Query 需要与此前 Token 的 Keys 进行 Attention 计算，并根据结果读取对应 Values。

关键问题在于：此前 Token 的 Key 和 Value 在生成过程中通常已经计算过，而且不会因为新 Token 出现而需要从头重新生成。

KV Cache 因此会把这些 K 和 V 保存下来。当新的 Token 出现时，模型只需要计算新 Token 对应的 Q、K 和 V，再将新的 K、V 加入缓存，就可以利用此前保存的 KV 继续进行 Attention。

为什么没有 KV Cache 时 LLM 会产生大量重复计算？

要理解 KV Cache 的价值，可以看一个简化的文本生成过程。

假设 Prompt 是：

AI models can

模型首先处理这三个 Token，并预测出：

generate

此时上下文变成：

AI models can generate

模型接下来需要预测第五个 Token。如果没有 KV Cache，它可能需要重新处理此前的“AI models can generate”，再次计算历史 Token 在各个 Attention Layer 中的 Key 和 Value。

假设下一步生成“text”，上下文再次增长：

AI models can generate text

如果继续从头处理，已经计算过多次的历史 Token 又会参与重复的 K/V 投影计算。

随着输出长度增加，这种重复工作会越来越多。

KV Cache 改变了这一过程。第一次处理“AI models can”时，模型就把这些 Token 的 Key 和 Value 保存下来。生成“generate”后，只需要计算这个新 Token 的相关表示并加入缓存；生成“text”时，再继续追加新的 K 和 V。

因此，KV Cache 的核心并不是让模型“少看历史上下文”，而是：

让模型继续使用完整历史上下文，同时避免重复计算历史 Token 已经得到的 Key 和 Value。

KV Cache 是如何工作的？

KV Cache 与 Transformer 的 Self-Attention 密切相关。

在自回归 Decoder 中，每个新 Token 都需要根据此前上下文预测下一个 Token。假设模型已经处理了四个 Token：

T1 → T2 → T3 → T4

Attention 已经为这些 Token 生成对应的 Key 和 Value。KV Cache 会保存：

K1, V1K2, V2K3, V3K4, V4

当新的 T5 进入模型时，不需要重新计算 T1 到 T4 的 K 和 V。模型只需要计算：

Q5, K5, V5

然后让 Q5 与缓存中的 K1–K4 以及新的 K5 进行 Attention 计算，再使用对应的 Values 得到新的 Attention 输出。

随后：

K5, V5

也会被加入 KV Cache，为 T6 的生成做好准备。

整个过程可以简化为：

Previous Tokens → Cached K/V

New Token → New Q/K/V → Attention with Cached K/V → Generate Next Token → Add New K/V to Cache

这个过程会发生在使用 KV Cache 的相关 Transformer Attention Layer 中，因此对于拥有大量层的大语言模型，KV Cache 本身也可能占据相当可观的内存空间。

Prefill 和 Decode 阶段有什么区别？

LLM 推理通常可以分成两个非常重要的阶段：Prefill（预填充）和 Decode（解码生成）。理解这两个阶段，也能更清楚地理解 KV Cache 的作用。

假设用户提交了一个包含 2,000 个 Token 的 Prompt。

在 Prefill 阶段，模型需要处理这 2,000 个输入 Token，计算它们之间的 Attention，并为后续生成建立 KV Cache。由于 Prompt 中的 Token 已经全部存在，这一阶段通常可以利用 GPU 的并行计算能力批量处理。

完成 Prefill 后，模型开始生成回答，进入 Decode 阶段。

Decode 阶段通常是自回归的：生成一个 Token，再生成下一个 Token。此时 KV Cache 开始发挥非常重要的作用，因为历史 Token 的 K/V 已经被缓存，新 Token 可以直接与这些缓存结果进行 Attention，而不需要重新执行全部历史计算。

因此，用户感受到的 LLM 延迟也可以拆成两个常见指标：

指标	含义	主要受到什么影响
TTFT	Time to First Token，首 Token 延迟	Prompt 长度、Prefill 计算等
TPOT	Time per Output Token，每个输出 Token 的生成时间	Decode、KV Cache、硬件性能等

一个 Prompt 非常长时，用户可能需要更久才能看到第一个 Token；而进入 Decode 后，KV Cache 的管理效率会直接影响后续 Token 的生成速度和系统吞吐量。

为什么 KV Cache 能提高 LLM 推理速度？

KV Cache 的主要性能优势来自避免重复执行历史 Token 的 K/V 投影计算。

对于自回归 LLM 来说，历史上下文会随着每个新 Token 不断增长。如果没有缓存机制，每一步都重新计算全部历史表示，会产生大量重复工作。

KV Cache 将已经完成的 Key 和 Value 保存下来，使每个 Decode Step 主要处理新 Token，并复用此前的 Attention 状态。

这对于长文本生成尤其重要。输出只有几个 Token 时，缓存带来的优势可能没有那么直观；但当模型连续生成数百甚至数千 Token 时，历史上下文越来越长，避免重复计算的价值也会越来越明显。

不过，KV Cache 并没有让 Attention 变成“与上下文长度无关”。新 Token 的 Query 仍然需要与越来越多的历史 Keys 计算 Attention，并读取对应 Values。因此，上下文增长仍会增加计算和内存访问压力。

KV Cache 优化的是重复计算，而不是消除长上下文本身的成本。

为什么 KV Cache 会占用大量 GPU 显存？

KV Cache 带来的主要代价就是内存占用。

模型需要为已经处理的 Token 保存 Key 和 Value，而且这些缓存通常存在于多个 Transformer Layer 中。因此，KV Cache 大小会受到多个因素影响，包括模型层数、KV Head 数量、Head Dimension、数据精度、上下文长度和并发请求数量。

最直观的规律是：

上下文越长 → 需要缓存的 Token 越多 → KV Cache 越大。

如果一个用户只有几百个 Token 的上下文，KV Cache 相对较小；但如果上下文扩展到数万甚至更长，缓存规模会明显增加。

并发会进一步放大这个问题。推理服务器通常需要同时处理多个用户，而每个正在生成的请求都可能维护自己的 KV Cache。如果同时存在大量长上下文请求，显存可能很快被缓存占据。

因此，在 LLM Serving 中，GPU 显存不仅用于存储模型权重，还需要为 KV Cache、中间计算结果以及 Batch 等保留空间。这也是为什么“模型能装进 GPU”并不等于“这块 GPU 可以高吞吐量地服务大量用户”。

上下文长度为什么会影响 KV Cache？

Context Window（上下文窗口）与 KV Cache 之间存在直接关系，因为模型需要保存当前有效上下文中 Token 对应的 K/V 状态。

假设模型已经处理 1,000 个 Token，那么 KV Cache 需要保存这些 Token 的相关状态；当上下文增长到 10,000 个 Token 时，需要维护的数据量也随之显著增加。

这会产生两个影响。

首先是显存压力增加。更长的 Context Window 意味着单个请求可能占用更多缓存空间，因此相同 GPU 能够同时服务的请求数量可能下降。

其次是内存访问和 Attention 计算增加。生成新的 Token 时，需要访问更长的 K/V 序列，因此即使历史 K/V 不需要重新计算，长上下文仍可能降低 Decode 效率。

所以，一个模型支持 128K 或更长 Context Window，并不意味着使用超长上下文没有成本。最大上下文能力和实际推理效率是两个不同的问题。

MHA、MQA 和 GQA 为什么会影响 KV Cache 大小？

现代 Transformer 为了降低 KV Cache 成本，还发展出了不同的 Attention 设计，其中常见的包括 MHA、MQA 和 GQA。

传统 Multi-Head Attention（MHA）通常为不同 Attention Heads 保留各自的 Key 和 Value，因此 KV Cache 较大。

Multi-Query Attention（MQA）则让多个 Query Heads 共享同一组 Key 和 Value，大幅减少需要缓存的 K/V 数量。Grouped-Query Attention（GQA）位于两者之间，让一组 Query Heads 共享 K/V，在模型能力和缓存效率之间进行权衡。

Attention 类型	K/V 结构	KV Cache 特征
MHA	每个 Query Head 通常有对应 K/V Head	缓存较大
GQA	多个 Query Heads 共享一组 K/V Heads	缓存明显降低
MQA	Query Heads 共享更少的 K/V Heads	缓存进一步降低

这也是为什么分析现代 LLM 推理效率时，不能只看模型参数量。即使两个模型规模接近，如果它们采用不同的 Attention 架构，KV Cache 的显存需求也可能存在明显差异。

KV Cache 与 Batch Size、吞吐量有什么关系？

对于 AI 服务商而言，KV Cache 不只是单个用户的速度问题，还直接影响整个推理系统能够同时处理多少请求。

GPU 显存是有限的。模型权重占据一部分空间后，剩余显存可以用于 KV Cache 和其他运行数据。如果单个请求需要更大的 KV Cache，那么同一块 GPU 能够同时容纳的请求数量就可能减少。

这会影响 Batch Size（批处理规模）。较大的 Batch 通常有助于提高 GPU 利用率和整体吞吐量，但前提是显存能够同时容纳这些请求的 KV Cache。

因此，LLM Serving 需要在多个目标之间寻找平衡：

长上下文、并发用户数量、Batch Size、延迟、吞吐量和显存使用。

这也是为什么现代推理框架会专门优化 KV Cache 管理，例如减少内存碎片、动态分配缓存空间、复用共享前缀，以及使用更低精度的数据格式保存 KV。

KV Cache 与 Prompt Caching 是一回事吗？

不是。两者都包含“缓存”，但缓存的对象和使用层级不同。

KV Cache 主要是模型推理过程中的内部缓存，用于保存 Attention 已经计算出的 Key 和 Value，从而加速同一次生成过程中的后续 Token 计算。

Prompt Caching 通常指在多个请求之间复用相同 Prompt 或共同前缀已经产生的计算结果。例如，大量请求都包含相同的 System Prompt，推理平台可以尝试复用这部分前缀对应的缓存，而不必为每个请求从头完成相同的 Prefill。

因此，可以简单理解为：

对比	KV Cache	Prompt Caching
缓存对象	Attention 的 Key / Value	重复 Prompt / Prefix 的计算结果
主要作用	加速当前序列的 Decode	减少重复 Prompt 的 Prefill 成本
使用场景	几乎所有自回归生成	存在重复前缀的请求
影响	Token 生成速度与显存	TTFT、计算量与服务成本

Prompt Caching 的底层实现可能利用或复用 KV 状态，但从用户和系统设计角度看，两者解决的问题并不完全相同。

KV Cache 与 LLM 推理优化有什么关系？

KV Cache 是 LLM Inference Optimization 中非常基础的一环，但现代推理系统通常不会只依赖这一种技术。

除了 KV Cache，推理系统还可能采用 Continuous Batching、Paged Attention、KV Cache Quantization、Prefix Caching 和 Speculative Decoding 等方法提高吞吐量或降低延迟。

这些技术解决的问题各不相同。例如，Paged Attention 重点改善 KV Cache 的内存管理效率，KV Cache Quantization 尝试降低缓存精度以减少显存占用，而 Speculative Decoding 则尝试减少生成多个 Token 所需要的串行推理成本。

因此，现代 LLM 推理优化的核心问题已经不仅是“模型计算有多快”，还包括如何管理显存、如何调度请求，以及如何让有限 GPU 资源同时服务更多 Token 和用户。

KV Cache 正处于这些问题的交汇点，因此也是理解 AI Inference 基础设施的重要概念。

总结

KV Cache（Key-Value Cache）是 Transformer 大语言模型推理中的关键缓存机制。它会保存此前 Token 在 Attention 中已经计算得到的 Key 和 Value，让 Decoder 在生成新 Token 时能够直接复用历史结果，避免反复计算整个上下文的 K/V。

这使 KV Cache 成为提高自回归 LLM 推理效率的重要技术。但缓存并不是免费的：上下文越长、模型层数越多、KV Heads 越多、并发请求越高，需要占用的内存通常也越大。

因此，KV Cache 同时连接了 LLM 推理中的两个核心问题：速度和显存。它能减少重复计算、提高 Decode 效率，却也可能成为长上下文和高并发服务中的主要显存消耗来源。

理解 KV Cache 后，也更容易理解为什么现代 AI 推理系统会采用 GQA、MQA、Paged Attention、Prefix Caching 和 KV Cache Quantization 等技术。这些优化本质上都在解决同一个更大的问题：如何让大语言模型在有限计算和内存资源下，更高效地生成 Token。

FAQ

KV Cache 会改变 LLM 生成的回答吗？

正常情况下不会。KV Cache 主要复用已经计算过的 Attention Key 和 Value，是推理效率优化机制，并不会改变模型本身的参数。

关闭 KV Cache 后 LLM 还能生成文本吗？

可以，但自回归生成通常会产生更多重复计算，尤其在长文本生成时效率会明显下降。

KV Cache 会一直增长吗？

在一个生成请求中，随着上下文 Token 增加，KV Cache 通常也会增长，直到达到上下文限制、请求结束或系统采用相应的缓存管理策略。

为什么长上下文模型更需要关注 KV Cache？

因为更长的上下文意味着需要保存更多 Token 的 Key 和 Value，同时生成新 Token 时还需要访问更长的缓存序列，因此显存占用和内存访问压力都会增加。

KV Cache 是模型训练时也必须使用的吗？

KV Cache 的主要价值体现在自回归推理阶段。训练通常可以并行处理完整序列，因此其计算模式与逐 Token Decode 不同，通常不会以相同方式依赖推理时的 KV Cache。