模型权重装进显存，不等于长对话一定能跑起来。对于使用完整因果注意力的自回归语言模型，输入和输出越长，需要保留的 KV cache 往往越大。估算部署容量时，把权重和这部分运行状态分开，通常比只盯着“模型多少 B”更有用。

KV cache 保存的是什么？

注意力计算会把 token 的表示映射为查询 Q、键 K 和值 V。逐个生成新 token 时，新位置的查询需要与已有位置的键和值交互。KV cache 留下历史位置的 K、V，下一步复用它们，避免再次计算同一段历史的键和值。

它并不是缓存“模型给出的答案”，也不意味着完全跳过历史上下文。新 token 仍需要对可见历史做注意力计算。缓存减少重复工作，却要用存储空间换取这部分计算。

为什么上下文越长，显存越吃紧？

先看一个简化估算：各层都采用完整注意力，K、V 以相同精度存储，忽略内存对齐、分配器和其他临时张量。设层数为 L，同时处理的序列数为 B，缓存长度为 T，KV 头数为 H，单头维度为 D，每个数占 S 字节。

KV 字节数 ≈ 2 × L × B × T × H × D × S

前面的 2 分别对应 K 和 V。T 包括已处理的提示词及生成过程中需要保留的 token；对于长度不同的批次，实际占用还与引擎是否填充、如何分配缓存有关。

一个能复算的容量例子

假设 32 层、一个序列、8192 个缓存位置、8 个 KV 头、每头 128 维，以每个数 2 字节存储。代入上式得到 1 GiB。若其余条件不变，仅将 KV 头数改为 32，则是 4 GiB。这是一组虚构参数的算术示例，不是某款模型的实测内存。

def kv_gib(layers, batch, tokens, kv_heads, head_dim, bytes_per_element=2):
    return 2 * layers * batch * tokens * kv_heads * head_dim * bytes_per_element / 2**30
assert kv_gib(32, 1, 8192, 8, 128) == 1.0
assert kv_gib(32, 1, 8192, 32, 128) == 4.0
print('8 KV heads:', kv_gib(32, 1, 8192, 8, 128), 'GiB')
print('32 KV heads:', kv_gib(32, 1, 8192, 32, 128), 'GiB')

这段纯 Python 示例已运行，断言通过，输出为：

8 KV heads: 1.0 GiB
32 KV heads: 4.0 GiB

GiB 使用 2 的 30 次方字节为单位。这里算的只有 K、V 张量，不能把结果当成整个推理服务的显存预算。权重、激活、工作区、缓存分配和框架开销都需要另外考虑。

权重量化，不会自动解决缓存问题

“模型已经量化到 4 bit”通常是在描述权重。KV cache 是否量化、使用什么精度，是另一项配置。权重变小后，长上下文仍可能使缓存成为主要占用之一。

选择优化方法时，可以先确认是长度、并发还是精度带来的压力。缩短无关历史、控制同时生成的请求数、采用适合模型和引擎的缓存策略，各自针对不同问题。不要仅凭一个内存公式承诺性能改善。

不同缓存策略在交换什么？

动态缓存按生成过程增长；静态缓存预留空间，让形状更稳定，但可能为短请求留出用不到的容量。卸载把一部分缓存放到 CPU，减少设备端存储压力，同时增加数据搬运。缓存量化减少表示所需空间，也引入额外处理与精度权衡。

这些策略是否可用、能否配合编译，以及具体接口，取决于模型和软件版本。先确认支持范围，再在目标硬件上测量首 token 延迟、逐 token 延迟和峰值内存，比直接复制一组配置更可靠。

部署优化还涉及权重和执行方式，可结合此前的大语言模型部署与优化一起阅读。KV cache 是其中一个独立预算项，而不是对所有性能问题的统一解释。

参考资料

• Hugging Face Transformers：How caching works，缓存机制的第一手文档。
• Hugging Face Transformers：Cache strategies，缓存策略和支持范围。main 分支会持续变化，本文不固定承诺某个版本的接口行为。

补发说明：文章日期保留原计划的北京时间 2026 年 10 月 7 日 14:00，实际于当日稍后补发。本文讨论已有技术原理，不作为实时新闻。