Skip to main content

GPU 故障与 RMA 实战：大集群的硬件运维日常

· 4 min read
AI Compute Cards Wiki Editorial
Industry Research Team

"超大规模集群唯一确定的事，就是故障。"Meta 在 Llama 3 405B 训练论文里公布的 54 天故障账单，是目前最详实的万卡集群硬件运维样本。本文以它为底，聊聊 GPU 故障的真实分布、RMA 流程怎么设计、备件池要多大。

一份真实的故障账单​

Meta 用 16384 张 H100 训练 Llama 3 405B，54 天快照期内共发生 466 次任务中断：47 次是固件升级等计划内维护，419 次是意外中断——平均每天近 8 次，约每三小时一次。其中约 78% 归因于确认或疑似的硬件问题，尽管如此，团队仍把有效训练时间保在了 90% 以上，绝大多数故障由自动化系统处置，仅 3 次需要大量人工介入。

中断原因（419 次意外中断）次数占比
GPU 本体故障（含 NVLink）14830.1%
GPU HBM3 显存故障7217.2%
软件缺陷5412.9%
交换机与线缆358.4%
计划外主机维护327.6%
GPU SRAM 故障194.5%
CPU、内存、SSD、电源等传统部件合计不到 20 次约 4%

结论很清晰：GPU 及其显存是绝对的第一故障源，两者合计占意外中断的近一半；而 CPU 这类传统部件在 54 天里只坏了 2 颗。GPU 承受 700W 高热应力，天然比 CPU 脆弱。

RMA 流程设计：快诊断比快换件更重要​

大集群 RMA 的瓶颈通常不在换件速度，而在定位速度。一个训练任务中断，可能是 GPU、NVLink、网卡、交换机或软件任意一环，逐台人工排查根本来不及。可落地的实践包括：

  • 建立自动化诊断流水线：任务中断后，调度器自动拉黑可疑节点，用底层诊断工具跑 GPU 显存、NVLink、带宽压测，几分钟内给出"可复用、需复检、需换件"三级结论；
  • 用 ECC 错误率做预测性维护：HBM 出现可纠正 ECC 错误的卡，故障概率显著高于基线，主动下线比等它崩溃成本低得多；
  • 警惕静默数据腐蚀（SDC）：算错但不报错的卡最危险，定期跑 SDC 筛查基准，把"会算错的卡"挡在下一个任务之前；
  • checkpoint 与快速重启是兜底：Meta 把 checkpoint 写入时间压缩到分钟级，配合 NCCL 飞行记录器快速定位 hang 住的任务，这才撑起了 90% 的有效训练时间。

备件池与厂商 SLA：谈判桌上见真章​

万卡集群的备件策略要按"故障率乘以修复时间"倒推。按公开数据粗算，万卡集群每月坏几十张卡属于正常范围，备件池比例通常在 1% 到 3% 之间，再配供应商的托盘级或整机级换件 SLA。谈判时重点盯三个数字：上门响应时间、备件本地库存深度、批量返修的周转周期。另据业界经验值，返修卡重新上线前必须过一遍完整的老化与 SDC 筛查，否则故障卡回流集群会形成"惯犯"。

写在最后​

给正在扩大集群规模的团队三条建议：第一，从第一天就把故障当常态设计，自动化诊断、自动拉黑、自动重调度是万卡集群的生存底线，人工工单撑不过千卡；第二，建立硬件健康档案，每张卡从上机起记录 ECC、温度与历史故障，RMA 决策基于数据而非感觉；第三，把 RMA SLA 写进采购合同并定期演练，别等坏了才知道厂商的"次日响应"是工作日口径。大模型训练的竞争力，一半在算法，一半在这些不起眼的运维流程里。