AI Infra: 10k-GPU cluster
导言
- 为什么需要万卡集群
- 万卡集群的使用难点
- 应对方案
问题¶
节点故障、性能抖动、通信与存储瓶颈，在集群规模被放大之后都会成为常态问题，很多在千卡规模下可以容忍的风险，在万卡场景中都会被大幅放大。1
方案¶
- 并行策略选择（SimuMax）1
- 训练前的模拟与起飞检查:
- 训练启动前，会先运行一组特定的benchmark（基准测试），对计算节点、网络、存储以及调度节点进行全面检查。
- 当检测出问题后，起飞检查会自动剔除异常节点，不再依赖人工介入，实现真正的无人值守训练启动。
- 异步 Checkpoint:
- 先将checkpoint写入本地内存，后续再异步写入存储系统，将checkpoint时间压缩到秒级。
- 在DP并行策略的情况，并不需要每个节点都写checkpoint，我们对checkpoint进行切片，由不同节点负责不同分片，避免重复写入和资源浪费。
- 如果某个负责分片的节点发生故障，则会分配其他节点完成写入任务。在读取阶段，如果某个节点挂掉，完全从后端存储读取会非常慢，我们采用了P2P机制，直接从其他节点的内存中加载checkpoint，将加载时间压缩到半分钟以内。
- 有了这些优化，我们可以用非常高的频率来做checkpoint，例如每十分钟做一次。
- 慢节点治理:
- 慢节点的发现通常有两个来源：一类是节点或卡本身处于亚健康状态，在起飞检查阶段可以发现；另一类是在运行过程中出现亚健康状态，需要运行时的检查。
- 解决方案是在训练过程中引入了整体监控机制。 1. 训练包含前向传播和反向传播，中间包括多个通信与计算步骤，我们会监控这些步骤的执行时间。 2. 计算和通信步骤的执行时间整体上符合统计分布规律，但不能拿绝对值去看每个步骤的快慢，不同的模型时间不一样，我们通过聚类分析识别某些异常的慢节点，并自动剔除，整个过程完全自动化。
- 静默数据错误:
- 与引起训练报错甚至中断的问题不同，静默数据错误不会触发异常，也不会中断训练，数值看起来“正常”，但实际上已经发生错误。
- 造成原因: 1. 一种是计算硬件有一定的故障率，在一定概率下可能会算错，就会造成静默数据； 2. 另外，内存或显存上的ECC特性对性能的影响比较大，在训练的过程可能没有开启； 3. 在传输的过程中，也会出现纠错码失效的情况，导致误码没有被发现。
- 影响： 1. 对于轻微的数值错误，在万亿参数规模下往往会被其他数值平均掉，影响不明显，可以继续训练。 2. 有一类是严重错误，可能导致Loss值或梯度出现一个非常大的偏差，Loss曲线会出现异常尖峰，频繁出现时会影响模型精度。如果这种问题经常发生，会导致训练精度的下降。 3. 还有一种致命错误，数值异常传递并最终导致出现NaN 或Inf，导致训练中断，只能回退到之前的checkpoint进行回训。
- 方案： 1. 一方面在硬件验收阶段和训练起飞检查阶段进行压力测试，尽早识别“体质较弱”的卡； 2. 另一方面，压测要多算子覆盖，除了GEMM、Attention外，还会用一些执行较少的算子，因为不同算子会用到卡的不同部件，达到全面压力测试的目的。 3. 同时，我们重点监控温度、电压等关键硬件指标，这些异常往往与错误高度相关。
- Hang (挂起/假死) 问题
- 原因：通讯死锁为主
- 监控：心跳监控、Watchdog 机制、自动化巡检
- 方案: 1. 一般情况下，Hang通过重启即可恢复， 2. 但如果某个节点经常Hang，会导致训练非常不稳定，此时需要将该节点剔除。解决Hang问题后，整体训练稳定性会有明显提升。
- Inf/NaN 稳定性问题
- 难点在于传播性， Inf加减任何正常值，都会把正常值“吃掉”。
- 方案：重点关注 Inf/NaN 最早出现的位置和时间点，定位那些频繁触发异常的算子或阶段。