KV Cache 原理
KV Cache 是自回归解码（decode）阶段最重要的加速手段之一：缓存历史 token 的 Key/Value，避免每一步重复计算与重复读取。
为什么会慢：从“每步重算”说起
在第 (t) 步解码时，模型输入长度是 (t)。如果你每一步都对整个长度重新计算 attention，那么总成本大致是：
[ \sum_{t=1}^{T} O(t^2) = O(T^3) ]
这在长输出时不可接受（实际实现会有细节差异，但“重复计算随步数累积爆炸”的趋势是一样的）。
KV Cache 的做法
对每一层注意力，把历史 token 的 (K,V) 缓存起来：
prefill（处理 prompt）阶段：一次性算出所有位置的 (K,V) 并缓存
decode 阶段：每来一个新 token，只算这个新 token 的 (K_t,V_t)，并 append 到缓存
在第 (t) 步：
(Q_t)：只对当前 token 计算
(K_{1:t},V_{1:t})：直接从 cache 读取
于是每步 attention 成本从“重算全部”变成：
[ O(t) \quad (\text{与序列长度线性相关}) ]
总成本约为：
[ \sum_{t=1}^T O(t) = O(T^2) ]
这就是 KV Cache 在推理中必不可少的原因。
KV Cache 的代价：显存与带宽
KV cache 的显存大致与以下因素成正比：
batch size
序列长度（prompt + 已生成）
层数 (L)
头数与每头维度（以及是否使用 GQA/MQA）
dtype（fp16/bf16/int8 等）
很多推理系统的瓶颈不是算力而是 KV cache 带宽（读写 cache 的开销）。
常见工程优化
GQA/MQA：减少 K/V 头数，显著降低 cache 体积与带宽压力
Paged KV Cache：把 cache 做成分页/块状管理，减少碎片并支持高并发变长请求（vLLM 等常用）
量化 KV：把 KV cache 低比特存储以换显存（需要权衡精度与吞吐）
FlashAttention：在训练/prefill 阶段减少中间张量与提升带宽利用率
与“并发/吞吐/延迟”的关系
在服务端推理中，KV cache 直接决定：
能同时服务多少请求（并发）
每个 token 的生成速度（吞吐）
是否能进行高效 batching（动态 batch / continuous batching）
因此你会看到：推理系统的很多工程设计（batching、调度、memory manager）都围绕 KV cache 展开。