详细解释
多头潜在注意力（Multi-head Latent Attention，MLA） 是 DeepSeek 团队在 2024 年发布的 DeepSeek-V2 中提出的注意力架构，并一路延续到 DeepSeek-V3 与后续的推理模型，如今已成为开源长上下文模型最具代表性的技术名片之一。它要解决的是长上下文推理中最现实的一道坎：上下文越长，KV 缓存 占用的显存就越夸张，直接把并发能力和单位成本卡死。传统 多头注意力 的每层、每个 KV 头都要把完整的 Key 和 Value 张量留在显存里，序列长度翻一倍缓存就翻一倍，128K 上下文下 70B 级模型的 KV 缓存动辄几十 GB，几乎与模型权重同量级，显存水位一高，能同时服务的请求数就急剧下降。MLA 的出发点很明确——想办法让显存里真正缓存的东西变得更小，而不是像早年的做法那样简单粗暴地砍掉 KV 头数、用质量换空间。对商用推理来说，这直接意味着同一张卡能承载的并发请求更少、长文档类业务的单位成本更高，MLA 的压缩正是冲着这个成本痛点来的。
MLA 的机制可以用一句话概括：把每个 Token 的 Key 与 Value 先用一个低秩投影联合压缩成一个维度小得多的潜在向量，推理时显存里只缓存这一个潜在向量，需要计算注意力时再用上投影矩阵把它还原成 Key 和 Value。这里的「低秩」指的是中间向量的维度远小于原本 Key、Value 拼接后的维度，相当于先把高维的 KV 信息打包压成一个小「压缩包」，用时再解压展开。于是显存里缓存的就不再是完整的 Key 和 Value，而是一个体积小得多的潜在向量，KV 缓存体积相比标准 MHA 通常下降 90% 以上。位置信息则采用「解耦」设计：模型专门留出一部分通道用来承载 旋转位置编码，让这部分与压缩后的潜在向量分开处理，避免位置信息在低秩压缩的过程中被一并抹掉。用中文把整个流程说清楚就是——先把 Key 和 Value 压成一条短向量存进显存，用的时候再用两组上投影矩阵分别把它还原成 Key 和 Value 参与注意力计算，缓存的对象始终是那条短向量，而不是还原后的完整结果。
把它和 MQA、分组查询注意力 放在一起比较，思路差异很直观：MQA 和 GQA 是从「数量」入手，让多个 Query 头共享更少的 KV 头，本质上是直接减少要缓存的头数；MLA 是从「体积」入手，头数可以保留得比较多，但每个头缓存的内容被低秩压缩成了一条潜在向量，压缩得更彻底，也更容易兼顾质量。MLA 通常与 混合专家模型 搭配出现（DeepSeek 系列正是 MLA 加 MoE 的组合），一个省显存、一个省算力，在 长上下文扩展 场景里叠加收益很可观。唯元智创 在长上下文网关侧的实践是：把采用 MLA 架构的开源模型作为长序列请求的默认后端，对上层完全透明——调用方依旧按标准接口发请求，无需关心底层是 MLA 还是 GQA，但同样的显存预算下可承载的并发与最大上下文都明显提升，长文档与长会话类业务的单位成本随之下降。权威依据可参考 DeepSeek-V2 论文。
主流注意力变体的 KV 缓存压缩对比表
| 变体 | KV 头数策略 | KV 缓存相对体积 | 压缩方式 | 是否需训练期改动 | 推理精度损失 | 典型代表模型 |
|---|---|---|---|---|---|---|
| MHA（多头注意力） | 每个 Query 头各配一组 KV 头 | 基准 100% | 无压缩 | 本身即原始结构，无需改动 | 无 | GPT-3.5 早期、多数早期 Dense 模型 |
| MQA（多查询注意力） | 所有 Query 头共享一组 KV 头 | 约降到 1/H，个位数百分比 | 共享 KV 头 | 需在预训练时确定 | 明显，长文本与代码任务尤甚 | PaLM、Falcon |
| GQA（分组查询注意力） | Query 头分组，组内共享一组 KV 头 | 约为 MHA 的 12% 至 25% | 组内共享 KV 头 | 需在预训练时确定 | 接近 MHA | Llama 3.x、Qwen3 |
| MLA（多头潜在注意力） | KV 头保留较多，但每头内容被低秩压缩 | 相比 MHA 下降 90% 以上 | 低秩联合压缩为潜在向量 | 需在预训练时确定 | 极小，长上下文反有增益 | DeepSeek-V2、DeepSeek-V3 |
| 唯元智创 支持的长上下文模型组合 | 以 GQA 与 MLA 架构模型为主 | 视模型而定，普遍低于 MHA 一半以上 | 架构层压缩叠加网关侧前缀复用 | 取决于所选开源模型 | 低 | DeepSeek 系列等开源长上下文模型 |
注意力架构四代演进对照表
| 代际 | 结构特征 | KV 缓存开销 | 训练稳定性 | 长上下文友好度 |
|---|---|---|---|---|
| 第一代 MHA | 每个 Query 头独立配 KV 头，结构最直接 | 最高，随序列长度线性增长 | 高，训练最成熟 | 一般，长上下文显存压力大 |
| 第二代 MQA | 全部 Query 头共享一组 KV 头 | 最低，但以输出质量为代价 | 较低，训练易震荡掉点 | 尚可，但长文本质量不理想 |
| 第三代 GQA | 分组共享 KV 头，在质量与开销之间折衷 | 中低，约为 MHA 的 12% 至 25% | 高，工程落地最广泛 | 较好，128K 场景常见选择 |
| 第四代 MLA | 低秩联合压缩加解耦位置编码 | 很低，相比 MHA 下降 90% 以上 | 高，已被超大规模训练验证 | 优，长上下文首选之一 |
实战经验与避坑
-
MLA 的收益只有在长上下文和高并发时才会显现，短请求场景几乎感知不到。 因为压缩优化的是显存里缓存的 KV 体积，只有当缓存本身足够大时，压缩带来的显存与带宽节省才有意义。一段几百 Token 的短问答，KV 缓存本来就很小，无论底层是 MLA 还是 MHA，延迟和成本差别可以忽略。所以如果你的业务以短请求为主，不要因为「MLA 更先进」就盲目追求；真正该看的指标是长序列占比、平均上下文长度和并发水位，只有这些指标上去了，MLA 的优势才会转化成实打实的并发容量与单位成本下降。
-
不要试图在推理阶段把 MLA 改回 MHA 来「提精度」，那会重新引入显存问题。 MLA 的关键收益正是来自那层低秩压缩，推理时若强行展开成完整的 Key 和 Value，等于把压缩的好处全部退回去，显存占用瞬间回到 MHA 水平，长上下文很容易直接爆显存。而且不少推理引擎只实现了 MLA 的压缩路径，强行改结构还可能触发未测路径导致结果错误。精度方面，MLA 在长上下文任务上通常并不吃亏，反而因为能稳定容纳更长上下文而表现更好，因此没有必要为理论上的一点点精度去做这种得不偿失的改动。
-
MLA 是预训练阶段就确定的结构，无法对已经训练好的 MHA 模型做事后转换。 压缩用的下投影矩阵和还原用的上投影矩阵都是模型权重的一部分，是在预训练中一起学出来的，不是推理时临时拼装的。给一份纯 MHA 权重硬塞一套随机初始化的投影矩阵，得到的只是随机压缩，输出会严重退化。因此选型时要在模型层面就选好架构，而不是指望部署阶段「升级」成 MLA。把这一点在选型阶段就把前提讲清楚，可以避免团队到部署时才发现方案不可行。若你手上已有 MHA 模型又不便更换，现实的做法是在新一批 GQA 与 MLA 模型里重新选型，或借助 长上下文扩展 技巧缓解显存压力，而不是硬改架构。在这一步上多做一次确认，往往能省下后期大量返工成本。
-
量化与 MLA 组合时要格外留意潜在向量的量化误差会被放大。 潜在向量是压缩后的中间表示，本身维度低、信息密度高，一旦量化到较低位宽，误差会随着上投影还原过程被放大，导致注意力分布偏离。实践中比较稳妥的做法是对潜在向量所在的缓存保持较高精度（例如 INT8 起步甚至更高），而把量化力度更多放在权重侧，并且在采用 MLA 模型的场景下务必做一轮长上下文质量回归，确认没有出现长距离依赖变差、细节回忆失败等问题，再决定是否进一步压低位宽。
-
部署前一定要确认推理引擎版本支持 MLA，老版本 vLLM 并不支持。 MLA 不是标准注意力，需要推理引擎有对应的内核实现和 KV 缓存管理逻辑。早期版本的 vLLM 对 MLA 支持不完整甚至完全没有，强行加载会走错误路径或直接报错。上线前应核对引擎版本说明与模型适配清单，必要时升级到明确支持 MLA 的版本，或换用 SGLang 等对 DeepSeek 系列适配较好的引擎。不要只看「模型能加载成功」就认为万事大吉，还要实测长上下文下的正确性与稳定性，尤其是超长序列的端到端回归。
-
选型时不要只盯着 KV 体积，还要看解码阶段的计算开销。 MLA 把缓存压小了，但还原 Key 和 Value 需要额外的投影计算，这部分开销在解码每一步都会发生，并不是免费的。因此比较不同注意力方案时，要把显存占用、解码每步计算量、实测吞吐与延迟一起看，尤其在高并发高吞吐场景里，计算开销的差异可能比显存差异更早成为瓶颈。最可靠的方式是用真实业务流量做压测，观察长上下文下的显存水位、每步延迟和整体吞吐，而不是只比较一张对比表上的单个数字。尤其在你计划同时上线多路长上下文服务时，务必先用接近真实的并发组合跑出容量曲线，再据此决定显存与实例规格。