DeepSeek-V3 技术报告全文
本文译自 DeepSeek-AI 的技术报告 DeepSeek-V3 Technical Report1,2024 年 12 月 27 日提交于 arXiv,2025 年 2 月 18 日修订。这里是全文翻译,覆盖摘要、§1 引言、§2 架构、§3 基础设施、§4 预训练、§5 后训练、§6 结论、局限与未来方向,以及附录 B(低精度训练消融)和附录 C(expert 专业化模式)。附录 A 是作者名单与致谢,不在译文范围内。
摘要
我们发布 DeepSeek-V3,一个强大的 Mixture-of-Experts(MoE)语言模型,总参数 671B,每个 token 激活 37B。为了实现高效推理和经济的训练,DeepSeek-V3 采用 Multi-head Latent Attention(MLA)和 DeepSeekMoE 架构,这两者已经在 DeepSeek-V2 中得到充分验证。此外,DeepSeek-V3 首创了一种用于负载均衡的无辅助损失(auxiliary-loss-free)策略,并设置了 multi-token prediction 训练目标以获得更强的性能。我们在 14.8 万亿条多样、高质量的 token 上预训练 DeepSeek-V3,之后是 Supervised Fine-Tuning 和 Reinforcement Learning 两个阶段,充分释放它的能力。全面评测显示,DeepSeek-V3 超过其他开源模型,性能可与领先的闭源模型相比。尽管性能出色,DeepSeek-V3 的完整训练只需要 278.8 万 H800 GPU 小时。此外,它的训练过程异常稳定。在整个训练过程中,我们没有遭遇任何不可恢复的 loss spike,也没有做过任何回滚。模型 checkpoint 已公开发布2。
1 引言
近年来,大语言模型(LLM)经历了快速的迭代与演进345,与通用人工智能(AGI)的差距在逐步缩小。除了闭源模型,开源模型也在大步前进,包括 DeepSeek 系列6789、LLaMA 系列10111213、Qwen 系列141516 和 Mistral 系列1718,都在努力追赶闭源同行。为了进一步推动开源模型能力的边界,我们把模型规模扩大,推出 DeepSeek-V3——一个 671B 参数的大型 Mixture-of-Experts(MoE)模型,每个 token 激活 37B。
抱着前瞻的视角,我们始终同时追求强劲的模型性能和经济的成本。因此在架构上,DeepSeek-V3 仍然采用 Multi-head Latent Attention(MLA)7以实现高效推理,采用 DeepSeekMoE19以实现低成本训练。这两个架构已经在 DeepSeek-V27 中得到验证,证明了它们能在保持稳健模型性能的同时实现高效的训练与推理。在基本架构之外,我们又实现了两项策略来进一步增强模型能力。第一,DeepSeek-V3 首创了一种用于负载均衡的无辅助损失策略20,目的是把「为了鼓励负载均衡而付出的努力」对模型性能的不利影响降到最低。第二,DeepSeek-V3 采用了 multi-token prediction 训练目标,我们观察到它能提升在评测 benchmark 上的整体表现。
为了实现高效训练,我们支持 FP8 混合精度训练,并对训练框架做了全面优化。低精度训练已经成为高效训练的一条有希望的路线21222324,它的演进和硬件能力的进步紧密相关252627。在这项工作里,我们引入了一个 FP8 混合精度训练框架,并首次在超大规模模型上验证了它的有效性。通过对 FP8 计算与存储的支持,我们同时获得了训练加速和显存占用的下降。在训练框架方面,我们设计了 DualPipe 算法来实现高效的流水线并行,它的流水线气泡更少,并通过计算-通信重叠把训练中的大部分通信隐藏起来。这种重叠意味着,随着模型进一步扩大,只要我们保持计算与通信的比例不变,就仍然可以跨节点使用细粒度 expert,同时把 all-to-all 通信开销压到接近零。此外,我们还开发了高效的跨节点 all-to-all 通信 kernel,把 InfiniBand(IB)和 NVLink 的带宽用满。我们也对显存占用做了细致优化,使得训练 DeepSeek-V3 不必使用昂贵的张量并行。这些努力结合起来,我们实现了很高的训练效率。
预训练阶段,我们在 14.8T 高质量、多样的 token 上训练 DeepSeek-V3。预训练过程异常稳定。在整个训练过程中,我们没有遇到任何不可恢复的 loss spike,也不必回滚。接下来,我们对 DeepSeek-V3 做两阶段的上下文长度扩展:第一阶段把最大上下文长度扩到 32K,第二阶段进一步扩到 128K。之后,我们在 DeepSeek-V3 的基础模型上进行后训练,包括 Supervised Fine-Tuning(SFT)和 Reinforcement Learning(RL),使它与人类偏好对齐并进一步释放潜力。在后训练阶段,我们从 DeepSeek-R1 系列模型中蒸馏推理能力,同时小心地维持模型准确率与生成长度之间的平衡。
我们在一整套全面的 benchmark 上评测 DeepSeek-V3。尽管训练成本经济,全面评测显示 DeepSeek-V3-Base 已经成为当前最强的开源基础模型,在代码和数学上尤其突出。它的 chat 版本也超过其他开源模型,并在一系列标准与开放式 benchmark 上取得了可与领先闭源模型(包括 GPT-4o 和 Claude-3.5-Sonnet)相比的表现。
最后,我们再次强调 DeepSeek-V3 经济的训练成本,汇总在 Table 1 里,这是通过算法、框架、硬件的协同设计优化实现的。在预训练阶段,DeepSeek-V3 每训练一万亿 token 只需要 18 万 H800 GPU 小时,也就是在我们 2048 张 H800 的集群上 3.7 天。因此,我们的预训练阶段在不到两个月内完成,花费 266.4 万 GPU 小时。加上上下文长度扩展的 11.9 万 GPU 小时和后训练的 5 千 GPU 小时,DeepSeek-V3 的完整训练只花了 278.8 万 GPU 小时。假设 H800 GPU 的租用价格是每 GPU 小时 2 美元,我们的总训练成本仅为 557.6 万美元。注意上述成本只包含 DeepSeek-V3 的正式训练,不包含此前在架构、算法、数据上的研究和消融实验的花费。
Table 1:DeepSeek-V3 的训练成本,假设 H800 的租用价格为每 GPU 小时 2 美元。
| 训练成本 | 预训练 | 上下文扩展 | 后训练 | 合计 |
|---|---|---|---|---|
| 以 H800 GPU 小时计 | 2664K | 119K | 5K | 2788K |
| 以美元计 | $5.328M | $0.238M | $0.01M | $5.576M |
我们的主要贡献包括:
架构:创新的负载均衡策略与训练目标
- 在 DeepSeek-V2 高效架构的基础上,我们首创了一种用于负载均衡的无辅助损失策略,它把「鼓励负载均衡」所带来的性能下降降到最低。
- 我们研究了 Multi-Token Prediction(MTP)目标,并证明它对模型性能有益。它还可以用于 speculative decoding 来加速推理。
预训练:迈向极致的训练效率
- 我们设计了一个 FP8 混合精度训练框架,并首次在超大规模模型上验证了 FP8 训练的可行性与有效性。
- 通过算法、框架、硬件的协同设计,我们克服了跨节点 MoE 训练中的通信瓶颈,实现了近乎完全的计算-通信重叠。这显著提升了训练效率、降低了训练成本,使我们能在不增加额外开销的情况下进一步扩大模型规模。
- 以仅 266.4 万 H800 GPU 小时的经济代价,我们在 14.8T token 上完成了 DeepSeek-V3 的预训练,产出当前最强的开源基础模型。预训练之后的各个训练阶段只需要 10 万 GPU 小时。
后训练:从 DeepSeek-R1 蒸馏知识
- 我们提出了一套创新方法,把长链式思考(CoT)模型——具体来说是 DeepSeek-R1 系列中的某个模型——的推理能力蒸馏进标准 LLM,特别是 DeepSeek-V3。我们的流程巧妙地把 R1 的验证与反思模式融入 DeepSeek-V3,显著提升了它的推理表现。同时,我们也保持了对 DeepSeek-V3 输出风格与长度的控制。
核心评测结果小结
- 知识。(1)在 MMLU、MMLU-Pro、GPQA 这类教育类 benchmark 上,DeepSeek-V3 超过所有其他开源模型,在 MMLU 上取得 88.5、MMLU-Pro 上 75.9、GPQA 上 59.1。它的表现可与 GPT-4o、Claude-Sonnet-3.5 这类领先闭源模型相比,在这个领域缩小了开源与闭源模型的差距。(2)在事实性 benchmark 上,DeepSeek-V3 在 SimpleQA 和 Chinese SimpleQA 上都是开源模型中表现最好的。虽然它在英文事实知识(SimpleQA)上落后 GPT-4o 和 Claude-Sonnet-3.5,但在中文事实知识(Chinese SimpleQA)上超过了这些模型,凸显出它在中文事实知识上的强项。
- 代码、数学与推理。(1)在所有非长 CoT 的开源与闭源模型中,DeepSeek-V3 在数学相关 benchmark 上达到了 state-of-the-art。值得注意的是,它在 MATH-500 这类特定 benchmark 上甚至超过了 o1-preview,展示出稳健的数学推理能力。(2)在代码相关任务上,DeepSeek-V3 成为 LiveCodeBench 这类编程竞赛 benchmark 上表现最好的模型,坐稳了这一领域的领先位置。在工程相关任务上,虽然 DeepSeek-V3 略低于 Claude-Sonnet-3.5,但仍以显著优势领先所有其他模型,展示了它在各类技术 benchmark 上的竞争力。
本文余下部分的安排如下。我们首先详细阐述 DeepSeek-V3 的模型架构(§2)。接着介绍我们的基础设施,涵盖计算集群、训练框架、对 FP8 训练的支持、推理部署策略,以及我们对未来硬件设计的建议。然后描述预训练过程,包括训练数据的构造、超参设置、长上下文扩展技术、相应的评测,以及一些讨论(§4)。之后讨论我们在后训练上的工作,包括 Supervised Fine-Tuning(SFT)、Reinforcement Learning(RL)、相应评测与讨论(§5)。最后我们总结这项工作,讨论 DeepSeek-V3 现存的局限,并提出未来研究的可能方向(§6)。
2 架构
我们首先介绍 DeepSeek-V3 的基本架构,其特点是用 Multi-head Latent Attention(MLA)7实现高效推理、用 DeepSeekMoE19 实现经济的训练。然后介绍 Multi-Token Prediction(MTP)训练目标,我们观察到它能提升在评测 benchmark 上的整体表现。对于其他没有明确提到的细节,DeepSeek-V3 遵循 DeepSeek-V27 的设置。
2.1 基本架构
DeepSeek-V3 的基本架构仍然在 Transformer28 框架之内。为了高效推理和经济训练,DeepSeek-V3 同样采用 MLA 和 DeepSeekMoE,这两者已被 DeepSeek-V2 充分验证。与 DeepSeek-V2 相比,一个例外是我们额外为 DeepSeekMoE 引入了一种无辅助损失的负载均衡策略20,以缓解「为确保负载均衡而付出的努力」所诱发的性能下降。Figure 2 展示了 DeepSeek-V3 的基本架构,本节将简要回顾 MLA 和 DeepSeekMoE 的细节。
2.1.1 Multi-Head Latent Attention
在 attention 上,DeepSeek-V3 采用 MLA 架构。令 $d$ 表示 embedding 维度,$n_h$ 表示 attention head 数,$d_h$ 表示每个 head 的维度,$\mathbf{h}_{t} \in \mathbb{R}^{d}$ 表示给定 attention 层上第 $t$ 个 token 的 attention 输入。MLA 的核心是对 attention 的 key 和 value 做低秩联合压缩,以减少推理时的 Key-Value(KV)cache:
$$ \begin{aligned} \boxed{\color{blue} \mathbf{c}_{t}^{KV}} &= W^{DKV} \mathbf{h}_{t}, \\ [\mathbf{k}_{t, 1}^{C};\mathbf{k}_{t, 2}^{C};...;\mathbf{k}_{t, n_{h}}^{C}] = \mathbf{k}_{t}^{C} &= W^{UK} \mathbf{c}_{t}^{KV}, \\ \boxed{\color{blue}\mathbf{k}_{t}^{R}} &= \operatorname{RoPE}({W^{KR}} \mathbf{h}_{t}), \\ \mathbf{k}_{t, i} &= [\mathbf{k}_{t, i}^{C}; \mathbf{k}_{t}^{R}], \\ [\mathbf{v}_{t, 1}^{C};\mathbf{v}_{t, 2}^{C};...;\mathbf{v}_{t, n_{h}}^{C}] = \mathbf{v}_{t}^{C} &= W^{UV} \mathbf{c}_{t}^{KV}, \end{aligned} $$其中 $\mathbf{c}_{t}^{KV} \in \mathbb{R}^{d_c}$ 是 key 和 value 的压缩 latent 向量;$d_c (\ll d_h n_h)$ 表示 KV 压缩维度;$W^{DKV} \in \mathbb{R}^{d_c \times d}$ 表示下投影矩阵;$W^{UK},W^{UV} \in \mathbb{R}^{d_h n_h \times d_c}$ 分别是 key 和 value 的上投影矩阵;$W^{KR} \in \mathbb{R}^{d_h^R \times d}$ 是用来产生携带 Rotary Positional Embedding(RoPE)29的解耦 key 的矩阵;$\operatorname{RoPE}(\cdot)$ 表示施加 RoPE 矩阵的操作;$[\cdot;\cdot]$ 表示拼接。注意对 MLA 来说,生成时只需要缓存蓝框里的向量(即 $\color{blue} \mathbf{c}_{t}^{KV}$ 和 $\color{blue}\mathbf{k}_{t}^{R}$),这使 KV cache 显著减小,同时保持与标准 Multi-Head Attention(MHA)28相当的性能。
对于 attention 的 query,我们也做了低秩压缩,这可以减少训练时的激活显存:
$$ \begin{aligned} \mathbf{c}_{t}^{Q} &= W^{DQ} \mathbf{h}_{t}, \\ [\mathbf{q}_{t, 1}^{C};\mathbf{q}_{t, 2}^{C};...;\mathbf{q}_{t, n_{h}}^{C}] = \mathbf{q}_{t}^{C} &= W^{UQ} \mathbf{c}_{t}^{Q}, \\ [\mathbf{q}_{t, 1}^{R};\mathbf{q}_{t, 2}^{R};...;\mathbf{q}_{t, n_{h}}^{R}] = \mathbf{q}_{t}^{R} &= \operatorname{RoPE}({W^{QR}} \mathbf{c}_{t}^{Q}), \\ \mathbf{q}_{t, i} &= [\mathbf{q}_{t, i}^{C}; \mathbf{q}_{t, i}^{R}], \end{aligned} $$其中 $\mathbf{c}_{t}^{Q} \in \mathbb{R}^{d_c^{\prime}}$ 是 query 的压缩 latent 向量;$d_c^{\prime} (\ll d_h n_h)$ 表示 query 压缩维度;$W^{DQ} \in \mathbb{R}^{d_c^{\prime} \times d}, W^{UQ} \in \mathbb{R}^{d_h n_h \times d_c^{\prime}}$ 分别是 query 的下投影和上投影矩阵;$W^{QR} \in \mathbb{R}^{d_h^R n_h \times d_c^{\prime}}$ 是用来产生携带 RoPE 的解耦 query 的矩阵。
最终,attention 的 query($\mathbf{q}_{t, i}$)、key($\mathbf{k}_{j, i}$)和 value($\mathbf{v}_{j, i}^{C}$)组合起来得到最终的 attention 输出 $\mathbf{u}_{t}$:
$$ \begin{aligned} \mathbf{o}_{t, i} &= \sum_{j=1}^{t} \operatorname{Softmax}_j(\frac{\mathbf{q}_{t, i}^T \mathbf{k}_{j, i}}{\sqrt{d_{h} + d_{h}^{R}}}) \mathbf{v}_{j, i}^{C}, \\ \mathbf{u}_{t} &= W^{O} [\mathbf{o}_{t, 1};\mathbf{o}_{t, 2};...;\mathbf{o}_{t, n_{h}}], \end{aligned} $$其中 $W^{O} \in \mathbb{R}^{d \times d_h n_h}$ 表示输出投影矩阵。
2.1.2 DeepSeekMoE 与无辅助损失的负载均衡
DeepSeekMoE 的基本架构。对于前馈网络(FFN),DeepSeek-V3 采用 DeepSeekMoE 架构19。与 GShard30 这类传统 MoE 架构相比,DeepSeekMoE 使用更细粒度的 expert,并把一部分 expert 隔离出来作为 shared expert。令 $\mathbf{u}_{t}$ 表示第 $t$ 个 token 的 FFN 输入,我们按如下方式计算 FFN 输出 $\mathbf{h}_{t}^{\prime}$:
$$ \begin{aligned} \mathbf{h}_{t}^{\prime} & = \mathbf{u}_{t} + \sum_{i=1}^{N_{s}} {\operatorname{FFN}^{(s)}_{i}\left( \mathbf{u}_{t} \right)} + \sum_{i=1}^{N_r} {g_{i,t} \operatorname{FFN}^{(r)}_{i}\left( \mathbf{u}_{t} \right)}, \\ g_{i,t} & = \frac{g^{\prime}_{i,t}}{\sum_{j=1}^{N_r} g^{\prime}_{j,t}}, \\ g^{\prime}_{i,t} & = \begin{cases} s_{i,t}, & s_{i,t} \in \operatorname{Topk} (\{ s_{j, t} | 1 \leq j \leq N_r \}, K_{r}), \\ 0, & \text{otherwise}, \end{cases} \\ s_{i,t} & = \operatorname{Sigmoid} \left( {\mathbf{u}_{t}}^{T} \mathbf{e}_{i} \right), \end{aligned} $$其中 $N_{s}$ 和 $N_r$ 分别表示 shared expert 和 routed expert 的数量;$\operatorname{FFN}^{(s)}_{i}(\cdot)$ 和 $\operatorname{FFN}^{(r)}_{i}(\cdot)$ 分别表示第 $i$ 个 shared expert 和第 $i$ 个 routed expert;$K_{r}$ 表示被激活的 routed expert 数量;$g_{i,t}$ 是第 $i$ 个 expert 的门控值;$s_{i,t}$ 是 token 到 expert 的 affinity;$\mathbf{e}_{i}$ 是第 $i$ 个 routed expert 的质心向量;$\operatorname{Topk}(\cdot, K)$ 表示为第 $t$ 个 token 与所有 routed expert 计算出的 affinity 分数中最高的 $K$ 个所组成的集合。与 DeepSeek-V2 略有不同,DeepSeek-V3 用 sigmoid 函数计算 affinity 分数,并在所有被选中的 affinity 分数之间做归一化来产生门控值。
无辅助损失的负载均衡。对 MoE 模型来说,不均衡的 expert 负载会导致路由崩塌31,并在有 expert 并行的场景下降低计算效率。传统方案通常依赖辅助损失3230来避免负载不均衡。然而辅助损失太大会损害模型性能20。为了在负载均衡和模型性能之间取得更好的取舍,我们首创了一种无辅助损失的负载均衡策略20来确保负载均衡。具体来说,我们为每个 expert 引入一个偏置项 $b_i$,把它加到对应的 affinity 分数 $s_{i,t}$ 上来决定 top-K 路由:
$$ \begin{aligned} g^{\prime}_{i,t} & = \begin{cases} s_{i,t}, & s_{i,t} + b_i \in \operatorname{Topk} (\{ s_{j, t} + b_j | 1 \leq j \leq N_r \}, K_{r}), \\ 0, & \text{otherwise}. \end{cases} \end{aligned} $$注意这个偏置项只用于路由。要与 FFN 输出相乘的门控值,仍然由原始的 affinity 分数 $s_{i,t}$ 导出。训练过程中,我们持续监控每个训练 step 整个 batch 上的 expert 负载。在每个 step 结束时,如果某个 expert 过载,我们就把它对应的偏置项减小 $\gamma$;如果欠载,就增大 $\gamma$。其中 $\gamma$ 是一个超参数,称为偏置更新速度。通过这种动态调整,DeepSeek-V3 在训练中保持了均衡的 expert 负载,并且比那些用纯辅助损失来鼓励负载均衡的模型取得了更好的性能。
互补的 sequence-wise 辅助损失。虽然 DeepSeek-V3 主要依靠无辅助损失策略来实现负载均衡,为了防止任何单条序列内部出现极端不均衡,我们也采用一个互补的 sequence-wise 均衡损失:
$$ \begin{aligned} \mathcal{L}_{\mathrm{Bal}} & = \alpha \sum_{i=1}^{N_r}{f_i P_i}, \\ f_i = \frac{N_r}{K_r T} \sum_{t=1}^{T} \mathbb{1} & \left( s_{i,t} \in \operatorname{Topk} ( \{ s_{j, t} | 1 \leq j \leq N_r \}, K_{r} ) \right), \\ s^{\prime}_{i,t} & = \frac{s_{i,t}}{\sum_{j=1}^{N_r} s_{j,t}}, \\ P_i & = \frac{1}{T} \sum_{t=1}^{T}{s^{\prime}_{i,t}}, \end{aligned} $$其中均衡因子 $\alpha$ 是一个超参数,对 DeepSeek-V3 会赋一个极小的值;$\mathbb{1}(\cdot)$ 表示指示函数;$T$ 表示一条序列中的 token 数。sequence-wise 均衡损失鼓励每条序列上的 expert 负载趋于均衡。
节点受限路由。和 DeepSeek-V2 使用的设备受限路由类似,DeepSeek-V3 也使用一种受限的路由机制来限制训练时的通信成本。简单说,我们确保每个 token 最多被发往 $M$ 个节点,这些节点是按照分布在每个节点上的 expert 中最高 $\frac{K_r}{M}$ 个 affinity 分数之和来选出的。在这个约束下,我们的 MoE 训练框架几乎可以做到完全的计算-通信重叠。
不丢弃 token。由于负载均衡策略有效,DeepSeek-V3 在整个训练过程中都保持良好的负载均衡。因此 DeepSeek-V3 在训练时不丢弃任何 token。此外我们也实现了特定的部署策略来确保推理时的负载均衡,所以 DeepSeek-V3 在推理时也不丢弃 token。
2.2 Multi-Token Prediction
受 Gloeckle 等人33的启发,我们为 DeepSeek-V3 研究并设置了 Multi-Token Prediction(MTP)目标,它把每个位置上的预测范围扩展到多个未来 token。一方面,MTP 目标使训练信号更稠密,可能提升数据效率。另一方面,MTP 可能让模型提前规划其表示,以更好地预测未来 token。Figure 3 展示了我们的 MTP 实现。与 Gloeckle 等人33用独立的输出头并行预测 $D$ 个额外 token 不同,我们顺序地预测额外 token,并在每个预测深度上保持完整的因果链。本节介绍我们 MTP 实现的细节。
MTP 模块。具体来说,我们的 MTP 实现用 $D$ 个顺序的模块来预测 $D$ 个额外 token。第 $k$ 个 MTP 模块由一个共享的 embedding 层 $\operatorname{Emb}(\cdot)$、一个共享的输出头 $\operatorname{OutHead}(\cdot)$、一个 Transformer block $\operatorname{TRM}_k(\cdot)$ 和一个投影矩阵 $M_k \in \mathbb{R}^{d \times 2d}$ 组成。对第 $i$ 个输入 token $t_i$,在第 $k$ 个预测深度上,我们首先用线性投影把第 $i$ 个 token 在第 $(k-1)$ 深度的表示 $\mathbf{h}_i^{k-1} \in \mathbb{R}^{d}$ 与第 $(i+k)$ 个 token 的 embedding $Emb(t_{i+k}) \in \mathbb{R}^{d}$ 组合起来:
$$ \mathbf{h}_i^{\prime k} = M_k [\operatorname{RMSNorm}(\mathbf{h}_i^{k-1}) ; \operatorname{RMSNorm}(\operatorname{Emb}(t_{i+k}))], $$其中 $[\cdot ; \cdot]$ 表示拼接。特别地,当 $k=1$ 时,$\mathbf{h}_i^{k-1}$ 指的是主模型给出的表示。注意每个 MTP 模块的 embedding 层都与主模型共享。组合后的 $\mathbf{h}_i^{\prime k}$ 作为第 $k$ 深度 Transformer block 的输入,产生当前深度的输出表示 $\mathbf{h}_{i}^{k}$:
$$ \mathbf{h}_{1:T-k}^{k} = \operatorname{TRM}_k(\mathbf{h}_{1:T-k}^{\prime k}), $$其中 $T$ 表示输入序列长度,$_{i:j}$ 表示切片操作(左右边界都包含)。最后,以 $\mathbf{h}_{i}^{k}$ 为输入,共享的输出头将计算第 $k$ 个额外预测 token 的概率分布 $P_{i+1+k}^{k} \in \mathbb{R}^{V}$,其中 $V$ 是词表大小:
$$ P_{i+k+1}^{k} = \operatorname{OutHead}(\mathbf{h}_{i}^{k}). $$输出头 $\operatorname{OutHead}(\cdot)$ 把表示线性映射为 logits,随后施加 $\operatorname{Softmax}(\cdot)$ 函数来计算第 $k$ 个额外 token 的预测概率。同样,每个 MTP 模块的输出头也与主模型共享。我们保持预测因果链的原则与 EAGLE34 类似,但它的主要目标是 speculative decoding3536,而我们用 MTP 来改进训练。
MTP 训练目标。对每个预测深度,我们计算一个交叉熵损失 $\mathcal{L}_{\text{MTP}}^{k}$:
$$ \mathcal{L}_{\text{MTP}}^{k} = \operatorname{CrossEntropy}(P_{2 + k:T + 1}^{k}, t_{2 + k:T + 1}) = -\frac{1}{T} \sum_{i=2 + k}^{T + 1} \log P_i^k [t_i], $$其中 $T$ 表示输入序列长度,$t_i$ 表示第 $i$ 个位置上的真实 token,$P_i^k [t_i]$ 表示第 $k$ 个 MTP 模块给出的 $t_i$ 的对应预测概率。最后,我们对所有深度的 MTP 损失取平均,再乘以一个权重因子 $\lambda$,得到整体 MTP 损失 $\mathcal{L}_{\text{MTP}}$,它作为 DeepSeek-V3 的一个额外训练目标:
$$ \mathcal{L}_{\text{MTP}} = \frac{\lambda}{D} \sum_{k=1}^{D} \mathcal{L}_{\text{MTP}}^{k}. $$推理中的 MTP。我们的 MTP 策略主要目的是提升主模型的性能,所以推理时可以直接丢弃 MTP 模块,主模型能独立正常工作。此外,我们也可以把这些 MTP 模块重新用于 speculative decoding,进一步改善生成延迟。
3 基础设施
3.1 计算集群
DeepSeek-V3 在一个配备 2048 张 NVIDIA H800 GPU 的集群上训练。H800 集群中每个节点包含 8 张 GPU,节点内通过 NVLink 和 NVSwitch 连接。跨节点之间使用 InfiniBand(IB)互联来完成通信。
3.2 训练框架
DeepSeek-V3 的训练由 HAI-LLM 框架支持,这是我们工程师从零打造的一个高效、轻量的训练框架。总体上,DeepSeek-V3 采用 16 路 流水线并行(PP)37、跨 8 个节点的 64 路 expert 并行(EP)30,以及 ZeRO-1 数据并行(DP)38。
为了让 DeepSeek-V3 的训练高效,我们实施了细致的工程优化。第一,我们设计了 DualPipe 算法来实现高效的流水线并行。与已有的 PP 方法相比,DualPipe 的流水线气泡更少。更重要的是,它把前向与反向过程中的计算阶段和通信阶段重叠起来,从而解决了跨节点 expert 并行带来的沉重通信开销这一挑战。第二,我们开发了高效的跨节点 all-to-all 通信 kernel,把 IB 和 NVLink 的带宽用满,同时节省专用于通信的 Streaming Multiprocessor(SM)。第三,我们对训练中的显存占用做了细致优化,从而使我们能够在不使用昂贵的张量并行(TP)的情况下训练 DeepSeek-V3。
3.2.1 DualPipe 与计算-通信重叠
对 DeepSeek-V3 来说,跨节点 expert 并行引入的通信开销使计算与通信之比低到大约 1:1,很不划算。为了应对这个挑战,我们设计了一个创新的流水线并行算法,称为 DualPipe。它不仅通过有效重叠前向与反向的计算-通信阶段来加速模型训练,还减少了流水线气泡。
DualPipe 的核心想法是把一对独立的前向与反向 chunk 内部的计算和通信重叠起来。具体来说,我们把每个 chunk 分成四个组成部分:attention、all-to-all dispatch、MLP 和 all-to-all combine。特别地,对于反向 chunk,attention 和 MLP 都会进一步拆成两部分——backward for input 和 backward for weights,就像 ZeroBubble37 那样。此外我们还有一个 PP communication 组件。如 Figure 4 所示,对一对前向与反向 chunk,我们重排这些组件,并手动调节专用于通信与专用于计算的 GPU SM 比例。在这个重叠策略下,我们可以确保 all-to-all 和 PP 通信在执行过程中都被完全隐藏。有了这个高效的重叠策略,完整的 DualPipe 调度如 Figure 5 所示。它采用双向流水线调度,从流水线两端同时喂入 micro-batch,很大一部分通信因此可以被完全重叠。这种重叠也意味着,随着模型进一步扩大,只要我们保持计算与通信的比例不变,就仍然可以跨节点使用细粒度 expert,同时把 all-to-all 通信开销压到接近零。
此外,即便在通信负担不重的更一般场景下,DualPipe 仍然显示出效率优势。在 Table 2 中,我们汇总了不同 PP 方法的流水线气泡和显存占用。如表所示,与 ZB1P37 和 1F1B39 相比,DualPipe 显著减少了流水线气泡,而峰值激活显存只增加了 $\frac{1}{PP}$ 倍。虽然 DualPipe 需要保留两份模型参数,但由于训练时我们使用了很大的 EP size,这并没有显著增加显存消耗。与 Chimera40 相比,DualPipe 只要求流水线阶段数和 micro-batch 数都能被 2 整除,而不要求 micro-batch 数能被流水线阶段数整除。另外对 DualPipe 来说,气泡和激活显存都不会随 micro-batch 数增长而增加。
Table 2:不同流水线并行方法的流水线气泡与显存占用对比。$F$ 表示一个前向 chunk 的执行时间,$B$ 表示一个完整反向 chunk 的执行时间,$W$ 表示一个「对权重求反向」chunk 的执行时间,$F\&B$ 表示两个相互重叠的前向与反向 chunk 的执行时间。
| 方法 | 气泡 | 参数 | 激活 |
|---|---|---|---|
| 1F1B | $(PP-1)(F+B)$ | $1\times$ | $PP$ |
| ZB1P | $(PP-1)(F+B-2W)$ | $1\times$ | $PP$ |
| DualPipe(本文) | $(\frac{PP}{2}-1)(F\&B+B-3W)$ | $2\times$ | $PP+1$ |
3.2.2 跨节点 All-to-All 通信的高效实现
为了保证 DualPipe 有足够的计算性能,我们定制了高效的跨节点 all-to-all 通信 kernel(包括 dispatch 和 combine),以节省专用于通信的 SM 数量。这些 kernel 的实现与 MoE 门控算法、以及我们集群的网络拓扑协同设计。具体来说,在我们的集群里,跨节点的 GPU 通过 IB 全互联,节点内通信走 NVLink。NVLink 提供 160 GB/s 的带宽,大约是 IB(50 GB/s)的 3.2 倍。为了有效利用 IB 和 NVLink 不同的带宽,我们限制每个 token 最多被 dispatch 到 4 个节点,从而减少 IB 流量。对每个 token,当它的路由决策做出后,它会先通过 IB 传输到目标节点上具有相同节点内序号的 GPU。一旦到达目标节点,我们会努力保证它立刻通过 NVLink 转发到承载其目标 expert 的特定 GPU 上,不被后续到达的 token 阻塞。这样一来,经由 IB 和 NVLink 的通信被完全重叠,每个 token 可以高效地在每个节点上平均选中 3.2 个 expert,而不产生额外的 NVLink 开销。这意味着,虽然 DeepSeek-V3 实际只选 8 个 routed expert,它可以在保持相同通信成本的前提下把这个数字扩大到最多 13 个 expert(4 个节点 $\times$ 3.2 个 expert/节点)。总的来说,在这样的通信策略下,只用 20 个 SM 就足以把 IB 和 NVLink 的带宽用满。
具体实现上,我们采用 warp specialization 技术41,把 20 个 SM 划分成 10 个通信通道。dispatch 过程中,(1)IB 发送、(2)IB 到 NVLink 的转发、(3)NVLink 接收分别由各自的 warp 负责。分配给每个通信任务的 warp 数量会根据所有 SM 上的实际负载动态调整。类似地,combine 过程中,(1)NVLink 发送、(2)NVLink 到 IB 的转发与累加、(3)IB 接收与累加也由动态调整的 warp 处理。此外,dispatch 和 combine 两个 kernel 都与计算流重叠,所以我们也要考虑它们对其他 SM 上计算 kernel 的影响。具体来说,我们采用定制的 PTX(Parallel Thread Execution)指令并自动调优通信 chunk 大小,这显著减少了 L2 cache 的使用和对其他 SM 的干扰。
3.2.3 用极小开销极致省显存
为了减少训练时的显存占用,我们采用以下技术。
重算 RMSNorm 与 MLA 上投影。我们在反向传播时重算所有 RMSNorm 操作和 MLA 上投影,从而无需持久保存它们的输出激活。以很小的开销,这个策略显著降低了存储激活所需的显存。
指数移动平均放在 CPU。训练过程中,我们保留模型参数的指数移动平均(EMA),用于在学习率衰减后提前估计模型性能。EMA 参数存放在 CPU 内存中,每个训练 step 之后异步更新。这个做法让我们在不引入额外显存或时间开销的情况下维护 EMA 参数。
Multi-Token Prediction 的 embedding 与输出头共享。借助 DualPipe 策略,我们把模型最浅的几层(包括 embedding 层)和最深的几层(包括输出头)部署在同一个 PP rank 上。这个安排使 MTP 模块与主模型之间能够物理共享共用 embedding 和输出头的参数与梯度。这种物理共享机制进一步提升了我们的显存效率。
3.3 FP8 训练
受近期低精度训练进展232442的启发,我们提出一个细粒度的 混合精度框架,用 FP8 数据格式来训练 DeepSeek-V3。虽然低精度训练前景可观,它常常受制于激活、权重和梯度中的离群值434445。尽管推理量化方面已有显著进展4647,但在大规模语言模型预训练中成功应用低精度技术的研究相对很少45。为了应对这个挑战、有效扩展 FP8 格式的动态范围,我们引入一种细粒度量化策略:按 $1\times N_c$ 个元素做 tile-wise 分组,或按 $N_c\times N_c$ 个元素做 block-wise 分组。在我们提高了精度的累加过程下,相应的反量化开销基本被消除——这一点对实现准确的 FP8 通用矩阵乘(GEMM)至关重要。此外,为了进一步减少 MoE 训练中的显存和通信开销,我们以 FP8 缓存并 dispatch 激活,同时以 BF16 存储低精度的优化器状态。我们在两个规模上验证了所提出的 FP8 混合精度框架,规模分别与 DeepSeek-V2-Lite 和 DeepSeek-V2 相近,训练约 1 万亿 token(更多细节见附录 B.1)。值得注意的是,与 BF16 baseline 相比,我们 FP8 训练模型的相对 loss 误差始终低于 0.25%,这个水平完全在训练随机性的可接受范围内。
3.3.1 混合精度框架
在低精度训练已被广泛采用的技术2122之上,我们提出一个 FP8 训练的混合精度框架。在这个框架里,大多数计算密集的操作以 FP8 进行,而少数关键操作则策略性地保留其原有数据格式,以平衡训练效率和数值稳定性。整体框架如 Figure 6 所示。
首先,为了加速模型训练,绝大部分核心计算 kernel——也就是 GEMM 操作——以 FP8 精度实现。这些 GEMM 操作接受 FP8 张量作为输入,产生 BF16 或 FP32 的输出。如 Figure 6 所示,与 Linear 算子相关的三个 GEMM,即 Fprop(前向)、Dgrad(激活反向)和 Wgrad(权重反向),都以 FP8 执行。这个设计在理论上把计算速度提高到原 BF16 方法的两倍。此外,FP8 的 Wgrad GEMM 使得激活可以以 FP8 存储供反向传播使用,这显著减少了显存消耗。
尽管 FP8 格式有效率优势,某些算子由于对低精度计算敏感,仍然需要更高精度。此外,一些低成本的算子也可以用更高精度,而对整体训练成本的开销微乎其微。因此,经过仔细研究,我们对以下组件保留原有精度(如 BF16 或 FP32):embedding 模块、输出头、MoE 门控模块、归一化算子和 attention 算子。这些有针对性地保留高精度的做法确保了 DeepSeek-V3 训练动态的稳定。为了进一步保证数值稳定性,我们以更高精度存储 master weight、权重梯度和优化器状态。虽然这些高精度组件带来一些显存开销,但在我们的分布式训练系统中,通过在多个 DP rank 之间高效切分,它们的影响可以被降到最小。
3.3.2 量化与乘法带来的精度改进
基于我们的 FP8 混合精度框架,我们引入若干策略来提升低精度训练的准确率,聚焦于量化方法和乘法过程两方面。
细粒度量化。在低精度训练框架中,由于 FP8 格式受其减少的指数位所限、动态范围有限,上溢和下溢是常见的挑战。作为一种标准做法,输入分布会通过把输入张量的最大绝对值缩放到 FP8 的最大可表示值来对齐到 FP8 的可表示范围22。这种方法使低精度训练对激活离群值高度敏感,可能严重降低量化准确率。为了解决这个问题,我们提出一种在更细粒度上施加缩放的细粒度量化方法。如 Figure 7(a)所示,(1)对激活,我们按 1x128 的 tile 为单位分组并缩放(即每个 token 的每 128 个通道);(2)对权重,我们按 128x128 的 block 为单位分组并缩放(即每 128 个输入通道、每 128 个输出通道)。这个做法让量化过程能够按更小的元素组来自适应缩放,从而更好地容纳离群值。在附录 B.2 中,我们进一步讨论了当我们像量化权重那样按 block 为单位分组缩放激活时出现的训练不稳定。
我们方法中的一个关键改动,是在 GEMM 操作的内维度上引入 per-group 的 scaling factor。这个功能在标准 FP8 GEMM 中没有直接支持。不过,结合我们精确的 FP32 累加策略,它可以被高效实现。
值得注意的是,我们的细粒度量化策略与 microscaling 格式27的思路高度一致,而 NVIDIA 下一代 GPU(Blackwell 系列)的 Tensor Core 已经宣布支持量化粒度更小的 microscaling 格式48。我们希望我们的设计能为未来工作跟进最新 GPU 架构提供参考。
提高累加精度。低精度 GEMM 操作常常受下溢问题困扰,其准确率很大程度上依赖高精度累加,通常以 FP32 精度进行2122。然而我们观察到,NVIDIA H800 GPU 上 FP8 GEMM 的累加精度只能保留大约 14 位,显著低于 FP32 的累加精度。当内维度 K 很大时这个问题会更突出49,而这正是大规模模型训练中 batch size 和模型宽度都增大时的典型情形。以两个 K = 4096 的随机矩阵的 GEMM 操作为例,在我们的初步测试中,Tensor Core 有限的累加精度导致了接近 2% 的最大相对误差。尽管存在这些问题,有限的累加精度在一些 FP8 框架中仍然是默认选项50,严重制约了训练准确率。
为了解决这个问题,我们采用提升到 CUDA Core 以获得更高精度的策略51。这个过程如 Figure 7(b)所示。具体来说,在 Tensor Core 上执行 MMA(Matrix Multiply-Accumulate)时,中间结果以有限的位宽累加。一旦达到 $N_C$ 的间隔,这些部分结果就会被拷贝到 CUDA Core 上的 FP32 寄存器,在那里执行全精度的 FP32 累加。如前所述,我们的细粒度量化在内维度 K 上施加 per-group 的 scaling factor。这些 scaling factor 可以在 CUDA Core 上高效相乘,作为反量化过程,额外的计算成本极小。
值得指出的是,这个改动会降低单个 warpgroup 的 WGMMA(Warpgroup-level Matrix Multiply-Accumulate)指令发射率。不过在 H800 架构上,通常会有两个 WGMMA 并存:当一个 warpgroup 执行提升操作时,另一个可以执行 MMA 操作。这个设计使两种操作得以重叠,维持了 Tensor Core 的高利用率。根据我们的实验,把 $N_C$ 设为 128 个元素,相当于 4 个 WGMMA,是能显著改善精度又不引入明显额外开销的最小累加间隔。
优先保留尾数而非指数。与先前工作502352采用的混合 FP8 格式不同——它们在 Fprop 用 E4M3(4 位指数、3 位尾数),在 Dgrad 和 Wgrad 用 E5M2(5 位指数、2 位尾数)——我们在所有张量上都采用 E4M3 格式以获得更高精度。我们认为这个做法之所以可行,归功于我们的细粒度量化策略,也就是 tile-wise 和 block-wise 缩放。通过在更小的元素组上操作,我们的方法有效地在这些被分组的元素之间共享了指数位,缓解了动态范围有限的影响。
在线量化。tensor-wise 量化框架采用延迟量化5023,它维护此前若干次迭代的最大绝对值历史来推断当前值。为了确保 scale 准确并简化框架,我们对每个 1x128 激活 tile 或 128x128 权重 block 在线计算最大绝对值。基于它导出 scaling factor,然后在线把激活或权重量化成 FP8 格式。
3.3.3 低精度的存储与通信
配合我们的 FP8 训练框架,我们把缓存的激活和优化器状态压缩到更低精度的格式,进一步降低显存消耗和通信开销。
低精度优化器状态。我们采用 BF16 数据格式而不是 FP32 来跟踪 AdamW53 优化器中的一阶和二阶矩,这并未带来可观察到的性能退化。不过,master weight(由优化器保存)和梯度(用于 batch size 累积)仍然保留 FP32,以确保训练全程的数值稳定性。
低精度激活。如 Figure 6 所示,Wgrad 操作以 FP8 执行。为了减少显存消耗,把激活以 FP8 格式缓存下来供 Linear 算子的反向传播使用是一个自然的选择。不过,为了实现低成本的高精度训练,我们对几个算子作了特殊考虑:
- attention 算子之后
Linear的输入。这些激活也用于 attention 算子的反向传播,这使它对精度敏感。我们专门为这些激活采用定制的E5M6数据格式。此外,这些激活在反向传播中会从1x128的量化 tile 转换成128x1的 tile。为了避免引入额外的量化误差,所有 scaling factor 都做取整缩放,即取 2 的整数次幂。 - MoE 中 SwiGLU 算子的输入。为了进一步降低显存成本,我们缓存 SwiGLU 算子的输入,在反向传播时重算其输出。这些激活同样用我们的细粒度量化方法以 FP8 存储,在显存效率和计算准确率之间取得平衡。
低精度通信。通信带宽是 MoE 模型训练中的一个关键瓶颈。为了缓解这个挑战,我们在 MoE 上投影之前把激活量化成 FP8,然后施加 dispatch 组件,这与 MoE 上投影中的 FP8 Fprop 是兼容的。与 attention 算子之后 Linear 的输入一样,这个激活的 scaling factor 也取 2 的整数次幂。对 MoE 下投影之前的激活梯度采用类似策略。对前向和反向的 combine 组件,我们都保留 BF16,以在训练流程的关键部分保住训练精度。
3.4 推理与部署
我们把 DeepSeek-V3 部署在 H800 集群上,每个节点内的 GPU 通过 NVLink 互联,集群中所有 GPU 通过 IB 全互联。为了同时保证在线服务的服务等级目标(SLO)和高吞吐,我们采用以下把 prefilling 阶段和 decoding 阶段 分离的部署策略。
3.4.1 Prefilling
prefilling 阶段的最小部署单元由 4 个节点、32 张 GPU 组成。attention 部分采用 4 路张量并行(TP4)配合序列并行(SP),并结合 8 路数据并行(DP8)。它较小的 TP size 为 4,限制了 TP 通信的开销。对 MoE 部分,我们使用 32 路 expert 并行(EP32),这确保每个 expert 处理足够大的 batch size,从而提升计算效率。对 MoE 的 all-to-all 通信,我们采用与训练相同的方法:先经 IB 跨节点传输 token,再经 NVLink 在节点内 GPU 之间转发。特别地,我们对浅层的 dense MLP 使用 1 路张量并行,以节省 TP 通信。
为了在 MoE 部分的不同 expert 之间实现负载均衡,我们需要确保每张 GPU 处理大致相同数量的 token。为此我们引入一种 冗余 expert 的部署策略,它复制高负载的 expert 并冗余部署。高负载的 expert 根据在线部署期间采集的统计数据检测出来,并周期性调整(比如每 10 分钟)。确定冗余 expert 集合之后,我们根据观察到的负载在节点内的 GPU 之间小心地重新排布 expert,尽可能均衡 GPU 之间的负载,同时不增加跨节点 all-to-all 通信开销。对 DeepSeek-V3 的部署,我们在 prefilling 阶段设置 32 个冗余 expert。对每张 GPU,除了它原本承载的 8 个 expert 之外,还会额外承载一个冗余 expert。
此外,在 prefilling 阶段,为了提升吞吐、隐藏 all-to-all 和 TP 通信的开销,我们同时处理两个计算负载相近的 micro-batch,把一个 micro-batch 的 attention 和 MoE 与另一个的 dispatch 和 combine 重叠起来。
最后,我们正在探索一种 动态冗余 策略:每张 GPU 承载更多 expert(比如 16 个),但每次推理 step 只激活其中 9 个。在每一层的 all-to-all 操作开始之前,我们即时计算全局最优的路由方案。鉴于 prefilling 阶段涉及的计算量很大,计算这个路由方案的开销几乎可以忽略。
3.4.2 Decoding
decoding 时,我们把 shared expert 当作一个 routed expert 来处理。从这个视角看,每个 token 在路由时会选择 9 个 expert,其中 shared expert 被视为一个总是会被选中的高负载 expert。decoding 阶段的最小部署单元由 40 个节点、320 张 GPU 组成。attention 部分采用 TP4 配合 SP,并结合 DP80,而 MoE 部分使用 EP320。对 MoE 部分,每张 GPU 只承载一个 expert,另有 64 张 GPU 负责承载冗余 expert 和 shared expert。dispatch 和 combine 部分的 all-to-all 通信通过 IB 上的直接点对点传输完成,以获得低延迟。此外,我们利用 IBGDA54 技术进一步降低延迟、提升通信效率。
与 prefilling 类似,我们基于线上服务的 expert 负载统计,按一定间隔周期性地确定冗余 expert 集合。不过我们不需要重新排布 expert,因为每张 GPU 只承载一个 expert。我们也在探索 decoding 的 动态冗余 策略。不过这需要对计算全局最优路由方案的算法做更细致的优化,并与 dispatch kernel 融合以降低开销。
此外,为了提升吞吐、隐藏 all-to-all 通信的开销,我们也在探索在 decoding 阶段同时处理两个计算负载相近的 micro-batch。与 prefilling 不同,attention 在 decoding 阶段占用的时间比例更大。因此我们把一个 micro-batch 的 attention 与另一个的 dispatch+MoE+combine 重叠。在 decoding 阶段,每个 expert 的 batch size 相对较小(通常在 256 个 token 以内),瓶颈是访存而不是计算。由于 MoE 部分只需要加载一个 expert 的参数,访存开销很小,所以用更少的 SM 不会显著影响整体性能。因此,为了避免影响 attention 部分的计算速度,我们可以只给 dispatch+MoE+combine 分配一小部分 SM。
3.5 对硬件设计的建议
基于我们在 all-to-all 通信和 FP8 训练方案上的实现,我们向 AI 硬件厂商提出以下芯片设计建议。
3.5.1 通信硬件
在 DeepSeek-V3 中,我们实现了计算与通信的重叠,把通信延迟隐藏在计算之下。相比串行的计算与通信,这显著降低了对通信带宽的依赖。然而,当前的通信实现依赖昂贵的 SM(比如我们把 H800 GPU 上 132 个可用 SM 中的 20 个用于此目的),这会限制计算吞吐。而且,用 SM 做通信会造成显著的低效,因为 tensor core 完全没被利用。
目前,SM 主要为 all-to-all 通信执行以下任务:
- 转发数据,在 IB(InfiniBand)与 NVLink 域之间转发,同时把从单张 GPU 出发、目标为同一节点内多张 GPU 的 IB 流量聚合起来。
- 搬运数据,在 RDMA buffer(已注册的 GPU 显存区域)与输入/输出 buffer 之间搬运。
- 执行
reduce操作,用于all-to-all的combine。 - 管理细粒度的显存布局,在跨 IB 与 NVLink 域向多个 expert 分块传输数据时管理。
我们期待未来的厂商开发出把这些通信任务从宝贵的计算单元 SM 上卸载下来的硬件,充当 GPU 协处理器或网络协处理器,类似 NVIDIA SHARP55。此外,为了降低应用编程的复杂度,我们希望这类硬件能从计算单元的视角统一 IB(scale-out)和 NVLink(scale-up)两张网络。有了这个统一接口,计算单元就可以基于简单的原语提交通信请求,从而轻松在整个 IB-NVLink 统一域上完成 read、write、multicast、reduce 这类操作。
3.5.2 计算硬件
Tensor Core 中更高的 FP8 GEMM 累加精度。在当前 NVIDIA Hopper 架构的 Tensor Core 实现中,FP8 GEMM 的累加精度受限。在按最大指数右移对齐 32 个尾数乘积之后,Tensor Core 只用每个尾数乘积的最高 14 位做加法,超出这个范围的位被截断。加法结果累加进寄存器时也采用 14 位精度。我们的实现部分缓解了这个限制:把 128 次 FP8$\times$FP8 乘法的加法结果以 FP32 精度累加到 CUDA core 的寄存器中。尽管这有助于成功实现 FP8 训练,它仅仅是针对 Hopper 架构在 FP8 GEMM 累加精度上的硬件缺陷所做的一种妥协。未来的芯片需要采用更高的精度。
支持 tile-wise 与 block-wise 量化。当前 GPU 只支持 per-tensor 量化,缺乏对我们这种 tile-wise 和 block-wise 细粒度量化的原生支持。在现有实现中,当达到 $N_C$ 间隔时,部分结果会从 Tensor Core 拷贝到 CUDA core,乘上 scaling factor,再加到 CUDA core 上的 FP32 寄存器里。虽然结合我们精确的 FP32 累加策略,反量化开销已被显著缓解,但 Tensor Core 与 CUDA core 之间频繁的数据搬运仍然限制了计算效率。因此我们建议未来的芯片支持细粒度量化:让 Tensor Core 能够接收 scaling factor,并实现带 group scaling 的 MMA。这样,整个部分和累加与反量化都可以直接在 Tensor Core 内部完成,直到产出最终结果,从而避免频繁的数据搬运。
支持在线量化。当前的实现难以有效支持在线量化,尽管我们的研究已证明它的有效性。在现有流程中,我们需要从 HBM(High Bandwidth Memory)读出 128 个 BF16 激活值(上一步计算的输出)来量化,量化后的 FP8 值再写回 HBM,之后又要为 MMA 再读一次。为了解决这种低效,我们建议未来的芯片把 FP8 cast 和 TMA(Tensor Memory Accelerator)访问集成为一个融合操作,这样量化就可以在激活从 global memory 搬到 shared memory 的过程中完成,避免频繁的显存读写。我们还建议支持 warp 级的 cast 指令以加速,这进一步方便了 layer normalization 与 FP8 cast 的更好融合。另一种做法是采用近存计算,把计算逻辑放在 HBM 附近。这样,BF16 元素在从 HBM 读入 GPU 时就可以直接 cast 成 FP8,把片外访存减少大约 50%。
支持转置的 GEMM 操作。当前架构使矩阵转置与 GEMM 操作的融合相当麻烦。在我们的工作流里,前向传播时的激活被量化成 1x128 的 FP8 tile 并存储。反向传播时,这个矩阵需要被读出、反量化、转置、重新量化成 128x1 的 tile,再存回 HBM。为了减少显存操作,我们建议未来的芯片支持在 MMA 操作之前直接从 shared memory 转置读取矩阵,对训练和推理都需要的那些精度都提供支持。结合 FP8 格式转换与 TMA 访问的融合,这项改进将显著简化量化流程。
4 预训练
4.1 数据构造
与 DeepSeek-V2 相比,我们优化了预训练语料,提高数学和编程样本的比例,并把多语覆盖扩展到英文和中文之外。同时,我们改进了数据处理流程,在保持语料多样性的同时把冗余降到最低。受 Ding 等人56启发,我们采用文档打包方法来保持数据完整性,但训练时不引入跨样本的 attention masking。最终,DeepSeek-V3 的训练语料在我们的 tokenizer 下由 14.8T 条高质量、多样的 token 构成。
在 DeepSeekCoder-V29 的训练过程中,我们观察到 Fill-in-Middle(FIM)策略不会损害 next-token prediction 的能力,同时能让模型基于上下文线索准确预测中间文本。与 DeepSeekCoder-V2 保持一致,我们在 DeepSeek-V3 的预训练中也采用 FIM 策略。具体来说,我们用 Prefix-Suffix-Middle(PSM)框架把数据组织成如下形式:
<|fim_begin|> f_pre <|fim_hole|> f_suf <|fim_end|> f_middle <|eos_token|>
这个结构在文档级别施加,作为预打包过程的一部分。FIM 策略以 0.1 的比例应用,与 PSM 框架一致。
DeepSeek-V3 的 tokenizer 采用 Byte-level BPE57,词表扩展到 128K 个 token。我们修改了 tokenizer 的预分词器和训练数据,以优化多语压缩效率。此外,与 DeepSeek-V2 相比,新的预分词器引入了把标点与换行组合起来的 token。然而,当模型处理末尾没有换行的多行 prompt 时,这个技巧可能引入 token 边界偏置58,在 few-shot 评测 prompt 上尤其明显。为了解决这个问题,我们在训练中随机拆开一定比例的这类组合 token,让模型见到更广泛的特殊情形,从而缓解这一偏置。
4.2 超参
模型超参。我们把 Transformer 层数设为 61,隐层维度设为 7168。所有可学习参数以 0.006 的标准差随机初始化。在 MLA 中,我们把 attention head 数 $n_h$ 设为 128,每个 head 的维度 $d_h$ 设为 128。KV 压缩维度 $d_c$ 设为 512,query 压缩维度 $d_c^{\prime}$ 设为 1536。对解耦的 query 和 key,我们把每个 head 的维度 $d_h^R$ 设为 64。除前三层之外,我们把所有 FFN 都替换成 MoE 层。每个 MoE 层由 1 个 shared expert 和 256 个 routed expert 组成,每个 expert 的中间隐层维度是 2048。在 routed expert 中,每个 token 会激活 8 个,并确保每个 token 最多被发往 4 个节点。multi-token prediction 深度 $D$ 设为 1,也就是说除了正好的下一个 token,每个 token 还会额外预测一个 token。与 DeepSeek-V2 一样,DeepSeek-V3 也在压缩 latent 向量之后加入额外的 RMSNorm 层,并在宽度瓶颈处乘上额外的 scaling factor。在这个配置下,DeepSeek-V3 共有 671B 参数,每个 token 激活 37B。
训练超参。我们采用 AdamW 优化器53,超参设为 $\beta_1=0.9$、$\beta_2=0.95$、$\mathrm{weight\_decay}=0.1$。预训练时最大序列长度设为 4K,在 14.8T token 上预训练 DeepSeek-V3。学习率调度方面,我们先在前 2K 步把学习率从 0 线性升到 $2.2 \times 10^{-4}$,然后保持 $2.2 \times 10^{-4}$ 恒定,直到模型消耗 10T 训练 token。之后按余弦衰减曲线,在 4.3T token 内把学习率逐步衰减到 $2.2 \times 10^{-5}$。在最后 500B token 的训练中,前 333B token 保持 $2.2 \times 10^{-5}$ 恒定,剩下 167B token 切换到另一个恒定值 $7.3 \times 10^{-6}$。梯度裁剪范数设为 1.0。我们采用 batch size 调度策略:在前 469B token 的训练中把 batch size 从 3072 逐步增加到 15360,之后的训练保持 15360。我们利用流水线并行把模型的不同层部署到不同 GPU 上,对每一层,routed expert 会均匀部署在属于 8 个节点的 64 张 GPU 上。节点受限路由方面,每个 token 最多被发往 4 个节点(即 $M=4$)。无辅助损失负载均衡方面,前 14.3T token 把偏置更新速度 $\gamma$ 设为 0.001,剩下 500B token 设为 0.0。均衡损失的 $\alpha$ 设为 0.0001,仅用于避免任何单条序列内部出现极端不均衡。MTP 损失权重 $\lambda$ 在前 10T token 设为 0.3,剩下 4.8T token 设为 0.1。
4.3 长上下文扩展
我们采用与 DeepSeek-V27 类似的做法,让 DeepSeek-V3 获得 长上下文能力。预训练阶段之后,我们施加 YaRN59 做上下文扩展,并执行两个额外的训练阶段,每个阶段 1000 步,逐步把上下文窗口从 4K 扩到 32K,再扩到 128K。YaRN 的配置与 DeepSeek-V2 使用的一致,只施加在解耦的 shared key $\mathbf{k}^R_t$ 上。两个阶段的超参完全相同:scale $s = 40$、$\alpha = 1$、$\beta = 32$,scaling factor $\sqrt{t} = 0.1 \ln{s} + 1$。第一阶段序列长度设为 32K,batch size 为 1920。第二阶段序列长度增加到 128K,batch size 减少到 480。两个阶段的学习率都设为 $7.3 \times 10^{-6}$,与预训练阶段的最终学习率一致。
通过这个两阶段的扩展训练,DeepSeek-V3 能够处理最长 128K 的输入,同时保持强劲性能。Figure 8 显示,经过 supervised fine-tuning 之后的 DeepSeek-V3 在「Needle In A Haystack」(NIAH)测试上取得了显著成绩,在直到 128K 的各个上下文窗口长度上都表现出一致的稳健性。
4.4 评测
4.4.1 评测 benchmark
DeepSeek-V3 的基础模型在一个以英文和中文为主的多语语料上预训练,因此我们在一系列主要为英文和中文的 benchmark 上、以及一个多语 benchmark 上评测它的性能。我们的评测基于集成在 HAI-LLM 框架中的内部评测框架。考察的 benchmark 分类列举如下,其中标注(中)的是中文 benchmark,标注(多)的是多语 benchmark:
多学科选择题数据集包括 MMLU60、MMLU-Redux61、MMLU-Pro62、MMMLU(多)63、C-Eval(中)64 和 CMMLU(中)65。
语言理解与推理数据集包括 HellaSwag66、PIQA67、ARC68 和 BigBench Hard(BBH)69。
闭卷问答数据集包括 TriviaQA70 和 NaturalQuestions71。
阅读理解数据集包括 RACE72、DROP73、C3(中)74 和 CMRC(中)75。
指代消歧数据集包括 CLUEWSC(中)76 和 WinoGrande77。
语言建模数据集包括 Pile78。
中文理解与文化数据集包括 CCPM(中)79。
数学数据集包括 GSM8K80、MATH81、MGSM82 和 CMath(中)83。
代码数据集包括 HumanEval84、LiveCodeBench-Base(0801-1101)85、MBPP86 和 CRUXEval87。
标准化考试包括 AGIEval(中)88。注意 AGIEval 同时包含英文和中文子集。
沿用我们此前的工作67,我们对 HellaSwag、PIQA、WinoGrande、RACE-Middle、RACE-High、MMLU、MMLU-Redux、MMLU-Pro、MMMLU、ARC-Easy、ARC-Challenge、C-Eval、CMMLU、C3 和 CCPM 采用基于困惑度的评测,对 TriviaQA、NaturalQuestions、DROP、MATH、GSM8K、MGSM、HumanEval、MBPP、LiveCodeBench-Base、CRUXEval、BBH、AGIEval、CLUEWSC、CMRC 和 CMath 采用基于生成的评测。此外,我们对 Pile-test 做基于语言建模的评测,用 Bits-Per-Byte(BPB)作为指标,以保证使用不同 tokenizer 的模型之间比较公平。
Table 3:DeepSeek-V3-Base 与其他代表性开源基础模型的对比。所有模型都在我们的内部框架里评测,共享相同的评测设置。分差不超过 0.3 的分数视为同一水平。DeepSeek-V3-Base 在大多数 benchmark 上取得最好成绩,数学和代码任务上尤为突出。
| Benchmark(指标) | # Shots | DeepSeek-V2 Base | Qwen2.5 72B Base | LLaMA-3.1 405B Base | DeepSeek-V3 Base | |
|---|---|---|---|---|---|---|
| 架构 | - | MoE | Dense | Dense | MoE | |
| 激活参数量 | - | 21B | 72B | 405B | 37B | |
| 总参数量 | - | 236B | 72B | 405B | 671B | |
| 英文 | Pile-test (BPB) | - | 0.606 | 0.638 | 0.542 | 0.548 |
| 英文 | BBH (EM) | 3-shot | 78.8 | 79.8 | 82.9 | 87.5 |
| 英文 | MMLU (EM) | 5-shot | 78.4 | 85.0 | 84.4 | 87.1 |
| 英文 | MMLU-Redux (EM) | 5-shot | 75.6 | 83.2 | 81.3 | 86.2 |
| 英文 | MMLU-Pro (EM) | 5-shot | 51.4 | 58.3 | 52.8 | 64.4 |
| 英文 | DROP (F1) | 3-shot | 80.4 | 80.6 | 86.0 | 89.0 |
| 英文 | ARC-Easy (EM) | 25-shot | 97.6 | 98.4 | 98.4 | 98.9 |
| 英文 | ARC-Challenge (EM) | 25-shot | 92.2 | 94.5 | 95.3 | 95.3 |
| 英文 | HellaSwag (EM) | 10-shot | 87.1 | 84.8 | 89.2 | 88.9 |
| 英文 | PIQA (EM) | 0-shot | 83.9 | 82.6 | 85.9 | 84.7 |
| 英文 | WinoGrande (EM) | 5-shot | 86.3 | 82.3 | 85.2 | 84.9 |
| 英文 | RACE-Middle (EM) | 5-shot | 73.1 | 68.1 | 74.2 | 67.1 |
| 英文 | RACE-High (EM) | 5-shot | 52.6 | 50.3 | 56.8 | 51.3 |
| 英文 | TriviaQA (EM) | 5-shot | 80.0 | 71.9 | 82.7 | 82.9 |
| 英文 | NaturalQuestions (EM) | 5-shot | 38.6 | 33.2 | 41.5 | 40.0 |
| 英文 | AGIEval (EM) | 0-shot | 57.5 | 75.8 | 60.6 | 79.6 |
| 代码 | HumanEval (Pass@1) | 0-shot | 43.3 | 53.0 | 54.9 | 65.2 |
| 代码 | MBPP (Pass@1) | 3-shot | 65.0 | 72.6 | 68.4 | 75.4 |
| 代码 | LiveCodeBench-Base (Pass@1) | 3-shot | 11.6 | 12.9 | 15.5 | 19.4 |
| 代码 | CRUXEval-I (EM) | 2-shot | 52.5 | 59.1 | 58.5 | 67.3 |
| 代码 | CRUXEval-O (EM) | 2-shot | 49.8 | 59.9 | 59.9 | 69.8 |
| 数学 | GSM8K (EM) | 8-shot | 81.6 | 88.3 | 83.5 | 89.3 |
| 数学 | MATH (EM) | 4-shot | 43.4 | 54.4 | 49.0 | 61.6 |
| 数学 | MGSM (EM) | 8-shot | 63.6 | 76.2 | 69.9 | 79.8 |
| 数学 | CMath (EM) | 3-shot | 78.7 | 84.5 | 77.3 | 90.7 |
| 中文 | CLUEWSC (EM) | 5-shot | 82.0 | 82.5 | 83.0 | 82.7 |
| 中文 | C-Eval (EM) | 5-shot | 81.4 | 89.2 | 72.5 | 90.1 |
| 中文 | CMMLU (EM) | 5-shot | 84.0 | 89.5 | 73.7 | 88.8 |
| 中文 | CMRC (EM) | 1-shot | 77.4 | 75.8 | 76.0 | 76.3 |
| 中文 | C3 (EM) | 0-shot | 77.4 | 76.7 | 79.7 | 78.6 |
| 中文 | CCPM (EM) | 0-shot | 93.0 | 88.5 | 78.6 | 92.0 |
| 多语 | MMMLU-non-English (EM) | 5-shot | 64.0 | 74.8 | 73.8 | 79.4 |
4.4.2 评测结果
在 Table 3 中,我们把 DeepSeek-V3 的基础模型与当前最好的开源基础模型作对比,包括 DeepSeek-V2-Base7(我们此前的发布)、Qwen2.5 72B Base16 和 LLaMA-3.1 405B Base13。我们用内部评测框架评测所有这些模型,并确保它们共享相同的评测设置。注意由于过去几个月我们评测框架的变化,DeepSeek-V2-Base 的表现与我们此前报告的结果略有差异。总体上,DeepSeek-V3-Base 全面超过 DeepSeek-V2-Base 和 Qwen2.5 72B Base,并在大多数 benchmark 上超过 LLaMA-3.1 405B Base,基本上成为最强的开源模型。
从更细的角度,我们把 DeepSeek-V3-Base 逐个与其他开源基础模型比较。(1)与 DeepSeek-V2-Base 相比,由于模型架构的改进、模型规模与训练 token 的扩大、以及数据质量的提升,DeepSeek-V3-Base 如预期取得了显著更好的表现。(2)与当前最好的中文开源模型 Qwen2.5 72B Base 相比,DeepSeek-V3-Base 只用一半的激活参数就展现出显著优势,在英文、多语、代码和数学 benchmark 上尤其明显。中文 benchmark 方面,除了 CMMLU 这个中文多学科选择题任务,DeepSeek-V3-Base 也比 Qwen2.5 72B 表现更好。(3)与激活参数是它 11 倍的最大开源模型 LLaMA-3.1 405B Base 相比,DeepSeek-V3-Base 在多语、代码和数学 benchmark 上同样表现好得多。英文和中文语言 benchmark 方面,DeepSeek-V3-Base 表现有竞争力或更好,在 BBH、MMLU 系列、DROP、C-Eval、CMMLU 和 CCPM 上尤其出色。
由于高效的架构和全面的工程优化,DeepSeek-V3 达到了极高的训练效率。在我们的训练框架和基础设施下,每训练一万亿 token 的 DeepSeek-V3 只需要 18 万 H800 GPU 小时,比训练 72B 或 405B 的 dense 模型便宜得多。
4.5 讨论
4.5.1 Multi-Token Prediction 的消融
Table 4:MTP 策略的消融结果。MTP 策略在大多数评测 benchmark 上都一致地提升了模型表现。
| Benchmark(指标) | # Shots | Small MoE Baseline | Small MoE w/ MTP | Large MoE Baseline | Large MoE w/ MTP |
|---|---|---|---|---|---|
| 激活参数量(推理时) | - | 2.4B | 2.4B | 20.9B | 20.9B |
| 总参数量(推理时) | - | 15.7B | 15.7B | 228.7B | 228.7B |
| 训练 token 数 | - | 1.33T | 1.33T | 540B | 540B |
| Pile-test (BPB) | - | 0.729 | 0.729 | 0.658 | 0.657 |
| BBH (EM) | 3-shot | 39.0 | 41.4 | 70.0 | 70.7 |
| MMLU (EM) | 5-shot | 50.0 | 53.3 | 67.5 | 66.6 |
| DROP (F1) | 1-shot | 39.2 | 41.3 | 68.5 | 70.6 |
| TriviaQA (EM) | 5-shot | 56.9 | 57.7 | 67.0 | 67.3 |
| NaturalQuestions (EM) | 5-shot | 22.7 | 22.3 | 27.2 | 28.5 |
| HumanEval (Pass@1) | 0-shot | 20.7 | 26.8 | 44.5 | 53.7 |
| MBPP (Pass@1) | 3-shot | 35.8 | 36.8 | 61.6 | 62.2 |
| GSM8K (EM) | 8-shot | 25.4 | 31.4 | 72.3 | 74.0 |
| MATH (EM) | 4-shot | 10.7 | 12.6 | 38.6 | 39.8 |
在 Table 4 中,我们给出 MTP 策略的消融结果。具体来说,我们在两个不同规模的 baseline 模型之上验证 MTP 策略。小规模上,我们在 1.33T token 上训练一个总参数 15.7B 的 baseline MoE 模型。大规模上,我们在 540B token 上训练一个总参数 228.7B 的 baseline MoE 模型。在它们之上,保持训练数据和其他架构不变,我们各加一个深度为 1 的 MTP 模块,训练两个带 MTP 策略的模型作对比。注意推理时我们直接丢弃 MTP 模块,所以被比较的模型推理成本完全相同。从表中可以看到,MTP 策略在大多数评测 benchmark 上都一致地提升了模型表现。
4.5.2 无辅助损失均衡策略的消融
Table 5:无辅助损失均衡策略的消融结果。与纯粹基于辅助损失的方法相比,无辅助损失策略在大多数评测 benchmark 上都一致取得更好的模型表现。
| Benchmark(指标) | # Shots | Small MoE Aux-Loss-Based | Small MoE Aux-Loss-Free | Large MoE Aux-Loss-Based | Large MoE Aux-Loss-Free |
|---|---|---|---|---|---|
| 激活参数量 | - | 2.4B | 2.4B | 20.9B | 20.9B |
| 总参数量 | - | 15.7B | 15.7B | 228.7B | 228.7B |
| 训练 token 数 | - | 1.33T | 1.33T | 578B | 578B |
| Pile-test (BPB) | - | 0.727 | 0.724 | 0.656 | 0.652 |
| BBH (EM) | 3-shot | 37.3 | 39.3 | 66.7 | 67.9 |
| MMLU (EM) | 5-shot | 51.0 | 51.8 | 68.3 | 67.2 |
| DROP (F1) | 1-shot | 38.1 | 39.0 | 67.1 | 67.1 |
| TriviaQA (EM) | 5-shot | 58.3 | 58.5 | 66.7 | 67.7 |
| NaturalQuestions (EM) | 5-shot | 23.2 | 23.4 | 27.1 | 28.1 |
| HumanEval (Pass@1) | 0-shot | 22.0 | 22.6 | 40.2 | 46.3 |
| MBPP (Pass@1) | 3-shot | 36.6 | 35.8 | 59.2 | 61.2 |
| GSM8K (EM) | 8-shot | 27.1 | 29.6 | 70.7 | 74.5 |
| MATH (EM) | 4-shot | 10.9 | 11.1 | 37.2 | 39.6 |
在 Table 5 中,我们给出无辅助损失均衡策略的消融结果。我们在两个不同规模的 baseline 模型之上验证这个策略。小规模上,我们在 1.33T token 上训练一个总参数 15.7B 的 baseline MoE 模型。大规模上,我们在 578B token 上训练一个总参数 228.7B 的 baseline MoE 模型。两个 baseline 模型都纯粹用辅助损失来鼓励负载均衡,并使用带 top-K affinity 归一化的 sigmoid 门控函数。它们控制辅助损失强度的超参分别与 DeepSeek-V2-Lite 和 DeepSeek-V2 相同。在这两个 baseline 模型之上,保持训练数据和其他架构不变,我们移除所有辅助损失、引入无辅助损失均衡策略作对比。从表中可以看到,无辅助损失策略在大多数评测 benchmark 上都一致取得更好的模型表现。
4.5.3 batch-wise 负载均衡 vs. sequence-wise 负载均衡
无辅助损失均衡与 sequence-wise 辅助损失之间的关键区别在于均衡的作用范围:batch-wise 还是 sequence-wise。与 sequence-wise 辅助损失相比,batch-wise 均衡施加的约束更灵活,因为它不强制每条序列内部的 in-domain 均衡。这种灵活性让 expert 能更好地在不同领域上专业化。为了验证这一点,我们在 Pile 测试集的不同领域上记录并分析了一个 16B 基于辅助损失的 baseline 和一个 16B 无辅助损失模型的 expert 负载。如 Figure 9 所示,我们观察到无辅助损失模型如预期展现出更强的 expert 专业化模式。
为了进一步考察这种灵活性与模型性能优势之间的关联,我们额外设计并验证了一种 batch-wise 辅助损失,它鼓励每个训练 batch 上的负载均衡,而不是每条序列上的。实验结果表明,在达到相近的 batch-wise 负载均衡水平时,batch-wise 辅助损失也能取得与无辅助损失方法相近的模型性能。具体来说,在我们 1B MoE 模型的实验中,验证 loss 分别是:2.258(用 sequence-wise 辅助损失)、2.253(用无辅助损失方法)、2.253(用 batch-wise 辅助损失)。在 3B MoE 模型上我们也观察到类似结果:用 sequence-wise 辅助损失的模型验证 loss 为 2.085,而用无辅助损失方法或 batch-wise 辅助损失的模型取得相同的验证 loss 2.080。
此外,虽然 batch-wise 负载均衡方法显示出一致的性能优势,它们在效率上也面临两个潜在挑战:(1)某些序列或小 batch 内部的负载不均衡;(2)推理时由领域漂移引起的负载不均衡。第一个挑战被我们使用大规模 expert 并行和数据并行的训练框架自然解决了,因为它保证了每个 micro-batch 的规模足够大。对第二个挑战,我们也设计并实现了带冗余 expert 部署的高效推理框架,如 §3.4 所述,用以克服它。
5 后训练
5.1 Supervised Fine-Tuning
我们精心整理指令微调数据集,包含跨多个领域的 150 万条实例,每个领域采用针对其具体要求定制的数据生成方法。
推理数据。对推理相关的数据集——包括聚焦数学、代码竞赛题和逻辑谜题的那些——我们利用一个内部的 DeepSeek-R1 模型来生成数据。具体来说,尽管 R1 生成的数据准确率很高,它也存在过度思考、格式糟糕、长度过长这些问题。我们的目标是在 R1 生成推理数据的高准确率和常规格式推理数据的清晰简洁之间取得平衡。
为了确立我们的方法,我们首先用一条结合 Supervised Fine-Tuning(SFT)和 Reinforcement Learning(RL)的训练流程,针对某个特定领域(如代码、数学或通用推理)开发一个 expert 模型。这个 expert 模型充当最终模型的数据生成器。训练过程中,我们为每条实例生成两种不同类型的 SFT 样本:第一种把问题与它原始的回答配成 <问题, 原始回答> 的格式;第二种把 system prompt 和问题、R1 的回答一起组成 <system prompt, 问题, R1 回答> 的格式。
system prompt 经过精心设计,包含引导模型产出富含反思与验证机制的回答的指令。RL 阶段,模型利用高温采样来生成融合了 R1 生成数据与原始数据两种模式的回答,即便在没有明确 system prompt 的情况下也是如此。经过数百个 RL step,中间的 RL 模型学会了融入 R1 的模式,从而策略性地提升了整体表现。
RL 训练阶段完成后,我们施加拒绝采样,为最终模型精选高质量的 SFT 数据,其中 expert 模型被用作数据生成源。这个方法确保最终的训练数据保留了 DeepSeek-R1 的强项,同时产出简洁而有效的回答。
非推理数据。对非推理数据,例如创意写作、角色扮演和简单问答,我们用 DeepSeek-V2.5 生成回答,并招募人工标注员来核实数据的准确性与正确性。
SFT 设置。我们用 SFT 数据集对 DeepSeek-V3-Base 微调两个 epoch,采用余弦衰减学习率调度,从 $5 \times 10^{-6}$ 开始逐步降到 $1 \times 10^{-6}$。训练时,每条序列由多个样本打包而成。不过我们采用样本掩码策略,确保这些样例彼此隔离、互不可见。
5.2 Reinforcement Learning
5.2.1 奖励模型
我们在 RL 过程中同时采用基于规则的奖励模型(RM)和基于模型的 RM。
基于规则的 RM。对可以用特定规则验证的问题,我们采用基于规则的奖励系统来确定反馈。举例来说,某些数学题有确定的结果,我们要求模型把最终答案写在指定格式里(比如放进一个框内),这样我们就可以用规则来验证正确性。类似地,对 LeetCode 题目,我们可以用编译器基于测试用例生成反馈。只要有可能就利用基于规则的验证,我们就能确保更高的可靠性,因为这个方法不容易被操纵或钻空子。
基于模型的 RM。对拥有自由形式 ground-truth 答案的问题,我们依靠奖励模型来判断回答是否与预期的 ground-truth 相符。反过来,对没有确定 ground-truth 的问题,比如涉及创意写作的那些,奖励模型的任务是把问题和相应答案作为输入来给出反馈。奖励模型从 DeepSeek-V3 的 SFT checkpoint 训练而来。为了增强它的可靠性,我们构造的偏好数据不只提供最终的奖励,还包含导向该奖励的链式思考。这个做法有助于降低特定任务上 reward hacking 的风险。
5.2.2 Group Relative Policy Optimization
与 DeepSeek-V27 类似,我们采用 Group Relative Policy Optimization(GRPO)89,它舍弃了通常与策略模型同等大小的 critic 模型,改为从组内分数来估计 baseline。具体来说,对每个问题 $q$,GRPO 从旧策略模型 $\pi_{\theta_{old}}$ 采样一组输出 $\{o_1, o_2, \cdots, o_G\}$,然后通过最大化以下目标来优化策略模型 $\pi_{\theta}$:
$$ \begin{split} \mathcal{J}_{GRPO}(\theta) &= \mathbb{E}{[q \sim P(Q), \{o_i\}_{i=1}^G \sim \pi_{\theta_{old}}(O|q)]} \\ & \frac{1}{G}\sum_{i=1}^G \left( \min \left( \frac{\pi_\theta(o_i |q)}{\pi_{\theta_{old}}(o_i |q)} A_i, \text{clip} \left( \frac{\pi_\theta(o_i |q)}{\pi_{\theta_{old}}(o_i |q)}, 1 - \epsilon, 1 + \epsilon \right) A_i \right) - \beta \mathbb{D}_{KL}\left(\pi_{\theta} || \pi_{ref}\right)\right), \end{split} $$ $$ \mathbb{D}_{KL}\left(\pi_{\theta} || \pi_{ref}\right) = \frac{\pi_{ref}(o_i|q)}{\pi_{\theta}(o_i|q)}- \log\frac{\pi_{ref}(o_i|q)}{\pi_{\theta}(o_i|q)} - 1, $$其中 $\epsilon$ 和 $\beta$ 是超参数;$\pi_{ref}$ 是参考模型;$A_i$ 是 advantage,由每组内输出所对应的奖励 $\{r_1, r_2, \ldots, r_G\}$ 导出:
$$ A_i = \frac{r_i - {\operatorname{mean}(\{r_1, r_2, \cdots, r_G\})}}{{\operatorname{std}(\{r_1, r_2, \cdots, r_G\})}}. $$RL 过程中我们纳入了来自不同领域的 prompt,比如代码、数学、写作、角色扮演和问答。这个做法不仅让模型更贴近人类偏好,也提升了 benchmark 上的表现,在可用 SFT 数据有限的场景下尤其明显。
5.3 评测
5.3.1 评测设置
评测 benchmark。除了用于基础模型测试的那些 benchmark,我们还在 IFEval90、FRAMES91、LongBench v292、GPQA93、SimpleQA94、C-SimpleQA95、SWE-Bench Verified96、Aider97、LiveCodeBench85(2024 年 8 月到 11 月的题目)、Codeforces98、中国高中数学奥林匹克(CNMO 2024)99 和 2024 年美国邀请赛数学考试(AIME 2024)100 上评测指令模型。
对照 baseline。我们把我们的 chat 模型与若干强 baseline 做全面评测,包括 DeepSeek-V2-0506、DeepSeek-V2.5-0905、Qwen2.5 72B Instruct、LLaMA-3.1 405B Instruct、Claude-Sonnet-3.5-1022 和 GPT-4o-0513。对 DeepSeek-V2 系列模型,我们选取最具代表性的变体来比较。对闭源模型,评测通过它们各自的 API 进行。
详细评测配置。对 MMLU、DROP、GPQA、SimpleQA 这些标准 benchmark,我们采用 simple-evals 框架101的评测 prompt。对 MMLU-Redux,我们在 zero-shot 设置下采用 Zero-Eval 的 prompt 格式102。对其他数据集,我们遵循它们原始的评测协议,使用数据集作者提供的默认 prompt。代码和数学 benchmark 方面,HumanEval-Mul 数据集共包含 8 种主流编程语言(Python、Java、Cpp、C#、JavaScript、TypeScript、PHP 和 Bash)。我们用 CoT 和非 CoT 两种方式评测模型在 LiveCodeBench 上的表现,数据采集自 2024 年 8 月到 11 月。Codeforces 数据集用选手百分位来衡量。SWE-Bench Verified 用 agentless 框架103评测。Aider 相关的 benchmark 我们用「diff」格式评测。数学评估方面,AIME 和 CNMO 2024 以温度 0.7 评测,结果取 16 次运行的平均,而 MATH-500 采用贪心解码。所有 benchmark 上我们都允许模型最多输出 8192 个 token。
Table 6:DeepSeek-V3 与其他代表性 chat 模型的对比。所有模型都在把输出长度限制为 8K 的配置下评测。样本数少于 1000 的 benchmark 用不同的温度设置多次测试,以得到稳健的最终结果。DeepSeek-V3 是表现最好的开源模型,与前沿闭源模型相比也有竞争力。
| Benchmark(指标) | DeepSeek V2-0506 | DeepSeek V2.5-0905 | Qwen2.5 72B-Inst. | LLaMA-3.1 405B-Inst. | Claude-3.5-Sonnet-1022 | GPT-4o 0513 | DeepSeek V3 | |
|---|---|---|---|---|---|---|---|---|
| 架构 | MoE | MoE | Dense | Dense | - | - | MoE | |
| 激活参数量 | 21B | 21B | 72B | 405B | - | - | 37B | |
| 总参数量 | 236B | 236B | 72B | 405B | - | - | 671B | |
| 英文 | MMLU (EM) | 78.2 | 80.6 | 85.3 | 88.6 | 88.3 | 87.2 | 88.5 |
| 英文 | MMLU-Redux (EM) | 77.9 | 80.3 | 85.6 | 86.2 | 88.9 | 88.0 | 89.1 |
| 英文 | MMLU-Pro (EM) | 58.5 | 66.2 | 71.6 | 73.3 | 78.0 | 72.6 | 75.9 |
| 英文 | DROP (3-shot F1) | 83.0 | 87.8 | 76.7 | 88.7 | 88.3 | 83.7 | 91.6 |
| 英文 | IF-Eval (Prompt Strict) | 57.7 | 80.6 | 84.1 | 86.0 | 86.5 | 84.3 | 86.1 |
| 英文 | GPQA-Diamond (Pass@1) | 35.3 | 41.3 | 49.0 | 51.1 | 65.0 | 49.9 | 59.1 |
| 英文 | SimpleQA (Correct) | 9.0 | 10.2 | 9.1 | 17.1 | 28.4 | 38.2 | 24.9 |
| 英文 | FRAMES (Acc.) | 66.9 | 65.4 | 69.8 | 70.0 | 72.5 | 80.5 | 73.3 |
| 英文 | LongBench v2 (Acc.) | 31.6 | 35.4 | 39.4 | 36.1 | 41.0 | 48.1 | 48.7 |
| 代码 | HumanEval-Mul (Pass@1) | 69.3 | 77.4 | 77.3 | 77.2 | 81.7 | 80.5 | 82.6 |
| 代码 | LiveCodeBench (Pass@1-COT) | 18.8 | 29.2 | 31.1 | 28.4 | 36.3 | 33.4 | 40.5 |
| 代码 | LiveCodeBench (Pass@1) | 20.3 | 28.4 | 28.7 | 30.1 | 32.8 | 34.2 | 37.6 |
| 代码 | Codeforces (Percentile) | 17.5 | 35.6 | 24.8 | 25.3 | 20.3 | 23.6 | 51.6 |
| 代码 | SWE Verified (Resolved) | - | 22.6 | 23.8 | 24.5 | 50.8 | 38.8 | 42.0 |
| 代码 | Aider-Edit (Acc.) | 60.3 | 71.6 | 65.4 | 63.9 | 84.2 | 72.9 | 79.7 |
| 代码 | Aider-Polyglot (Acc.) | - | 18.2 | 7.6 | 5.8 | 45.3 | 16.0 | 49.6 |
| 数学 | AIME 2024 (Pass@1) | 4.6 | 16.7 | 23.3 | 23.3 | 16.0 | 9.3 | 39.2 |
| 数学 | MATH-500 (EM) | 56.3 | 74.7 | 80.0 | 73.8 | 78.3 | 74.6 | 90.2 |
| 数学 | CNMO 2024 (Pass@1) | 2.8 | 10.8 | 15.9 | 6.8 | 13.1 | 10.8 | 43.2 |
| 中文 | CLUEWSC (EM) | 89.9 | 90.4 | 91.4 | 84.7 | 85.4 | 87.9 | 90.9 |
| 中文 | C-Eval (EM) | 78.6 | 79.5 | 86.1 | 61.5 | 76.7 | 76.0 | 86.5 |
| 中文 | C-SimpleQA (Correct) | 48.5 | 54.1 | 48.4 | 50.4 | 51.3 | 59.3 | 64.8 |
5.3.2 标准评测
Table 6 给出评测结果,显示 DeepSeek-V3 是表现最好的开源模型。此外,它与 GPT-4o、Claude-3.5-Sonnet 这类前沿闭源模型相比也有竞争力。
英文 benchmark。MMLU 是一个广受认可的 benchmark,用于评估大语言模型在不同知识领域和任务上的表现。DeepSeek-V3 表现出有竞争力的水平,与 LLaMA-3.1-405B、GPT-4o、Claude-Sonnet 3.5 这些顶级模型相当,同时显著超过 Qwen2.5 72B。此外,DeepSeek-V3 在更有挑战的教育知识 benchmark MMLU-Pro 上表现出色,紧随 Claude-Sonnet 3.5 之后。在标签经过修正的 MMLU 精修版 MMLU-Redux 上,DeepSeek-V3 超过了同行。另外,在博士水平的评测平台 GPQA-Diamond 上,DeepSeek-V3 取得了显著成绩,仅次于 Claude 3.5 Sonnet,并以相当大的优势超过所有其他竞争者。
在 DROP、LongBench v2、FRAMES 这类长上下文理解 benchmark 上,DeepSeek-V3 继续展现出顶级模型的地位。它在 DROP 的 3-shot 设置下取得令人印象深刻的 91.6 F1 分,在这一类别中超过所有其他模型。在 FRAMES——一个要求在 10 万 token 上下文上做问答的 benchmark——上,DeepSeek-V3 紧随 GPT-4o 之后,并以显著优势超过所有其他模型。这表明 DeepSeek-V3 处理极长上下文任务的能力很强。DeepSeek-V3 的长上下文能力还通过它在 LongBench v2 上同类最佳的表现得到进一步验证,这个数据集在 DeepSeek-V3 发布前几周才刚刚公开。在事实知识 benchmark SimpleQA 上,DeepSeek-V3 落后 GPT-4o 和 Claude-Sonnet,主要是由于它的设计侧重和资源分配。DeepSeek-V3 把更多训练 token 分配给学习中文知识,因此在 C-SimpleQA 上表现出色。在指令遵循 benchmark 上,DeepSeek-V3 显著超过它的前身 DeepSeek-V2 系列,凸显出它在理解并遵守用户定义的格式约束上的进步。
代码与数学 benchmark。编程对 LLM 来说是一项既有挑战又实用的任务,既包含 SWE-Bench-Verified 和 Aider 这类偏工程的任务,也包含 HumanEval 和 LiveCodeBench 这类算法任务。在工程任务上,DeepSeek-V3 落后 Claude-Sonnet-3.5-1022,但显著超过开源模型。开源的 DeepSeek-V3 有望推动代码相关工程任务的进展。通过开放它稳健的能力,DeepSeek-V3 可以驱动软件工程和算法开发等领域的创新与改进,让开发者和研究者去推动开源模型在代码任务上所能达到的边界。在算法任务上,DeepSeek-V3 表现更胜一筹,在 HumanEval-Mul 和 LiveCodeBench 这类 benchmark 上超过所有 baseline。这一成功可以归功于它先进的知识蒸馏技术,它有效增强了模型在算法向任务上的代码生成与问题求解能力。
在数学 benchmark 上,DeepSeek-V3 表现出色,显著超过各 baseline,为非 o1 类模型确立了新的 state-of-the-art。具体来说,在 AIME、MATH-500 和 CNMO 2024 上,DeepSeek-V3 以约 10% 的绝对分数超过第二名 Qwen2.5 72B,对这样有挑战性的 benchmark 来说是相当大的优势。这一出色能力凸显了从 DeepSeek-R1 蒸馏这项技术的有效性,它已被证明对非 o1 类模型非常有益。
中文 benchmark。Qwen 和 DeepSeek 是两个对中文和英文都有稳健支持的代表性模型系列。在事实 benchmark Chinese SimpleQA 上,DeepSeek-V3 超过 Qwen2.5-72B 达 16.4 分,尽管 Qwen2.5 是在一个 18T token 的更大语料上训练的,比 DeepSeek-V3 预训练用的 14.8T token 多 20%。
在中文教育知识评测的代表性 benchmark C-Eval 和 CLUEWSC(中文 Winograd Schema Challenge)上,DeepSeek-V3 与 Qwen2.5-72B 表现水平相近,说明两个模型都在有挑战的中文推理与教育任务上得到了良好优化。
5.3.3 开放式评测
Table 7:英文开放式对话评测。对 AlpacaEval 2.0,我们用长度受控的胜率作为指标。
| 模型 | Arena-Hard | AlpacaEval 2.0 |
|---|---|---|
| DeepSeek-V2.5-0905 | 76.2 | 50.5 |
| Qwen2.5-72B-Instruct | 81.2 | 49.1 |
| LLaMA-3.1 405B | 69.3 | 40.5 |
| GPT-4o-0513 | 80.4 | 51.1 |
| Claude-Sonnet-3.5-1022 | 85.2 | 52.0 |
| DeepSeek-V3 | 85.5 | 70.0 |
除了标准 benchmark,我们也在开放式生成任务上用 LLM 作为裁判来评测我们的模型,结果见 Table 7。具体来说,我们遵循 AlpacaEval 2.0104 和 Arena-Hard105 的原始配置,它们都用 GPT-4-Turbo-1106 作为裁判做成对比较。在 Arena-Hard 上,DeepSeek-V3 相对 baseline GPT-4-0314 取得了超过 86% 的惊人胜率,与 Claude-Sonnet-3.5-1022 这类顶级模型相当。这凸显了 DeepSeek-V3 稳健的能力,尤其是在处理包含编码与调试任务的复杂 prompt 时。此外,DeepSeek-V3 成为第一个在 Arena-Hard benchmark 上超过 85% 的开源模型,实现了开创性的里程碑。这一成就显著弥合了开源与闭源模型之间的性能差距,为开源模型在有挑战领域所能达到的水平树立了新的标准。
类似地,DeepSeek-V3 在 AlpacaEval 2.0 上展现出出色的表现,超过闭源和开源模型。这展示了它在写作任务和处理直白问答场景上的卓越熟练度。值得注意的是,它以 20% 的显著优势超过 DeepSeek-V2.5-0905,凸显出在应对简单任务上的实质改进,也展示了这些进步的有效性。
5.3.4 DeepSeek-V3 作为生成式奖励模型
我们把 DeepSeek-V3 的判断能力与当前最好的模型——即 GPT-4o 和 Claude-3.5——作对比。Table 8 给出这些模型在 RewardBench106 上的表现。DeepSeek-V3 取得了与 GPT-4o-0806 和 Claude-3.5-Sonnet-1022 的最佳版本相当的表现,并超过其他版本。此外,DeepSeek-V3 的判断能力还可以通过投票技术进一步增强。因此,我们用 DeepSeek-V3 配合投票,为开放式问题提供自我反馈,从而提升对齐过程的有效性与稳健性。
Table 8:GPT-4o、Claude-3.5-sonnet 和 DeepSeek-V3 在 RewardBench 上的表现。
| 模型 | Chat | Chat-Hard | Safety | Reasoning | 平均 |
|---|---|---|---|---|---|
| GPT-4o-0513 | 96.6 | 70.4 | 86.7 | 84.9 | 84.7 |
| GPT-4o-0806 | 96.1 | 76.1 | 88.1 | 86.6 | 86.7 |
| GPT-4o-1120 | 95.8 | 71.3 | 86.2 | 85.2 | 84.6 |
| Claude-3.5-sonnet-0620 | 96.4 | 74.0 | 81.6 | 84.7 | 84.2 |
| Claude-3.5-sonnet-1022 | 96.4 | 79.7 | 91.1 | 87.6 | 88.7 |
| DeepSeek-V3 | 96.9 | 79.8 | 87.0 | 84.3 | 87.0 |
| DeepSeek-V3 (maj@6) | 96.9 | 82.6 | 89.5 | 89.2 | 89.6 |
5.4 讨论
5.4.1 从 DeepSeek-R1 蒸馏
我们基于 DeepSeek-V2.5 消融了从 DeepSeek-R1 蒸馏的贡献。baseline 在短 CoT 数据上训练,而它的对手用的是上面描述的 expert checkpoint 生成的数据。
Table 9 展示了蒸馏数据的有效性,在 LiveCodeBench 和 MATH-500 两个 benchmark 上都有显著提升。我们的实验揭示了一个有趣的取舍:蒸馏带来更好的表现,但也大幅增加了平均回答长度。为了在模型准确率和计算效率之间保持平衡,我们为 DeepSeek-V3 在蒸馏上小心地选择了最优设置。
Table 9:从 DeepSeek-R1 蒸馏的贡献。LiveCodeBench 和 MATH-500 的评测设置与 Table 6 相同。
| 模型 | LiveCodeBench-CoT Pass@1 | LiveCodeBench-CoT Length | MATH-500 Pass@1 | MATH-500 Length |
|---|---|---|---|---|
| DeepSeek-V2.5 Baseline | 31.1 | 718 | 74.6 | 769 |
| DeepSeek-V2.5 +R1 Distill | 37.4 | 783 | 83.2 | 1510 |
我们的研究表明,从推理模型蒸馏知识是后训练优化的一个有希望的方向。虽然我们当前的工作聚焦于从数学和代码领域蒸馏数据,这个做法在各种任务领域上都显示出更广泛的应用潜力。它在这些特定领域展现的有效性说明,长 CoT 蒸馏对于提升模型在其他需要复杂推理的认知任务上的表现可能很有价值。在不同领域上进一步探索这个方法,仍然是未来研究的一个重要方向。
5.4.2 自我奖励
奖励在 RL 中扮演关键角色,引导着优化过程。在通过外部工具做验证很直接的领域,比如某些代码或数学场景,RL 显示出卓越的效力。然而在更通用的场景下,靠硬编码来构造反馈机制是不切实际的。在 DeepSeek-V3 的开发过程中,对这些更宽泛的语境,我们采用 constitutional AI 方法107,把 DeepSeek-V3 自身的投票评测结果作为反馈来源。这个方法产生了显著的对齐效果,大幅提升了 DeepSeek-V3 在主观评测上的表现。通过纳入额外的 constitutional 输入,DeepSeek-V3 可以朝着 constitutional 的方向优化。我们相信这种把补充信息与 LLM 结合作为反馈来源的范式极其重要。LLM 充当一个多用途的处理器,能够把来自不同场景的非结构化信息转化为奖励,最终促成 LLM 的自我改进。除了自我奖励,我们也致力于挖掘其他通用且可扩展的奖励方法,以持续推进模型在通用场景下的能力。
5.4.3 Multi-Token Prediction 评测
DeepSeek-V3 不是只预测下一个 token,而是通过 MTP 技术预测接下来 2 个 token。结合 speculative decoding3536 的框架,它可以显著加速模型的解码速度。一个自然的问题是额外预测的那个 token 的接受率如何。根据我们的评测,第二个 token 预测的接受率在各类生成主题上介于 85% 到 90% 之间,表现出一致的可靠性。这个很高的接受率使 DeepSeek-V3 的解码速度显著改善,达到 1.8 倍的 TPS(Tokens Per Second)。
6 结论、局限与未来方向
本文我们介绍了 DeepSeek-V3,一个总参数 671B、激活参数 37B 的大型 MoE 语言模型,在 14.8T token 上训练。除了 MLA 和 DeepSeekMoE 架构,它还首创了一种用于负载均衡的无辅助损失策略,并设置了 multi-token prediction 训练目标以获得更强性能。由于对 FP8 训练的支持和细致的工程优化,DeepSeek-V3 的训练是经济的。后训练也成功地从 DeepSeek-R1 系列模型中蒸馏出推理能力。全面评测表明,DeepSeek-V3 已成为当前可获得的最强开源模型,并取得了可与 GPT-4o、Claude-3.5-Sonnet 这类领先闭源模型相比的表现。尽管性能强劲,它也保持了经济的训练成本。它的完整训练——包括预训练、上下文长度扩展和后训练——只需要 278.8 万 H800 GPU 小时。
在承认它强劲的性能和成本效益的同时,我们也认识到 DeepSeek-V3 存在一些局限,尤其是在部署上。第一,为了确保推理高效,DeepSeek-V3 推荐的部署单元相对较大,对小规模团队可能构成负担。第二,尽管我们对 DeepSeek-V3 的部署策略已经实现了 DeepSeek-V2 两倍以上的端到端生成速度,仍有进一步提升的潜力。所幸随着更先进硬件的发展,这些局限有望自然地被解决。
DeepSeek 始终以长期主义坚守开源模型这条路线,目标是稳步接近 AGI(通用人工智能)这个终极目标。未来我们计划在以下方向战略性地投入研究。
- 我们将持续研究并改进我们的模型架构,目标是进一步提升训练和推理效率,努力接近对无限上下文长度的高效支持。此外,我们会尝试突破 Transformer 的架构局限,从而拓展它建模能力的边界。
- 我们将持续迭代训练数据的数量与质量,并探索纳入额外的训练信号来源,目标是在更全面的维度上推动数据的 scaling。
- 我们将持续探索并迭代模型的深度思考能力,目标是通过扩展它们的推理长度与深度来增强其智能和问题求解能力。
- 我们将探索更全面、更多维的模型评测方法,以防止研究过程中出现针对一组固定 benchmark 做优化的倾向,那会造成对模型能力的误导性印象、影响我们的基础判断。
附录 B 低精度训练的消融
B.1 FP8 vs. BF16 训练
我们在两个不同规模的 baseline 模型之上,通过与 BF16 训练对比来验证我们的 FP8 混合精度框架。小规模上,我们在 1.33T token 上训练一个总参数约 16B 的 baseline MoE 模型。大规模上,我们在约 0.9T token 上训练一个总参数约 230B 的 baseline MoE 模型。我们在 Figure 10 中给出训练曲线,表明在我们的高精度累加与细粒度量化策略下,相对误差始终保持在 0.25% 以下。
B.2 关于 block-wise 量化的讨论
尽管我们的 tile-wise 细粒度量化有效缓解了特征离群值引入的误差,它要求激活量化采用不同的分组方式,即前向用 1x128、反向用 128x1。激活梯度也需要类似的处理。一个直白的策略是像量化模型权重那样,按 128x128 个元素做 block-wise 量化。这样反向只需要做转置。因此我们做了一个实验,把与 Dgrad 相关的所有张量都按 block-wise 量化。结果显示,Dgrad 这个计算激活梯度、并以链式方式向浅层反传的操作对精度高度敏感。具体来说,对激活梯度做 block-wise 量化,会使一个总参数约 16B、训练约 300B token 的 MoE 模型发散。我们推测这种敏感性源于激活梯度在 token 之间高度不均衡,产生了与 token 相关的离群值108。这些离群值无法被 block-wise 量化方法有效处理。
附录 C 16B 基于辅助损失与无辅助损失模型的 expert 专业化模式
我们记录了 16B 基于辅助损失的 baseline 和无辅助损失模型在 Pile 测试集上的 expert 负载。如 Figure 11 所示,无辅助损失模型在所有层上都倾向于有更强的 expert 专业化。
Figure 11 分五个 panel 给出全部 26 个 MoE 层的结果。每个 panel 的每一层画两条热力图:上为 Aux-Loss-Based,下为 Aux-Loss-Free,每条热力图的三行分别对应 Wikipedia (en)、Github、DM Mathematics 三个领域,横轴是 64 个 expert。相对 expert 负载指实际 expert 负载与理论均衡负载之比,色标从 0(浅黄)到 10(深红)。无辅助损失模型在每一层都比基于辅助损失的模型呈现出更明显的领域特异峰值。
-
DeepSeek-V3 Technical Report, https://arxiv.org/abs/2412.19437 ↩︎
-
DeepSeek-V3 模型 checkpoint, https://github.com/deepseek-ai/DeepSeek-V3 ↩︎
-
Hello GPT-4o, OpenAI, https://openai.com/index/hello-gpt-4o/ ↩︎
-
Claude 3.5 Sonnet, Anthropic, https://www.anthropic.com/news/claude-3-5-sonnet ↩︎
-
Our Next-Generation Model: Gemini 1.5, Google, https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024 ↩︎
-
DeepSeek LLM: Scaling Open-Source Language Models with Longtermism, https://arxiv.org/abs/2401.02954 ↩︎ ↩︎
-
DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model, https://arxiv.org/abs/2405.04434 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
-
DeepSeek-Coder: When the Large Language Model Meets Programming — The Rise of Code Intelligence, https://arxiv.org/abs/2401.14196 ↩︎
-
DeepSeek-Coder-V2: Breaking the Barrier of Closed-Source Models in Code Intelligence, https://arxiv.org/abs/2406.11931 ↩︎ ↩︎
-
LLaMA: Open and Efficient Foundation Language Models, https://arxiv.org/abs/2302.13971 ↩︎
-
Llama 2: Open Foundation and Fine-Tuned Chat Models, https://arxiv.org/abs/2307.09288 ↩︎
-
Llama 3 Model Card, https://github.com/meta-llama/llama3/blob/main/MODEL_CARD.md ↩︎
-
Llama 3.1 Model Card, https://github.com/meta-llama/llama-models/blob/main/models/llama3_1/MODEL_CARD.md ↩︎ ↩︎
-
Qwen Technical Report, https://arxiv.org/abs/2309.16609 ↩︎
-
Introducing Qwen1.5, https://qwenlm.github.io/blog/qwen1.5 ↩︎
-
Qwen2.5: A Party of Foundation Models, https://qwenlm.github.io/blog/qwen2.5 ↩︎ ↩︎
-
Mistral 7B, https://arxiv.org/abs/2310.06825 ↩︎
-
Cheaper, Better, Faster, Stronger: Continuing to Push the Frontier of AI and Making It Accessible to All, Mistral, https://mistral.ai/news/mixtral-8x22b ↩︎
-
DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models, https://arxiv.org/abs/2401.06066 ↩︎ ↩︎ ↩︎
-
Auxiliary-Loss-Free Load Balancing Strategy for Mixture-of-Experts, https://arxiv.org/abs/2408.15664 ↩︎ ↩︎ ↩︎ ↩︎
-
A Study of BFLOAT16 for Deep Learning Training, https://arxiv.org/abs/1905.12322 ↩︎ ↩︎ ↩︎
-
FP8-LM: Training FP8 Large Language Models, https://arxiv.org/abs/2310.18313 ↩︎ ↩︎ ↩︎ ↩︎
-
LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale, NeurIPS 2022 ↩︎ ↩︎
-
FP8 Formats for Deep Learning, https://arxiv.org/abs/2209.05433 ↩︎
-
Ascend HiFloat8 Format for Deep Learning, https://arxiv.org/abs/2409.16626 ↩︎
-
Microscaling Data Formats for Deep Learning, https://arxiv.org/abs/2310.10537 ↩︎ ↩︎
-
RoFormer: Enhanced Transformer with Rotary Position Embedding, Neurocomputing 568, 2024 ↩︎
-
GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding, ICLR 2021 ↩︎ ↩︎ ↩︎
-
Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer, ICLR 2017 ↩︎
-
Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity, https://arxiv.org/abs/2101.03961 ↩︎
-
Better & Faster Large Language Models via Multi-Token Prediction, ICML 2024 ↩︎ ↩︎
-
EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty, ICML 2024 ↩︎
-
Speculative Decoding: Exploiting Speculative Execution for Accelerating Seq2seq Generation, Findings of EMNLP 2023 ↩︎ ↩︎
-
Fast Inference from Transformers via Speculative Decoding, ICML 2023 ↩︎ ↩︎
-
Zero Bubble Pipeline Parallelism, https://arxiv.org/abs/2401.10241 ↩︎ ↩︎ ↩︎
-
ZeRO: Memory Optimizations Toward Training Trillion Parameter Models, SC 2020 ↩︎
-
PipeDream: Fast and Efficient Pipeline Parallel DNN Training, https://arxiv.org/abs/1806.03377 ↩︎
-
Chimera: Efficiently Training Large-Scale Neural Networks with Bidirectional Pipelines, SC 2021 ↩︎
-
Singe: Leveraging Warp Specialization for High Performance on GPUs, PPoPP 2014 ↩︎
-
8-bit Numerical Formats for Deep Neural Networks, https://arxiv.org/abs/2206.02915 ↩︎
-
Massive Activations in Large Language Models, https://arxiv.org/abs/2402.17762 ↩︎
-
Understanding and Minimising Outlier Features in Transformer Training, NeurIPS 2024 ↩︎
-
Scaling FP8 Training to Trillion-Token LLMs, https://arxiv.org/abs/2409.12517 ↩︎ ↩︎
-
SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models, ICML 2023 ↩︎
-
GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers, https://arxiv.org/abs/2210.17323 ↩︎
-
Blackwell Architecture, NVIDIA, https://www.nvidia.com/en-us/data-center/technologies/blackwell-architecture/ ↩︎
-
Stable and Low-Precision Training for Large-Scale Vision-Language Models, NeurIPS 2023 ↩︎
-
TransformerEngine, NVIDIA, https://github.com/NVIDIA/TransformerEngine ↩︎ ↩︎ ↩︎
-
CUTLASS, NVIDIA, https://github.com/NVIDIA/cutlass ↩︎
-
Hybrid 8-bit Floating Point (HFP8) Training and Inference for Deep Neural Networks, NeurIPS 2019 ↩︎
-
Decoupled Weight Decay Regularization, https://arxiv.org/abs/1711.05101 ↩︎ ↩︎
-
Improving Network Performance of HPC Systems Using NVIDIA Magnum IO NVSHMEM and GPUDirect Async, NVIDIA, https://developer.nvidia.com/blog/improving-network-performance-of-hpc-systems-using-nvidia-magnum-io-nvshmem-and-gpudirect-async ↩︎
-
Scalable Hierarchical Aggregation Protocol (SHArP): A Hardware Architecture for Efficient Data Reduction, COMHPC 2016 ↩︎
-
Fewer Truncations Improve Language Modeling, https://arxiv.org/abs/2404.10830 ↩︎
-
Byte Pair Encoding: A Text Compression Scheme That Accelerates Pattern Matching, 1999 ↩︎
-
The Art of Prompt Design: Prompt Boundaries and Token Healing, https://towardsdatascience.com/the-art-of-prompt-design-prompt-boundaries-and-token-healing-3b2448b0be38 ↩︎
-
YaRN: Efficient Context Window Extension of Large Language Models, https://arxiv.org/abs/2309.00071 ↩︎
-
Measuring Massive Multitask Language Understanding, https://arxiv.org/abs/2009.03300 ↩︎
-
Are We Done with MMLU?, https://arxiv.org/abs/2406.04127 ↩︎
-
MMLU-Pro: A More Robust and Challenging Multi-Task Language Understanding Benchmark, https://arxiv.org/abs/2406.01574 ↩︎
-
Multilingual Massive Multitask Language Understanding (MMMLU), OpenAI, https://huggingface.co/datasets/openai/MMMLU ↩︎
-
C-Eval: A Multi-Level Multi-Discipline Chinese Evaluation Suite for Foundation Models, https://arxiv.org/abs/2305.08322 ↩︎
-
CMMLU: Measuring Massive Multitask Language Understanding in Chinese, https://arxiv.org/abs/2306.09212 ↩︎
-
HellaSwag: Can a Machine Really Finish Your Sentence?, ACL 2019 ↩︎
-
PIQA: Reasoning about Physical Commonsense in Natural Language, AAAI 2020 ↩︎
-
Think You Have Solved Question Answering? Try ARC, the AI2 Reasoning Challenge, https://arxiv.org/abs/1803.05457 ↩︎
-
Challenging BIG-Bench Tasks and Whether Chain-of-Thought Can Solve Them, https://arxiv.org/abs/2210.09261 ↩︎
-
TriviaQA: A Large Scale Distantly Supervised Challenge Dataset for Reading Comprehension, ACL 2017 ↩︎
-
Natural Questions: A Benchmark for Question Answering Research, TACL 7, 2019 ↩︎
-
RACE: Large-Scale Reading Comprehension Dataset From Examinations, EMNLP 2017 ↩︎
-
DROP: A Reading Comprehension Benchmark Requiring Discrete Reasoning Over Paragraphs, NAACL-HLT 2019 ↩︎
-
Investigating Prior Knowledge for Challenging Chinese Machine Reading Comprehension, 2019 ↩︎
-
A Span-Extraction Dataset for Chinese Machine Reading Comprehension, EMNLP-IJCNLP 2019 ↩︎
-
CLUE: A Chinese Language Understanding Evaluation Benchmark, COLING 2020 ↩︎
-
WinoGrande: An Adversarial Winograd Schema Challenge at Scale, 2019 ↩︎
-
The Pile: An 800GB Dataset of Diverse Text for Language Modeling, https://arxiv.org/abs/2101.00027 ↩︎
-
CCPM: A Chinese Classical Poetry Matching Dataset, 2021 ↩︎
-
Training Verifiers to Solve Math Word Problems, https://arxiv.org/abs/2110.14168 ↩︎
-
Measuring Mathematical Problem Solving with the MATH Dataset, https://arxiv.org/abs/2103.03874 ↩︎
-
Language Models Are Multilingual Chain-of-Thought Reasoners, ICLR 2023 ↩︎
-
CMath: Can Your Language Model Pass Chinese Elementary School Math Test?, 2023 ↩︎
-
Evaluating Large Language Models Trained on Code, https://arxiv.org/abs/2107.03374 ↩︎
-
LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code, https://arxiv.org/abs/2403.07974 ↩︎ ↩︎
-
Program Synthesis with Large Language Models, https://arxiv.org/abs/2108.07732 ↩︎
-
CRUXEval: A Benchmark for Code Reasoning, Understanding and Execution, 2024 ↩︎
-
AGIEval: A Human-Centric Benchmark for Evaluating Foundation Models, https://arxiv.org/abs/2304.06364 ↩︎
-
DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models, https://arxiv.org/abs/2402.03300 ↩︎
-
Instruction-Following Evaluation for Large Language Models, https://arxiv.org/abs/2311.07911 ↩︎
-
Fact, Fetch, and Reason: A Unified Evaluation of Retrieval-Augmented Generation, https://arxiv.org/abs/2409.12941 ↩︎
-
LongBench v2: Towards Deeper Understanding and Reasoning on Realistic Long-Context Multitasks, https://arxiv.org/abs/2412.15204 ↩︎
-
GPQA: A Graduate-Level Google-Proof Q&A Benchmark, https://arxiv.org/abs/2311.12022 ↩︎
-
Introducing SimpleQA, OpenAI, https://openai.com/index/introducing-simpleqa/ ↩︎
-
Chinese SimpleQA: A Chinese Factuality Evaluation for Large Language Models, https://arxiv.org/abs/2411.07140 ↩︎
-
Introducing SWE-bench Verified, OpenAI, https://openai.com/index/introducing-swe-bench-verified/ ↩︎
-
Aider, https://aider.chat ↩︎
-
Codeforces, https://codeforces.com ↩︎
-
中国高中数学联赛(CNMO 2024), https://www.cms.org.cn/Home/comp/comp/cid/12.html ↩︎
-
American Invitational Mathematics Examination(AIME 2024), https://maa.org/math-competitions/american-invitational-mathematics-examination-aime ↩︎
-
simple-evals, OpenAI, https://github.com/openai/simple-evals ↩︎
-
ZeroEval: A Unified Framework for Evaluating Language Models, https://github.com/WildEval/ZeroEval ↩︎
-
Agentless: Demystifying LLM-based Software Engineering Agents, https://arxiv.org/abs/2407.01489 ↩︎
-
Length-Controlled AlpacaEval: A Simple Way to Debias Automatic Evaluators, https://arxiv.org/abs/2404.04475 ↩︎
-
From Crowdsourced Data to High-Quality Benchmarks: Arena-Hard and BenchBuilder Pipeline, https://arxiv.org/abs/2406.11939 ↩︎
-
RewardBench: Evaluating Reward Models for Language Modeling, https://arxiv.org/abs/2403.13787 ↩︎
-
Constitutional AI: Harmlessness from AI Feedback, https://arxiv.org/abs/2212.08073 ↩︎
-
Training Transformers with 4-bit Integers, NeurIPS 2023 ↩︎
Author houmin
Publish July 30, 2026
LastMod July 31, 2026
License 本作品采用 CC BY-NC-ND 4.0 许可协议进行许可,转载时请注明原文链接
如果你在浏览博客的过程中发现了任何问题,欢迎在对应文章下评论。如果你有其他事情想要咨询,可以通过邮件联系我。