在大型 GPU 集群上训练 AI 模型给模型构建者带来了重大挑战。随着作业规模的增加，人工干预变得不切实际，因此自动化对于保持高 GPU 利用率和训练生产力至关重要。卓越的训练体验需要具有弹性的系统，这些系统可提供低延迟错误归因，并根据根本原因分析自动进行故障转移。自动化并不新鲜。Health checks、preflight checks、syslogs 和 telemetry 都适用于各种硬件和软件组件。遗憾的是，其中大多数对最终用户来说是不透明的，并且难以访问和用作一线工具。
在大多数情况下，模型构建器首先在训练过程中遇到问题。他们必须与基础设施和运营团队合作，收集必要的数据来分类问题，例如，错误是否是由硬件或软件引起的，或者是间歇性的还是持久性的。
这种昂贵的人工干预过程会拖慢整个开发周期，并阻碍快速实验。随着研究人员扩大实验规模，所涉及系统的组合复杂性也加剧了这一问题。本文将介绍如何在 NVIDIA DGX Cloud 上实现可靠、高效的大语言模型 (LLMs) 训练。我们介绍了我们的团队在训练 NVIDIA Llama Nemotron 和其他基础模型时遇到的一些挑战，重点介绍了提高弹性训练的机会，并展示了 DGX Cloud 如何在 2K-10K GPU 规模的训练中实现约 1% 的硬件机时间的一些想法。
更大限度地减少机时间
作为模型构建者，当您在训练过程中遇到错误时，关键的挑战是识别原因、找到问题并找到一种方法来保持工作进展以避免延误。在需要工程师干预以进行恢复的环境中，这种延迟会进一步加剧，这通常会增加 triage 和 remediation 的时间。
由于这些干预和延迟会对工作效率产生重大影响，因此务必要有一个指标来反映您的实际体验以及在将训练重新上线时遇到的困难。传统指标，例如主要反映硬件利用率的 MFU 和衡量平均故障间隔时间的 MTTF，侧重于基础设施效率，而非完整的训练体验。它们没有完全考虑您的观点，即不仅因崩溃而损失的时间，还包括 checkpoint、因错误而损失的工作以及 restart 所损失的时间。
为了捕捉这些真实世界的成本和痛点，我们专注于停机时间，即从模型构建器的角度来看，非生产性训练的总时间。这包括以下内容：
- 检查点时间：训练循环被阻塞以保存检查点。
- 丢失的工作 ：迭代在关闭前的最后一个检查点后丢失。
- 关闭时间： 从上次迭代到系统停止。
- 重启时间： 从作业启动到重新开始富有成效的训练
当硬件或基础架构发生故障时，这些问题都会受到影响。因此，在我们寻求改善开发者的训练体验时，downtime 是尝试最小化的关键指标。
在整个训练过程中，减少机时间既需要反应灵敏的系统，也需要主动式系统。大规模出现错误是不可避免的，而检测和恢复的速度至关重要。对于应用程序和硬件故障，错误属性是关键。
系统必须确定问题是否需要用户干预，或者是否可以自动解决，例如，通过排除不良节点并自动重启，或在通知用户之前多次重试。在本文中，我们主要侧重于改进错误属性，将恢复时间和特定自动化技术留待未来研究。
错误归因
对于错误归因，我们将研究人员遇到的错误大致分类为以下主要类别：
- 即时崩溃 ：起源于硬件故障，如 BIOS、电源或热问题、不可纠正的 ECC 错误、无提示的数据损坏（中间结果中的 NaN）或网络不稳定（链路抖动）。
- 通信库中挂起 ：通常表现为 PyTorch NCCL watch dog 错误和 Transformer Engine 通信挂起。挂起通常是由于从文件系统 (例如，输入数据) 和从张量 (例如，梯度、中间激活函数等) 传输数据时的级联依赖性，特别是在东西向 (E/W) 网络中。这凸显了在库和应用中对稳健的容错、遏制和早期检测机制的需求。
- 速度回归 ：这些包括瞬时减速 (例如，临时网络或存储问题) 和持续瓶颈 (例如，大型集群中的 GPU 持续缓慢)。这些回归会显著影响整体训练速度和效率。
虽然此类故障可能源于底层硬件、基础设施或软件问题，但从您的角度来看，它们通常会显示为训练期间的突然中断或严重减速。通过识别这些常见的故障模式，我们可以更好地开发解决方案和流程，使研究人员能够保持势头并保持工作流程向前发展。
图 1 突出显示了 6K GPU 训练运行中不同故障类型的分布。虽然研究人员通常会将这些故障视为单个错误，但要找出根本原因，还需要进行更深入的分析。我们发现，关联集群、节点和应用程序遥测可提高速度和准确性，从而提供有效的补救策略
集群遥测
此遥测包括存储服务器，涵盖元数据操作、读/写操作和交换机。这种可见性至关重要，因为一个节点的故障通常会通过通信调用、传递损坏的梯度或使存储系统过载而扩散到其他节点。
例如，如果单个作业因生成过多元数据操作而使存储节点不堪重负，则其他作业或节点可能会因此遇到性能问题。
节点遥测
节点级别的定期健康检查可确保关键的硬件和软件组件（例如 GPU、CPU、内存、网络、存储和服务）正常运行。作业开始前的初步检查还会验证硬件状态、验证软件依赖项以及为任务配置环境。
这种对潜在问题的早期检测可缩短调试时间并提高整体可靠性。作业完成后，清理例程回收资源、存储日志并将系统恢复到清理状态。这些也称为 prolog 和 epilog 脚本。
应用程序日志
应用对关键控制点、不变量和进度衡量标准（包括系统错误和性能模式）拥有关键知识。它们为错误属性提供了最强大的信号之一，尤其是在与中央存储库中的历史数据关联以发现随时间推移反复出现的故障时。
例如，这些日志有助于确定是否存在掉队者、挂起，或者故障是否间歇性或反复发生。某些错误 (例如 NaN 错误) 在相同的迭代和秩中确定性地出现，但不同的物理节点可能是应用程序错误。但是，在无此类模式的节点上反复出现的相同错误可能表明硬件故障更加严重。
统一遥测
在 作业内部 (单个作业内) 和 作业间 (跨多个作业) 上下文中分析这些时间数据有助于识别反复出现的问题、检测模式，并采取主动措施，而不是被动反应。
通过推荐、警报和可视化，运营团队和研究人员可以共享这种统一的遥测数据，确保这两个团队对系统行为和故障模式有一个共同的看法。
这种遥测的交叉授粉意味着研究人员可以利用基础设施数据来改进调试，而运营团队则使用应用程序见解来改进系统自动化，以减少硬件停机时间。
虽然机时间是规模的函数，但对于使用约 1 万个 GPU 运行的训练，由于这些技术的硬件故障，我们实现了不到 1%的机时间。我们的结果是在 NVIDIA DGX Cloud 上针对 2024-2025 年运行的 Nemotron 模型系列训练取得的。我们将硬件机时间计算为所有作业中可归因于硬件故障的总机时间的百分比平均值。
结语
我们发现，端到端弹性需要一个整体的视角。长的正常运行时间取决于涵盖基础架构和开发者体验的综合方法。
这种方法可以连接应用程序和基础设施，提高调试速度和准确性，同时实现更主动的系统。它可以帮助研究人员在发生故障时高效解决问题，并减少在诊断反复出现的问题时出现的摩擦。对于模型构建器而言，强大的错误归因系统对于实现有效的自动化至关重要。借助这种自动化技术，研究人员无需全天候监控作业即可训练模型。
除了充分利用 GPU 之外，这还可以帮助您和 DGX Cloud 上的其他研究人员专注于真正重要的事情：开发模型、推动科学发展，以及将繁重的工作交给我们。
如需了解有关在 DGX Cloud 上训练弹性服务的更多信息，请报名参加 Cloud-Native Approach to Achieving Training Resilience and Efficiency at Extreme Scale GTC 会议。如需详细了解我们如何加速您的预训练和后训练工作负载，请联系我们。
