12｜KV 缓存轨道：为什么越聊越占内存

拆分 prefill 与 decode，计算缓存增长，并理解混合注意力的取舍。

生成第 100 个 token 时，前 99 个位置的键和值并没有改变。KV 缓存把这些历史结果停在轨道旁，下一轮只为新 token 计算并追加一格。

先建立整机直觉

不要先背术语。先问三个工程问题：这一阶段接收什么形状的数据、做了哪一种变换、结果交给谁。只要数据流清楚，公式就不再是孤立符号。

核心机械结构

• prefill 一次处理完整提示词，产生首批 K/V；decode 每轮只处理新位置。
• 缓存大小近似与层数 × K/V 头数 × head_dim × 序列长度 × 数据字节数成正比。
• 窗口注意力、线性注意力、量化缓存和 GQA 都在不同方向上降低长序列成本，但可能改变质量或兼容性。

跟着一个例子走

24 层、4 个 K/V 头、head_dim=128、长度 4096、每元素 2 字节，K 和 V 合计约 24×4×128×4096×2×2≈192 MiB，尚未包含批次和其他激活。

阅读例子时，把“固定权重”和“本次请求产生的激活”分别标记。前者在训练后保存，后者会随输入变化；混淆两者会导致对记忆、隐私和性能的错误判断。

容易掉进的坑

缓存不会让注意力变成常数成本：新查询仍要读取历史键值，缓存也持续占内存。它省的是历史 K/V 的重复投影和部分层计算。

动手工坊

1. 用给定公式计算 8k 与 32k 上下文的缓存差异。
2. 分别画出 prefill 和单步 decode 的输入输出形状。
3. 为移动设备提出三种降内存策略，并写出每种可能的质量代价。

完成后不要只保存结果。记录输入、参数、观察和结论，换一组输入重复实验。一个现象只有在可重复时才是证据。

检查点

你应能解释 KV cache 用内存换取了哪些时间。

回到页面上方的互动任务，调节两个控制量并完成选择题。答对后，本关会在浏览器中记为完成并获得 XP。

参考与延伸

• https://mlx.void.app/zh
• https://arxiv.org/abs/2505.09388

本课程为 aiHubHub 原创改写。外部站点只用于核对概念范围与交互启发，正文、例子、练习和界面均重新设计。