跳转至

How we keep GPUs reliable across Databricks AI

Ch01.055 How we keep GPUs reliable across Databricks AI

📊 Level ⭐ | 8.3KB | entities/how-we-keep-gpus-reliable-across-databricks-ai.md

How we keep GPUs reliable across Databricks AI

已评分 | v*c=72 | value=8 | confidence=9 | stars=4

摘要

Databricks AI 团队分享了其在大规模 GPU 训练可靠性方面的实践经验。文章系统梳理了 GPU 在大规模训练负载下的三种故障模式（任务崩溃、静默降级、数值损坏），以及 Databricks 应对这些故障的多阶段健康检查体系。系列开篇聚焦于故障模式的分类和检测方法。

背景

分布式 GPU 训练已成为行业常规操作。团队现在训练基础模型、微调前沿模型、构建大规模视觉系统和运行深度推荐网络——规模之大曾是前沿实验室的专属。Databricks AI 每周运行大规模训练工作负载，故障持续出现在硬件、网络和软件层面。

GPU 训练负载下的三种故障模式

1. 任务崩溃（Crashed Jobs）

分布式训练任务因多种原因崩溃：GPU 降级或从总线断开、RDMA 网络问题、I/O 系统挂起、CPU 端 rank 与其他 rank 发散。从工作负载视角看，几乎所有故障都以同样的方式呈现——任务因 NCCL 看门狗超时而崩溃。每个 rank 都在同一集合操作上阻塞，看门狗最终杀死任务，然后从上一个检查点重启。但超时本身几乎无法说明根因。诊断实际问题通常需要从仅显示症状的堆栈跟踪出发，跨越硬件、网络、文件系统和软件层进行追踪。

2. 静默降级（Silent Slowdowns）

静默降级的 GPU 可以继续训练，日志正常显示，损失仍在下降。然而，吞吐量受限于最慢的 GPU，浪费算力和资金。这些降级源于硬件的退化状态：热传感器在持续负载下触发、互连链路在持续错误后降级、内存带宽随故障累积而下降。每种情况表现在不同的硬件级信号上——例如 DCGM 节流原因中的 HW_SLOWDOWN 或 HW_THERMAL_SLOWDOWN。

3. 数值损坏（Numerical Corruption）

现代 GPU 使用纠错码（ECC）检测并自动纠正许多瞬时内存故障而不中断训练。但并非所有故障都能恢复。损坏可能源于内存、互连、内核或软件层，并在被检测或遏制之前扩散。在这些情况下，训练可能立即停止或继续使用错误的值。故障可能表现为 NaN 损失、不稳定的收敛，或仅在后期才发现的模型质量退化。

深度分析

1. 三种故障模式的"可见性"与"危害性"的逆相关

Databricks 的分类揭示了一个重要的系统可靠性洞察：故障的可见性与危害性之间存在逆相关。任务崩溃（crashed jobs）最明显——团队立即知道发生了故障，但这类故障的恢复也最简单（只需从检查点重启）。相反，静默降级（silent slowdowns）和数值损坏（numerical corruption）几乎没有外部信号，但危害更大——前者浪费大量算力和时间而无人知晓，后者可能产生看似成功但结果错误的模型输出。这种"隐形但危险"的故障模式是所有大规模分布式系统的共同挑战。

2. NCCL 看门狗超时：症状的聚合器而非故障的定位器

文章中一个关键洞察：几乎所有分布式训练故障最终都表现为 NCCL 看门狗超时，但这个超时信息几乎不包含任何根因线索。这意味着故障诊断必须采用跨层的根因分析方法——从堆栈跟踪中唯一的症状出发，同时检查 GPU 硬件状态（DCGM 指标）、互连网络（RDMA 链路健康）、I/O 系统（存储延迟和吞吐量）、CPU 层（rank 进程状态）和软件层（框架日志和 NCCL 调试信息）。这与 Meta 的 AI 存储架构 中讨论的存储延迟问题形成直接关联——存储系统 I/O hang 也是 NCCL 超时的常见来源之一。

3. GPU 硬件故障率 vs 传统硬件的显著差异

文章末尾指出"GPU 硬件故障事件率可能比其他硬件高一个数量级"——这是理解 GPU 基础设施运维挑战的核心数据点。高故障率意味着：(1) GPU 集群的运维模式必须从"故障→修复"的被动模式转变为"预测→预防"的主动模式；(2) 检查点频率、弹性训练（elastic training）和渐进式降级策略成为必备而非可选；(3) GPU 集群的规模和故障率之间的权衡成为关键架构决策——更大的集群意味着更频繁的故障，需要更精细的分区和隔离策略。

4. 多阶段健康检查体系的必要性

针对三种不同类型的故障，需要不同层次的检测机制：任务崩溃可以通过看门狗和心跳检测（秒级），静默降级需要通过 DCGM 指标的持续监控和基线比较（分钟级），数值损坏则需要通过验证集评估的长期趋势分析和 ECC 错误计数的异常检测（小时级）。Databricks 的多阶段健康检查体系正是针对这种时间跨度和检测粒度的差异而设计的。有效的 GPU 可靠性体系应当是分层的——每一层针对特定的故障模式和时间尺度，各层之间通过告警和自动恢复机制联动。

5. 对 AI 基础设施运维的启示

Databricks 的实践为大规模 AI 设施运维提供了几个重要参考：(1) 监控体系必须覆盖从硬件传感器到应用层指标的全栈；(2) 静默故障的检测比显式崩溃更重要——这些是最隐蔽的成本漏洞；(3) GPU 的可靠性工程需要专门的工具和知识体系（如 DCGM、NCCL Flight Recorder），不同于传统服务器运维；(4) 故障恢复的自动化程度直接影响训练效率——从检查点恢复的速度和弹性训练的能力是核心竞争力。这些发现与 Graviton 优化 Agentic RL Sandbox 中讨论的算力成本优化互补——可靠性问题直接影响 GPU 的有效利用率和单位算力成本。

实践启示

  1. 监控静默故障优先于显式故障：静默降级和数值损坏的检测难度大、危害性高，应作为 GPU 可靠性工程的首要关注点。部署 DCGM 持续监控、设置基线比较告警、定期检查 ECC 错误计数。

  2. 建立跨层根因分析能力：NCCL 超时无法定位问题根因。需要构建同时覆盖 GPU 硬件、网络互连、存储 I/O 和软件栈的联合监控和诊断体系。

  3. 弹性训练和检查点是王道：面对一个数量级更高的 GPU 故障率，频繁的检查点和弹性训练（节点故障时不中断训练，仅移除故障节点）应成为标配而非加分项。

  4. 验证集评估是最后的防线：对于数值损坏类故障，监控 NaN 损失和损失收敛曲线是最有效的检测手段。在每个训练阶段后进行验证集评估，作为"模型健康"的最终判断。

  5. 热管理和互连健康不容忽视：静默降级的主要来源是热节流和互连链路降级。确保 GPU 集群的散热设计冗余、监控互连链路健康状态（链接速度、重试率、错误计数）。

相关实体

来源

→ 原文存档