1. 万亿参数llm训练的挑战2. 内存与算力约束3. 数据并行与通信优化4. ZeRO零冗余优化器5. 梯度检查点6. FlashAttention7. Ring Attention8. 混合专家模型MoE9. 并行策略组合10. 集群故障恢复机制11. 完整训练系统架构12. 趋势与训练成本估算1. 万亿参数LLM训练训练2万亿参数的大语言模型面临三大核心限制限制类型具体挑战内存限制模型状态占用32TB单块H100仅80GB需要400块GPU通信瓶颈网络速度比服务器内部连接慢约18倍算力需求需要4.8×10²⁶次浮点运算需上万台芯片并行运行数月关键约束数值精度权衡比特数越少计算越快、内存越少但比特数过少会导致梯度超出数值范围或被四舍五入为0训练无法收敛故障频率在长达数月的持续运行中几乎每隔几小时就会出现某处故障2. 内存与算力约束模型状态的内存占用每个参数在内存中占据5份存储项总计16字节工作副本(2B)梯度(2B)Adam优化器状态高精度备份(4B)Adam优化器状态梯度滑动均值(4B)Adam优化器状态梯度方差(4B)总容量2万亿参数 × 16字节 **32TB**H100显存80GB/块仅存储模型状态需要400块H1002.2 激活值的内存占用激活值是前向传播时在层与层之间流动的数值缓存这些激活值是因为反向传播时需要读取它们来计算梯度。激活值占用量随批量大小和序列长度增长与参数数量无关序列长度为4096的单个训练样本产生642GB激活值批量大小为32时激活值占用量提升到20TB与模型状态大小相当2.3 算力需求单次训练总浮点运算量 参数量 × token数 × 6 其中6 前向传播2次 反向传播4次2万亿参数模型约需4.8×10²⁶次浮点运算单块H100发挥峰值50%性能需要30700年16384块GPU并行计算仍需将近两年3. 数据并行与通信优化3.1 数据并行基础将模型复制到每块GPU上把批次拆分成N个分片每块GPU独立处理自己的分片3.2 环形全归约Ring All-Reduce问题反向传播完成后每块GPU上的梯度不同需要对梯度取平均值。如果把所有数据传到一台机器上处理会产生瓶颈。解决环形全归约将过程拆分为两个阶段阶段一规约分发Reduce-Scatter将N块GPU在逻辑上排列成一个环形将每个梯度张量拆分成N个块每一步中每块GPU处理不同的梯度块所有GPU同时发送和接收数据没有链路空闲执行步骤每块GPU向右发送一个梯度块同时累加从左侧收到的梯度块重复N次后每块GPU持有一个完成规约的梯度块但每块GPU持有的梯度块各不相同阶段二全收集All-Gather梯度块在环中传递最终每块GPU都会拿到全部N个梯度块即完整的平均梯度。通信量分析每块GPU总通信量 2 × (N-1) / N × 梯度总大小 当N增大时该值趋近于 2 × 梯度总大小特点带宽最优方案通信量与GPU数量无关优化每层的全归约操作可与更早层的反向传播计算重叠执行通信过程被GPU本来就要完成的计算掩盖3.3 LAMB优化器数据并行可以让批次大小随GPU数量增加而扩大。但当GPU数量达到16000块时批次会达到临界批次大小额外的样本无法再提升梯度估计精度大幅更新反而会导致优化过程偏离最优方向LAMB优化器Layer-wise Adaptive Mixed Batch optimizer能将LLaMA的训练批次大小提升到32868把原本需要3天的训练时间压缩到76分钟但一旦超过临界批次大小即使将批次翻倍能节省的梯度更新步数也不到一半4. ZeRO零冗余优化器数据并行中每块GPU都会存储一份完整的模型副本32TB。ZeRO的答案是拆分状态到不同GPU上存储每块GPU只保留自己负责的那部分需要时再调取。4.2 三级分片策略第一阶段优化器状态分片ZeRO-1拆分Adam优化器状态占比最大16字节中有12字节是优化器状态大规模场景下单GPU内存占用降到原来的1/4通信量完全不增加数据并行本身就要执行的全归约操作可零额外成本完成拆分后状态的更新第二阶段梯度分片ZeRO-2在ZeRO-1基础上进一步拆分梯度大规模场景下总内存占用降到原来的1/8仍无额外通信量零额外成本第三阶段参数分片ZeRO-3拆分模型参数本身需要付出通信代价示例2048块GPU训练2万亿参数模型 - 单块GPU仅需存储 16GB 数据 - 远低于H100的80GB显存上限 工作流程 1. 运行任意层之前所有GPU需要收集该层的权重 2. 临时拼凑出一份完整副本 3. 完成该层的计算后丢弃临时副本 通信量 基准的 1.5 倍全程没有任何一块GPU持有完整模型ZeRO效果总结阶段分片内容内存占用额外通信量ZeRO-1优化器状态1/4无ZeRO-2梯度1/8无ZeRO-3参数显著降低1.5倍基准5. 梯度检查点技术问题激活值缓存的层输出大小与模型状态相当当批次大小为32时可达20TB目前还没有被优化。解决梯度检查点Gradient Checkpointing / Activation Checkpointing前向传播过程中大部分激活值被丢弃反向传播时从保存的检查点重新计算激活值代价计算量约增加33%5.2 不同激活值的重计算成本差异高重计算成本、低内存占用线性层的输入重新生成需要重新运行计算量很大的矩阵乘法内存占用小但重计算成本高低重计算成本、高内存占用注意力内部状态、softmax输出、dropout掩码形成序列长度的矩阵大小随序列长度的平方增长但重新计算成本很低只需一次小型矩阵乘法 一次softmax运算占整个层计算量的比例非常小5.3 选择性检查点策略Selective Checkpointing策略保留体积小但重计算成本高的线性层输入丢弃体积大但重计算成本低的内容即注意力内部状态效果指标全重计算选择性检查点激活值内存占用11/5浮点运算量增加33%2.7%模型浮点运算利用率MFU42.1%54.2%6. FlashAttention6.1 标准自注意力的内存问题标准自注意力机制会构建完整的N×N注意力矩阵N为序列长度序列长度每个注意力头矩阵条目数40961600万131K170亿这些矩阵存储在GPU的高带宽内存HBM中H100的HBM带宽约3TB/s芯片上的SM流多处理器速度约是HBM的100倍但容量只有192MB6.2 FlashAttention解决方案将注意力计算切分成足够小的块刚好可以放入SRAM中处理。关键分块Softmax处理每个块时持续追踪当前的最大值和累计分母如果下一个块的最大值更大先给之前的部分合成一个校正因子再加上新的项校正因子 e^(旧最大值 - 新最大值)因为Softmax本身就是基于指数运算的分块计算能保持数值完全精确优势指标标准注意力FlashAttention内存复杂度O(N²)O(N)运行速度基准提升2~4倍浮点运算量不变不变是否生成完整注意力矩阵是否影响由于FlashAttention围绕内存带宽优化它已经是长序列训练的默认方案让上下文并行具备了实用性7. 张量并行与序列并行7.1 张量并行Tensor ParallelismTP问题ZeRO解决了存储问题没有GPU需要保存完整模型但每一次独立的矩阵乘法仍然在单个GPU上运行。方案拆分矩阵乘法本身每个GPU负责矩阵乘法的一部分运算最后把所有结果拼接起来通信模式拼接是阻塞式的通信传递所有GPU必须等待通信完成才能继续后续运算每层需要进行4次这样的通信每层都如此场景张量并行只能在集群中速度最快的链路上运行连接类型带宽相对速度NVLink节点内8卡900GB/s基准InfiniBand跨节点50GB/s慢18倍因此TP度严格设为8对应单台服务器不需要用到慢链路7.2 注意力模块的张量并行注意力模块本身已经是多个独立的注意力头并行运行的结构实现方式 1. 有N块GPU每块负责一部分注意力头 2. 运算之后只需要一次通信就能把结果合并 通信次数 - 前向传播2次通信 - 反向传播2次通信 - 全部是阻塞式的7.3 矩阵切分技巧技巧将第一个矩阵按纵向切分第二个矩阵按横向切分切分后矩阵的衔接处刚好对齐。工作流程每个GPU完成第一部分乘法后得到的中间结果恰好就是它执行第二部分乘法时需要的输入片段中间过程不需要在GPU之间传输任何数据只在最后进行一次通信把各部分结果汇总7.4 序列并行Sequence ParallelismSP问题拼接完成后每个GPU上都有完全相同的完整输出。接下来的运算归一化、残差连接等都是逐token的对每个token的特征做归一化偶尔会将某个token的特征屏蔽再把原始输入加回去这些运算不会在不同token之间交换信息每个GPU都在对相同的数据做相同的运算完全是重复劳动。解决沿token维度拆分这些运算每个GPU只负责自己分到的那部分token的运算效果GPU之间传输的总数据量保持不变只是在主token运算前后分别做一次分发和收集激活值的内存占用降低T倍T为张量并行度8. 流水线并行8.1 朴素流水线的问题假设有126层Transformer均匀拆分到16块GPU上每块GPU分到8层。前向传播顺序GPU1(层1-8) → GPU2(层9-16) → … → GPU16(层121-126)问题GPU1计算时GPU2到16都处于闲置状态等待输入任意时刻只有1块GPU在工作剩下15块都在等待这些总闲置时间叫做流水线气泡8.2 微批次Micro-batch调度解决方案把输入批次拆分成更小的微批次示例GPU1处理完Micro-batch 1后就可以开始处理Micro-batch 2同时GPU2开始处理Micro-batch 1多块GPU并行处理不同的数据气泡占比公式气泡占比 (P - 1) / (M P - 1) 其中 - P 流水线阶段数 - M 正在处理的微批次数量计算示例16个阶段气泡占比降到1%以下需要多少微批次0.01 (16 - 1) / (M 16 - 1) M ≈ 1500 → 需要约1600个微批次内存根本放不下这么多微批次8.3 1F1B调度One Forward One Backward1F1B 一次前项 一次反向阶段划分预热阶段执行若干前向传播稳定阶段交替执行前向和反向优势反向传播一旦开始就会消耗激活值用完就可以释放对应内存只需要保留P个正在处理的微批次而不是M个气泡占比不变但内存占用大幅降低8.4 交错调度Interleaved Scheduling改进把每块GPU负责的层块拆成更小的部分示例 原本GPU1负责层1-8、GPU2负责层9-16... 改进GPU1负责层1、第33层、第65层、第97层 GPU2负责层9、第41层、第73层... 这些层分散在整个模型的不同位置效果气泡缩小到原来的1/4代价通信量变成原来的4倍8.5 流水线边界优化LLaMA 3还有一个优化技巧第一块GPU要负责词嵌入查找操作最后一块GPU要负责输出投影计算这两项都是流水线边界阶段的额外工作优化方案首尾2个GPU各负责7层 中间14个GPU各负责8层 总层数 126层 所有GPU都能同时完成计算效果MFU提升6.5%峰值内存占用减少5TB8.6 反向传播拆分1F1B with Zero Bubble核心思想对反向传播本身进行拆分反向传播需要计算两个部分梯度类型说明下游依赖输入梯度前一个阶段马上要用立即需要权重梯度只在步骤结束时才用到无下游依赖解决方案把权重梯度的计算插到流水线气泡的空闲时间段里效果吞吐量提升23%9. 环形注意力Ring Attention问题:FlashAttention可在单块GPU上处理长度为13.1万token的序列100万token的长度已经超出单个设备的承载上限解决方案: **上下文并行**通过环形注意力算法将序列本身拆分到多块GPU上实现步骤将GPU按逻辑环形排列每块GPU存储一部分query tokenKV块沿环形网络流转每次传递到相邻的下一个节点每块GPU用当前持有的KV块计算部分注意力结果然后把KV块传给下一个相邻节点9.3 计算与通信重叠数据传输和计算过程并行重叠当前的KV块还在计算时下一个块就已经送达-经过一轮完整流转后所有query都与所有key完成了计算9.4 最终结果获取Ring Attention会屏蔽每个token对后续token的注意力计算把其余无关部分置零最终得到精确的注意力结果。实际应用: LLaMA 3使用这项技术在128块H100上运行4050亿参数的模型仅用77秒就完成了100万token的预填充10. 混合专家模型MoE10.1 背景目前从未有人训练过2万亿参数的稠密模型但存在以下模型模型参数量架构SwitchTransformer1.6万亿MoE传闻GPT-41.8万亿MoEDeepSeek-V36710亿MoE10.2 MoE基本原理路由模块从更大的专家池中为每个token选出排名前K的专家每个token仅需少量计算可实现极大的模型容量挑战一通信问题每个MoE层触发两次全对全通信All-to-All调度阶段把token发送到对应专家所在的GPU汇总阶段把计算结果返回注意这与All-Reduce不同All-Reduce是把所有贡献汇总成一个共享结果。挑战二负载均衡问题问题如果路由模块偏好少数常用专家这些专家所在的GPU会成为瓶颈其他GPU会闲置。标准解决方案加入辅助损失惩罚不均衡的路由分配SwitchTransformer使用 α 10⁻² 的α值推动路由分配趋向均匀分布问题这种损失会和路由模块学到的偏好产生冲突可能会降低模型质量10.4 DeepSeek-V3偏置路由方案创新方案给每个专家的路由得分添加一个**偏置**调整规则负载不足的专家偏置提高负载过高的专家偏置降低关键偏置只影响哪些专家会被选中不参与门控值的计算门控值用于给选中专家的输出加权因此梯度可以顺畅传递效果在整个14.8万亿token的训练过程中没有用到辅助损失没有出现token丢弃没有出现损失飙升11. 数值精度选择11.1 浮点数结构每个权重是一个浮点数由符号位、尾数、指数组成类似科学技术法组成部分作用指数决定数值范围尾数决定精度11.2 BF16 vs FP16FP1616个比特1符号位 5指数位 10尾数位能表示的最大值上限是**65504**问题训练时梯度经常会超过这个值溢出变成无穷大训练中断解决方案损失缩放损失缩放会在参数更新前用一个常数把梯度缩小再缩放回去如果这个常数超出合适范围训练会发散BF16同样16个比特但重新分配位宽8个指数位 7个尾数位恢复FP32的全部数值范围10⁻³⁸ 到 10³⁸所有梯度都能被容纳不需要损失缩放结论对于训练稳定性数值范围远比精度重要所以BF16是默认选择。11.3 FP8训练进一步减少比特数得到FP8每个权重只占1字节H100 Tensor Core上FP8矩阵乘法速度是BF16的2倍但位宽很紧张总共只能表示256个不同的数值DeepSeek-V3的解决方案逐块缩放技术实现方式权重被拆成128×128的块激活值被拆成1×128的块每个token对应一个块每个块都有独立的缩放因子缩放因子每一步都会更新让FP8的数值窗口匹配当前局部的数值大小关键细节矩阵乘法的部分和用FP32累积舍入误差不会累积效果与全BF16训练的基线相比差距仅在0.25%以内11.4 FP4展望NVIDIA Blackwell架构支持FP4总共只能表示16个数值在这种精度下保持训练稳定仍是待解决的问题早期的小规模测试结果和FP8的表现非常接近12. 并行策略组合实例12.1 并行维度GPU总数量是5个并行维度的乘积总GPU数 TP × PP × CP × EP × DP其中TP 张量并行Tensor ParallelismPP 流水线并行Pipeline ParallelismCP 上下文并行Context ParallelismEP 专家并行Expert ParallelismDP 数据并行Data Parallelism12.2 LLaMA 3 405B配置参数值总参数量4050亿GPU数量16384块H100张量并行度8通过NVLink单节点内通信带宽900GB/s流水线并行度16通过InfiniBand跨节点组通信数据并行度128计算验证8 × 16 × 128 16384✓其他配置单GPU算力400 TFLOPS处理131K token长上下文训练时上下文并行度提升到16数据并行度降到8序列长度支持扩大到原来的16倍12.3 DeepSeek-V3配置参数值总参数量6710亿每token激活参数量370亿专家数量256GPU数量2048块H800流水线并行度16专家并行度64张量并行度0完全不使用为什么DeepSeek-V3不使用张量并行原因H800 NVLink带宽为每秒400GB不到H100的一半900GB/s在关键路径上使用张量并行的通信成本过高DeepSeek-V3的优化流水线调度策略将专家路由与前向反向计算重叠把通信开销隐藏在有效计算过程中12.4 成本对比指标LLaMA 3DeepSeek-V3GPU小时消耗较高278.8万训练成本较高560万美元基准测试表现相当相当GPU小时比值基准约1/11结论两种都是合理的设计选择各自都由团队可用的硬件条件决定。13. 集群故障恢复机制13.1 故障频率统计LLaMA 3 405B在754天的训练过程中共记录419起意外故障约每3小时发生一起故障类型占比GPU和NVLink故障30%HBM显存故障17%网络和软件问题其余13.2 检查点机制LLaMA 3 4050亿参数的完整检查点大小约为6.5TB。多层备份策略备份频率存储位置说明每5分钟内存内存快照每30分钟本地SSD检查点保存每隔几小时远程存储持久化备份13.3 自动恢复流程异常检测 → 暂停任务 → 诊断原因 → 切换热备 → 从检查点恢复恢复流程异常检测会先暂停受影响的任务诊断程序定位故障原因调度器切换到热备用设备从最新的检查点恢复训练效果419起故障中仅有3起需要大量人工干预有效训练时间占比达到90%以上软件也可能出现故障谷歌的PaLM 540B训练过程中出现约20次损失尖峰训练损失突然大幅上升解决方法从尖峰出现前100步的检查点重启训练跳过导致问题的数据批次14. 完整训练系统架构14.1 数据准备训练前置条件磁盘上必须存好40万亿个token来源网页、书籍、代码、数学内容、精选数据经过清洗、去重通过分词器处理后以整数形式存储约160TB大小存储系统支撑3TB/s的训练集群总存储容量240PB总带宽可达2TB/s14.2 数据配比与训练顺序语料组成内容类型占比通用网页内容约50%数学和推理相关内容约25%代码约1/6多语言内容和精选资料其余训练阶段顺序阶段一大部分训练使用8000 token的上下文窗口阶段二长上下文爬坡分6个步骤将上下文窗口扩展到128K token阶段三冷却阶段学习率衰减到零提高高质量数据的采样权重14.3 数据分发策略每块GPU的数据分配按照训练部署和自身编号拉取固定的语料分片不会有2块GPU拿到相同的token中断后恢复运行时生成的批次数据与之前完全一致预取机制CPU侧的预取队列提前准备好接下来要用到的批次数据总带宽需求很小每块GPU只需几千字节每秒真正的问题是长尾延迟只要有一个节点速度变慢下一次集体通信时其他16000个节点都会被卡住14.4 训练步骤的并行执行16000块GPU的并行策略数据并行128个副本每个副本内部128块GPU → 张量并行NVLink带宽900GB/s副本间 → 流水线并行InfiniBand每层使用FlashAttention采用混合专家路由使用混合精度计算反向传播使用零气泡流水线优化器优化器状态拆分存储在各个副本上14.5 控制与监控控制平面集群调度器负责启动所有进程并行网格为每块GPU分配对应的角色位置检查点机制异步每隔几分钟保存状态快照到内存每半小时保存到SSD每隔几小时保存到长期存储健康监控守护进程监控慢节点和故障情况节点故障时编排器切换到热备节点从最新检查点恢复训练连续运行时间约3个月15. 技术趋势15.1 硬件感知代码设计DeepSeek-V3已经证明针对特定硬件调整并行策略可以达到前沿效果在H800带宽更低的NVLink上避免使用张量并行以极低的成本达到高质量效果15.2 NVIDIA GB200 NVL72规格参数 - 72块Blackwell GPU部署在同一机柜 - 通过NVLink互联 - 单GPU带宽1800GB/s - 总GPU内存13.5TB - 总聚合带宽130TB/s 影响 - 此前讨论的所有系统受限于张量并行上限仅为8 - 现在上限提升到72 - 对于参数规模低于万亿的模型机柜内的流水线并行可能不再有必要15.3 Delta等工作节点每个工作节点在自己的数据分片上用本地优化器运行**数百步训练**然后通过外部梯度更新同步参数增量效果通信量减少500倍还能保持训练同步场景数据中心之间的分布式训练示例Nvidia展示 - 场景相距1000千米的两个数据中心之间的训练 - 扩展效率96%这个技术栈里有多项技术在5年前都还不存在等到下一代前沿模型问世时还会有更多技术发生变化再大的努力都比不过一次底层模型的升级qwq16. 训练成本估算计算公式总浮点运算量 C 参数数量N × token数D × 6 其中 - 前向传播每个参数需要2次运算 - 反向传播额外4次运算16.2 token数量规则DeepSeek-V3确立了计算最优规则每个参数对应 20 个token 计算示例 2万亿参数 × 40万亿token 所需的token数量16.3 成本计算计算过程 C 2 × 10¹² × 40 × 10¹² × 6 4.8 × 10²⁶ 假设条件 - H100每小时成本约2美元 - 算力利用率50% 单次训练成本 ≈ 7.5亿美元16.4 不同模型对比模型类型参数量激活参数量稀疏比训练成本LLaMA 3稠密4050亿4050亿1:1约7.5亿美元DeepSeek-V3MoE6710亿370亿18:1约560万美元稀疏模型成本约为稠密模型的1/130DeepSeek-V3在工程优化方面堪称优化仙人1F1B调度和零气泡流水线优化器效果-经典流水线提高吞吐量
训练2万亿参数大模型的实现
发布时间：2026/7/16 10:45:24
1. 万亿参数llm训练的挑战2. 内存与算力约束3. 数据并行与通信优化4. ZeRO零冗余优化器5. 梯度检查点6. FlashAttention7. Ring Attention8. 混合专家模型MoE9. 并行策略组合10. 集群故障恢复机制11. 完整训练系统架构12. 趋势与训练成本估算1. 万亿参数LLM训练训练2万亿参数的大语言模型面临三大核心限制限制类型具体挑战内存限制模型状态占用32TB单块H100仅80GB需要400块GPU通信瓶颈网络速度比服务器内部连接慢约18倍算力需求需要4.8×10²⁶次浮点运算需上万台芯片并行运行数月关键约束数值精度权衡比特数越少计算越快、内存越少但比特数过少会导致梯度超出数值范围或被四舍五入为0训练无法收敛故障频率在长达数月的持续运行中几乎每隔几小时就会出现某处故障2. 内存与算力约束模型状态的内存占用每个参数在内存中占据5份存储项总计16字节工作副本(2B)梯度(2B)Adam优化器状态高精度备份(4B)Adam优化器状态梯度滑动均值(4B)Adam优化器状态梯度方差(4B)总容量2万亿参数 × 16字节 **32TB**H100显存80GB/块仅存储模型状态需要400块H1002.2 激活值的内存占用激活值是前向传播时在层与层之间流动的数值缓存这些激活值是因为反向传播时需要读取它们来计算梯度。激活值占用量随批量大小和序列长度增长与参数数量无关序列长度为4096的单个训练样本产生642GB激活值批量大小为32时激活值占用量提升到20TB与模型状态大小相当2.3 算力需求单次训练总浮点运算量 参数量 × token数 × 6 其中6 前向传播2次 反向传播4次2万亿参数模型约需4.8×10²⁶次浮点运算单块H100发挥峰值50%性能需要30700年16384块GPU并行计算仍需将近两年3. 数据并行与通信优化3.1 数据并行基础将模型复制到每块GPU上把批次拆分成N个分片每块GPU独立处理自己的分片3.2 环形全归约Ring All-Reduce问题反向传播完成后每块GPU上的梯度不同需要对梯度取平均值。如果把所有数据传到一台机器上处理会产生瓶颈。解决环形全归约将过程拆分为两个阶段阶段一规约分发Reduce-Scatter将N块GPU在逻辑上排列成一个环形将每个梯度张量拆分成N个块每一步中每块GPU处理不同的梯度块所有GPU同时发送和接收数据没有链路空闲执行步骤每块GPU向右发送一个梯度块同时累加从左侧收到的梯度块重复N次后每块GPU持有一个完成规约的梯度块但每块GPU持有的梯度块各不相同阶段二全收集All-Gather梯度块在环中传递最终每块GPU都会拿到全部N个梯度块即完整的平均梯度。通信量分析每块GPU总通信量 2 × (N-1) / N × 梯度总大小 当N增大时该值趋近于 2 × 梯度总大小特点带宽最优方案通信量与GPU数量无关优化每层的全归约操作可与更早层的反向传播计算重叠执行通信过程被GPU本来就要完成的计算掩盖3.3 LAMB优化器数据并行可以让批次大小随GPU数量增加而扩大。但当GPU数量达到16000块时批次会达到临界批次大小额外的样本无法再提升梯度估计精度大幅更新反而会导致优化过程偏离最优方向LAMB优化器Layer-wise Adaptive Mixed Batch optimizer能将LLaMA的训练批次大小提升到32868把原本需要3天的训练时间压缩到76分钟但一旦超过临界批次大小即使将批次翻倍能节省的梯度更新步数也不到一半4. ZeRO零冗余优化器数据并行中每块GPU都会存储一份完整的模型副本32TB。ZeRO的答案是拆分状态到不同GPU上存储每块GPU只保留自己负责的那部分需要时再调取。4.2 三级分片策略第一阶段优化器状态分片ZeRO-1拆分Adam优化器状态占比最大16字节中有12字节是优化器状态大规模场景下单GPU内存占用降到原来的1/4通信量完全不增加数据并行本身就要执行的全归约操作可零额外成本完成拆分后状态的更新第二阶段梯度分片ZeRO-2在ZeRO-1基础上进一步拆分梯度大规模场景下总内存占用降到原来的1/8仍无额外通信量零额外成本第三阶段参数分片ZeRO-3拆分模型参数本身需要付出通信代价示例2048块GPU训练2万亿参数模型 - 单块GPU仅需存储 16GB 数据 - 远低于H100的80GB显存上限 工作流程 1. 运行任意层之前所有GPU需要收集该层的权重 2. 临时拼凑出一份完整副本 3. 完成该层的计算后丢弃临时副本 通信量 基准的 1.5 倍全程没有任何一块GPU持有完整模型ZeRO效果总结阶段分片内容内存占用额外通信量ZeRO-1优化器状态1/4无ZeRO-2梯度1/8无ZeRO-3参数显著降低1.5倍基准5. 梯度检查点技术问题激活值缓存的层输出大小与模型状态相当当批次大小为32时可达20TB目前还没有被优化。解决梯度检查点Gradient Checkpointing / Activation Checkpointing前向传播过程中大部分激活值被丢弃反向传播时从保存的检查点重新计算激活值代价计算量约增加33%5.2 不同激活值的重计算成本差异高重计算成本、低内存占用线性层的输入重新生成需要重新运行计算量很大的矩阵乘法内存占用小但重计算成本高低重计算成本、高内存占用注意力内部状态、softmax输出、dropout掩码形成序列长度的矩阵大小随序列长度的平方增长但重新计算成本很低只需一次小型矩阵乘法 一次softmax运算占整个层计算量的比例非常小5.3 选择性检查点策略Selective Checkpointing策略保留体积小但重计算成本高的线性层输入丢弃体积大但重计算成本低的内容即注意力内部状态效果指标全重计算选择性检查点激活值内存占用11/5浮点运算量增加33%2.7%模型浮点运算利用率MFU42.1%54.2%6. FlashAttention6.1 标准自注意力的内存问题标准自注意力机制会构建完整的N×N注意力矩阵N为序列长度序列长度每个注意力头矩阵条目数40961600万131K170亿这些矩阵存储在GPU的高带宽内存HBM中H100的HBM带宽约3TB/s芯片上的SM流多处理器速度约是HBM的100倍但容量只有192MB6.2 FlashAttention解决方案将注意力计算切分成足够小的块刚好可以放入SRAM中处理。关键分块Softmax处理每个块时持续追踪当前的最大值和累计分母如果下一个块的最大值更大先给之前的部分合成一个校正因子再加上新的项校正因子 e^(旧最大值 - 新最大值)因为Softmax本身就是基于指数运算的分块计算能保持数值完全精确优势指标标准注意力FlashAttention内存复杂度O(N²)O(N)运行速度基准提升2~4倍浮点运算量不变不变是否生成完整注意力矩阵是否影响由于FlashAttention围绕内存带宽优化它已经是长序列训练的默认方案让上下文并行具备了实用性7. 张量并行与序列并行7.1 张量并行Tensor ParallelismTP问题ZeRO解决了存储问题没有GPU需要保存完整模型但每一次独立的矩阵乘法仍然在单个GPU上运行。方案拆分矩阵乘法本身每个GPU负责矩阵乘法的一部分运算最后把所有结果拼接起来通信模式拼接是阻塞式的通信传递所有GPU必须等待通信完成才能继续后续运算每层需要进行4次这样的通信每层都如此场景张量并行只能在集群中速度最快的链路上运行连接类型带宽相对速度NVLink节点内8卡900GB/s基准InfiniBand跨节点50GB/s慢18倍因此TP度严格设为8对应单台服务器不需要用到慢链路7.2 注意力模块的张量并行注意力模块本身已经是多个独立的注意力头并行运行的结构实现方式 1. 有N块GPU每块负责一部分注意力头 2. 运算之后只需要一次通信就能把结果合并 通信次数 - 前向传播2次通信 - 反向传播2次通信 - 全部是阻塞式的7.3 矩阵切分技巧技巧将第一个矩阵按纵向切分第二个矩阵按横向切分切分后矩阵的衔接处刚好对齐。工作流程每个GPU完成第一部分乘法后得到的中间结果恰好就是它执行第二部分乘法时需要的输入片段中间过程不需要在GPU之间传输任何数据只在最后进行一次通信把各部分结果汇总7.4 序列并行Sequence ParallelismSP问题拼接完成后每个GPU上都有完全相同的完整输出。接下来的运算归一化、残差连接等都是逐token的对每个token的特征做归一化偶尔会将某个token的特征屏蔽再把原始输入加回去这些运算不会在不同token之间交换信息每个GPU都在对相同的数据做相同的运算完全是重复劳动。解决沿token维度拆分这些运算每个GPU只负责自己分到的那部分token的运算效果GPU之间传输的总数据量保持不变只是在主token运算前后分别做一次分发和收集激活值的内存占用降低T倍T为张量并行度8. 流水线并行8.1 朴素流水线的问题假设有126层Transformer均匀拆分到16块GPU上每块GPU分到8层。前向传播顺序GPU1(层1-8) → GPU2(层9-16) → … → GPU16(层121-126)问题GPU1计算时GPU2到16都处于闲置状态等待输入任意时刻只有1块GPU在工作剩下15块都在等待这些总闲置时间叫做流水线气泡8.2 微批次Micro-batch调度解决方案把输入批次拆分成更小的微批次示例GPU1处理完Micro-batch 1后就可以开始处理Micro-batch 2同时GPU2开始处理Micro-batch 1多块GPU并行处理不同的数据气泡占比公式气泡占比 (P - 1) / (M P - 1) 其中 - P 流水线阶段数 - M 正在处理的微批次数量计算示例16个阶段气泡占比降到1%以下需要多少微批次0.01 (16 - 1) / (M 16 - 1) M ≈ 1500 → 需要约1600个微批次内存根本放不下这么多微批次8.3 1F1B调度One Forward One Backward1F1B 一次前项 一次反向阶段划分预热阶段执行若干前向传播稳定阶段交替执行前向和反向优势反向传播一旦开始就会消耗激活值用完就可以释放对应内存只需要保留P个正在处理的微批次而不是M个气泡占比不变但内存占用大幅降低8.4 交错调度Interleaved Scheduling改进把每块GPU负责的层块拆成更小的部分示例 原本GPU1负责层1-8、GPU2负责层9-16... 改进GPU1负责层1、第33层、第65层、第97层 GPU2负责层9、第41层、第73层... 这些层分散在整个模型的不同位置效果气泡缩小到原来的1/4代价通信量变成原来的4倍8.5 流水线边界优化LLaMA 3还有一个优化技巧第一块GPU要负责词嵌入查找操作最后一块GPU要负责输出投影计算这两项都是流水线边界阶段的额外工作优化方案首尾2个GPU各负责7层 中间14个GPU各负责8层 总层数 126层 所有GPU都能同时完成计算效果MFU提升6.5%峰值内存占用减少5TB8.6 反向传播拆分1F1B with Zero Bubble核心思想对反向传播本身进行拆分反向传播需要计算两个部分梯度类型说明下游依赖输入梯度前一个阶段马上要用立即需要权重梯度只在步骤结束时才用到无下游依赖解决方案把权重梯度的计算插到流水线气泡的空闲时间段里效果吞吐量提升23%9. 环形注意力Ring Attention问题:FlashAttention可在单块GPU上处理长度为13.1万token的序列100万token的长度已经超出单个设备的承载上限解决方案: **上下文并行**通过环形注意力算法将序列本身拆分到多块GPU上实现步骤将GPU按逻辑环形排列每块GPU存储一部分query tokenKV块沿环形网络流转每次传递到相邻的下一个节点每块GPU用当前持有的KV块计算部分注意力结果然后把KV块传给下一个相邻节点9.3 计算与通信重叠数据传输和计算过程并行重叠当前的KV块还在计算时下一个块就已经送达-经过一轮完整流转后所有query都与所有key完成了计算9.4 最终结果获取Ring Attention会屏蔽每个token对后续token的注意力计算把其余无关部分置零最终得到精确的注意力结果。实际应用: LLaMA 3使用这项技术在128块H100上运行4050亿参数的模型仅用77秒就完成了100万token的预填充10. 混合专家模型MoE10.1 背景目前从未有人训练过2万亿参数的稠密模型但存在以下模型模型参数量架构SwitchTransformer1.6万亿MoE传闻GPT-41.8万亿MoEDeepSeek-V36710亿MoE10.2 MoE基本原理路由模块从更大的专家池中为每个token选出排名前K的专家每个token仅需少量计算可实现极大的模型容量挑战一通信问题每个MoE层触发两次全对全通信All-to-All调度阶段把token发送到对应专家所在的GPU汇总阶段把计算结果返回注意这与All-Reduce不同All-Reduce是把所有贡献汇总成一个共享结果。挑战二负载均衡问题问题如果路由模块偏好少数常用专家这些专家所在的GPU会成为瓶颈其他GPU会闲置。标准解决方案加入辅助损失惩罚不均衡的路由分配SwitchTransformer使用 α 10⁻² 的α值推动路由分配趋向均匀分布问题这种损失会和路由模块学到的偏好产生冲突可能会降低模型质量10.4 DeepSeek-V3偏置路由方案创新方案给每个专家的路由得分添加一个**偏置**调整规则负载不足的专家偏置提高负载过高的专家偏置降低关键偏置只影响哪些专家会被选中不参与门控值的计算门控值用于给选中专家的输出加权因此梯度可以顺畅传递效果在整个14.8万亿token的训练过程中没有用到辅助损失没有出现token丢弃没有出现损失飙升11. 数值精度选择11.1 浮点数结构每个权重是一个浮点数由符号位、尾数、指数组成类似科学技术法组成部分作用指数决定数值范围尾数决定精度11.2 BF16 vs FP16FP1616个比特1符号位 5指数位 10尾数位能表示的最大值上限是**65504**问题训练时梯度经常会超过这个值溢出变成无穷大训练中断解决方案损失缩放损失缩放会在参数更新前用一个常数把梯度缩小再缩放回去如果这个常数超出合适范围训练会发散BF16同样16个比特但重新分配位宽8个指数位 7个尾数位恢复FP32的全部数值范围10⁻³⁸ 到 10³⁸所有梯度都能被容纳不需要损失缩放结论对于训练稳定性数值范围远比精度重要所以BF16是默认选择。11.3 FP8训练进一步减少比特数得到FP8每个权重只占1字节H100 Tensor Core上FP8矩阵乘法速度是BF16的2倍但位宽很紧张总共只能表示256个不同的数值DeepSeek-V3的解决方案逐块缩放技术实现方式权重被拆成128×128的块激活值被拆成1×128的块每个token对应一个块每个块都有独立的缩放因子缩放因子每一步都会更新让FP8的数值窗口匹配当前局部的数值大小关键细节矩阵乘法的部分和用FP32累积舍入误差不会累积效果与全BF16训练的基线相比差距仅在0.25%以内11.4 FP4展望NVIDIA Blackwell架构支持FP4总共只能表示16个数值在这种精度下保持训练稳定仍是待解决的问题早期的小规模测试结果和FP8的表现非常接近12. 并行策略组合实例12.1 并行维度GPU总数量是5个并行维度的乘积总GPU数 TP × PP × CP × EP × DP其中TP 张量并行Tensor ParallelismPP 流水线并行Pipeline ParallelismCP 上下文并行Context ParallelismEP 专家并行Expert ParallelismDP 数据并行Data Parallelism12.2 LLaMA 3 405B配置参数值总参数量4050亿GPU数量16384块H100张量并行度8通过NVLink单节点内通信带宽900GB/s流水线并行度16通过InfiniBand跨节点组通信数据并行度128计算验证8 × 16 × 128 16384✓其他配置单GPU算力400 TFLOPS处理131K token长上下文训练时上下文并行度提升到16数据并行度降到8序列长度支持扩大到原来的16倍12.3 DeepSeek-V3配置参数值总参数量6710亿每token激活参数量370亿专家数量256GPU数量2048块H800流水线并行度16专家并行度64张量并行度0完全不使用为什么DeepSeek-V3不使用张量并行原因H800 NVLink带宽为每秒400GB不到H100的一半900GB/s在关键路径上使用张量并行的通信成本过高DeepSeek-V3的优化流水线调度策略将专家路由与前向反向计算重叠把通信开销隐藏在有效计算过程中12.4 成本对比指标LLaMA 3DeepSeek-V3GPU小时消耗较高278.8万训练成本较高560万美元基准测试表现相当相当GPU小时比值基准约1/11结论两种都是合理的设计选择各自都由团队可用的硬件条件决定。13. 集群故障恢复机制13.1 故障频率统计LLaMA 3 405B在754天的训练过程中共记录419起意外故障约每3小时发生一起故障类型占比GPU和NVLink故障30%HBM显存故障17%网络和软件问题其余13.2 检查点机制LLaMA 3 4050亿参数的完整检查点大小约为6.5TB。多层备份策略备份频率存储位置说明每5分钟内存内存快照每30分钟本地SSD检查点保存每隔几小时远程存储持久化备份13.3 自动恢复流程异常检测 → 暂停任务 → 诊断原因 → 切换热备 → 从检查点恢复恢复流程异常检测会先暂停受影响的任务诊断程序定位故障原因调度器切换到热备用设备从最新的检查点恢复训练效果419起故障中仅有3起需要大量人工干预有效训练时间占比达到90%以上软件也可能出现故障谷歌的PaLM 540B训练过程中出现约20次损失尖峰训练损失突然大幅上升解决方法从尖峰出现前100步的检查点重启训练跳过导致问题的数据批次14. 完整训练系统架构14.1 数据准备训练前置条件磁盘上必须存好40万亿个token来源网页、书籍、代码、数学内容、精选数据经过清洗、去重通过分词器处理后以整数形式存储约160TB大小存储系统支撑3TB/s的训练集群总存储容量240PB总带宽可达2TB/s14.2 数据配比与训练顺序语料组成内容类型占比通用网页内容约50%数学和推理相关内容约25%代码约1/6多语言内容和精选资料其余训练阶段顺序阶段一大部分训练使用8000 token的上下文窗口阶段二长上下文爬坡分6个步骤将上下文窗口扩展到128K token阶段三冷却阶段学习率衰减到零提高高质量数据的采样权重14.3 数据分发策略每块GPU的数据分配按照训练部署和自身编号拉取固定的语料分片不会有2块GPU拿到相同的token中断后恢复运行时生成的批次数据与之前完全一致预取机制CPU侧的预取队列提前准备好接下来要用到的批次数据总带宽需求很小每块GPU只需几千字节每秒真正的问题是长尾延迟只要有一个节点速度变慢下一次集体通信时其他16000个节点都会被卡住14.4 训练步骤的并行执行16000块GPU的并行策略数据并行128个副本每个副本内部128块GPU → 张量并行NVLink带宽900GB/s副本间 → 流水线并行InfiniBand每层使用FlashAttention采用混合专家路由使用混合精度计算反向传播使用零气泡流水线优化器优化器状态拆分存储在各个副本上14.5 控制与监控控制平面集群调度器负责启动所有进程并行网格为每块GPU分配对应的角色位置检查点机制异步每隔几分钟保存状态快照到内存每半小时保存到SSD每隔几小时保存到长期存储健康监控守护进程监控慢节点和故障情况节点故障时编排器切换到热备节点从最新检查点恢复训练连续运行时间约3个月15. 技术趋势15.1 硬件感知代码设计DeepSeek-V3已经证明针对特定硬件调整并行策略可以达到前沿效果在H800带宽更低的NVLink上避免使用张量并行以极低的成本达到高质量效果15.2 NVIDIA GB200 NVL72规格参数 - 72块Blackwell GPU部署在同一机柜 - 通过NVLink互联 - 单GPU带宽1800GB/s - 总GPU内存13.5TB - 总聚合带宽130TB/s 影响 - 此前讨论的所有系统受限于张量并行上限仅为8 - 现在上限提升到72 - 对于参数规模低于万亿的模型机柜内的流水线并行可能不再有必要15.3 Delta等工作节点每个工作节点在自己的数据分片上用本地优化器运行**数百步训练**然后通过外部梯度更新同步参数增量效果通信量减少500倍还能保持训练同步场景数据中心之间的分布式训练示例Nvidia展示 - 场景相距1000千米的两个数据中心之间的训练 - 扩展效率96%这个技术栈里有多项技术在5年前都还不存在等到下一代前沿模型问世时还会有更多技术发生变化再大的努力都比不过一次底层模型的升级qwq16. 训练成本估算计算公式总浮点运算量 C 参数数量N × token数D × 6 其中 - 前向传播每个参数需要2次运算 - 反向传播额外4次运算16.2 token数量规则DeepSeek-V3确立了计算最优规则每个参数对应 20 个token 计算示例 2万亿参数 × 40万亿token 所需的token数量16.3 成本计算计算过程 C 2 × 10¹² × 40 × 10¹² × 6 4.8 × 10²⁶ 假设条件 - H100每小时成本约2美元 - 算力利用率50% 单次训练成本 ≈ 7.5亿美元16.4 不同模型对比模型类型参数量激活参数量稀疏比训练成本LLaMA 3稠密4050亿4050亿1:1约7.5亿美元DeepSeek-V3MoE6710亿370亿18:1约560万美元稀疏模型成本约为稠密模型的1/130DeepSeek-V3在工程优化方面堪称优化仙人1F1B调度和零气泡流水线优化器效果-经典流水线提高吞吐量
