如何在Databricks AI中保持GPU的可靠性

在Databricks AI，大规模分布式GPU训练已成为常态。然而，随着集群规模的扩大，GPU故障变得频繁且不可避免。本文将深入探讨如何通过系统化的方法保持GPU在高负载下的可靠性。

GPU在大规模训练中的失败模式

大规模GPU训练中的故障大致可分为三类。第一类是任务崩溃（Crashed Jobs），这是最直观的故障，表现为训练作业突然停止并出现NCCL看门狗超时错误。然而，超时本身通常无法揭示根本原因，需要跨硬件、网络、文件系统和软件层进行诊断。第二类是静默降速（Silent Slowdowns），这种故障下训练看似正常，损失函数也在下降，但整体吞吐量受限于最慢的GPU，导致计算资源和资金的浪费。静默降速通常源于硬件在降级状态下运行，例如热传感器触发、互连链路降速或内存带宽下降。第三类是数值错误（Numerical Corruption）。现代GPU使用ECC（错误校正码）技术自动修正瞬时内存错误，但并非所有错误都能恢复。未恢复的错误可能导致NaN损失、不稳定的收敛或模型质量下降，甚至需要事后才能发现。

压力测试与健康检查系统

Databricks AI采用独特的策略来应对这些挑战。首先，通过运行多样化的极端工作负载（如强化学习训练、智能体编码模型、文档智能系统）来对平台进行压力测试。这些工作负载以不同方式考验平台，从而提前暴露网络问题、热热点或集体通信的边缘情况。例如，一次训练运行在7小时后因NCCL超时而失败，最终追溯到单个Infiniband端口的一次长时间中断。这一发现促使团队调整了NCCL_IB_TIMEOUT参数，使其更具韧性。

其次，团队构建了名为gpu-monitor的多阶段健康检查系统，运行在每个GPU节点上，覆盖节点整个生命周期。该系统包含三个层次：

• 主动引导检查：在节点首次部署和工作负载启动前执行，验证GPU计算速度、GPU间点对点连接、节点内NCCL通信、RDMA带宽、ECC内存健康、PCIe拓扑和NVIDIA DCGM诊断等。未通过检查的节点立即从集群中移除。
• 被动连续检查：在节点运行期间持续监控，捕捉非确定性故障，如NVLink链路状态、GPU时钟降频原因、RDMA端口状态（基于累积停机时间而非抖动次数）、关键XID错误、PCIe AER错误、热梯度和NVSwitch错误状态。失败的节点会被隔离并重新测试。
• 定期多节点主动检查：在客户工作负载之间的空闲节点上运行，验证节点间互连行为。这些检查包括从8字节到2GB的NCCL集合通信带宽探测，覆盖不同算法路径（小消息的延迟主导、中消息的树/环切换、大消息的带宽限制）。检查标准根据有效载荷大小设定不同的延迟或带宽阈值。

这三个层次协同工作：在启动前验证硬件，运行时监控状态，在空闲时验证整体网络。随着新故障模式的出现，团队不断更新gpu-monitor并部署到整个集群。

结论

GPU可靠性是一个系统性工程。Databricks AI通过压力测试和健康检查系统的结合，将故障对训练的影响降到最低。本文只是系列的第一篇，后续将涵盖更高级的可靠性策略，如调度规避、优雅恢复等。对于任何运行大规模GPU训练的组织，理解故障模式并建立多层次检测机制是保障生产力的关键。