简介《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.44MBCSDN已有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^RKV 缓存量大幅下降。对训练来说查询侧也做了同样的低秩压缩目的是减少前向传播时的激活内存。压缩后的查询会拆成普通部分和带 RoPE 的解耦部分拼接后再参与注意力计算。V3 沿用 MLA 而不是换成 GQA是因为这套压缩机制在 V2 里已经被验证过压缩没有带来可感知的性能损失报告里 MMLU 88.5 的成绩就是在这个前提下拿到的。下表是三种注意力机制在缓存量级上的对比。方案每层每 token 缓存内容缓存量级MHA完整 K、V维度为 d × n_h随头数线性增长GQA所有头共享 K、V单份 K/V但仍需缓存全维度MLAc 潜在向量 解耦键 k^R压到 d_c 解耦维远小于前两者注意这张表只做量级对比真正的工程实现还要考虑位置编码分块、中间变量对齐等因素。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 模块复用成推测解码的草稿模型用低开销的草稿预测配合主模型验证减少串行生成步数。到这里可以把三个架构选型放到一起看它们各自解决一个维度的问题。模块主要收益代价MLA省推理 KV 缓存和训练激活内存多一层压缩投影计算DeepSeekMoE总参 671B 但每个 token 只算 37B引入跨节点通信和负载均衡问题MTP训练信号更密可复用为推测解码训练时多 D 个轻量 Transformer 块这套组合的逻辑是MoE 负责控制计算量MLA 负责控制显存MTP 负责用好省下来的计算预算。三者是配套设计的单独抄某一个不一定有效果。3. 训练效率从哪来FP8 精度分配、DualPipe 调度与跨节点通信3.1 FP8 混合精度主权重保住高精度计算和存储走低精度V3 在 2048 张 H800 GPU 上完成预训练每万亿 token 只花 180K GPU 小时折合 3.7 天。这个效率指标背后最重的一笔是 FP8 混合精度训练。注意“混合”两个字——不是整个训练流程全部塞进 FP8那样数值稳定性很快会崩。实际的精度分配是分角色处理的。张量类型精度理由主权重BF16保证每步参数更新精度优化器状态更高精度梯度的均值和方差统计需要稳定前向激活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 数据并行不使用张量并行。三种管道并行方案的对比做了一个简表。方法管道气泡激活内存约束条件1F1B(PP-1)(FB)1×PP实现直接气泡大ZB1P较小1×PP需要对权重梯度做额外切分DualPipe最小2×PP1要求 PP 和微批次数可被 2 整除表里的 F 是前向块执行时间B 是完整反向块时间W 是权重梯度反向时间。DualPipe 需要保留两份模型参数副本但因为 EP 规模大分摊到每个设备上的额外消耗并不明显。3.3 跨节点通信与内存优化IB 和 NVLink 分工重计算换显存集群网络环境里节点间走 InfiniBand带宽约 50GB/s节点内 NVLink 提供 160GB/s两者差约 3.2 倍。如果所有跨节点通信都走 IBIB 会成为瓶颈。如果指望 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 美元折算如下。训练阶段GPU 小时折算成本预训练2,664K$5.328M上下文扩展119K$0.238M后训练5K$0.01M合计2,788K$5.576M写硬件预算方案时这个表可以直接作为对标基准每万亿 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群体相对策略优化。相比传统 PPOGRPO 不依赖单独的大规模价值模型而是从同一组采样输出的相对表现里估计基线这对训练显存的节省很可观因为少了一个 critic 模型的负担。奖励模型也不是单一的打分器报告把正确性、格式、长度拆开分别建模并且还验证了让 V3 自己作为生成奖励模型给其他模型输出打分——这意味着 RL pipeline 里的奖励模型环节也可以被主模型自己替代。后训练阶段的评估结果报告里的公开数字如下。基准得分说明MMLU88.5多领域知识问答MMLU-Pro75.9更具挑战性的知识问答GPQA-Diamond59.1研究生级别科学问答这三个分数放在开源模型里都是第一梯队。更值得注意的是训练这个模型只用了 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 技术报告保留了大量公式推导、消融实验和成本数据下载一份放着写训练方案或者做技术评审时能直接引用。希望帮到你。本文还有配套的精品资源点击获取