随着大模型的迭代，其GPU用量也在不断增长。
Meta的Llama 1使用了2028块GPU，而到了Llama 3.1 405B，这个数字变成了16384。
规模如此庞大的超算系统迎来了可靠性和运行方面的巨大挑战——
据Meta最近公布的研究显示，Llama 3.1训练持续了54天，在此期间集群遇到了419次意外组件故障，平均每3小时发生一次!
在一半的故障案例中，罪魁祸首正是英伟达的H100 GPU及其板载的HBM3内存。
在超算领域，有一句古老的谚语，「大规模系统唯一可以确定的事就是发生故障」。
一个由成千上万个处理器、数十万个其他芯片和数百英里的电缆组成的超算集群，是极其复杂的。这样复杂的系统不可避免地会发生故障，甚至以几个小时为间隔单位都很正常。
开发人员要做的是确保系统在这些局部故障的情况下仍然能够正常运行。
Meta已经为抵御故障对系统的影响而耗费了不少精力，马斯克的包含10万块H100的超算集群比Llama 3.1的训练集群足足多了6倍，很难想象，其故障发生的频率将会有多高。
419次意外中断
Meta的Llama 3.1 405B的训练集群共包含16384个Nvidia H100 80GB GPU的集群上进行训练的。
1.6万块GPU训练的复杂性和潜在故障情况超出了Llama团队的既有经验，这是他们迄今为止运行过的最大的集群。
此外，训练的同步性也降低了容错性——单个GPU故障可能会导致整个训练任务中断，整个作业必须要重新启动。
在54天的预训练期间，共有466次作业中断，其中47次是计划内的，419次是意外的。
计划内的中断是由于自动维护，如固件和Linux内核升级、数据集更新等操作员发起的操作，这导致每天至少有一次训练中断。
而意外的中断主要是由硬件问题引起的，约78%的意外中断归因于已确认的硬件问题。如GPU或主机组件故障、静默数据损坏、计划外的单个主机维护事件等。
其中，GPU问题是最大的一类，占所有意外问题的58.7%（下图中红色部分）。
在419次意外中断中，有148次（30.1%）是由于各种GPU故障（包括NVLink故障）引起的，而72次（17.2%）是由HBM3内存故障引起的。
这并不意外——英伟达H100 GPU有着高达700W的功耗，并因此需要承受大量热应力。
相比之下，在54天内只有两个CPU发生故障（上图中蓝色部分）。
虽然GPU是最重要但也最脆弱的组件，占到意外问题的58.7%，但剩余41.3%的意外中断是由多种因素引起的，包括软件错误、网络电缆和网络适配器。
尽管故障数量众多，Llama团队还是保持了超过90%的有效训练时间，在训练期间仅有三次需要大量人工干预，其余问题均由自动化处理。
解决办法
为了提高效率，Meta团队减少了作业启动和检查点时间，并开发了专有的诊断工具。
PyTorch的NCCL飞行记录器被广泛使用，该功能可将集体元数据和堆栈跟踪记录到环形缓冲区中，从而使研究人员能够快速诊断大规模挂起和性能问题，尤其是NCCLX方面的问题。
NCCLX在故障检测和定位中发挥了关键作用，特别是在训练网络中，NVLink和RoCE的混合使用使大规模训练中的调试问题变得复杂。
对于NVLink和RoCE带来的复杂性问题，NCCLX通过与PyTorch的紧密协同设计提高了故障检测和定位的速度和准确性，允许PyTorch访问NCCLX的内部状态并跟踪相关信息。
虽然NVLink故障导致的停滞无法完全避免，但这个系统会监控通信库的状态，并在检测到此类停滞时自动超时。
除此之外，有时一些仍在运行但速度缓慢的滞留器很难被检测到。
Meta团队开发的工具，能够用于识别「拖后腿」的GPU。
这个工具的原理是对来自选定进程组的可能有问题的通信进行优先排序，只需调查几个最大的嫌疑人，通常就能有效地识别出滞后的GPU。
从而有效地检测和及时解决滞后问题，确保减慢速度的情况最小化，保持整体训练效率。
运行挑战
Meta透露，超算集群还有来自环境因素和功耗剧烈波动带来的运行挑战。
环境因素
Meta团队发现一个有趣的现象是环境因素对大规模培训性能的影响，研究人员注意到，吞吐量会有1-2%的昼夜变化。
这种波动是由于中午较高的温度影响了GPU的动态电压和频率缩放，从而影响训练性能。
功耗波动
Llama 3.1 405B大语言模型训练团队面临的另一个挑战是数万GPU同时功耗变化，这给他们的数据中心电网带来了压力。
这些波动有时高达数十兆瓦，达到了电网的极限，这意味着Meta必须确保其数据中心有足够的电力。
在训练过程中，数以万计的GPU可能会同时增加或减少功耗，例如，由于所有GPU都在等待检查点或集体通信的完成，或者整个训练任务的启动或关闭。
当这种情况发生时，整个数据中心的功耗会瞬间波动数十兆瓦，从而挑战电网的极限。
Meta认为，在为未来更大型的Llama模型扩展训练时，这将会是一个持续的挑战。
