[DeepSeek-1] DeepSeek-V3 技术报告：从 671B MoE 到低成本训练系统

DeepSeek-V3 最吸引眼球的数字是：671B 总参数、每个 token 激活 37B 参数、14.8T 训练 token，以及 2.788M H800 GPU 小时。

但如果只记住这些数字，很容易错过这份技术报告真正有价值的地方。DeepSeek-V3 并不是靠某一个孤立技巧降低成本，而是把模型结构、数值精度、并行策略和通信实现放在一起设计：

• 用 DeepSeekMoE 扩大参数容量，同时控制每个 token 的计算量；
• 用 MLA 压缩推理时随上下文增长的 KV Cache；
• 用无辅助损失负载均衡稳定专家路由，减少均衡目标对语言建模的干扰；
• 用 **Multi-Token Prediction（MTP）**增加训练信号，并为推测解码提供 draft token；
• 用 FP8 混合精度降低 GEMM 成本和训练显存；
• 用 DualPipe、定制 All-to-All kernel 和节点受限路由隐藏 MoE 通信。

因此，更准确的一句话概括是：

DeepSeek-V3 是一个围绕“稀疏计算如何真正落到大规模集群上”进行软硬件协同设计的 671B MoE 模型。

本文基于 2025 年 2 月 18 日修订的 《DeepSeek-V3 Technical Report》v2。模型权重、配置与转换说明可参考 DeepSeek-V3 官方仓库。

1. 先统一数字口径#

报告给出的关键配置如下：

这里最重要的是区分三种“大小”：

1. 671B 是总参数容量，决定权重存储和完整模型部署的总体规模；
2. 37B 是每个 token 前向时激活的参数量，更接近单 token 计算量；
3. KV Cache 与上下文长度、并发数有关，它是另一类推理内存成本，不能从 37B 直接推导。

MoE 让“模型能记住多少”和“每次要计算多少”部分解耦，但并没有让其余 634B 参数消失。专家权重仍要分布在设备上，路由后的 token 仍要通过网络到达对应专家。

2. DeepSeekMoE：容量扩张不等于等比例增加计算#

标准 Dense Transformer 的每个 token 都经过同一套 FFN 参数。MoE 则准备许多专家，只为当前 token 激活其中少数几个。

DeepSeek-V3 的前 3 层保留 Dense FFN，后续 58 层使用 MoE。每个 MoE 层包含：

• 1 个所有 token 都会经过的共享专家；
• 256 个负责细粒度知识分工的路由专家；
• 每个 token 选择其中 8 个路由专家；
• 每个专家的中间隐藏维度为 2048。

把 attention 输出记为 $u_t$，MoE 层可以简化写成：

其中只有被 Top-K 路由选中的 8 个 $g_{i,t}$ 非零。

共享专家吸收多个领域都会使用的共通知识，路由专家则可以形成更细的专业分工。相比让所有专家重复学习公共模式，这种拆分希望提高参数利用率。报告附录中的专家负载可视化也显示，无辅助损失方案形成了更明显的领域特化，但“专家可解释性”仍不应仅凭负载图下结论。

2.1 37B 不代表可以像 37B Dense 模型一样部署#

激活参数量主要描述计算路径，不等于部署所需的权重容量。一个 37B Dense 模型只需要保存 37B 参数，而 DeepSeek-V3 即使每次只计算部分专家，服务集群仍要容纳 671B 权重，并为专家路由准备通信和负载均衡机制。

所以 MoE 的收益和代价是一体两面：

3. MLA：把 KV Cache 从完整 K/V 压缩为 latent#

长上下文推理中的一个核心瓶颈是 KV Cache。标准 Multi-Head Attention 需要为每一层、每个历史 token 保存各个 head 的 Key 和 Value；上下文越长、并发越高，缓存越大。

Multi-Head Latent Attention（MLA）的核心是对 Key 和 Value 做低秩联合压缩。对第 $t$ 个 token 的隐藏状态 $h_t$，先得到压缩向量：

需要参与 attention 时，再分别上投影为 Key 和 Value：

RoPE 所需的位置信息被单独放进 decoupled key：

推理时不必缓存完整的每头 K/V，主要缓存 $c_t^{KV}$ 与 $k_t^R$。DeepSeek-V3 的 KV 压缩维度为 512，RoPE key 维度为 64；相比 128 个 head、每头 128 维的完整表示，缓存规模显著下降。

Query 侧也做低秩压缩：

其压缩维度为 1536，再上投影得到内容 query 和携带 RoPE 的 query。Query 压缩主要减少训练激活内存，而 KV 压缩直接影响自回归推理缓存。

3.1 MLA 不只是“把 KV 量化一下”#

MLA 改变的是 attention 参数化与缓存表示，不是简单把 MHA 的 KV Cache 从 BF16 改成更低 bit。运行时需要从 latent 恢复或吸收上投影计算，并正确处理解耦的 RoPE 部分。

它解决的核心问题可以概括为：

传统 MHA：缓存每个历史 token 的完整多头 K/V
MLA：     缓存每个历史 token 的共享压缩 latent + RoPE 部分

这也是为什么 MLA 对 128K 上下文和高并发服务很重要：MoE 主要减少 FFN 计算，MLA 则直接处理 attention 的缓存与带宽问题，两者优化的是不同瓶颈。

4. 无辅助损失负载均衡：把“选谁”和“给多大权重”分开#

MoE 路由最怕两个问题：

• 少数专家过载，形成通信和计算热点；
• 大量 token 挤向少数专家，其他专家训练不足，甚至发生 routing collapse。

传统做法是在语言建模 loss 之外增加 load-balancing auxiliary loss。它能推动均衡，但系数过大时，模型可能为了“分得均匀”而牺牲本来更合适的专家选择。

DeepSeek-V3 为每个专家维护一个 bias $b_i$。首先计算 token 与专家的原始 affinity：

Top-K 选择依据是修正后的 $s_{i,t}+b_i$，但专家输出的门控权重仍来自原始 $s_{i,t}$：

每个训练 step 结束后：

• 专家过载，则把 $b_i$ 下调；
• 专家负载不足，则把 $b_i$ 上调。

这相当于让 bias 充当路由流量的慢速反馈控制器。它影响“能否进入 Top-K”，却不直接改变选中专家参与输出混合时的原始 affinity 权重。

4.1 “无辅助损失”不是完全没有均衡 loss#

报告仍保留了一个极小的序列级均衡损失，用于防止单条序列内部出现极端路由不均。其系数 $\alpha=0.0001$。因此更准确的表述是：

DeepSeek-V3 不再依赖主要的 batch-level auxiliary loss 来实现全局负载均衡，但保留了很弱的 sequence-wise 补充约束。

训练时 bias update speed $\gamma$ 在前 14.3T token 设为 0.001，最后 500B token 设为 0。报告的消融实验显示，这种方法在维持负载均衡的同时，比纯 auxiliary-loss 方案保留了更好的模型表现。

4.2 路由还必须考虑物理拓扑#

逻辑上选出 8 个专家还不够。如果它们散落在 8 个节点，单个 token 会制造大量跨节点通信。DeepSeek-V3 使用 node-limited routing，把每个 token 最多限制在 4 个节点内，并声称训练和推理都不需要 token dropping。

这里体现了报告反复出现的设计原则：路由算法不能只优化模型分数，还要把专家所在的物理位置作为约束。

5. Multi-Token Prediction：训练目标与推测解码的连接点#

标准语言模型在位置 $t$ 只监督下一个 token：

Multi-Token Prediction 让同一个位置继续预测更远的未来 token。DeepSeek-V3 设置 MTP depth $D=1$，也就是主模型预测下一个 token，额外的 MTP 模块预测再下一个 token。

它不是简单增加一个并列输出头。MTP 模块会把主模型在当前位置的表示，与训练时下一个真实 token 的 embedding 组合，经过线性投影和一个 Transformer block，保持完整的因果链，再预测第二个未来 token。Embedding 与 output head 和主模型共享。

训练目标可以概括为：

报告中 $\lambda$ 在前 10T token 为 0.3，后 4.8T token 降到 0.1。MTP 的价值有两层：

1. 训练阶段：同一段数据产生更密集的预测信号，报告消融显示它能改善主模型能力；
2. 推理阶段：MTP 模块可以充当 speculative decoding 的 draft 模块，一次提出额外 token，再由主模型验证。

普通自回归推理可以移除 MTP 模块，主模型仍可独立运行。报告测得第二个 token 的接受率约为 85%–90%，并报告约 1.8 倍 TPS。这个数字应理解为其特定实现和工作负载下的系统结果，而不是所有部署都能直接复现的固定加速比。

6. FP8 混合精度：关键不是“用了 FP8”，而是哪里不能用#

DeepSeek-V3 把 Linear 算子的三类主要 GEMM 都放到 FP8 中：

• Fprop：前向计算；
• Dgrad：输入或激活梯度；
• Wgrad：权重梯度。

FP8 输入经过 GEMM 后，输出保留为 BF16 或 FP32。与此同时，数值敏感或计算占比较低的模块继续使用高精度：

这不是“把所有张量统一转成 FP8”，而是一套混合精度边界设计。

6.1 细粒度量化如何处理异常值#

低精度训练容易被 activation、weight 和 gradient 中的异常值破坏。DeepSeek-V3 采用细粒度 scaling：

• activation 按 1 x 128 tile 缩放，即每个 token、每 128 个 channel 一组 scale；
• weight 按 128 x 128 block 缩放；
• scale 在线计算，而不是依赖历史统计预测当前范围。

分组越细，异常值污染同组正常值的范围越小，但 scale 管理和反量化开销也更高。

6.2 更高精度累加是 FP8 能训练稳定的关键#

仅把乘法输入改成 FP8 并不足够。报告每累积 128 个 FP8 乘法结果，就把部分和提升到 CUDA Core 中用 FP32 累加，以弥补 Hopper Tensor Core 的 FP8 累加精度限制。

报告中的“相对 BF16 loss 误差低于 0.25%”来自两个不同规模的验证模型：约 16B 模型训练 1.33T token，以及约 230B 模型训练约 0.9T token。它支持这套方法的可行性，但不等价于公开了一组完整 671B V3 的 BF16 对照训练。

7. DualPipe：MoE 训练真正困难的是通信#

DeepSeek-V3 使用 2048 张 H800。每个节点有 8 张 GPU，节点内通过 NVLink 与 NVSwitch 连接，节点间使用 InfiniBand。

训练并行配置是：

16-way Pipeline Parallelism
64-way Expert Parallelism，跨 8 个节点
ZeRO-1 Data Parallelism
不使用 Tensor Parallelism

不使用训练期 Tensor Parallelism 可以避免高频 TP 通信，但要求通过 EP、PP、ZeRO、重计算和状态放置把 671B 参数及激活装入集群。

跨节点 EP 带来的 All-to-All 通信非常重。报告称未经处理时，计算与通信的比例大约是 1:1。DualPipe 的做法是把一个 chunk 拆成：

Attention
All-to-All dispatch
MLP
All-to-All combine

反向阶段再把 attention 和 MLP 拆成输入梯度与权重梯度部分，重新排布这些计算和通信。完整调度从流水线两端同时注入 micro-batch，让一个方向的计算覆盖另一个方向的通信。

DualPipe 不是没有代价。它需要保留两份模型参数，峰值 activation memory 也略有增加；报告认为大规模 EP 已经摊薄了单设备参数，因此这个交换是划算的。

7.1 通信 kernel 与路由共同设计#

报告没有停在 pipeline schedule。团队还定制了跨节点 dispatch/combine kernel：

• 先经 IB 跨节点发送，再经 NVLink 在节点内转发；
• 根据负载动态分配不同通信任务的 warp；
• 用定制 PTX 和自动调节 chunk size 减少 L2 cache 干扰；
• 在 H800 的 132 个 SM 中，用约 20 个 SM 承担通信。

再结合“每个 token 最多去 4 个节点”的路由约束，DualPipe 才能把大量 All-to-All 隐藏在计算之后。单独复制 schedule、kernel 或路由策略中的任何一个，都不等于复制了完整训练效率。

8. 报告中的部署方案：Prefill 与 Decode 分开设计#

训练方案不能直接照搬到在线推理，因为 prefill 和 decode 的瓶颈不同：

• Prefill 有大量 token 并行，计算密度高；
• Decode 每步 token 少，attention 和权重读取更容易受内存带宽与通信延迟限制。

报告给出的线上部署参考方案如下：

Decode 阶段把共享专家视作必选的 routed expert，因此每个 token 等价于选择 9 个专家。每张 GPU 主要放一个专家，并使用一部分 GPU 承载共享专家与冗余专家。

为什么需要冗余专家？训练期的平均均衡不代表线上每一批请求都均衡。领域变化会让少数专家突然变热，因此报告根据线上统计周期性复制高负载专家，并调整专家放置。Prefill 方案中设置了 32 个冗余专家，每张 GPU 在原有 8 个专家之外再放 1 个副本。

这组 32/320 GPU 数字描述的是报告为了满足线上 SLO 和吞吐采用的服务设计，不是“运行 DeepSeek-V3 权重的唯一方式”或所有量化部署的最低硬件要求。它更重要的启示是：MoE 推理不能只做静态权重切分，还要处理随流量变化的专家热点。

9. 数据、长上下文与后训练#

9.1 14.8T token 预训练#

DeepSeek-V3 使用 14.8T 高质量、多样化 token，增加数学、代码和多语言数据比例。Tokenizer 是 128K 词表的 Byte-level BPE，并针对多语言压缩效率调整 pretokenizer。

报告还使用 Fill-in-Middle（FIM）训练，采用 PSM 格式，比例为 0.1。预训练的最大序列长度为 4K。

9.2 从 4K 扩展到 128K#

预训练完成后，模型使用 YaRN 做两阶段上下文扩展：

4K -> 32K：1000 steps
32K -> 128K：1000 steps

第一阶段 batch size 为 1920，第二阶段由于序列更长降到 480。报告中的 Needle In A Haystack 测试显示 SFT 后模型在最长 128K 范围内保持了较稳定表现。

上下文窗口达到 128K 不代表任意 128K 任务都能可靠完成。NIAH 更偏向信息检索压力测试，不能替代长文推理、跨段整合和真实多轮任务评估。

9.3 SFT、R1 蒸馏与 GRPO#

后训练使用约 1.5M 条 SFT 样本。推理数据由内部 DeepSeek-R1 模型提供能力来源，再通过领域专家模型、RL 与 rejection sampling 控制过度思考、格式和长度；非推理数据主要由 DeepSeek-V2.5 生成并经人工校验。

SFT 之后，DeepSeek-V3 同时使用规则奖励和模型奖励进行强化学习，并采用 Group Relative Policy Optimization（GRPO）。数学与代码等可验证任务优先使用规则、编译器和测试用例，开放式任务则依赖模型型 Reward Model。

R1 蒸馏提升了数学和代码能力，但报告的消融也显示回答长度明显增加。这说明“蒸馏推理能力”不仅改变正确率，也会改变模型的输出分布和服务成本。

10. 训练成本应该怎样理解#

报告给出的正式训练成本为：

预训练每 1T token 约消耗 180K H800 GPU hours。按 2048 张 H800 计算，14.8T token 的正式预训练不到两个月。

但“557.6 万美元训练出 DeepSeek-V3”是一个有严格边界的说法。报告明确指出，该数字只包括 DeepSeek-V3 的正式训练，不包括：

• 前置架构研究；
• 数据清洗和数据实验；
• 消融实验与失败尝试；
• 人员、集群建设和运维；
• 推理服务与后续迭代。

此外，2 美元/H800 GPU hour 是报告用于统一估算的租赁价格，不是其集群的完整财务成本。这个数字最适合衡量最终训练 run 的计算效率，不适合作为整个项目研发投入。

11. 如何阅读报告中的评测结果#

报告中的 DeepSeek-V3 chat 模型部分结果如下：

这些分数需要和三个限定条件一起看：

1. 对比对象是报告发布时的 GPT-4o-0513、Claude-3.5-Sonnet-1022、Qwen2.5-72B 等版本；
2. 结果来自作者评测框架，Table 6 将模型最大输出限制为 8K，并对小于 1000 样本的基准使用多次不同 temperature 评测；
3. 这里混合了 EM、Pass@1、percentile 和 resolved rate，不应该横向比较数字大小。

因此，这张表适合回答“DeepSeek-V3 在 2024 年末处于什么能力位置”，不适合作为 2026 年的实时排行榜。它也不能单独证明某项架构改动贡献了多少能力；判断 MLA、MTP 或负载均衡的独立作用，应优先看报告中的消融实验。

12. 把六项技术连起来看#

DeepSeek-V3 最值得学习的不是六个关键词，而是它们之间的因果关系：

可以看到，每个优化都会制造一个新的约束，而下一层设计正是在解决这个约束。DeepSeek-V3 的效率不是“MoE 参数稀疏”自然带来的，而是路由、并行、精度、kernel 和部署共同完成的。

13. 报告没有证明什么#

读技术报告时，还需要保留几条边界：

• 37B activated 不等于 37B 部署成本。 671B 权重和专家通信仍然存在。
• auxiliary-loss-free 不等于完全没有辅助 loss。 还有很小的 sequence-wise balance loss。
• FP8 误差低于 0.25% 不等于完整 671B BF16 对照实验。 该结论来自两个较小验证模型。
• 1.8 倍 TPS 不是 MTP 的通用保证。 接受率、batch、kernel 和验证开销都会影响结果。
• 557.6 万美元不是项目总投入。 它只覆盖正式训练，并采用假设的 GPU 小时单价。
• 128K 窗口不等于所有长上下文任务都可靠。 NIAH 只能覆盖长上下文能力的一部分。

这些限定不会削弱报告价值，反而能帮助我们判断哪些结论可以迁移到自己的系统，哪些依赖 DeepSeek 的特定集群与实现。

14. 推荐阅读顺序#

如果只想抓住最有价值的部分，可以按下面顺序读原报告：

1. 2.1.2 DeepSeekMoE：理解 bias 如何把路由选择与门控权重分开；
2. 3.2 Training Framework：看 DualPipe、All-to-All kernel 和内存优化如何配合；
3. 3.3 FP8 Training：重点看细粒度量化与高精度累加，而不只是精度名称；
4. 4.2 Hyper-Parameters：核对模型、路由、MTP 和训练配置；
5. 3.4 Inference and Deployment：理解训练期均衡为什么不能替代线上冗余专家；
6. Appendix B/C：查看 FP8 和负载均衡的消融边界。

最后再回到全文，可以得到一个比“671B MoE 很便宜”更准确的结论：

DeepSeek-V3 的关键贡献，是让大规模稀疏模型的容量优势、训练稳定性、通信效率和线上可部署性形成了一套闭环。