​​【本文正在参与 AI.x社区AIGC创新先锋者征文大赛】​​​​​​

作者 | Soumith Chintala

编译 |岳扬

我的好友 Francois Fleuret 提出了上述问题。我迅速总结了一些在大规模训练领域中相当普遍的知识，内容分为三部分。

01 如何将尽可能大的神经网络和 batch-size 适配到那 10000 张 H100s 上

1.1 并行策略

持续优化并行策略，直到所有 GPU 都能被高效利用，达到最高利用率。

1.2 Checkpointing / Compute vs memorize

02 尽可能高效地在 GPU 集群间传递模型状态信息

2.1 Communication overlap 策略：

在需要 GPU 间通信时，应尽可能早地启动通信过程：

2.2 探索并利用网络底层拓扑结构：

在多个计算节点间传递大量模型状态信息（如梯度、优化器状态信息）是一项复杂的任务。在使用 Sync SGD 时，需要尽可能快地集中传输这些状态信息。

网络中可能包含多层交换机，并具备 RDMA 能力（可以直接将 GPU 内存中的数据复制到网卡，完全绕过 CPU 内存），同时拥有前端和后端网卡（前端网卡连接到如 NFS 之类的存储系统，后端网卡则将 GPU 连接到集群中的其他 GPU）。

因此，在执行 all-reduce 或 scatter/gather 等通信操作时，充分利用这些网络信息至关重要。例如，通过树形归约算法（tree-reduce），all-reduce 操作的时间复杂度可以降低到O(log(n))；同时，网络光纤连接节点间的不同类型光纤对常数因子的影响，对于减少整体延迟时间也是非常重要的。

像 NCCL 这样的库能够智能地识别底层网络拓扑，并在执行 all-reduce 和其他通信操作时加以利用。

在这样的大规模计算中，我们还必须调整交换机和网卡中的数据包路由算法，以实现有效的负载均衡。交换机也需要大量的 HBM 内存（不仅仅是 GPU 需要），因为当数据包排队等待时，需要在某个地方排队而不会被丢弃——这就是交换机级别的 HBM 内存。

03 如何在遇到硬件或软件故障时，尽可能迅速地恢复系统？

故障是不可避免的，涉及GPU、网卡、电缆等多种硬件。有些故障能够迅速被发现，而有些则可能因为某个节点没有按时响应（比如 NCCL 的 all-reduce 操作卡住了）才被察觉。我们开发了多种工具来监控机群的健康状况，并尽可能快地将故障节点从机群中移除。这可不是一件容易的事。

在这种规模下，内存位随机翻转导致的隐性数据损坏概率增加，可能导致训练 loss 值异常升高。虽然这种问题在小规模系统中很少见，但在大规模系统中则可能频繁发生。在软件层面提前检测这种问题非常困难。一些硬件设备配备了内置校验和的电路，可以在计算后进行校验 —— 这样，一旦发生位翻转，硬件就能触发中断。但 H100 和之前的 NVIDIA GPU 都不具备这一功能。

为了应对这些故障，我们需要尽可能频繁且迅速地保存模型状态信息；一旦发生故障，我们也要能够迅速恢复并继续训练。通常，我们会迅速将模型状态信息另存到 CPU 内存的一个独立线程中，并在后台将数据从 CPU 内存写入到磁盘或远程存储系统。我们还以分片的形式保存模型状态信息（利用了 torch.distributed 的 checkpointing 功能），也就是说，不是每个 GPU 都需要保存完整的模型权重；每个 GPU 只需保存一部分权重 —— 其余部分可以通过其他 GPU 的分片 checkpoints 来恢复。

Thanks for reading!

Hope you have enjoyed and learned new things from this blog!

About the authors

Soumith Chintala

Cofounded and lead@PyTorchat Meta. Also dabble in robotics at NYU. AI is delicious when it is accessible and open-source.

本期互动内容