KV 缓存与上下文长度

所谓 KV 缓存，是模型在处理提示并生成回复时构建的对话运行内存——这也是为什么即使模型本身的大小没有变化，更长的上下文也会消耗更多 VRAM 的原因。本页将解释它的本质以及其增长方式；有关构建和使用它的预填充（prefill）和解码（decode）机制，请参阅 推理如何工作。

​

KV 缓存究竟是什么

“KV” 代表键/值（key/value）——即模型为迄今为止处理的每个令牌计算出的内部表示。模型不会为每个新令牌从头重新计算这些表示，而是将它们存储在 KV 缓存中并重复使用，每次向序列中添加令牌时追加一个新条目。 这使得生成成为可能。如果没有缓存，生成回复中的第 500 个令牌意味着每次都要重新处理它之前的所有 499 个令牌。有了缓存，模型只需为每个新令牌执行新的工作，并复用已经计算过的所有内容。 缓存是在预填充阶段（当模型读取你的提示时）构建的，并在解码阶段（当它生成回复时）每个令牌扩展一个条目——有关这两个阶段如何工作，请参阅 推理如何工作。

​

为什么更长的上下文会消耗更多内存

只要令牌保留在活跃上下文中，KV 缓存就会为每个令牌、每个层保留一个条目。这意味着其大小直接与以下因素成正比：

• Context length（上下文长度）——参与计算的令牌越多，缓存条目就越多。128K 令牌的对话比 4K 令牌的对话持有更多的缓存状态。
• 批处理大小——如果你同时服务多个请求，每个请求都需要自己的 KV 缓存，因此总缓存内存会随着并发请求而倍增。

这是模型权重之外额外占用的内存，而不是用来替代权重。一个在短上下文中勉强适合你 VRAM 的模型，一旦你将其用于长对话或大文档，可能会完全耗尽内存，因为权重保持不变，但缓存持续增长。有关 KV 缓存如何计入完整的容量估算公式，请参阅 内存与卸载；有关具体的 VRAM 表格，请参阅 GPU 模型适配指南——本页不会重复这些数字。

​

上下文与速度之间的权衡

除了内存之外，更大的 KV 缓存还有速度成本。解码受内存带宽限制——每生成一个令牌，模型除了读取其权重外，还会读取迄今为止构建的整个 KV 缓存（请参阅 推理如何工作）。更大的缓存意味着每一步要读取的数据更多，因此：

• 更长的上下文会减慢解码速度。 随着对话的增长，生成速度（令牌/秒）往往会下降，即使模型本身没有变化。
• 更长的上下文会消耗更多内存，这与速度成本无关——这是第二笔独立的开销。

这两种效应都源于同一个根本原因：KV 缓存随上下文扩展，而解码的所有方面都随 KV 缓存扩展。

​

实际建议

在决定为部署分配多少上下文时，将其视为真实的资源预算，而不是免费设置。一个宣传具有巨大最大上下文（128K、256K）的模型并不意味着你应该始终以该限制运行它——根据任务的实际需求调整上下文大小，并在提交之前使用GPU 模型适配指南检查实际的内存成本。

​

深入了解

​

上下文和内存适配之后

调整 KV 缓存的大小是让模型在本地良好运行的一部分。一旦它在 localhost 上运行并响应请求，下一步就是从其他地方访问它。