GPU 集群的故障工程：故障率、巡检与自愈

GPU 故障工程：万卡集群的日常（手绘信息图）

故障的规模：为什么万卡集群「每天有故障」

大规模 GPU 集群的故障率可以用概率算出来：一张 GPU 的月度故障率约 1–2%（业界估算），一个 10000 卡的集群每天平均有 3–5 张卡出问题。故障的频率公式：集群越大 × 单卡故障率 = 每天固定次数的故障——故障不是「会不会发生」而是「今天会发生几次」。再加上网络的抖动（本库 RDMA 篇）、存储的抖动、电力与冷却的波动——大规模训练/推理系统的设计前提就是「故障是日常」（本库断点续训篇与可观测性篇的工程前提）。

故障的类型学：从 ECC 到整机故障

GPU 故障的类型学，按严重程度分级。级一：可纠正错误（ECC 可纠）。显存的 ECC 单比特错误（HBM 的 ECC 自动纠正——常态发生的、无感知的），ECC 错误率的异常升高是前兆信号（纠错率上升 = 这张卡在退化——预测性维护的指标）。级二：不可纠错误（ECC 不可纠/DUE）。显存的不可纠错误——导致 kernel 崩溃或计算结果错误——卡需要隔离。级三：卡故障。GPU 掉卡（PCIe 链路断开——机器内少一张卡）、XID 错误（NVIDIA 的驱动错误码——XID 79/48 等典型码的分类）、温度与降频（散热问题的降频——性能损失但没死）。级四：整机/机柜故障。电源模块、NVSwitch、交换机、网络链路——影响面大。故障的定位工具：XID 码的对照表（NVIDIA 官方的 XID 类型学——每个码的含义与处理建议）、nvidia-smi -q 的健康状态（ECC 计数、温度、功耗）、DCGM（数据中心的 GPU 监控框架——DCGM 的诊断与导出是集群 GPU 运维的标准工具）。

巡检与预测性维护：在故障前换卡

巡检与预测性维护的体系。巡检的指标。ECC 错误率趋势（纠错率上升 = 退化预警——趋势比绝对值重要）、温度与功耗的模式（异常的温升/功耗——散热问题的前兆）、降频的记录（时钟频率的异常下降）、以及NVLink/PCIe 的错误计数（链路层的退化）。预测性维护的逻辑：故障前的信号（ECC 纠错率上升、温度异常——多数故障有前兆：慢性劣化而非突然死亡）→ 主动隔离与换卡（在它造成训练中断前换掉——换卡的成本 << 训练中断的成本）。巡检的自动化：DCGM 的指标采集（Prometheus 集成——本库可观测性篇）+ 异常检测（ECC 趋势的告警规则）+ 巡检的例行化（每日的健康报告、每周的深度诊断——dcgmi diag 的深度诊断级别）。巡检的 ROI：一次预测成功的换卡，省下的是一次数小时训练中断 + 排查——巡检的投入在第一次成功预测时回本。

自动化的故障自愈：从告警到自愈的闭环

故障自愈的闭环（本库后台智能体篇的「自愈」在 GPU 集群的应用）。自愈的三层。层一：任务级的自愈——训练任务遇到卡故障：自动检测（XID/ECC 异常）→ 自动隔离坏卡 → 从 checkpoint 恢复（本库断点续训）——重启的自动化（Slurm/K8s 的自动重启 + 换节点的调度）。层二：服务级的自愈——推理副本的 GPU 故障：健康检查摘除坏副本 → 新副本拉起（换节点）——K8s 的机制自动完成（本库 K8s 篇）。层三：硬件级的工单——自动化生成硬件工单（坏卡的服务器自动标记、通知机房换卡——从「告警」到「工单」的自动化闭环，本库后台智能体篇）。自愈的纪律：自愈的边界（自动修复「已知模式」、人工介入「未知模式」——本库后台篇的原则）、自愈的验证（演练：人为注入故障验证自愈链路——本库断点篇的演练纪律）、以及故障的台账（每次故障的记录与分析——故障台账是集群运维的知识资产，本库断点篇）。故障工程的收束：GPU 集群运维的成熟标志，不是「零故障」，是「故障的 MTTR（平均恢复时间）足够短」——检测自动化（巡检）、恢复自动化（自愈）、知识沉淀化（台账）——三件事做好了，故障从「事故」变成「日志里的一行」。

GPU 故障的实战案例：一次训练中断的排查

GPU 故障（正文类型学）的实战案例：一次训练中断的完整排查。症状：训练到第 14 万步，任务突然崩溃，日志显示 XID 79（GPU 掉卡）。排查的四步。第一步：现场保全——dmesg 与 XID 日志的保存（故障现场的第一手证据：XID 码、时间戳、涉及卡位）、checkpoint 的确认（最后一次 checkpoint 的时间——损失多少步）。第二步：卡的健康诊断——DCGM 的诊断（dcgmi diag -l 3 的深度诊断）、ECC 计数的检查（该卡的 ECC 纠错率——是否早有前兆）、温度与功耗的历史（巡检数据里这张卡的历史）。第三步：处置的决策——换卡（这张卡的历史显示 ECC 上升趋势 = 退化的卡——换卡而非重试）、任务的恢复（隔离坏卡、从 checkpoint 恢复、跳过坏节点继续——本库断点篇的恢复流程）。第四步：闭环。故障的台账（故障记录：时间、类型、根因、处置、恢复耗时——本库正文的故障台账）、预防的落实（同批次卡的巡检加强——同批次的卡可能有同样的隐患）、以及自愈链路的检查（为什么自动隔离没有更早触发——自愈链路的改进）。案例的收束：一次 GPU 故障的排查，是「现场保全 → 诊断 → 处置 → 闭环」的四步舞——每一步都有工具与纪律；四步舞练熟了，GPU 故障从「惊吓」变成「流程」。

GPU 故障的预防：从巡检到供应链的全方位

GPU 故障（正文巡检）的预防体系：从巡检到供应链的全方位——故障预防的完整体系。预防的第一层：巡检的自动化（本库正文的巡检体系——DCGM 指标的自动化采集与告警）。预防的第二层：负载的均衡。热点的管理（GPU 的温度与功耗的分布均衡——热点是故障的加速器：负载均衡的调度（故障的预防性调度——本库训推一体篇）、散热的优化（气流与温度的管理——本库电力篇的冷却）。预防的第三层：供应链与批次管理。卡批次的质量追踪（同批次的故障率统计——某批次的高故障率 = 采购决策的数据）、供应商的质量反馈（故障数据反哺采购——用故障台账跟供应商谈判）、以及备件的储备（坏卡更换的备件池——备件的储备量 = 故障率 × 更换时效）。预防的第四层：架构的容错。故障域的隔离设计（本库网络篇的故障域、本库训推篇的隔离）、冗余的设计（N+1 的冗余——本库电力篇）、以及软件的容错（断点续训、副本自愈——本库各篇的软件容错）。预防体系的收束：GPU 故障的预防是四层体系：巡检自动化（发现前兆）→ 负载均衡（减少应力）→ 供应链管理（批次与备件）→ 架构容错（故障域隔离）——四层都是「让故障的影响变小」而不是「让故障不发生」；承认故障的必然性，才能设计出真正可靠的系统。**

GPU 故障的进阶：大规模故障的应急处理

GPU 故障（正文自愈）的进阶：大规模故障的应急处理——一次影响数百卡的事件。场景：数据中心的冷却系统故障，温度超过阈值导致数百卡降频甚至宕机。应急的流程。第一响应（分钟级）：熔断保护——训练任务自动暂停（温度保护）、推理服务降级（关键服务保底、非关键服务暂停）——保住最重要的服务。第二步（小时级）：根因的定位——冷却系统的根因（泵的故障？管道的泄漏？——冷却的故障排除需要基础设施团队）、影响的范围评估（多少卡受影响、多少任务中断）。第三步（天级）：恢复的分层——先恢复推理（冷却修复或临时风冷）、再恢复训练（从 checkpoint 恢复——本库断点篇）、最后恢复非关键任务。第四步（周级）：根因的修复——冷却系统的维修或升级、预防的加固（冷却的冗余、温度的告警阈值调整——同类故障不再发生）。应急的预案要点：预案要提前写（冷却故障的应急流程——预案在故障前写，不是故障时想）、演练（冷却故障的模拟演练——没有演练的预案是纸）、以及通信的预案（影响的客户通知、团队的信息同步——大规模故障的通信比技术更难）。大规模故障的收束：大规模故障的应急，是「分层响应」——先保关键、再恢复核心、最后全面恢复——响应的分层、预案的提前、通信的及时，三件事是大规模故障应急的生死线；没有这三件事，一次基础设施故障就可能演变为业务危机。**

GPU 故障的预防案例

GPU 故障预防案例：集群巡检体系搭建——从零到自动化巡检过程。第一步指标采集：DCGM 部署（每节点 dcgm-exporter——GPU 全量指标自动采集：利用率温度功耗ECC时钟频率）。第二步告警规则：ECC 纠错率告警（纠错率上升等于退化预警）、温度告警（温度超阈值分级告警——P99 温度趋势监控）功耗异常告警（功耗异常波动——电源或负载问题）。第三步巡检报告：每日健康报告（集群 GPU 健康概览——每卡状态自动汇总）每周深度诊断（dcgmi diag 深度诊断——全量卡性能与健康验证）。第四步台账建立：故障记录（每次故障时间类型根因处置）趋势分析（故障率趋势批次对比——故障规律性分析）。巡检体系收束：GPU 集群巡检体系从手动检查到自动告警到预测维护——三步演进把 GPU 故障从被动救火变成主动管理；巡检体系投入（一周工程）换来故障 MTTR 数量级降低——巡检是 GPU 集群运维体检系统没有体检健康管理是盲目的。

GPU 故障的进阶案例：一次降频事故的诊断

GPU 故障（正文类型学）的进阶案例：一次降频事故的诊断——「训练变慢但没报错」的排查。症状：训练集群的吞吐突然下降 20%——没有报错、没有 OOM、没有掉卡——「静默的性能劣化」。排查的五步。第一步：GPU 利用率的检查——GPU 利用率正常（90%+）但训练步时间变长——「在算但算得慢」。第二步：频率的检查——nvidia-smi -q 的时钟频率——发现 GPU 的 SM 时钟从 1980MHz 降到 1400MHz——降频确认。第三步：降频的原因——nvidia-smi -q 的时钟原因（Clocks Throttle Reasons）——发现原因是「HW Slowdown：Thermal」——温度触发的硬件降频。第四步：根因的定位——散热系统的检查（发现液冷系统的流量下降——冷却液泵的性能衰减——本库电力篇的冷却系统）。第五步：处置——冷却系统的维修 → 温度恢复 → 频率恢复 → 训练吞吐恢复。诊断的收束：「静默的性能劣化」是 GPU 运维最阴险的故障形态——没有报错、没有崩溃、只是变慢——它的发现靠的是「性能基线的对比」而非「错误日志的告警」；巡检体系（本库正文的巡检）的吞吐趋势监控，是发现静默劣化的唯一手段。**

小结

GPU 集群的故障是概率常态（万卡集群每天数次），类型学从 ECC 可纠到整机故障分级。巡检与预测性维护的关键是「故障前兆的信号」（ECC 纠错率趋势、温度模式）——主动换卡的成本远低于训练中断。自动化自愈的三层闭环（任务级重启、服务级摘除、硬件级工单）+ 演练验证 + 故障台账，让故障从事故变成日志。GPU 集群运维的成熟标志不是零故障，是 MTTR 足够短——把故障当日常运营，集群才配得上「大规模」三个字。