宜布网网站谁做的,找哪个公司做网站推广最好,山西省智慧建筑信息平台,网络营销的目的和意义万卡 GPU 集群实战#xff1a;探索 LLM 预训练的挑战 一、背景
在过往的文章中#xff0c;我们详细阐述了LLM预训练的数据集、清洗流程、索引格式#xff0c;以及微调、推理和RAG技术#xff0c;并介绍了GPU及万卡集群的构建。然而#xff0c;LLM预训练的具体细节尚待进一…nbsp;
万卡 GPU 集群实战探索 LLM 预训练的挑战
nbsp; nbsp;
一、背景
在过往的文章中我们详细阐述了LLM预训练的数据集、清洗流程、索引格式以及微调、推理和RAG技术并介绍了GPU及万卡集群的构建。然而LLM预训练的具体细节尚待进一步探讨。本文旨在为您揭秘这一核心环节提供更为深入的解读。
已构建万卡GPU训练集群并备妥数据预训练任务启动并非一蹴而就。启动前需精心选择分布式策略实施高效Checkpointing故障巡检修复并考虑弹性训练等优化与容错策略确保训练顺利高效完成。
本文聚焦大规模LLM预训练通过Meta OPT、BigScience Bloom、TII Falcon-180B、字节MegaScale及阿里DLRover等案例深入解析分布式策略、优化方案及容错弹性机制为您揭示预训练技术的核心奥秘。
二、引言
2.1 训练预估
LLM的预训练成本高昂常需上千GPU训练数十天。早期百B规模LLM训练Token量仅几百B如今已跃升至几T级别如LLaMA-3系列模型其训练Token数高达15T显示了技术的飞速进步与投入的巨大增长。
Decoder Only LLM训练时长可通过模型参数量、Token数及训练资源预估。Token的Forward计算量近似为模型参数量的两倍W代表参数量为精确规划训练资源提供了有力依据。 鉴于总计算量与Forward计算量之比通常接近3:1我们可以精确估算每个Token在训练中的计算量这一发现与论文[2001.08361]中关于神经语言模型缩放规律的结论相吻合为训练效率提供了可靠的数据支持。 通过Token计算量和资源可预估训练时长。MFU模型浮点运算利用率作为衡量分布式训练效率的指标为我们提供了训练效率的直观参考。
训练天数计算公式天数 Token数 × Ctoken ÷ (GPU数 × FLOPs × MFU) ÷ 86400万。快速估算训练时长。
使用8192个H100-80G GPU和10T Token数据训练175B模型预估仅需30天即可完成高效且强大。
10T*6*175B/(8192*1000T*50%)/3600/2430 天
NVIDIA在《Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM》中运用了Activation重计算策略这一创新要求额外进行一次Forward操作。因此整体计算量相应增加为训练大型语言模型提供了高效且规模化的解决方案。
Ctoken 8 * W
在论文[2205.05198]中作者对大型Transformer模型的Activation重计算进行了显著优化基本维持了3:1的比例效率。因此后续研究仍以此比例为指导。如图Table 4所示这一优化为实现更高效的大型模型训练提供了重要参考。 2.2 显存占用
训练中显存占用通常包含四个部分模型参数优化器状态梯度以及中间激活。
Adam优化器融合动量与RMSprop自适应学习率技术为深度学习模型训练提供强大动力。其独特之处在于能根据参数更新历史自适应调整学习率显著提升收敛速度并保障训练稳定性。通过维护两个额外参数或“矩”Adam为每个参数量身打造优化策略确保模型训练的高效与精准。
二阶矩基于梯度平方的指数移动平均反映梯度变化率实现参数自适应学习率。参数更新依据梯度不确定性智能调整学习步长确保参数空间内步进适中优化效果更佳。
分布式训练中指数加权平均EMA是减少噪声、保障稳定性的关键。尽管EMA引入需额外维护其指数平均值占用一定空间但其在提升训练效果上不可或缺后续计算中可暂时忽略其影响。
模型参数高达175B占用约350GB存储空间。在混合精度训练中为确保训练稳定并减少误差常保留一份FP32精度的参数此时模型参数总量约达750GB充分保障训练效果与数据安全性。Adam优化器状态占用高达700GB350GB*2包括一阶矩m和二阶矩v。若采用FP32存储显存需求翻倍至1400GB确保计算效能与数据精度。梯度达350 GB。训练时得益于链式法则无需永久保存所有梯度。通过边反向传播边更新如Pytorch默认操作更新后即刻释放空间这是显存优化的关键。然而若采用梯度累积或需梯度常驻的方案则无法实时销毁需额外管理显存。激活相对以上参数会小一些暂时忽略。
LLM预训练显存占用高达8倍参数量或12倍如175B模型占显存1400GB远超单机8*H100 80G限制。为确保运行至少需3台8*H100 80G设备体现了模型训练的硬件挑战与资源需求。
2.3 分布式策略
2.3.1 DP PP TP
LLM模型庞大单一GPU或机器难以容纳故需进行切分处理。同时为提高训练效率普遍采用数据并行策略。图6展示了一种经典组合方案结合数据并行DP、流水线并行PP及张量并行TP实现高效训练。这一策略不仅解决了模型容量问题还显著提升了训练速度。
DP切片实现并行处理每片含完整模型副本独立处理不同数据。完成训练步骤后各切片通过All Reduce聚合梯度并同步更新模型参数。这种策略显著提升了训练效率确保模型更新的一致性和准确性。PP将模型按照层次切分不同 GPU 上可以放置一部分的层通常需要切分尽可能的均衡。由于 Transformer 模型Decoder每一层参数量和计算量是固定的因此相对比较好切分。不过也需要考虑开始的 Token Embedding 和最后 lm_head 中的 World Embedding因此也有论文中会在第一个 PP 和 最后一个 PP 时让 Transformer Layer 少一点以便更加的均衡[2210.02414] GLM-130B: An Open Bilingual Pre-trained Model 中的 PP 为 8共 70 层中间各 9 层起始各 8 层。PP 的通信量相对比较小因此常常会放在不同的机器上。TP技术可将模型如PP切片对应层分散至多个GPU实现Tensor跨GPU划分。虽通信量增大但置于单机内可充分利用NVLink高速带宽优化性能。这种布局最大化机器内部资源实现高效并行处理。 2.3.2 Zero-DP
为减少显存占用我们常采用Zero-DP优化技术包括Zero-1、Zero-2、Zero-3和Zero-offload等方案。这些优化技术源自Microsoft Research的ZeRO DeepSpeed研究它们让训练超过1000亿参数的模型成为可能。具体显存占用优化效果显著为您的深度学习项目提供高效且经济的解决方案。
Zero-1在不同 DP 组之间进一步切分优化器状态。Zero-2除了优化器状态外进一步切分梯度。Zero-3进一步切分模型参数。 2.3.3 EP
随着混合专家MoE模型的普及其参数量激增。为高效训练专家并行EP策略被广泛应用即将不同专家分配至不同GPU上也可与其他切分方案融合。如图6所示2个专家E0和E1可被切分至4个GPU每个GPU承载1/4的专家实现高效并行处理确保训练过程的高效与准确。 2.3.4 SP
其实有两个序列并行Sequence ParallelSP的工作一个是 ColossalAI 的 [2105.13120] Sequence Parallelism: Long Sequence Training from System Perspective一个是 Megatron-LM 的 [2205.05198] Reducing Activation Recomputation in Large Transformer Models。两者都叫 SP但是实际上方法不太一样解决的问题也不同。
ColossalAI SP策略核心在于将序列数据细分为小子序列并分发至多GPU并行运算。如图Figure 1长L的序列被切割为N个L/N的子序列实现N个GPU的高效并行处理大幅提升处理效能。 序列间依赖关系需通过图2中的Ring Self-Attention机制实现通信确保计算结果的等价性实现高效信息交互。 如图Figure 5所示Megatron-LM SP专注于解决TP中显存分摊难题。研究发现LayerNorm和Dropout的输入输出未跨GPU分摊。由于它们在Token间无依赖可按Sequence维度分割各GPU仅处理序列部分实现高效计算。此举显著提升显存利用率为深度学习模型训练提供新策略。 2.3.5 CP
在 Megatron-LM 中还有上下文并行Context ParallelismCP实际上就是 ColossalAI SP也就是按照输入序列进行切分。如下图所示为 Megatron-LM 中 TP 和 CP 的组合其中 AG/RS 表示 Forward 为 All GatherBackward 为 Reduce ScatterRS/AG 表示前向为 Reduce Scatter反向为 All Gather。具体可参考 Context parallelism overview - NVIDIA Docs 2.4 GPU 故障
GPU 故障是大规模 GPU 集群中最常见的问题之一通常会暴露 ECC Error 或 Xid Code有关 Xid Code 的错误可以参考 NVIDIA 的官方文档 XID Errors :: GPU Deployment and Management Documentation。也可参考一些公有云平台上的 FAQ比如 常见 Xid 事件的处理方法--机器学习平台-火山引擎此外也会提供一些排查手段比如 自助诊断GPU节点问题-阿里云。
GPU 故障最大的挑战是其数量比较多故障率比较高一个 GPU 异常往往意味这个训练任务的暂停而且通常需要按照整机的方式替换。比如 1 个 GPU 异常通常是直接驱逐整机。这是因为大规模 LLM 预训练往往要利用单机内高速的 NVLink如果不是整机调度很可能会影响整体吞吐。假设一天内 GPU 发生故障的概率为 0.1%则一台 8 卡 GPU 机器每天发生故障的概率为 1-(1-0.1%)^80.8%万卡 GPU 一天内有 GPU 发生故障的概率为 1-(1-0.1%)^1000099.99%。
三、Meta OPT
3.1 概述
Meta 在 2022 年上半年开源了 OPTOpen Pre-trained Transformer系列模型期望复现 OpenAI 的 GPT-3 模型。并且公开模型、代码等以便促进 NLP 技术在学术、工业界的研究和应用。对应的 Paper 为 [2205.01068] OPT: Open Pre-trained Transformer Language Models。除了论文之外Meta 也公开了其训练的 logbook Meta OPT-175B Logbook详细的记录了整个模型的训练过程包括遇到的各种问题相关的分析讨论以及采取的相应措施等具有很大的参考价值。
OPT-175B模型依托992台80GB A100 GPU每台GPU性能高达147 TFLOP/sMFU占比约47%。为确保训练稳定我们额外准备了12台备用机器每日平均替换2台以应对机器异常故障率1.61%。这一举措充分展示了我们对训练过程稳定性和可靠性的高度重视。
经过长达两个多月的密集训练涵盖了从2021年10月20日至11月11日的半月测试期以及随后57天的正式训练直至2022年1月6日圆满结束。相较于预期训练时间超出预估的25天展现了团队的专业与毅力。
300B*6*175B/(992*147)/3600/2425 天
在训练中实际有效时间仅占44%问题频发。初期任务手动重启达35次后引入自动重启机制。但硬件故障又触发70次重启平均日重启一次。这表明提高训练效率和稳定性仍是亟待解决的关键。
3.2 监控容错
自11-06起训练任务即已启动然而至11-11尽管尝试了多种方案效果仍未达到预期。据数据记录OPT/chronicles/10_percent_update.md此期间共发生10次重启每种颜色标记一次彰显挑战之严峻。我们持续努力力求突破。 作者经过深思熟虑决定与OpenAI同步配置以图为证11.XX为旧配置12.XX为同步后新配置现正式开启11-11训练从头出发精益求精。 OPT-175B模型训练中除配置重训外常遇硬件异常需重启如XX%的故障案例源于此类问题确保系统稳定运行至关重要。
GPU ECC错误频发每1-2天就有1/128节点受影响建议定期重启机器或重置GPU以确保稳定运行。 任务异常风险不容忽视如p2p_plugin.c:141 NCCL WARN NET/IB端口错误的警告提示直接指向潜在的任务异常需及时排查处理。OPT-175B训练多次遭遇与IB/NCCL问题紧密相关的任务停滞需人工介入检测以确保训练顺利进行。GPU故障常见表现为CUDA Error或程序异常退出如RuntimeError: 捕获到设备4的pin memory线程中的RuntimeError这些信号均指示GPU可能出现掉卡问题需及时排查解决。机器异常GPU 之外的硬件异常比如硬盘、CPU 等异常甚至机器直接挂掉。机器配置异常比如发现某个机器开启了 MIG。
任务异常的核心挑战在于计算资源的显著浪费。尽管Checkpointing机制支持从断点恢复训练但因其体积庞大且伴随额外开销需设定合理间隔进行保存。例如每300步保存一次异常后仅能从最新点恢复平均损失150步的计算量。因此优化Checkpointing策略对于提升训练效率和资源利用率至关重要。
四、BigScience Bloom
4.1 概述
BigScience 的 BloomBigScience Large Open-science Open-access Multilingual Language Model模型是一个开源、多语言的 LLM。它是众多研究机构和志愿者合作开发完成的旨在解决多种语言和文化的通用性问题并鼓励透明度和科学共享以推动全球研究社区的协作。对应的论文为[2211.05100] BLOOM: A 176B-Parameter Open-Access Multilingual Language Model。
BigScience 也公布了 Bloom 的详细训练 logbigscience/train/tr11-176B-ml/chronicles.md at master甚至包含详细的 Tensorboard 记录bigscience/tr11-176B-logs · Training metrics。其从 2022-03-11 正式启动训练并在 2022-06-28 完成 1 个 Epoch 的训练。由于还有预算又接着训练了一段时间并在 2022-07-04 从 48 台机器切换为 24 台机器。
Bloom训练运用48台搭载8个A100 80G的GPU机器总计384 GPU并配备4台灾备机资源规模不及OPT-175B之半。此次训练处理了366B TokenGPU最高效率达156 TFLOPs实际运行中保持150 TFLOPs历时3.5个月。相较于理论上的77天实际效率达70%展现了高效的计算能力和卓越的资源管理。
nbsp;366B*6*175B/(384*150T)/3600/2477 天 4.2 分布式并行方案
Bloom训练借助Megatron-DeepSpeed框架融合Megatron-LM与DeepSpeed精髓。其分布式并行方案8DP 12PP 4TP如图6所示显著提升训练效率。此外还引入了ZeRO-1技术进一步优化性能确保训练的高效与精准。 4.3 监控容错
训练中作者遭遇硬件挑战平均每周GPU异常1-2次。为减少损失每3小时保存Checkpoint重启时约损失1.5小时计算。同时PyTorch死锁Bug和硬盘满载问题也导致5-10小时闲置。尽管面临诸多困难作者仍持续努力确保训练进程的稳定与高效。
在训练初期Checkpoint保存间隔较大。然而2022年3月21日因GPU异常导致训练中断浪费了7.5小时。随后我们迅速调整策略将保存间隔缩短至每200个Step一次但次日再次遭遇失败耗时再增。为减少损失我们进一步将保存间隔缩减至每100个Step一次确保每次中断最多仅损失3小时极大提升了训练效率。
Bloom 训练时遭遇任务停滞问题2022-04-xx。为减少无效等待作者在启动时设定“NCCL_ASYNC_ERROR_HANDLING1”确保NCCL能迅速终止进程重启任务。同时评估任务停滞及任务异常但Slurm未正常退出等问题亦被关注。这些优化措施有效提升了训练效率与稳定性。
作者也在 2022-04-28 遇到了训练降速问题上图中的红框训练吞吐大概降低 5%GPU 从 149 TFLOPs 降低到 140 TFLOPs。作者怀疑是某个机器存在性能问题因此停掉任务进行相应的网络吞吐测试但是并没有发现异常节点。由于正好处于周末并且手头没有现成的对所有 GPU 进行快速基准测试的工具只能采用 3 个备份机器逐次替换的方案来找到异常机器。
经过多次尝试后终于发现异常机器并将其替换再次重启后恢复到 149 TFLOPs 的速度。PS有趣的是单独测试时该机器的性能只有 2.5% 的降低而不是 5%但是将其加入集群再次测试时又能复现 5% 的性能下降。
五、TII Falcon-180B
5.1 分布式并行方案
Falcon-180B阿联酋TII的杰作凭借180B参数基于RefinedWeb数据集精心训练完成3.5T Token的累积。采用4096 A100 40G GPU64DP 8PP 8TP配置以惊人的43,500 PFLOP/s-days算力支持。若MFU设为50%训练天数可观彰显了强大的科技实力与效率。
43500*1000T/(4096*312T*0.5)68天
按照之前的计算公式得出了和上述一致的结论
3.5T*6*180B/(4096*312T*0.5)/3600/2468天
Falcon-180B采用GQA与8KV head设计实现8TP方案确保每个KV head独享GPU资源。这一布局充分利用单机内高速NVLink带宽实现高效通信。在MLP Layer的矩阵乘法处理中通过先列切后行切的优化策略减少通信需求显著提升计算效率。整个系统展现出卓越的并行处理能力和计算效率。 对于流水线并行PP作者同样进行了 PP 的切分使用的 PP 为 8也就是模型按层切分为 8 个切片。为了减少 PP 中的 Bubble作者采用了 [2006.09503] Memory-Efficient Pipeline-Parallel DNN Training 的 1F1B 方案。
此外作者也尝试了 [2104.04473] Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM 中的 Interleaved-1F1B 方案当每个 DP 中 Micro-Batch 较小时Interleaved-1F1B 会有一定收益但是当 Micro-Batch 比较大时并没有获得收益。
如图4所示常规1F1B与创新的Interleaved-1F1B形成鲜明对比。Interleaved-1F1B通过灵活调整Micro Batch的Forward与Backend顺序显著减少Bubble现象优化性能。尽管调度策略更为复杂但其对1F1B的改进效果不容小觑为数据处理带来了新突破。 在1F1B优化的基础上为减少通信量作者还引入了Scatter-Gather优化策略显著提升效率。
然后通过 P2P 通信传输到下一个 PP 切片对应的 GPU 上跨机通信。最终通过All Gather操作下一个PP切片的所有GPU同步获取全量激活数据本机NVLink加速。 在优化显存占用方面尽管尝试采用序列并行SP结合ZeRO和FlashAttention但效果并未显著提升反而略有下降故未采用SP策略。
数据并行DP作为主流并行策略在TP和PP确定后需结合资源情况设定DP并行度。特别值得注意的是DP间的All Reduce会随着Batch Size增大而加重最终趋近带宽限制故需全面考量。鉴于拥有4096个GPU最终DP并行度优化至4096/8/864实现高效资源配置。
5.2 监控容错
当 GPU 数目比较大时有一个 GPU 出现故障的概率会急剧增加比如 4096 GPU 稳定运行一天相当于一个 GPU 连续稳定使用 11 年。作者同样面临了硬件故障的问题其中主要是 A100 的故障尤其是 ECC Error 等。但也并不是所有的故障都会返回 Xid Code通常需要人工测试来捕获因为它们通常会导致计算返回 NaN。因此作者在任务启动是会运行一系列的大型矩阵乘法来捕获这些故障。此外还会启动一些简单的通信测试以保证网络的正常。
确保任务稳定可靠监控至关重要。现有Web-Based监控工具如Prometheus采样间隔较长15s至60s易遗漏如毛刺等问题。为解决此局限作者专门部署了高效可视化工具实现精准监控确保任务无忧运行。
5.3 训练损失毛刺Spike
在训练过程中除了稳定性训练损失波动也需关注。Falcon作者巧妙应对损失毛刺问题通过恢复最新Checkpoint并跳过1B Token数据继续训练。在训练Falcon-180B时成功应对了9次此类挑战确保了训练的高效与准确。
其实 Google 训练 PaLM 模型[2204.02311] PaLM: Scaling Language Modeling with Pathways也遇到了同样的问题作者在一个训练中遇到了 20 次的毛刺。针对此种情况作者会重启训练并从毛刺之前的 100 个 step 开始然后跳过 200-500 个 Batch 的数据通过这种方式没有再出现毛刺现象。此外作者也做了消融实验发现并不是单个数据的问题而可能是这连续的一系列 Batch 数据引起的。
在[2211.05100] BLOOM模型中为确保训练稳定研究者创新地引入StableEmbedding Layer。这一策略借鉴了bitsandbytes库通过在Embedding Layer后增设layer normalization显著提升了训练稳定性。这一创新方法不仅体现了技术的精湛更彰显了对训练效果精益求精的追求为176B参数的多语言模型训练提供了强有力的保障。
如下图所示是 Bloom 中遇到的毛刺现象 针对训练损失毛刺现象[2210.02414] GLM-130B与bigscience/train/tr8b-104B/chronicles.md已深入探讨与实验。二者均提供了专业见解与实证数据对于理解和解决这一问题具有重要参考价值。详情请查阅原文以获取更全面的分析与策略。
六、字节 MegaScale
字节在今年 2 月份发表了 [2402.15627] MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs其中详细介绍了万卡 GPU 训练 LLM 的各种挑战和非常全面的优化手段。如下图 Table 2 所示其最终在 3072 GPU 上实现了 59.1% 的 MFU在 12288 GPU 上也实现了 55.2% 的 MFU相比 Megatron-LM 明显提升。 6.1 优化手段
算法优化聚焦三大核心首先引入并行Transformer Block实现Attention与MLP的高效并行处理其次应用滑动窗口Attention显著减少计算负担最后采用LAMB优化器不仅维持精度还能将Batch Size扩大4倍有效降低PP中的Bubble问题。这一创新使得MegaScale在PP Bubble上减少了高达87.5%的损耗为大规模计算提供了更为高效、稳定的解决方案。
通信优化涵盖分布式DP、PP的overlap以及TP与SP间的高效重叠三大关键方面助力实现通信效率的大幅提升。
通过采用FlashAttention-2及LayerNorm与GeLU的算子融合技术显著提升了算子优化效果。
数据处理优化关键于异步加载与共享机制。异步数据加载能在 GPU 同步梯度时处理下一轮数据有效隐藏处理成本。同时由于 TP 组在同一机器内共享数据我们实现 DataLoader 的跨机器共享并将数据存储在共享内存中让每个 GPU Worker 直接从共享内存加载极大提升数据处理效率。
字节对集合通信初始化进行了显著优化解决了 GPU 规模扩大时使用 torch.distributed 进行 NCCL 初始化的高昂开销问题。在 2048 Ampere GPU 上初始化时间从原先的 1047 秒锐减至 361 秒效率大幅提升。同时全局 barrier 的优化也实现了复杂度从 O(n²) 到 O(n) 的跨越进一步提升了系统性能。这些优化确保了在大规模 GPU 环境中计算任务能更高效地执行。
6.2 监控容错
面对万卡级别的训练挑战软硬件故障频发。为确保训练稳定作者创新构建自动故障检测与秒级恢复机制实现高效容错大幅减少人工介入保障训练流程的高效与安全。
如图Figure 5所示作者构建了一套高效稳定的训练流程。用户提交任务后系统自动在各GPU上创建训练Executor并伴随训练守护进程定期向Driver发送包含多种信息的心跳信号以实现实时异常检测与告警。若Driver在指定时间内未接收到心跳将自动启动故障恢复流程确保系统稳定运行。
暂停所有训练的 Executor并执行一系列的自检诊断。一旦发现异常机器立即剔除并替换为等量健康机器。同时提供用户接口支持手动识别并剔除异常机器确保集群高效稳定。机器恢复后将自动从最新Checkpoint恢复训练。作者已优化Checkpoint的保存与恢复流程确保训练进度几乎不受影响高效便捷。 通过上述的守护进程可以收集详细的信息用于数据分析。其心跳信号包括 IP 地址Pod 名字硬件信息等还包含当前的训练进度信息。除此之外训练进程的 stdout/stderr 日志也会被收集以便进行实时的聚合、过滤和分析。如果识别到 warning 或 error 等关键字Driver 将实时的上报这些诊断信息。最后RAMA 的流量指标也会包含在内以便更好的识别网络利用率和通信效率。为了增强对训练稳定性和性能的监控字节开发了一个精确到毫秒级的监控系统以便进行更全面的评估。
自检诊断流程精准高效作者巧妙平衡诊断时长与准确性采用轻量级测试全面覆盖软硬件故障确保训练过程无忧。
机内测试 回环测试全面测量机器内RAMA网卡至内存、GPU等端点的回环带宽实施full-mesh测试覆盖所有链路组合精准识别PCIe配置中的潜在链路问题确保系统性能稳定可靠。RNIC-to-RNIC测试精准评估机内RNIC间连通性与带宽性能确保速度规格达标及时发现潜在路由问题保障网络高效稳定。NCCL测试精准高效包括机内All-to-All测试与TOR交换机间All Reduce测试旨在迅速识别并解决潜在硬件故障与性能瓶颈。
Checkpoint保存与恢复优化采用两阶段高效方案。第一阶段GPU训练进程迅速将显存状态写入主机内存借助高速PCIe带宽仅耗时数秒确保训练无间断。第二阶段后台进程异步将状态同步至HDFS分布式文件系统。此方案确保训练连续性与数据安全性极大提升效率。
在训练过程中作者还发现 MFU 会随着训练的迭代逐步下降但是单独测试机器的性能又没有发现明显的差异。为了诊断这些问题作者开发了一个性能剖析工具其会记录每个训练 Executor 中关键代码片段的执行时间。与 torch profiler 和 Megatron-LM timer 不同作者的工具基于 CUDA events可以最大程度减少对 CUDA 同步的需求从而避免性能下降。通过 profiler 工具作者发现训练过程中有 0.5% 的机器性能较差驱逐这些机器后 MFU 变得很稳定。 可视化工具能呈现DP、PP、TP等多种分布式视图如图8所示直观展示了PP数据依赖关系助您轻松洞察数据流向与关联。 为了提升基于NCCL通信库的多机RDMA网络性能在HPC测试中建议增大超时阈值。NCCL_IB_TIMEOUT的可调范围为1-22尽管NCCL 2.14版本后将默认值从14提升至18但推荐设置为22以优化性能。需要注意的是有推荐设置为23的情况但需谨慎调整。火山引擎GPU云服务器助力您轻松应对高性能计算挑战。核心问题在于网卡、AOC电缆与交换机间链路质量不佳。通过强化网卡信号、AOC电缆质量及交换机侧信号的质量管理我们成功将抖动频率控制在可接受范围内。
除了 NCCL_IB_TIMEOUT 之外也可以关注 NCCL_IB_RETRY_CNT 的配置表示重试次数默认配置为 7 即可。奇怪的是NCCL 官方文档并没有介绍 NCCL_IB_RETRY_CNT 的范围不过其对应的值为 3bit 数值最大也就是 7不确定超过 7 后会怎么处理可以参考如下图所示的 issue NCCL only use RDMA_WRITE/READ why it still got opcode 0 error 12 err · Issue #902 · NVIDIA/nccl · GitHub 七、DLRover
7.1 概述
阿里针对大规模LLM训练难题推出DLRover——一款自动化分布式深度学习系统。DLRover具备容错、Flash Checkpoint及弹性能力确保训练稳定高效。同时计划开源其性能分析工具xpu_timer进一步提升训练效率。立即体验DLRover轻松应对大规模LLM训练挑战。
7.2 容错自愈
DLRover通过自动节点检查与训练进程重启显著增强训练稳定性实现故障自愈有效降低人工运维成本优化流程高效便捷。
任务失败后保存 Checkpoint 并启动故障检测。检测到异常机器后会驱逐并找到新的机器替换。重新检测正常后重启任务加载最新的 Checkpoint 继续训练。 机器检测流程高效精简每个GPU启动子进程执行轻量级任务涵盖矩阵乘法与All Gather操作确保高效数据处理。 检测过程中Job Master巧妙地将节点配对成多个Group并在其内执行All Gather任务实时报告结果。一旦Group中节点检测失败即标记为潜在故障机。紧接着启动第二轮精准测试重新组合故障与正常机器从而精准识别故障源确保系统稳定运行。 7.3 Flash Checkpoint
DLRover发布的Flash Checkpoint实现大模型训练秒级容错详述了其卓越能力支持快速恢复训练中断确保数据完整性与训练效率为大规模模型训练提供强大保障。
DLRover独具断点续存功能故障时迅速将Checkpoint数据持久化存储确保数据不丢失大幅减少迭代时间损耗提升效率。内存热加载优化非宕机问题下重启训练进程即可从主机内存加载Checkpoint无需访问存储系统显著提升效率。
7.4 弹性
DLRover革新TorchElastic的ElasticAgent大幅增强弹性。训练任务遇挫或资源紧缺时能智能驱逐异常机器精简资源继续训练一旦资源充足即迅速扩容无缝衔接训练确保高效稳定。 7.5 Profiling 工具
作者最新推出的Profiling工具——xpu_timer为大模型训练提供全面故障排查方案。该工具截获Cublas/Cudart库利用cudaEvent精准计时训练中的计算与通信。更配备Timeline分析、Hang检测及栈分析功能确保训练无死角。尽管尚未正式开源但已展现出卓越性能与潜力。 -对此您有什么看法见解-
-欢迎在评论区留言探讨和分享。-
