KV Cache & Inference Optimizations: 解释 KV Cache 的原理，为什么训练时不能用。

Core Concept: 缓存已算过的 K/V 避免重复计算，把每步复杂度从 O(S²) 降到 O(S)；但训练需全序列并行反向，缓存无用且占显存。

数学机理：<strong>自回归解码的重复计算问题</strong>——生成第 t 个 token 时，注意力需要该位置的 Q 与<strong>所有历史位置</strong>的 K/V。若不缓存，则每步都要重算历史位置的 K/V（因为它们依赖已固定的输入），造成 O(S²) 的重复计算。<strong>KV Cache</strong> 把每层每个位置算好的 K/V <strong>保存下来</strong>：解码第 t 步时，只计算新 token 的 Q（以及它的 K/V 并追加到 cache），然后用 Q 与<strong>整个 cache</strong>做注意力——每步复杂度从 O(S²) 降到 <strong>O(S)</strong>（读取 cache）。<strong>代价</strong>——显存占用 ∝ 2（K/V）× 层数 × KV 头数 × d_h × 序列长度 × batch × 精度；长上下文 + 大 batch 下 KV cache 常成为显存主导（可能超过权重）。<strong>为什么训练时不用</strong>——(1) <strong>训练是全序列并行的</strong>——前向一次处理整条序列（L 个位置同时算），注意力矩阵一次算出，<strong>不存在'逐步重复计算'</strong>，故无缓存需求；(2) <strong>反向传播需要全序列的中间量</strong>——若用缓存会导致梯度路径混乱（缓存的值在训练中会变化）；(3) <strong>训练时更应省的是激活显存</strong>（用检查点/Flash）而非 K/V。故 KV cache 是<strong>推理专属</strong>的优化。<strong>注意</strong>——训练与推理的注意力数学相同，只是'计算组织方式'不同（训练并行、推理串行 + 缓存）。

深度剖析与工程权衡：① <strong>KV cache 显存账本</strong>——以 LLaMA-2-7B（32 层、32 KV 头、d_h=128）为例：每 token 的 KV cache = 2×32×32×128×2 字节（FP16）≈ 0.5 MB；1k token 约 0.5 GB、32k token 约 16 GB——<strong>接近甚至超过权重</strong>（14 GB）。这解释了长上下文推理的显存瓶颈与 MQA/GQA/MLA/KV 量化的价值。② <strong>GQA 的收益计算</strong>——若 KV 头数从 32 降到 8（GQA），KV cache 降为 1/4（4 GB at 32k）；这是 LLaMA-2/3 采用 GQA 的直接原因。③ <strong>prefill vs decode 的差异</strong>——prefill 阶段（处理输入）可并行、且<strong>不需要</strong> cache（输入已知）；decode 阶段才依赖 cache。故'cache 的收益'只体现在 decode。④ <strong>与连续批处理的关系</strong>——KV cache 的显存决定'能同时跑多少请求'（批大小），进而决定吞吐；故 KV 压缩技术直接影响服务成本。⑤ <strong>'训练/推理不一致'的风险</strong>——训练时不用 cache、推理时用，若实现有差异（如位置编码处理、mask 处理）会导致性能下降；需专门验证（见 M3 的训练-推理一致性题）。⑥ <strong>面试要点</strong>——被问'KV cache 是什么'，应给出'<strong>缓存已算的 K/V → 每步 O(S²)→O(S)</strong>'与'<strong>显存 ∝ 2×层×KV头×d_h×S×batch</strong>'的账本，并说明'训练全序列并行故不需要'；能算出 7B 模型 32k 上下文的 KV cache 量级是硬功夫。