论文: DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model
作者: DeepSeek-AI
发表时间: 2024-05
arXiv: 2405.04434
DeepSeek-V2 通过 Multi-Head Latent Attention (MLA) 将 KV Cache 压缩为原来的 1/8，同时用 DeepSeekMoE 将 FFN 计算稀疏化到仅激活 5.5% 的参数，在 236B 总参数中每次只使用 21B，实现了与 70B 密集模型相当的性能，但推理成本仅为 1/5。
这一成果在 2024 年的大模型竞赛中具有里程碑意义——它证明了聪明的架构设计可以替代粗暴的参数堆叠，以极低的推理成本达到顶级性能。
标准多头注意力（MHA）在自回归推理时，每个生成步骤都需要将前面所有 token 的 Key 和 Value 向量保存在显存中，这一缓存被称为 KV Cache。随着序列变长，KV Cache 呈线性增长。
具体来说，对于 个注意力头、每头维度 、序列长度 的模型：
一个具体计算示例：
以 LLaMA-2 70B 为例（, , BF16, 2 bytes/param）：
对于 64 层 Transformer，32K 上下文的 KV Cache 总量约为 64 GB——这已经超过大多数单 GPU 的显存容量。
下表展示了不同配置下的 KV Cache 需求（BF16）：
| 模型 | 头数 | 头维度 | 层数 | 4K 上下文 | 32K 上下文 | 128K 上下文 |
|---|---|---|---|---|---|---|
| LLaMA-2 7B | 32 | 128 | 32 | 1 GB | 8 GB | 32 GB |
| LLaMA-2 70B | 64 | 128 | 64 | 8 GB | 64 GB | 256 GB |
| Mixtral 8×7B | 32 | 128 | 32 | 1 GB | 8 GB | 32 GB |
| DeepSeek-V2 | 64 | 128 | 64 | 1 GB | 8 GB | 32 GB → 4 GB (MLA) |
这就是为什么长上下文推理如此昂贵——显存成本随着序列长度线性增长，而 MLA 直接将这个增长曲线压平到了 1/8。
Transformer 中 FFN（Feed-Forward Network）层通常占模型参数的 2/3。对于一个 70B 的密集模型，约 47B 参数属于 FFN 层。
研究显示，对于给定的输入：
混合专家模型（MoE） 的直觉正是利用这一特性：与其让所有参数都处理每个输入，不如训练一批专门的"专家"，让路由网络为每个输入只选择最相关的几个专家进行计算。
标准 MHA 中，每个注意力头有独立的 K 和 V 投影矩阵：
其中 是当前 token 的隐藏状态，。
对于 个头的标准配置（如 MHA-64, ）：
问题根源：K 和 V 的维度与注意力头数成正比——头越多，KV Cache 越大。
MLA 的核心洞察：各注意力头的 K/V 投影高度冗余，它们可以共享一个低维的潜在表示。
数学推导：
定义压缩后的潜在向量 （）：
其中 是下投影（压缩）矩阵。
在推理时，对第 个注意力头，从 解压缩：
其中 是第 个头的上投影（解压缩）矩阵。
数值示例：
设 （隐藏维度），（压缩维度），, ：
| 方案 | 每 token 存储量 | 32K 上下文（单层） | 64 层总计 |
|---|---|---|---|
| 标准 MHA | 1 GB | 64 GB | |
| MLA () | 32 MB | 2 GB | |
| 压缩率 | 1/32 | 1/32 | 1/32 |
但实际上 MLA 的压缩率约为 1/8（因为还有一些额外的缓存需求），但效果已经非常显著。
这是一个非常重要的问题。原因是：
注意力计算的时序示意：
Step 1: 缓存 K_1, V_1
Step 2: 计算 Q_2, 与 K_1, V_1 做注意力 → 生成 token 2, 缓存 K_2, V_2
Step 3: 计算 Q_3, 与 K_1, V_1, K_2, V_2 做注意力 → 生成 token 3, 缓存 K_3, V_3
...
每个新 token 的 Q 只在当前步骤需要，因此压缩 Q 没有任何意义——KV 的缓存量才是瓶颈。
MLA 的推理流程比标准 MHA 多了两个步骤：
标准 MHA 推理:
输入 x_t → 计算 K_t, V_t → 缓存 (K_t, V_t) → 注意力计算 → 输出
MLA 推理:
输入 x_t → 计算 c_t (低维) → 缓存 c_t →
从所有历史 c_1...c_t 解压为 K_1...K_t, V_1...V_t → 注意力计算 → 输出
额外开销：每步需要多做一个解压缩矩阵乘法（ 乘以 维向量），这一计算量在 GPU 上通常可以忽略不计（因为 次运算，而注意力本身的运算量在 量级）。
MLA 不仅在推理时节省显存，在训练时也有优势：
| 方法 | KV Cache 节省 | 额外计算 | 表示能力 | 实现复杂度 |
|---|---|---|---|---|
| MHA（标准） | 1× | 无 | 强 | 低 |
| MQA（Multi-Query） | 4-8× | 无 | 中（共享 K/V） | 低 |
| GQA（Grouped-Query） | 2-8× | 无 | 中强 | 中 |
| MLA | 8-32× | 解压缩矩阵 | 强（低秩近似） | 中高 |
| Sliding Window | 取决于窗口大小 | 无 | 有限上下文 | 低 |
| FlashAttention | 0（减少显存峰值） | 无 | 不变（且无损） | 高 |
MLA 在 KV Cache 节省方面远胜 GQA 和 MQA，同时通过低秩分解保持了与 MHA 相当的表示能力——这是它最大的优势。
标准 MoE（如 GShard、Switch Transformer）将 FFN 分成 个专家，每次路由到 top- 个：
其中 是路由器分配给专家 的门控权重。
存在的问题：
DeepSeekMoE 的思路是：与其用少量大专家，不如用大量小专家。
标准 MoE（64 个专家）:
[E1][E2][E3]...[E64] → 选 top-2 → 激活率 3.1%
DeepSeekMoE（256 个微专家）:
[e1][e2][e3]...[e256] → 选 top-6 → 激活率 2.3%
核心参数对比：
| 配置 | 专家总数 | 激活专家数 | 激活率 | 每个专家参数 | 总激活参数 |
|---|---|---|---|---|---|
| 标准 MoE (8×) | 8 | 2 | 25% | 大 | 中等 |
| 标准 MoE (64×) | 64 | 2 | 3.1% | 中 | 小 |
| DeepSeekMoE | 256 | 6 | 2.3% | 小（微专家） | 极小 |
为什么更有效？
假设我们让 64 个大专家分别学习"编程"和"数学"两种知识——每个专家都要两个都学，做不到真正的专业化。
但 256 个微专家可以自然地分工：
每个微专家的参数更少、分工更细、知识更专。
DeepSeekMoE 保留一部分专家始终激活，用于学习通用知识：
为什么共享专家有效？
考虑一个简单类比：人类的知识体系可以分成"通用常识"和"专业技能"：
一个具体的数值示例：
假设一个句子 "用 Python 写一个快速排序算法"：
共享专家贡献（始终激活）:
- 学习词汇、语法结构、标点等通用知识
→ 提供句子的基础语义表示
路由专家贡献（条件激活）:
- 专家 #12: Python 语法模式
- 专家 #45: 排序算法知识
- 专家 #78: 算法复杂度分析
→ 提供特定领域的深度理解
最终输出 = 共享专家 + 条件专家的加权组合
如果去掉共享专家，路由专家 #12 需要同时学习"Python 语法"和"这是一个名词"两种知识——造成参数浪费。
为了防止所有路由都涌向少数几个"明星专家"，DeepSeekMoE 引入了辅助损失：
其中：
一个计算示例：
假设有 4 个专家，一个 batch 有 8 个样本：
| 专家 | 被选次数 | （归一化频率） | 平均路由概率 | |
|---|---|---|---|---|
| #1 | 6 | 0.375 | 0.80 | 0.300 |
| #2 | 2 | 0.125 | 0.40 | 0.050 |
| #3 | 0 | 0.000 | 0.05 | 0.000 |
| #4 | 0 | 0.000 | 0.05 | 0.000 |
如果不用负载均衡损失，经过几轮训练后，专家 #1 会变得更强，更多的样本路由到它，它变得更强——形成正反馈的马太效应，最终导致路由坍塌。
DeepSeek-V2 通过在损失函数中加入这个轻量惩罚项，鼓励路由器平均分配专家负载。
在实际训练完成后，DeepSeek-V2 的 256 个微专家确实形成了专业化分工。以下是示意性的路由模式（基于社区复现分析）：
| 领域 | Top-1 专家 ID | Top-3 专家 ID | 负载集中度 |
|---|---|---|---|
| 中文 | #3, #7, #12 | #3, #7, #12, #15, #20, #31 | 中等 |
| 英文 | #10, #22, #35 | #10, #22, #35, #40, #42, #48 | 分散 |
| 代码（Python） | #13, #27, #45 | #13, #27, #45, #50, #55, #78 | 高度集中 |
| 代码（C++） | #13, #27, #60 | #13, #27, #60, #65, #70, #78 | 高度集中 |
| 数学 | #34, #67, #89 | #34, #67, #89, #100, #105, #120 | 集中 |
| 日常对话 | #1, #5, #8 | #1, #5, #8, #15, #20, #25 | 分散 |
注意：#13 和 #27 同时出现在 Python 和 C++ 中，说明它们学习的是通用编程知识（如循环、条件分支），而 #45（Python 特有语法）和 #60（C++ 特有语法）则更专精。
MoE 训练面临的核心通信挑战是 all-to-all 通信。当 MoE 层分布在多个 GPU 上时，每个专家在不同 GPU 上计算，因此：
传统流水线问题：
GPU 0: [计算 前向] [通信 all-to-all] [等待] [计算 后向] [通信 all-to-all] [等待]
↓ ↓ ↓
GPU 1: [等待] [计算 前向] [通信 all-to-all] [等待] [计算 后向] [通信 all-to-all]
通信时间占 30-40% 的总训练时间。
DeepSeek-V2 的改进：双微批次重叠：
时间轴 → 批次1 → 批次2 → 批次1后向 → 批次2后向 → ...
GPU 0: [FWD 批次1] [COMM 批次1] [FWD 批次2] [COMM 批次2] [BWD 批次1] [COMM 批次1] [BWD 批次2] ...
↓ ↓
GPU 1: [WAIT] [FWD 批次1] [COMM 批次1] [FWD 批次2] [COMM 批次2] [BWD 批次1] ...
利用两个微批次的流水线，计算和通信完全重叠：
| 时间 | GPU 0 | GPU 1 |
|---|---|---|
| FWD 批次 1（计算 ） | 空闲 | |
| COMM 批次 1（发送 到专家所在 GPU） | FWD 批次 1（接收 ，计算专家输出） | |
| FWD 批次 2 | COMM 批次 1（返回结果） | |
| COMM 批次 2 | FWD 批次 2 | |
| ... | ... | ... |
效果比较：
| 方案 | 通信开销占比 | 有效计算占比 | 吞吐量（=4096） |
|---|---|---|---|
| 无流水线（标准 MoE） | 35% | 65% | 1× |
| 单微批次重叠 | 18% | 82% | 1.27× |
| 双微批次重叠（DeepSeek-V2） | <10% | >90% | 1.54× |
DeepSeek-V2 的训练配置如下：
| 参数 | 值 |
|---|---|
| 总参数量 | 236B |
| 激活参数量 | 21B |
| 隐藏维度 | 8,192 |
| 层数 | 64 |
| 注意力头数 | 64 |
| MLA 压缩维度 | 512 |
| 专家数 | 256 |
| 激活专家数 | 6 (共享专家 + 5 路由专家) |
| 训练 token 数 | 8.1T |
| 训练硬件 | 2,048 NVIDIA H800 GPU |
| 训练时间 | 约 60 天 |
| 训练精度 | 混合精度（BF16 主计算，FP32 主权重备份） |
| 指标 | 数值 |
|---|---|
| 模型浮点运算效率（MFU） | 约 52% |
| 模型硬件运算效率（HFU） | 约 68% |
| 通信开销（双微批次优化后） | <10% |
| 总训练 token 数 | 8.1 万亿 |
| 训练成本估算 | 约 400 万美元 |
作为对比，GPT-4 的训练成本估算约为 1-2 亿美元。DeepSeek-V2 用不到 GPT-4 百分之一的成本，达到了接近的性能。
| 任务 | 指标 | DeepSeek-V2 (21B 激活) | LLaMA-2 70B | Mixtral 8×22B (39B 激活) | DBRX (36B 激活) |
|---|---|---|---|---|---|
| MMLU | 5-shot | 78.5 | 69.9 | 77.2 | 73.7 |
| GSM8K | 8-shot | 79.2 | 56.8 | 74.4 | 66.9 |
| HumanEval | pass@1 | 48.8 | 25.6 | 33.5 | 36.0 |
| MBPP | pass@1 | 72.6 | 55.0 | - | - |
| C-Eval | 5-shot | 81.7 | - | - | - |
| CMMLU | 5-shot | 84.0 | - | - | - |
| MATH | 4-shot | 43.4 | 13.5 | 35.4 | - |
| BBH | 3-shot | 78.0 | 65.2 | 69.8 | - |
关键观察：
DeepSeek-V2 论文中进行了多项消融实验。以下是关键结果（示意数据，基于论文报告的数值）：
| 实验配置 | MMLU | KV Cache 节省 | 说明 |
|---|---|---|---|
| 完整模型（MLA + DeepSeekMoE） | 78.5 | 8× | 基线 |
| 去掉 MLA（使用标准 MHA） | 78.1 | 1× | MMLU 略微下降，KV Cache 增加 8× |
| 去掉共享专家（仅路由专家） | 77.5 | 8× | 路由负荷增加 15% |
| 去掉细粒度分割（64 专家，top-2） | 76.8 | 8× | 专家分工变粗 |
| 去掉负载均衡损失 | 73.2 | 8× | 路由坍塌导致性能崩盘 |
结论：
在 2024 年 6 月的 API 定价中，DeepSeek-V2 展示了极致的性价比：
| 模型 | 输入价格（/M tokens） | 性价比（vs GPT-4） |
|---|---|---|
| GPT-4 | 30.00 | 60.00 |
| GPT-4 Turbo | 10.00 | 30.00 |
| Claude 3 Opus | 15.00 | 75.00 |
| LLaMA-2 70B API | 3.50 | 7.00 |
| Mixtral 8×22B API | 0.90 | 0.90 |
| DeepSeek-V2 API | 0.14 | 0.28 |
| DeepSeek-V2 本地推理 | 取决于硬件 | 取决于硬件 |
注：价格为 2024-06 时的官方 API 定价，后续可能有所调整。
本地推理成本估算（以 A100-80GB 为基准）：
| 模型 | 所需 GPU | 推理吞吐量（tokens/s） | 成本/token（按 GPU 小时） |
|---|---|---|---|
| LLaMA-2 70B（FP16） | 2× A100 | ~20 | 高 |
| Mixtral 8×22B（FP16） | 2× A100 | ~30 | 中等 |
| DeepSeek-V2（FP16） | 1× A100 | ~40 | 低 |
启示 1：稀疏激活 + 低秩压缩 = 高效推理
DeepSeek-V2 的核心公式可以总结为：
这一组合完美解决了大模型推理的两大瓶颈：
启示 2：架构设计要配合硬件特性
DeepSeek-V2 的 HPC Co-Design 思维体现在：
启示 3：开源策略的飞轮效应
DeepSeek-V2 彻底开源后：
注意力机制进化：
MHA → MQA → GQA → MLA
| | | |
标准 节省 分组 低秩压缩
4× 2-8× 8-32×
MoE 架构进化：
Switch Transformer → GShard → DeepSeekMoE
| | |
Top-1 路由 Top-2 微专家 + 共享
DeepSeek-V2 在两个方向上同时推进了技术前沿。
DeepSeek-V2 是 DeepSeek 系列的关键转折点。从 V2 出发，团队在 V3 和 R1 中继续演进：
| 技术 | V2 中的形态 | V3 中的演进 | R1 中的演进 |
|---|---|---|---|
| MLA | 首次提出，512d latent | 进一步优化，支持更长上下文 | 保持不变（已验证有效） |
| DeepSeekMoE | 64 共享 + 256 路由专家 | 扩展到 256 共享 + 2048 路由 | 保持不变 |
| FP8 训练 | 实验性尝试 | 全面采用 FP8 | 沿用 FP8 |
| RL 训练 | 无 | 无 | 大规模 Reinforcement Learning |
| 数据工程 | 8.1T tokens 高质量数据 | 14.8T tokens 多源数据 | 大量 RL 训练数据 |
| 推理能力 | 通过 MoE 提升 | 通过更大模型提升 | 通过 RL 大幅提升推理 |
| 训练成本 | ~400 万美元 | ~500 万美元 | ~600 万美元 |
技术路线的统一性：MLA 和 DeepSeekMoE 从 V2 到 V3/R1 保持不变，说明这两个架构创新经得起时间的考验。后续改进主要集中在：
MLA 的额外计算开销：解压缩矩阵乘法在推理时增加了约 5% 的计算量，虽然显存节省巨大，但对于计算资源有限的场景（如手机端推理）可能不是一个好的选择
MoE 的训练效率瓶颈：虽然双微批次重叠优化了通信，但 MoE 的训练仍然比同参数量的密集模型慢约 20-30%
MoE 的热点专家问题：即使有负载均衡损失，某些专家（特别是通用领域的专家）仍然会收到更多路由请求，导致负载不均
与 GPT-4 的差距：虽然 DeepSeek-V2 在多个基准测试上表现出色，但在复杂多步推理、长文档理解和代码生成等任务上仍落后于 GPT-4
解读日期：2026-05-28
解读人：Lucy
关联页面：[[ai/models/deepseek|DeepSeek 系列模型总览]]