
Delta AI 集群的 GPU 故障分析和刻画
一、背景
我们在之前的文章中已经介绍过很多对大规模 AI 集群建设和维护相关相关的文章,包含 Meta、阿里、IBM、ImbueAI、字节、上海 AI-lab 等等。今天简单介绍一篇新的文章,其相对比较简单,主要关注 GPU 异常,与我们之前介绍万卡集群运维中的 Case 高度重合,但也有一些不一样的地方,就当简单回顾。
对应的论文为: [2503.11901] Characterizing GPU Resilience and Impact on AI/HPC Systems [1]
二、摘要
论文对 NCSA Delta AI 集群(算力超过 600 PFLOPs)的 GPU 故障特征进行了系统性分析。该集群包含多种 GPU 硬件(A40、A100、H100 等)以及部分 CPU 节点。基于两年半的 GPU 异常数据,评估了 GPU 硬件组件的可靠性特征,以确定不同组件的故障脆弱性及其对 GPU/节点可用性的影响。通过量化分析 GPU 硬件核心、NVLink 与显存系统的关键错误传播路径,进而考察了观测到的 GPU 错误对用户作业的实际影响。
三、引言
3.1 Delta 集群
如下图 Figure 2 所示,Delta 集群由 132 个 CPU 节点和 286 个 GPU 节点组成,共 1168 个 GPU,专门为运行多样化的科学研究及 AI/ML 工作负载而设计。具体包括:
- 132 个 CPU 节点。
- 100 个 4 x A40 节点,用于通用计算及轻量级 AI/ML 应用。
- 100 个 4 x A100 节点。
- 6 个 8 x A100 节点。
- 80 个 4 x GH200 节点。
网络层采用 HPE Cray Slingshot 11 互联架构(Dragonfly 架构),节点间通信带宽超过 400 Gbps,存储系统则基于 Lustre 分布式文件系统实现。
3.2 NVIDIA GPU 错误类别
NVIDIA GPU 错误会以 XID 错误形式上报,本文中作者根据 NVIDIA 开发手册(1. Introduction — XID Errors r555 documentation [2])、开发者论文、博客平台以及 Delta SRE 的评估,选取了被归类为高频且影响严重的 XID 错误子集,然后将其分为三类:
- GPU 硬件故障:重点研究核心硬件错误,包括:MMU 错误、GPU 掉卡、GSP RPC Timeout 及 PMU 通信错误等。此类错误可导致用户作业中断、GPU 挂起及数据损毁等。
- NVLink 互联故障:主要由 GPU 硬件缺陷、连接器故障或系统集成时安装不当引发,会造成 GPU 不可用及用户作业失败。此类错误还会阻碍 GPU 间数据传输,降低计算吞吐量。消除 NVLink 错误必须执行 GPU Reset 或节点重启操作。
- GPU 显存故障。本文主要研究的是 DBE(double-bit error),由于 SBE 可通过 ECC 机制自动校正,故未纳入记录范围。DBE 会触发下游错误恢复机制,若恢复机制失效则会导致 GPU/节点故障,需通过重启 GPU 或节点进行恢复。
如下图所示为作者集群中常见的故障:
- Category:上述 3 种错误类别。
- Count 出现的次数,越低越好。
- MTBE(mean time between errors),也就是平均无故障时间,越高越好。
- Persistence:错误持续的时间,越低越好。
上述错误也与我们之前梳理的常见错误类型高度重合,但也有些不一样:
- 我们遇到的 XID 94 比较多,而 XID 95 比较少。
- 我们遇到的 XID 74 很少。
- GSP 不只是存在 ERROR,在个别时候还会导致奇怪的性能问题,因此我们默认关闭 GSP。
- 我们经常遇到 48/63/94 一起出现。
- 很少遇到 XID 122 错误。
3.3 NVIDIA GPU 错误管理
NVLink 中提供了 CRC (Cyclic Redundancy Check) 错误检测机制,其核心目的是确保在通过高速 NVLink 互连传输数据时的数据完整性。当检测到 CRC 校验和错误时,系统将从最后已知的有效数据包开始重传。
如下图 Figure 3 所示,A40、A100 和 H100 的内存错误恢复流程如下:
- Ampere 和 Hopper 架构 GPU 应对 DBE 的主要机制是行重映射技术(Row Remapping)——通过备用行替换故障存储行,并记录行重映射事件(Row Remapping Event,RRE,XID 63)。若对应存储行无可用备用行,则标记行重映射失败(Row Remapping Fault,RRF,XID 64)。当存储体所有备用行耗尽导致 RRE 失败时,系统同样会记录 RRF。
- 虚线框展示了 A100 和 H100 的额外恢复机制。相较于 A40,A100 和 H100 GPU 支持不可纠正内存错误隔离(uncorrectable memory error containment)及动态页面离线(dynamic page offlining)技术以实现内存错误缓解。
动态页面离线技术通过将故障内存地址标记为不可用状态,无需 GPU 复位即可维持系统可用性。
错误隔离机制会终止使用故障内存地址的用户进程,从而阻止错误传播。抑制成功会报 Contained Memory Error(XID 94),抑制失败会报 Uncontained Memory Error(XID 95)。
3.4 数据源
作者分析基于 2022 年 1 月至 2024 年 5 月期间共计 855 天从 Delta 集群收集的数据。如下图 Figure 4 所示,数据处理流程包含多个阶段:
四、错误传播 & 关键发现
4.1 错误传播
4.1.1 GPU 硬件子系统
如下图 Figure 5 展示了 GPU 硬件组件间的错误传播情况。研究发现存在三条主要传播路径,其源头分别为:
- GSP RPC 超时错误:99%概率下,GSP 错误会导致同类错误重复发生或致使 GPU 进入不可操作状态。
- PMU SPI 通信错误:PMU SPI 通信错误会以 82% 概率向下游传播引发 MMU 错误,继而几乎 100% 导致作业失败。尽管从用户作业视角看 PMU SPI 通信错误属于高影响错误,但 NVIDIA 开发者手册未予重点说明。
- GPU 掉卡(总线脱落):通常是 GPU 与主板连接松动或散热导致的接触不良,最终几乎 100% 导致任务异常。
4.1.2 NVLink 互连架构
NVLink 是一种节点内 GPU 间高速互连技术,用于 GPU 间通信和数据交换。NVLink 故障可能影响单个或多个同节点 GPU。如下图 Figure 6 所示,作者在 3000 例 NVLink 错误中统计发现:
- 86% 的错误未发生跨 GPU 传播。
- 14% 的错误扩展到单个节点内的多个 GPU。
4.1.3 GPU 内存容错机制
如下图 Figure 7 展示了 GPU 内部不可纠正内存错误的恢复路径。由于 SBE 可通过 ECC 自动校正且不被记录,故未予呈现,这里展示的是 DBE 的恢复路径。数据显示:
- 43% 的 RRF 能成功实施错误隔离,GPU 可维持运行到下次维护窗口。
- 若 RRF 后未触发错误隔离(占 46%),GPU 将进入不可操作状态需执行复位。
- 内存错误隔离可能失败并导致未隔离内存错误。
- 总体而言,综合 RRE 与 RRF 后的错误隔离措施,70.6% 的 DBE 事件得到有效缓解且保持 GPU 持续运行。
4.2 关键发现
4.2.1 GPU 内存 vs 硬件可靠性
与常见认知相反,GPU 内存在 MTBE 方面比 GPU 硬件可靠 30 倍以上。
GPU 硬件和互连的 MTBE 为 800 节点小时,而 GPU 内存相关错误的 MTBE 为 26,093 节点小时。
4.2.2 GSP 是最脆弱的组件
新引入的 GSP 是最脆弱的 GPU 硬件组件。
超过 99% 的 GSP 错误会使 GPU 进入错误状态,导致用户作业失败。
GSP 错误需要节点重启,恢复时间可达 23 小时。
4.2.3 PMU SPI通 信错误的传播
PMU SPI 通信错误有 82% 的概率导致 MMU 错误。
MMU 错误几乎必然导致作业失败,系统可靠性受到严重威胁。
4.2.4 NVLink 错误特征
系统范围内 NVLink 错误的平均故障间隔时间仅为 6.9 小时。
遇到 NVLink 错误后,约三分之二的情况会导致作业失败。
剩余作业能成功完成,主要得益于 CRC 检测和重传机制的保护。
4.2.5 内存错误恢复机制
Ampere GPU 引入了创新的内存错误恢复技术,显著降低了 DBE 对应用的影响,将 DBE 对应用的性能损失减少了 70.6%。
4.2.6 GPU 错误与作业故障关联分析
作者针对最可能导致作业故障的特定 GPU 错误,对全部 GPU 故障作业进行细分统计。如下图 Table 2 所示,列出了各类 GPU 错误引发用户作业故障的概率分布。鉴于任何检测到的错误均可能导致作业故障,作者将 20 秒时间窗内出现的所有 GPU 错误均视为故障因素。可以看出,最常见的是 MMU 错误(XID 31),这个大部分与用户的应用有关。
五、参考链接:
- [1] https://arxiv.org/abs/2503.11901
- [2] https://docs.nvidia.com/deploy/xid-errors/
本文转载自AI闲谈,作者:AI闲谈
