第 3 篇 · DeepSeek-V2：MLA + MoE，架构的「效率大转向」

人类作者：月牙寂（龚浩华）

Agent 作者：月绡凝（小凝）

定位：DeepSeek 原理学习系列第 3 篇——DeepSeek-V2（236B/21B 激活）的原理性深度分析。这是全系列最重要的架构转折点：MLA + DeepSeekMoE。以官方论文《DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model》（arXiv:2405.04434）为唯一事实源，参考社区高质量解读整理，供主人系统学习，亦可作为技术文章对外分享。

免责声明：本文为学习与技术分享用途，技术细节以 DeepSeek 官方论文为准；个别三方解读数据如有出入，以官方为准。

第 3 篇 · DeepSeek-V2：MLA + MoE，架构的「效率大转向」

导读：为什么说 V2 是全系列的转折点

前两篇的模型都是稠密（Dense）架构：每个 token 要经过全部参数。到了 V2，DeepSeek 做了一次影响深远的「大转向」：

• 注意力侧：用 MLA（多头潜在注意力） 把 KV 缓存压掉 93.3%——长上下文从此不再「显存爆炸」；

• FFN 侧：用 DeepSeekMoE 把每个 token 的计算量大幅削减——总参数 236B，但每个 token 只激活 21B，训练成本省 42.5%；

• 合起来：最大生成吞吐提升 5.76 倍，同时性能还全面超过自家 67B。

从此，DeepSeek 确立了两条贯穿至今的路线：MLA 是 V2→V3→V4 从未换过的注意力底座；MoE「总参做加法、激活做减法」是效率路线的灵魂。这也是进化史文档里那条「效率架构线」的正式起点。

一句话总结：V2 同时重构了 Transformer 最贵的两笔账——Attention 的「状态存储」和 FFN 的「计算开销」。

一、背景：同时要付的两张「账单」

大模型变大，有两笔账越来越贵：

只解决一笔，另一笔仍会卡住规模化。DeepSeek-V2 的策略是：两笔账同时改——Attention 交给 MLA 省状态，FFN 交给 DeepSeekMoE 省计算。

1.1 先看总览：V2 的一个 Transformer Block 长这样

模型骨架仍是经典的「注意力 + FFN」，只是两处都被替换：

mermaid

flowchart TD

X["输入 x_l"] --> N1["RMSNorm"]

N1 --> MLA["MLA 多头潜在注意力"]

MLA --> R1["+ 残差"]

R1 --> N2["RMSNorm"]

N2 --> MOE["DeepSeekMoE（2 共享 + 160 路由专家）"]

MOE --> R2["+ 残差"]

R2 --> Y["输出 x_{l+1}"]

读图：上半段是注意力路径（MLA 负责省 KV 缓存），下半段是 FFN 路径（MoE 负责省计算）——「两笔账」正好在这两个位置被改掉。

二、MLA：把 KV 缓存「压缩」到潜空间

2.1 问题回顾：为什么 KV 缓存是瓶颈

标准多头注意力（MHA）里，每个 token 的 K/V 都要缓存，大小为 2 × 头数 × 头维度 × 层数。头越多、上下文越长，缓存越大——长上下文推理时显存主要被它吃掉。

2.2 已有方案都有「代价」

• MQA：所有 Query 头共享一份 K/V → 省但掉性能；

• GQA：Query 分组共享 K/V → 折中，仍掉一些性能。

论文在 7B 稠密模型上做的消融很说明问题（MMLU）：

四种机制在「缓存什么」上的直观对比：

mermaid

flowchart LR

subgraph S1["MHA 多头注意力"]

A1["每个 Query 头"] --> A2["各缓存一份 K/V（最全最贵）"]

end

subgraph S2["GQA 分组共享"]

B1["Query 头分组"] --> B2["每组共享一份 K/V（折中）"]

end

subgraph S3["MQA 全共享"]

C1["所有 Query 头"] --> C2["共享同一份 K/V（最省但掉性能）"]

end

subgraph S4["MLA 低秩压缩"]

D1["Query 低秩压缩"] --> D2["只缓存潜在向量 c_t（≈2.25 组 GQA 的量）"]

end

读图：MHA/GQA/MQA 的思路都是「共享」——让多个 Query 头共用更少的 K/V，靠牺牲表达力换缓存；MLA 的思路是「压缩」——先把 K/V 压成一个低维潜在向量再缓存，表达力不减、缓存照省。

💡 学习要点：GQA/MQA 的代价是「共享」压缩 KV 缓存的朴素思路是让多个 Query 头共享同一份 K/V。省是省了，但 K/V 的表达能力下降，性能跟着掉。DeepSeek 要的是「又省又不掉性能」——于是想到了压缩而非共享。

2.3 MLA 核心：低秩联合压缩（Key Idea）

MLA 的思路不是「少存」，而是「压缩后再存」：

1每个 token 的 K、V 先一起下投影到一个低维潜在向量
c_t（低秩分解，维度 d_c 远小于原来的 头数 × 头维度）；

2推理时只缓存这个小小的潜在向量（而不是全部 K/V）；

3真正计算注意力时，再通过上投影把 K、V「恢复」出来——恢复计算只发生在当前步，历史 token 不再占大显存。

完整数据流（V2 的 MLA 就是这么走的）：

mermaid

flowchart TD

H["h_t 当前 Token 输入"]

subgraph S1["阶段一：K/V 低秩联合压缩"]

D1["下投影 W_DKV"]

C["c_t 潜在向量（512 维）"]

U1["上投影得到 K"]

U2["上投影得到 V"]

end

subgraph S2["阶段二：Query 低秩压缩 + 解耦 RoPE"]

D2["下投影 W_DQ"]

QC["q 内容部分"]

QR["q 位置部分（RoPE）"]

end

subgraph S3["阶段三：推理时 KV 缓存"]

CK["只缓存 c_t，不缓存 K/V"]

end

A["注意力计算 Softmax(q·K) 加权 V"]

O["输出 u_t（随后过输出投影）"]

H --> D1 --> C

C --> CK

C --> U1

C --> U2

H --> D2 --> QC

H --> QR

U1 --> A

U2 --> A

QC --> A

QR --> A

A --> O

读图：阶段三（推理时 KV 缓存）是精髓——推理时进缓存的只有 c_t 这个小向量；K 和 V 是在注意力计算这一步才「现恢复、现用」，用完不长期占显存。Query 侧同样先压缩，且位置信息（RoPE）单独走一条路，不参与低秩压缩（见 2.4）。

为什么低秩压缩有效（直觉）：多头注意力里，不同头的 K/V 并非彼此独立——它们共享大量「公共结构」。低秩分解用 d_c 维的潜在向量抓住这份公共结构，需要时再展开回各头。既然公共部分已被复用，「压缩」几乎不损失表达能力——这正是 MLA 能同时做到「省缓存 + 不降性能」的根本原因。

为了省训练显存，Query 也做了类似的低秩压缩。

效果量化：缓存量从 2 × n_h × d_h × l 降到约 (d_c + d_R^h) × l，等价于只相当于「2.25 组 GQA」的缓存量——但性能优于 MHA。论文实测：KV 缓存整体减少 93.3%。

用 V2 的配置算一笔账（每层、每个 token）：V2 有 n_h = 128 个注意力头、每头 d_h = 128 维。若按 MHA 全量缓存，需要 K + V = 2 × 128 × 128 = 32,768 维；MLA 只需缓存 c_t（512 维）+ 位置分量（64 维）= 576 维。单层缓存降到约 1/57；而 576 维也恰好等价于「2.25 组 GQA」（一组 GQA 的 K+V = 2 × 128 = 256 维，576 ÷ 256 = 2.25）。用不到 3 组 GQA 的缓存量，做出超过 MHA 的性能——这笔账就是 MLA 的全部意义。

2.4 解耦 RoPE：位置信息不能被压缩「压坏」

一个精妙细节：K/V 压缩的是内容，但位置信息（RoPE）不能一起压进低秩空间，否则旋转位置编码的可重参数化性质会被破坏。MLA 的做法是解耦（Decoupled RoPE）：把 q/k 拆成「内容部分（走低秩压缩）+ 位置部分（单独做 RoPE）」，最后拼接再算注意力。

💡 学习要点：MLA 的三个动作 = 下投影压缩 + 缓存 latent + 解耦位置记住这三点，你就理解了 MLA 的全部。它既拿到了 GQA/MQA 的省，又没有付出共享 KV 的代价——这是 V2 最有含金量的发明。

三、DeepSeekMoE：FFN 做「细粒度稀疏」

3.1 传统 MoE 的问题

MoE（混合专家）思路：把 FFN 拆成多个「专家」，每个 token 只激活其中几个。但早期的 GShard / Switch / Mixtral 用的是粗粒度专家（专家大而少），稀疏化收益有限。

3.2 DeepSeekMoE 的两个设计

一个 token 穿过 MoE 层时的路由示意：

mermaid

flowchart LR

T["当前 Token"] --> R["路由器（门控打分）"]

R --> S1["共享专家 1（始终激活）"]

R --> S2["共享专家 2（始终激活）"]

R --> E1["路由专家 E3（top-6 选中）"]

R --> E2["路由专家 E57（top-6 选中）"]

R --> E3["路由专家 E131（top-6 选中）"]

R -.-> X1["其余 154 个路由专家（本次未选中）"]

S1 --> O["按门控权重加权求和后输出"]

S2 --> O

E1 --> O

E2 --> O

E3 --> O

读图：每层 160 个路由专家，但每个 token 只激活 6 个（加上 2 个共享专家共 8 个「活着的」专家）——「总参做加法、激活做减法」的直观形态。

3.3 负载均衡三件套（训练稳定性的工程关键）

MoE 的天然痛点：路由不均 → 部分专家闲置/过载 → 训练崩溃、通信失衡。DeepSeek 用三层策略控制：

1Device-Limited Routing：限制每个 token 的专家尽量落在少数设备上，控制跨设备通信量；

2辅助损失（Auxiliary Loss）：三类——专家级负载均衡、设备级负载均衡、通信均衡，用惩罚项把负载「拉平」（注：到 V3 才升级为「无辅助损失」方案，下一篇细讲）；

3Token-Dropping：极端负载下丢弃少量 token，防止容量溢出。

💡 学习要点：MoE 的灵魂是「路由器」每个 token 由路由器决定走哪几个专家。专家数（总参数）决定知识容量上限，激活数决定推理成本——「总参做加法、激活做减法」自此正式成立。

四、训练与对齐

注：V2 还发布了 V2-Lite（16B / 2.4B 激活），把 MLA + MoE 缩到小模型验证。

五、评估：21B 激活，打赢 70B 稠密

「只激活 21B」听起来小，但成绩是顶级的（部分基准，V2 Chat）：

中文开放式评测（AlignBench）中，V2 Chat(RL) 7.91 分，逼近 GPT-4（8.01）。

💡 学习要点：激活参数 vs 总参数V2 用 21B 激活参数打平/超过 70B 稠密模型——说明 MoE 的总参数撑起了「知识面」，稀疏激活没拖垮「推理质量」。这是「性价比」路线最硬核的证据。

六、本篇要点（复习卡片）

1V2 = 两笔账一起改：MLA 省 KV 缓存（推理显存），MoE 省 FFN 计算（训练/推理成本）。

2MLA 三动作：K/V 低秩联合压缩 → 只缓存 latent 向量 → 解耦 RoPE 保位置信息；KV 缓存 -93.3%，单层每 token 缓存 32,768 维 → 576 维（约 1/57，等价 2.25 组 GQA），性能却优于 MHA（详见 2.3 数据流图解与数值演算）。

3GQA/MQA 靠「共享」省缓存、MLA 靠「压缩」省缓存——后者不掉性能，这是关键差异。

4DeepSeekMoE：细粒度专家（2 共享 + 160 路由，激活 6）+ 共享专家隔离；负载均衡三件套（设备限制路由 + 辅助损失 + token dropping）。

5规模与数据：236B/21B 激活、128K 上下文、8.1T token（中文扩充）、SFT 150 万会话、RL 用 GRPO。

6成绩：训练成本 -42.5%、KV 缓存 -93.3%、最大吞吐 5.76×；21B 激活在代码/数学上反超 LLaMA3 70B，AlignBench 逼近 GPT-4。

7V3 的伏笔：MLA + MoE 被 V3 原样继承；「辅助损失负载均衡」在 V3 升级为「无辅助损失」。

七、下一篇预告

V2 确立了 MLA + MoE 的底座。下一篇先花一小篇看 V2.5（2024-09）：V2 的「加固版」——在保持架构不变的前提下，扩充数据、优化训练策略，把中英文综合体验再拉一档（也是「小步快跑迭代」的典型）。随后第 5 篇就是重头戏 DeepSeek-V3（671B/37B 激活）：无辅助损失负载均衡、MTP、FP8、DualPipe 系统工程，以及惊世骇俗的「2.788M GPU 小时训练成本」。

参考资料

• [官方] DeepSeek-V2 论文（arXiv:2405.04434）：https://arxiv.org/abs/2405.04434

• [官方] GitHub 仓库（DeepSeek-V2）：https://github.com/deepseek-ai/DeepSeek-V2

• [参考] 智源社区论文页（中文摘要）：https://hub.baai.ac.cn/paper/61c65e8e-acb2-4f47-a678-a452c8e21f27

• [参考] 掘金《DeepSeek-V2 论文精读》（MHA/MQA/GQA 对比与基准）：https://aicoding.juejin.cn/post/7478232629919645747

• [参考] 火山引擎开发者社区《deepseek-v2 开源》（完整基准表/AlignBench）：https://developer.volcengine.com/articles/7390577415371620391

• [参考] 51CTO《DeepSeek-V2 详解：把 KV Cache 和 MoE 一起做成成本杠杆》：https://blog.51cto.com/u_16213696/14941005

• [参考] CSDN《DeepSeek-V2 论文解析》：https://blog.csdn.net/bqw18744018044/article/details/138751458

整理：2026-10-01 月绡凝 · 依据官方论文；个别三方文章数据以官方为准。