简介：《DeepSeek-V3技术报告》是DeepSeek-AI团队发布的671B参数混合专家（MoE）语言模型官方技术文献，适合大模型研究者、AI工程师及对前沿架构感兴趣的开发者阅读。报告系统解析了多头潜在注意力（MLA）、DeepSeekMoE架构、无辅助损失负载平衡策略与多token预测训练目标，并详述了基于148万亿token的预训练、监督微调与强化学习完整流程。工程层面重点介绍FP8混合精度训练、DualPipe计算-通信重叠、低精度存储与通信优化，以及通信和计算硬件设计建议；同时给出模型在MMLU-Pro、GPQA、MATH、AIME等基准上的横向对比，并展示训练过程仅用2.788M H800 GPU小时且无不可逆损失峰值。该PDF共1个文件，压缩包大小5.44MB，CSDN已有157人学习下载。报告还包含多标记预测、无辅助损失和负载平衡策略的消融研究，为后续大规模MoE开发提供扎实参考。

1. DeepSeek-V3 技术报告：一张 557 万美元训练账单背后的架构决策

DeepSeek-V3 技术报告讲的是一个总参数 671B 的混合专家（MoE）语言模型，每次推理只激活其中 37B 参数。真正让人意外的不是这个规模，而是它的完整训练只花了 2.788M H800 GPU 小时，按每卡每小时 2 美元折算，全部成本不到 560 万美元。这在动辄千万美元训练账单的大模型圈子里几乎是另一个数量级。这份资源是 PDF 技术报告，不是模型权重包，也不含可直接运行的代码仓库，它把 MLA 多头潜在注意力、DeepSeekMoE、FP8 混合精度、DualPipe 管道并行一整套训练系统的设计逻辑摊开讲清楚了。适合想自己训 MoE、做推理部署优化、或者评估怎么把训练成本打下来的工程师。读完你至少能回答三个问题：负载均衡能不能不靠辅助损失？FP8 为什么敢用在 600B 以上规模？跨节点通信怎么做到接近零开销？

2. 架构三段式拆解：MLA、DeepSeekMoE 与 MTP 各自省掉了什么

2.1 MLA：把 KV 缓存从“每层全量”压成“一份潜在向量加一份解耦键”

标准多头注意力（MHA）在生成阶段要缓存每一层的 K 和 V，序列一长，显存占用随层数乘头数线性上涨。MLA 的思路是对 K、V 做低秩联合压缩：先通过下投影矩阵把 K、V 压到一个低维潜在向量 c 上，注意力计算前再上投影还原。这里的关键点是，RoPE 位置信息不能跟着一起压缩，否则位置编码会糊掉，所以单独留一份解耦键 k^R 承载 RoPE 信息。最终推理时只需要缓存 c 和 k^R，KV 缓存量大幅下降。

对训练来说，查询侧也做了同样的低秩压缩，目的是减少前向传播时的激活内存。压缩后的查询会拆成普通部分和带 RoPE 的解耦部分，拼接后再参与注意力计算。V3 沿用 MLA 而不是换成 GQA，是因为这套压缩机制在 V2 里已经被验证过：压缩没有带来可感知的性能损失，报告里 MMLU 88.5 的成绩就是在这个前提下拿到的。下表是三种注意力机制在缓存量级上的对比。

注意这张表只做量级对比，真正的工程实现还要考虑位置编码分块、中间变量对齐等因素。MLA 省显存不是免费的，代价是多了一次下投影和上投影计算，但相比省下来的显存带宽，这点计算开销在长上下文场景下完全值得。

2.2 DeepSeekMoE 与无辅助损失：bias 只在路由时生效，门控值始终干净

DeepSeekMoE 把 FFN 拆成共享专家加一组细粒度路由专家，每个 token 按 TopK 选出要激活的专家。V3 相比 V2 的一个改动是门控亲和力用 sigmoid 计算，选中的分数再做归一化，而不是直接用 softmax。另一个更重要的改动是引入了无辅助损失的负载均衡策略。

传统 MoE 通常会加一个辅助损失来鼓励专家负载均匀，但辅助损失的本质是往损失函数里塞了一个与任务无关的约束项，权重调大了损伤模型能力，调小了又不解决问题。V3 的做法是给每个专家挂一个 bias 项，路由决策时看的是“亲和力分数 + bias”的 TopK，但最终和 FFN 输出相乘的门控值仍然来自原始亲和力分数。训练过程中实时监控整批专家的负载，过载就减小 bias，欠载就增大 bias。

# 无辅助损失负载均衡：每个训练 step 结束后更新一次 bias for i in range(num_experts): avg_load = batch_expert_load[i] / batch_total_tokens if avg_load > target_load: bias[i] -= gamma # 该专家过载，降低被选概率 elif avg_load < target_load: bias[i] += gamma # 该专家欠载，提高被选概率

逻辑说明：bias 只参与路由选择，不参与门控值计算，所以它永远不会直接污染模型输出。gamma 是偏置更新速度超参数，调太大负载会来回震荡，调太小负载均衡收敛很慢，我一般从 0.01 起步，观察训练早期专家利用率曲线再微调。

报告同时保留了两个辅助约束：一个是序列级平衡损失，系数设得极小，用来防止单条序列内部的极端不平衡；另一个是节点限制路由，每个 token 最多分发到 M 个节点，用分布在各节点上的专家亲和力得分总和来选节点。这套组合拳保证了训练全程不丢 token，推理侧也有专门的部署策略做负载均衡，所以推理同样不丢 token。

2.3 MTP：顺序预测多个未来 token，训练信号密度更高，推理时直接丢弃

MTP 不是用 N 个独立输出头并行预测，而是用 D 个顺序模块逐个预测未来 token。第 k 个 MTP 模块的输入来自上一层表示和未来 token 嵌入的拼接，经过 RMSNorm 后过一个线性投影矩阵，再接一个 Transformer 块，最后用共享输出头算概率。这样每个预测深度都保持了完整的因果链——后一个深度能看到前一个深度算出来的表示，和 EAGLE 的思路类似，但 V3 做 MTP 的主要目的是增强训练信号，推测解码只是附带收益。

训练时，所有 MTP 深度的交叉熵损失取平均再乘一个权重系数，叠加到主模型损失上。推理时直接丢掉 MTP 模块，主模型独立正常运行。如果想做加速，可以把 MTP 模块复用成推测解码的草稿模型，用低开销的草稿预测配合主模型验证，减少串行生成步数。

到这里可以把三个架构选型放到一起看，它们各自解决一个维度的问题。

这套组合的逻辑是：MoE 负责控制计算量，MLA 负责控制显存，MTP 负责用好省下来的计算预算。三者是配套设计的，单独抄某一个不一定有效果。

3. 训练效率从哪来：FP8 精度分配、DualPipe 调度与跨节点通信

3.1 FP8 混合精度：主权重保住高精度，计算和存储走低精度

V3 在 2048 张 H800 GPU 上完成预训练，每万亿 token 只花 180K GPU 小时，折合 3.7 天。这个效率指标背后最重的一笔是 FP8 混合精度训练。注意“混合”两个字——不是整个训练流程全部塞进 FP8，那样数值稳定性很快会崩。实际的精度分配是分角色处理的。

FP8 训练的主要风险是数值溢出和舍入误差累积。报告用的是块级量化策略，按小 tile 计算缩放因子，把数据拉回 FP8 可表达的范围内，再配合在线累加来提升矩阵乘的精度。附录里的消融实验对比了 FP8 和 BF16 两种训练方式，结论是基准表现基本持平——这一步消融是整份报告里我建议反复读的部分，因为它给出了 FP8 敢用在 600B 以上规模模型的底气。

如果你在自己的小实验里想尝试 FP8，第一原则是不要全套照搬。先把矩阵乘输入换成 FP8，主权重保持 BF16，观察训练 loss 曲线是否和 BF16 基线一致。任何偏离都要先怀疑缩放因子策略是不是没对齐，而不是急着加大模型。

3.2 DualPipe：双向管道调度，把通信藏在反向计算里

跨节点 MoE 训练最大的问题是通信量：每个 token 要经过 all-to-all 发送到目标专家所在节点，再把结果合并回来。在 V3 的配置下，计算和通信的比率接近 1:1，如果不做重叠，GPU 大约有一半时间在空等。DualPipe 的存在就是为了把这些通信时间藏进计算里。

DualPipe 的核心做法是把每个 Transformer 块拆成四个部分：attention、all-to-all dispatch、MLP、all-to-all combine，反向块再把输入梯度和权重梯度分开。调度时从前向块和反向块成对取，手动调整专用于通信和计算的 SM 比例，让 dispatch 和 combine 与另一个块的计算同时执行。同时管道从两端同时输入微批次，管道气泡明显小于传统 1F1B。

# 伪代码：DualPipe 成对重叠的工作流 for fwd_block, bwd_block in paired_blocks: launch_all_to_all(fwd_block.dispatch) # 先发起通信 run_compute(bwd_block.input_grad) # 同时算反向输入梯度 wait_all_to_all(fwd_block.dispatch) run_compute(fwd_block.attention) # 通信完成后继续前向 # 反向的权重梯度计算与下一个前向块的通信继续重叠

逻辑说明：通信被提前发起，计算穿插在等待数据的周期里。通信数据到达时计算也刚好结束，下一次通信又能立刻启动，形成流水线。V3 实际配置是 16 路管道并行、64 路专家并行跨 8 个节点，配 ZeRO-1 数据并行，不使用张量并行。三种管道并行方案的对比做了一个简表。

表里的 F 是前向块执行时间，B 是完整反向块时间，W 是权重梯度反向时间。DualPipe 需要保留两份模型参数副本，但因为 EP 规模大，分摊到每个设备上的额外消耗并不明显。

3.3 跨节点通信与内存优化：IB 和 NVLink 分工，重计算换显存

集群网络环境里，节点间走 InfiniBand，带宽约 50GB/s，节点内 NVLink 提供 160GB/s，两者差约 3.2 倍。如果所有跨节点通信都走 IB，IB 会成为瓶颈。如果指望 NVLink 直连远端节点，物理上又够不到。V3 的解法是混合接力：每个 token 限制最多分发到 4 个节点，先通过 IB 传到目标节点上具有相同节点内索引的 GPU，到达目标节点后立刻通过 NVLink 转发到真正存放目标专家的 GPU。IB 传输和 NVLink 转发并行执行，一个 token 平均能覆盖 3.2 个专家/节点，实际选 8 个路由专家，但理论上可以扩展到 13 个专家，通信成本不变。

通信内核用 warp 专门化技术，静态划分 20 个 SM 组成 10 个通信通道，每个通道里的 warp 分别处理 IB 发送、IB 到 NVLink 转发、NVLink 接收三种任务。合并阶段反过来处理。调度和合并内核与计算流重叠，报告里提到用定制 PTX 指令和自动调优通信块大小来减少对 L2 缓存和其他 SM 的干扰。如果你要自己实现类似的通信内核，建议先抓两个指标：通信 SM 占比和 L2 缓存命中率。

内存优化还有三招值得抄。第一，RMSNorm 和 MLA 上投影在反向传播时重新计算，前向时不存输出激活，用少量计算换大量显存。第二，EMA 模型参数放在 CPU 内存里异步更新，每个训练 step 结束后更新一次，不占用 GPU 显存也不拖慢训练节奏。第三，MTP 模块的嵌入层和输出头与主模型物理共享——通过 DualPipe 把最浅层和最深层放在同一个管道等级上，参数和梯度都物理复用。这些措施叠加后，V3 能训练 671B 参数而不使用张量并行，省掉的显存和通信开销非常可观。

4. 避坑：读懂报告到动手复现，四个最容易翻车的理解误区

4.1 把 671B 当成推理时的实际计算量

现象：用 671B 参数去估算推理算力，得出单卡根本跑不动的结论，进而怀疑报告里的成本数字在吹牛。

原因：MoE 的总参数和激活参数是两回事。671B 是所有专家的参数总和，但每个 token 只激活 37B 参数，前向计算量由 37B 决定，671B 主要体现在存储和显存占用上。

解决：计算推理吞吐时，先用激活参数 37B 乘序列长度得到计算量；评估显存容量时，再按全部专家权重考虑。报告的部署策略里，预填充和解码也是分离优化的，不能简单套用稠密模型那套显存估算方式。

4.2 以为“无辅助损失”等于彻底不要负载均衡

现象：照抄“无辅助损失”的思路，在自己的小 MoE 上把所有负载均衡损失全部关掉，训练一段时间后部分专家完全闲置，利用率分布极差。

原因：报告的无辅助损失策略是用 bias 动态路由替代主辅助损失，但并没有取消负载均衡这个目标。序列级平衡损失仍然保留，只是系数设得极小；节点限制路由也在持续约束通信路径。推理侧还有专门的部署策略来保证不丢 token。

解决：小规模复现时保留轻量序列级平衡损失，同时监控每个专家在 batch 内的 token 占比。把 bias 更新速度 gamma 当成超参来调，而不是直接删掉整个均衡机制。

4.3 FP8 全套照搬，训练 loss 周期性尖峰

现象：把权重、激活、梯度全部转成 FP8，训练前期 loss 正常，后期开始出现周期性尖峰，回滚一次恢复正常但随后又出现。

原因：报告里的 FP8 是混合精度框架，主权重和优化器状态并没有用低精度。缩放因子按块级计算，全局统一缩放在大数值跨度下会溢出。梯度也只在通信前降精度，计算过程中仍然保留了高精度累加。

解决：先只量化矩阵乘的输入，主权重保持 BF16。调试时单独输出每一层的缩放因子分布，观察哪些层数值动态范围大，对这类层单独提高精度或加大缩放粒度，不要一上来就全套强制 FP8。

4.4 看到 MTP 能推测解码，就在推理时挂满所有模块

现象：听说 MTP 模块可以复用为推测解码加速，直接把全部 D 个 MTP 模块都挂上参与推理，结果生成延迟反而更高。

原因：MTP 的主要设计目的是增加训练信号密度，推测解码只是它的复用场景之一。推理时主模型完全可以独立运行，MTP 模块默认是丢掉的。推测解码的加速效果取决于草稿接受率，多挂模块等于多算好几个 Transformer 块，收益为负并不意外。

解决：做推理加速实验时，把 MTP 模块当成草稿模型单独评测，先在小 batch 上对比裸解码和开启推测解码后的延迟。接受率受数据分布影响很大，代码类任务和对话类任务要分别测，不要用一个 Benchmark 结论推广到所有场景。

5. 从 14.8T token 到 128K 上下文：预训练、两阶段扩展与 R1 蒸馏后训练

5.1 数据构建与成本基准：14.8T token 是数量，质量分布决定上限

V3 在 14.8T 高质量、多样化的 token 上完成预训练。对 MoE 来说，数据分布直接影响专家利用率。如果某一个领域的数据占比过少，对应专家长期欠载，bias 会不断上调，这会间接影响其他 token 的路由选择。报告的第 4.2 节并没有给出完整的超参数表，很多训练细节直接沿用 V2 的设置，想要精确的 learning rate 和 batch size 需要去开源仓库里翻配置。这本身就是一个值得记住的坑：技术报告不等于复现手册，超参细节在代码仓库里。

成本表是这份报告最有工程参考价值的部分，按 H800 每卡每小时 2 美元折算如下。

写硬件预算方案时，这个表可以直接作为对标基准：每万亿 token 约 180K H800 GPU 小时，2048 卡集群下大约 3.7 天完成一万亿 token。但要注意这个数字是在全优化训练框架下拿到的，集群拓扑、通信带宽、框架实现都会影响实际数值，照搬到自己的环境里只能作为下界参考。

5.2 两阶段上下文扩展：32K 到 128K，不是一步到位

上下文长度扩展分两阶段：第一阶段把最大长度扩展到 32K，第二阶段继续扩展到 128K。两阶段设计的原因很直接：直接从短序列跳到 128K 的训练成本太高，而且模型在长序列上的收敛不稳定。先在 32K 上让模型稳定适应位置编码和注意力模式的改变，再在 128K 上精调，每一步都更容易控制。报告没有明确说用的是哪种长度外推插值方法，但常见做法是 RoPE 相关的插值或外推算法配合增量式训练。

复现时的建议是拆成更多段：32K 先训练几百个 step，验证困惑度是否持续下降，再各花几百 step 做 64K 和 128K 扩展。如果 32K 阶段困惑度就出现回升或者平台期，延长训练量或调整插值参数，不要强行往下一段推进。长上下文扩展的评估也要单独做，不能只看短序列上的指标，要构造长程依赖的样本测记忆准确率。

5.3 后训练：SFT、GRPO 强化学习和 R1 蒸馏

SFT 阶段混合了两类数据：通用 SFT 数据和从 DeepSeek-R1 蒸馏出来的推理数据。蒸馏不是简单拿 R1 的输出当标准答案硬灌，而是把 R1 那种“先验证、再反思、带修正”的推理模式迁移到 V3 上，同时还要控制输出风格和长度，避免生成结果变成没有结构的冗长思考流。

RL 阶段用的是 GRPO，群体相对策略优化。相比传统 PPO，GRPO 不依赖单独的大规模价值模型，而是从同一组采样输出的相对表现里估计基线，这对训练显存的节省很可观，因为少了一个 critic 模型的负担。奖励模型也不是单一的打分器，报告把正确性、格式、长度拆开分别建模，并且还验证了让 V3 自己作为生成奖励模型给其他模型输出打分——这意味着 RL pipeline 里的奖励模型环节也可以被主模型自己替代。

后训练阶段的评估结果，报告里的公开数字如下。

这三个分数放在开源模型里都是第一梯队。更值得注意的是训练这个模型只用了 5K GPU 小时，说明后训练阶段只要方法对，成本可以压得非常低。如果你在规划小规模模型的训练预算，后训练这段是最容易先落地的部分。

6. 进阶：把报告改写成自己小规模实验的三个杠杆

6.1 杠杆一：MTP 当免费训练信号增强

在自己训练的 MoE 或稠密模型上挂一个 MTP 模块，共享嵌入层和输出头，增加的主要是轻量 Transformer 块和投影矩阵。训练时 MTP 损失乘上一个小权重叠到主损失上，等训练中期再关闭 MTP 只评估主模型的 loss。这里的重点是 MTP 的块深度不要和主模型完全对齐，报告保留了完整因果链但用了独立的轻量块。如果在验证集上主模型困惑度没有下降，先检查 MTP 损失是否已经收敛，很多情况是权重系数太小导致 MTP 模块根本没学到东西。

6.2 杠杆二：bias 负载均衡十行代码就能落地

把第 2 章的伪代码写进训练循环，需要记录每个专家在当前 batch 内处理的 token 数，算出 target_load 后按偏差更新 bias。关键设计是 bias 不参与门控值计算，所以可以随时关闭不会污染模型权重——这比辅助损失安全得多。我一般先在 8 专家的小 MoE 上跑通，观察专家利用率从乱序收敛到均匀需要多少 step，再把 gamma 调到合适范围。

6.3 杠杆三：用成本表倒推自己的算力预算

写实验方案时把“每万亿 token 180K H800 GPU 小时”作为基准，用自己的集群算力按比例折算。先跑一个 100B token 的小规模验证，观察 loss 曲线趋势，再线性外推到完整数据量。不要直接拿报告的训练曲线做参照，因为数据分布和框架效率差得远，但成本表做预算答辩足够有说服力。

我记得第一次照着类似的报告复现时，把无辅助损失理解成“去掉所有平衡”，结果一个专家吃掉了 60% 的 token，训练曲线震荡到怀疑人生。从那以后我每次读技术报告都会先列一张“它到底在哪个环节省了什么”的清单，再动手写代码。这份 DeepSeek-V3 技术报告保留了大量公式推导、消融实验和成本数据，下载一份放着，写训练方案或者做技术评审时能直接引用。希望帮到你。

本文还有配套的精品资源，点击获取