DeepSeek MLA：低秩 KV Cache 与推理效率

MLA（Multi-head Latent Attention）保留对完整历史 token 做 softmax attention 的访问语义，但把常驻 cache 从完整多头 K/V 换成低维 latent KV 与小型 RoPE 分支。它优化的是每个历史 token 存什么、读多少，不是把 attention 变成线性复杂度。

1. 低秩 KV 联合压缩

标准 KV Cache 保存各层历史 K/V。MLA 先把 attention 输入 $h_t$ 投影到共享 latent：

$$c_t^{KV}=W_{DKV}h_t$$

再从 latent 形成不含位置旋转的内容 Key 与 Value：

$$k_t^C=W_{UK}c_t^{KV}, \qquad v_t=W_{UV}c_t^{KV}$$

推理时主要缓存 $c_t^{KV}$，而不是完整 $k_t^C$、$v_t$。K 与 V 共用同一个低维 bottleneck，所以这不是对既有 cache 做事后压缩，而是模型原生的表示合同。

用 DeepSeek-V2 的参数说明：

参数	数值	含义
n_heads	128	attention heads
head_dim	128	每个 head 维度
d_c	512	latent KV 维度
d_R	64	解耦 RoPE key 维度

同等 head 配置的 MHA 每 token 每层为：

$$2\times128\times128=32768\ \text{elements}$$

MLA 缓存为：

$$d_c+d_R=512+64=576\ \text{elements}$$

在这个同配置理论口径下是约 $56.9\times$ 的元素数差异。

2. 为什么 MLA 不是 MQA

MQA 让所有 Query heads 共享一组完整 K/V；GQA 让一组 Query heads 共享一组 K/V。MLA 则让多个 heads 共享 latent，再通过上投影获得各自使用的内容子空间：

MQA: many Q heads -> one shared K/V
GQA: groups of Q heads -> several shared K/V
MLA: many Q heads -> shared latent -> projected head views

因此“cache 看起来很小”不代表三者表达路径相同。MQA/GQA 改的是 KV 份数，MLA 改的是 KV 表示。四条 Attention 演化路线的完整坐标见 Attention 架构演化。

3. RoPE 为什么必须解耦

若直接对 $W_{UK}c_i^{KV}$ 加 RoPE：

$$q_t\cdot\operatorname{RoPE}(W_{UK}c_i^{KV})^\top$$

位置相关旋转会阻止 $W_{UK}$ 被静态吸收到 Query 路径；decode 可能需要为历史 token 显式恢复内容 Key。MLA 因此把 Key 拆成：

$$k_t=[k_t^C;k_t^R]$$

• $k_t^C$：从 latent 恢复的内容部分，不直接施加 RoPE。
• $k_t^R$：独立投影并施加 RoPE 的小型位置分支。

cache 最终保存 $c_t^{KV}$ 与 $k_t^R$。这就是公式中 d_c + d_R，也说明只记 latent rank 会低估实际 payload。

4. 矩阵吸收如何避免全量解压

对内容 Key：

$$\operatorname{score}^{C}_{t,i} =q_t^\top W_{UK}c_i^{KV} =\left(W_{UK}^\top q_t\right)^\top c_i^{KV}$$

可以先把当前 Query 变换到 latent 空间，再直接与历史 $c_i^{KV}$ 计算，无需逐 token 恢复完整 $k_i^C$。

Value/output 路径同样可利用结合律：

$$o_t =W_O W_{UV}\left(\sum_i a_{t,i}c_i^{KV}\right)$$

工程实现把相关权重组合到适合的线性路径，这类 weight absorption 是 decode 节省数据移动的关键。RoPE 分支仍需单独参与 score，不能被这一步消掉。

5. 容量账必须标出分母

令 $L$ 为层数，$S$ 为已缓存 token，$B$ 为请求数，$b_{\text{elem}}$ 为 payload 元素字节数：

$$\text{MLA cache bytes} =L\times S\times B\times(d_c+d_R)\times b_{\text{elem}}$$

以 L=60、S=128000、d_c=512、d_R=64、BF16、batch 1 为例：

$$60\times128000\times576\times2 =8.85\ \text{GB}\approx8.24\ \text{GiB}$$

同配置 MHA 理论 payload 约为 $468.8$ GiB。这个比较用于说明 schema 差异；DeepSeek-V2 论文摘要报告的 93.3% 降幅是相对论文指定基线，附录消融又使用另一比较对象，不能与 $56.9\times$ 互相替换。

实际物理占用还要计 cache dtype 的 Scale/对齐、分页浪费、TP/DP 布局和 runtime workspace。

6. Prefix、Paged KV 与 P/D 分离

MLA 通常不改变 prefix 复用的语义：相同 token、模型/adapter 与位置上下文仍可命中。变化的是 page payload：

MHA/GQA page:
  K[block_tokens, kv_heads, head_dim]
  V[block_tokens, kv_heads, head_dim]

MLA page:
  c_KV[block_tokens, d_c]
  k_R[block_tokens, d_R]

Paged KV 仍可维护逻辑 block 到物理 block 的映射，但 bytes/token、stride 与 attention kernel 都必须理解 latent layout。P/D 分离传输的也是 MLA payload；字节更少不代表传输免费，接收端必须采用兼容的模型权重、位置语义和 decode kernel。

7. Prefill 与 Decode 的实现路径

vLLM 的 MLA 实现文档把常见路径区分为：

路径	更适合	主要考虑
compute-friendly	Prefill	Query 多、计算密度高，展开后更易利用算力
data-movement-friendly	Decode	Query 少、历史长，直接读取 latent 更省带宽

因此 MLA 不是“所有阶段都使用同一个压缩 GEMM”。scheduler、batch shape、cache dtype 与专用 kernel 会决定理论优势是否落地。

SGLang v0.3 发布材料把 weight absorption、grouped decoding kernels、FP8 batched MatMul 与 FP8 KV cache 组合后报告了特定 H100 实验中的 3x–7x 吞吐提升。该数字属于版本、模型、硬件和 baseline 绑定的来源结果，不能当作 MLA 的普遍收益。

8. 性能边界与诊断

MLA 直接改善的是 cache 容量和历史读取字节，但：

• Prefill 仍处理 causal 可见区域。
• Decode 仍访问历史 token，只是 payload 更小。
• 长上下文的 score 长度仍增长。
• 模型必须原生训练为 MLA。
• 无专用 layout/kernel 时，显式解压可能吃掉收益。

诊断时至少核对：

证据	要回答的问题
模型 config	d_c、d_R、层数与 attention 类型是什么？
runtime log / kernel trace	是否走 MLA 专用 prefill/decode 路径？
allocator 指标	实测 bytes/token 是否包含 Scale、对齐和页浪费？
性能 breakdown	TPOT、HBM read 与 attention kernel 时间是否符合预期？

TPOT 改善只能说明端到端结果，不能单独证明 MLA 路径已启用；batch、MoE、量化、scheduler 和网络都可能同时变化。

相关页面

• Attention 架构演化 — 区分 KV 共享、表示压缩、访问稀疏与递推状态。
• KV Cache — 逻辑容量、Paged KV、Prefix 与生命周期。
• CSA/HCA 注意力 — 压缩与稀疏访问的来源驱动案例。
• 推理框架对比 2026 — Serving stack 的实现与选型合同。
• 模拟器建模指南 — MLA 公式的 per-rank 与估算口径。

参考资料

• DeepSeek-V2 — MLA、RoPE 解耦、cache 对比与消融。
• DeepSeek-V3 Technical Report — V3 继续采用 MLA 的架构与部署背景。
• vLLM MLA attention API — Prefill/decode 路径与 latent cache 实现。
• SGLang v0.3 Release — 引擎侧 MLA 优化及其特定实验结果。