每3个小时1次、平均1天8次，Llama 3.1 405B预训练老出故障，H100是罪魁祸首？

　　Llama 3.1在为期54天的预训练期间，经历了共466次任务中断。其中只有47次是计划内的，419次纯属意外，意外中78%已确认或怀疑是硬件问题导致。

　　Llama 3.1 405模型是在一个含16384块Nvidia H100 80GB GPU集群上进行训练的。虽说针对大规模系统有句老话：唯一确定的就是会出故障。

　　具体来看，在419次意外中断中，148 次（30.1%）是由各种GPU故障（包括NVLink故障）引起的，72次（17.2%）可以具体到是由HBM3内存故障引起。

　　不过最终，Llama 3.1团队保持了超90%的有效训练时间。只有三起故障需要人工大幅介入，其余的都自动化处理了。

　　为了增加有效训练时间，Llama 3.1团队表示减少了任务启动和checkpointing时间，并开发了一些工具来快速诊断和解决问题。

　　其中广泛使用了PyTorch的内置NCCL flight recorder（Ansel等人2024年开发），是一个可以把集体元数据和堆栈跟踪记录到一个循环缓冲区里的功能，这样就能快速诊断大规模卡顿和性能问题，特别是跟NCCLX有关的问题。

　　用这个工具，团队能有效记录每次通信事件和每个集体操作的持续时间，在NCCLX Watchdog或Heartbeat超时时还能自动导出跟踪数据。

　　还可以根据需要，通过在线配置更改（Tang等人2015年提出的方法）来选择性地启用一些计算量更大的跟踪操作和元数据收集，而不需要重新发布代码或重启任务。

　　团队表示，在大规模训练中调试问题很复杂，因为网络同时使用了NVLink和RoCE。通过NVLink传输数据通常是通过CUDA内核发出的加载/存储操作来完成的，如果远程GPU或NVLink连接出了问题，往往表现为CUDA内核里的加载/存储操作卡住了，却不会返回明确的错误代码。

　　而NCCLX通过与PyTorch紧密配合，提高了故障检测和定位的速度和准确性，让PyTorch能够访问NCCLX的内部状态并跟踪相关信息。

　　此外，NCCLX还会跟踪每次NCCLX通信的内核和网络活动，并在失败时提供NCCLX集体操作内部状态“快照”，包括所有等级之间已完成和待处理的数据传输。团队通过分析这些数据来调试NCCLX的扩展问题。

　　有时，硬件问题可能导致某些部分虽然看起来还在运行，但速度变慢，这种情况很难被发现。即使只有一个部分变慢，也可能拖慢数千个其它GPU的速度。

　　为此团队开发了一些工具，可以优先处理某些可能有问题的进程组的通信。通常只需要调查几个最可疑的对象，就能有效找出那些变慢的部分。

　　团队还观察到了一个有趣的现象——环境因素对大规模训练性能的影响。在训练Llama 3.1 405B时，吞吐量会根据一天中时间的不同而有1-2%的变化。这是因为中午温度较高，影响了GPU动态电压和频率调节。

　　在训练过程中，数万个GPU可能会同时增加或减少功耗，比如在所有GPU等待checkpointing或集体通信完成时，或者在整个训练任务启动/关闭时。这种情况发生，可能导致数据中心的瞬时功耗波动达到数十兆瓦，对电网来说是个不小的考验。

　　Meta2022年首次分享了其AI研究超级集群（RSC）的详细信息，当时拥有16000个NVIDIA A100 GPU，帮助其构建了第一代AI模型，在Llama初代和Llama 2开发中都发挥了重要作用。

　　更是定下了到今年年底增加350000个NVIDIA H100 GPU的目标，作为整体算力的一部分（整体算力近600000个H100 GPU）。

　　这么大的规模，emmm可不是个持续性的挑战嘛。当然，大规模AI集群会给模型训练造成故障是一个有些“远古”的问题，很早之前就有相关研究。

　　在去年最新MLPerf训练基准测试中，英伟达H100集群，横扫八项测试，全部创下新纪录，并且在大语言模型任务中表现尤为突出。

　　11分钟内训练一遍GPT-3，8秒训完BERT。在大语言模型任务中，H100集群的加速性能逼近线性增长。即随着集群处理器数量增加，加速效果也几乎同比增加。

　　除此之外，H100还完成了推荐算法、CV、医学图像识别以及语音识别等任务，是唯一一个参加8项测试的集群。

　　不过，SemiAnalysis一个月前的一篇文章指出，构建大规模AI算力集群非常复杂，远远不只是有没有钱买卡的事。

(责任编辑：管理)