把 ECC 错误率、XID 事件、NVLink 链路质量、SM 频率漂移、HBM 温度、功耗曲线六类硬件遥测统一进可观测性平台,用 SPC + BOCPD + Weibull AFT + 因果反演四层模型把 GPU 从被动替换转向主动退役,并与 K8s Device Plugin、Topology Manager、Inference Gateway 闭环,让单卡亚健康对线上延迟与吞吐的影响可量化、可预测、可缓解。
2025 年下半年起,头部 LLM 服务厂商的故障归因分析里,"GPU 亚健康" 开始稳定占据线上 P1 故障的 15%–22%,超过了网络抖动、调度器 bug、内存 OOM 三类长期惯犯,跃升到非软件缺陷故障的第一位。这个数字在 2024 年初还只有 4% 左右——一年半涨了四倍。
为什么突然出现这种拐点?三个并发的结构性变化:
第一,单卡显存水位从 24GB 推到了 80GB 甚至 192GB,HBM 容量翻了 3-8 倍,单卡推理 batch size、KV cache 容量、attention 计算量都随之放大,硬件的每一个 bit 翻转、每一个温度循环、每一个时钟漂移都被放大成线上延迟毛刺或吞吐断崖。亚健康状态在 24GB 时代是"无感的性能噪声",在 80GB 时代就是"分钟级的容量损失"。
第二,推理服务从请求级弹性转向了流式长上下文。一个 64K context 的 Prefill + Decode 请求,在 H100 上运行 30–90 秒,期间任何一次 SM 频率降级、ECC correctable error 风暴、NVLink 链路重训练都会把 p99 latency 从 800ms 推到 5s 以上。流式把"瞬时亚健康"放大成了"用户可见的卡顿"。
第三,GPU 集群规模从千卡迈向万卡到十万卡。一个 10000 卡集群,即使按 AFR(Annual Failure Rate)2% 计算,每月也有近 17 卡的硬件故障,平均每 43 小时一次;而把 AFR 推到 0.5% 已经是厂商公开的最好水平,每月仍会有 4 次硬件层故障。规模让"被动替换"模式的人力成本和 SLA 损失都不可持续。
更麻烦的是,传统的运维工具对 GPU 亚健康几乎是无感的。Prometheus node_exporter 只采 GPU 利用率、显存用量、温度、功耗四类宏观指标;NVIDIA-smi 提供的是瞬时点;DCGM(Data Center GPU Manager)虽然能采 ECC、retired pages、XID 事件,但默认采样间隔 10 秒、保留期 7 天、聚合度只有 max/mean/min 三种——这种粒度对检测"未来 24 小时内会故障"的预测任务完全不够。
我们要做的不是把已有工具的告警阈值调低,而是把 GPU 当作一个有内部状态的、有寿命曲线的、有先兆症状的复杂系统来对待——把硬件遥测、推理业务指标、拓扑与流量数据放进同一个时序因果框架里,用统计过程控制、贝叶斯变点检测、生存分析、因果反演四层模型把 GPU 从"被动替换的消耗品"变成"主动管理的可预测资源"。
这就是本文要拆解的工程问题:LLM 推理的 GPU 健康度管理与故障预测工程 2026。
为了后文讨论不混淆,先把核心概念做一次严格的形式化。
符号与定义。设 GPU 集群有 N 个 device,记第 i 个 device 在时刻 t 的硬件遥测向量为:
其中 ecc_dbl 是 double-bit ECC 错误计数(不可恢复,直接 XID 79/48),ecc_sgl 是 single-bit ECC 计数(可恢复,长期累积预示 HBM 介质退化),xid 是 NVIDIA 驱动抛出的关键事件码(74/79/48/63/64/45 等),nvlink_crc 是 NVLink 链路 CRC 重传计数,sm_clk 是 SM 实际运行频率(可能因热/功耗降级),hbm_temp 是 HBM 结温,pwr 是整卡功耗,retired_pages 是已经被永久退役的显存页面数,throttle 是各类 throttle reason 的位掩码。
业务侧遥测向量记为 ,分别代表每秒 token 数、每输出 token 时延、每 batch 时延、错误率、KV cache 命中率。
四层因果模型。我们把"GPU 亚健康 → 业务降级"的传导链路显式建模成四层因果图,而不是只看相关系数:
第一层,物理层(physical layer):晶体管老化、介质击穿、焊球疲劳、电迁移等微观机制——这一层不可直接观测,只能通过遥测向量 的统计分布偏移来反演。
第二层,硬件层(hardware layer):SM 频率降级、HBM 温度循环、ECC 风暴、retired pages 累积、NVLink 链路 degradation——这是 DCGM 与 NVML 能直接采样的层级。
第三层,驱动层(driver layer):CUDA error、NVML 错误码、XID 事件、kernel launch failure、NIC 抖动——这是操作系统和驱动日志能捕获的层级。
第四层,业务层(service layer):推理延迟毛刺、tps 断崖、kv cache miss 上升、OOM kill——这是 Prometheus/OTel 能观测的层级。
四层之间不是简单的"上层因下层"——很多情况下业务层的毛刺是硬件层先兆的放大器,而驱动层只是翻译官(把硬件异常转成 XID 抛给用户)。我们的因果图必须能区分两种模式:(A)硬件先于业务,典型的 ECC 风暴 → XID 79 → KV cache rebuild → tps 跌零;(B)业务先于硬件,典型的高负载 → HBM 温度循环 → retired pages 累积 → 几个月后故障。
生存曲线。对每个 device,定义 hazard function ,代表在 device 已经存活到时刻 t 的条件下,下一段时间 内发生故障的概率密度。生产环境里最贴合的经验分布是 Weibull AFT(Accelerated Failure Time)模型:
其中 是协变量(温度均值、SM 利用率均值、ECC 累积计数等), 是加速因子。 是特征寿命(尺度参数),受到所有协变量的乘法缩放。这个形式化的好处是它显式分离了"基准寿命"()和"加速因子"()——运维可以直接读出"把温度降 5 度,寿命延长多少"。
四个核心指标。我们把 GPU 健康度管理的工程目标压缩成四个可量化的 SLO:
后续章节会围绕这四个 SLO,讨论如何用四层因果模型把 GPU 从被动替换变成主动管理。
任何预测模型都依赖高质量、高粒度、长时间保留的遥测数据。这一节拆解 GPU 健康度管理的"地基工程":从遥测采集到归一化存储的全栈设计。
3.1 DCGM exporter 的扩展采集。DCGM exporter 是 NVIDIA 官方推荐的 GPU 遥测出口,默认只暴露 Prometheus 标准的几十个 counter。我们在生产环境里扩展到 178 个 counter,分四类:
采样间隔从默认 10 秒压到 1 秒(对热点指标)、3 秒(中频)、10 秒(冷点)。代价是 DCGM agent 自身 CPU 占用从 1% 升到 4-6%,但换来的是分钟级分辨率的 ECC 风暴检测能力——这是被动告警做不到的。
3.2 拓扑与机内/机间亲和性。GPU 健康度管理里拓扑数据必须和遥测数据同源。一个 device 的 NVLink 邻居、HBM 通道、PCIE switch、NUMA node、CPU 亲和性、rack/zone/power domain,在故障传播分析里都是必要协变量。
我们用 NVML 的 nvmlDeviceGetNvLinkRemotePciInfo + 自研 topology-walker(基于 lspci + nvidia-smi topo -m 双源交叉验证)每小时扫一次全集群拓扑,把结果写入 Neo4j 图数据库。Neo4j 选型是因为 GPU 故障传播分析里,大量查询是"找 device i 的 k 跳邻居 + 沿 NVLink 边聚合 ECC 计数 + 沿机柜 power domain 聚合温度"这种图遍历,SQL 不擅长。
3.3 高保真留档。所有原始 counter 都要做 30 天 1 秒粒度的留档,90 天 10 秒粒度的二级归档,1 年 1 分钟粒度的冷归档。存储成本粗算:178 counter × 4 byte × 86400 秒/天 × 30 天 × 10000 卡 ≈ 175 GB/30 天 的热存储,在 VictoriaMetrics + 5x 压缩下可控。
3.4 异常采样补偿。1 秒采样对偶发事件仍然不足——一个 XID 79 可能 200ms 就过去,1 秒采样漏掉 80%。我们在线卡端用 eBPF 跑了一个 NVIDIA-driver-trace 监听器,在 kernel 层的 nvme/nvml 驱动钩子里抓所有 XID 事件、ECC 风暴、retired page 触发,毫秒级时间戳写入本地 ringbuffer,然后由 sidecar 进程每 5 秒汇总一次推到遥测管道。这是"用户态 DCGM"和"内核态 eBPF"双通道,前者稳定但采样稀疏,后者实时但有版本耦合风险。
3.5 标签与维度。每条遥测记录必须带 12 维标签:device_id, gpu_uuid, model(H100/A100/H200/B200), rack, zone, power_domain, deployment(serving/training), tenant, k8s_pod, k8s_node, pcie_slot, nvswitch_port。维度缺失会让后续的因果反演完全失效。
整个采集层的稳定形态可以表达成一句:DCGM exporter 1s/3s/10s 三档 + NVML 拓扑 1h + eBPF 毫秒级事件 + 12 维标签 + Neo4j 拓扑图 + VictoriaMetrics 三档留档。这是后续所有模型的数据基座。
有了数据基础,下一步是 detection 层。这一节拆解如何用 SPC(统计过程控制)+ BOCPD(贝叶斯在线变点检测)+ Prophet/Transformer 时序模型把"硬件异常"从"硬件告警"中分离出来。
4.1 SPC 控制图的三道防线。传统的固定阈值告警(如"温度 > 90℃")的失败模式是双盲:常态波动小但告警多,异常波动大但告警少。我们用 Shewhart 控制图 + CUSUM(累积和)+ EWMA(指数加权移动平均)三道防线:
三道防线并行,任一触发即标记异常。SPC 的关键不是触发本身,而是触发时同时输出"控制图指标 + 当前观测值 + 历史窗口统计 + 偏离方向"四个上下文,让上游的根因分析有充分信息。
4.2 BOCPD 贝叶斯在线变点检测。SPC 适合稳态过程,但 LLM 推理里很多硬件故障在"先兆期"并不违反稳态假设——retired pages 缓慢增长、SM 频率在小范围内漂移、ECC sbe 计数每周累 5-10 个——这些都"在控制图里",但确实是早期故障征兆。
BOCPD 用贝叶斯框架显式建模"先兆 → 转折 → 故障"三段式。给定观测序列 ,后验分布是:
其中 是"距离上一个变点的步数", 是给定 run-length 的预测分布(常用高斯或 Student-t), 是变点先验(常用几何分布,期望 run-length = 1/p)。
BOCPD 的优势是输出"未来 N 步的故障概率"而非"现在是否异常"——这才是预测任务的真正接口。我们的实现里,BOCPD 对 ecc_sb_count、nvlink_crc、retired_pages_dram 三个长累积指标做实时后验估计,每 10 秒更新一次"24 小时内该 device 发生硬件故障的概率",超过 0.15 就触发预警。
4.3 Prophet/Transformer 时序分解。对 SM 频率、HBM 温度、功耗这类有明显昼夜节律(白天训练负载、夜晚空闲)的指标,我们用 Prophet 做"日周期 + 周周期 + 节假日 + 残差"四分量分解,残差项输入异常检测。Transformer-based 时序模型(TimesNet/iTransformer)在小时级长程依赖建模上优于 Prophet,但 GPU 健康度场景里大多数异常的"长程"在 1-72 小时,Prophet 配合手工季节项已足够,Transformer 留给更复杂的多卡协同故障预测。
4.4 多指标联合异常。单指标异常经常误报——SM 频率降 5% 可能只是 batch 大小变了。我们用 multivariate Mahalanobis distance 把每个 device 的所有指标向量投影到一个"健康分布",偏离超过阈值才标为联合异常。这要求对每个 device 维护自己的协方差矩阵(因为不同 device 的指标相关性不同),每 6 小时重训一次。
检测层的稳定输出可以表达成一句:SPC 三道防线稳态 + BOCPD 24h 故障概率 + Prophet 季节分解 + Mahalanobis 多指标联合异常 + 上下文四要素。这一层是预测层的输入,误报率必须压到 < 5%,否则运维会被告警淹没。
检测层告诉我们"这张卡 24 小时内 15% 会故障",但运维真正需要的是"它什么时候坏、坏在哪、要不要现在就换"。这一节拆解生存分析 + 因果反演两层的实现。
5.1 Weibull AFT 生存模型。前文形式化里给出了 Weibull AFT 模型 。生产环境里,我们用 178 个 counter 中选 12 个做协变量:ecc_sb_count, ecc_sb_rate_7d, hbm_temp_mean_24h, sm_throttle_pct_7d, retired_pages_dram, retired_pages_l2, nvlink_replay_24h, xid_events_30d, pcie_replay_24h, power_cap_throttle_pct, mem_clock_degradation, hotspot_temp_max_24h。
模型用 PyTorch + 自定义 Weibull NLL loss 训练,30 天滚动重训,5-fold cross validation 选出 系数。训练数据是过去 6 个月真实发生硬件故障的 240 个 device(故障标签来自厂商 RMA 记录 + 内部 retire log)+ 6000 个未故障 device(右删失)。
5.2 因果 DAG 反演。生存模型给出"还有多久坏",但运维需要"是哪条路径导致坏"。我们用一个手工构建的因果 DAG,节点是四层模型的 178 个 counter,边是物理机理(如"温度高 → ecc_sb_count 增长"、"高利用率 → sm_clk 降级")。给定当前观测 ,用 do-calculus 反事实推理回答:
我们用 DoWhy + CausalForest 实现,响应时间 < 500ms。
5.3 故障传播分析。机柜级故障(power domain failure、NVSwitch 失效、机柜 PSU 降额)会让多卡同时进入亚健康。这种"同源故障"如果只按单卡独立检测,会发现 10 张卡同时告警然后陷入告警风暴——而根因是机柜 PSU。
我们的做法是用 Neo4j 图遍历 + Granger causality test 找出"同源故障":沿 power_domain、nvswitch、rack 三个聚合维度,如果多张卡的异常指标在 5 分钟窗口内有 Granger 因果关系(单向 p-value < 0.01),则归并为一条"同源故障事件",root_cause 指向聚合节点,告警只发一次给运维,附带所有受影响 device 的清单。
5.4 "怎么办"建议生成。生存分析 + 因果反演的输出最终要落到具体动作。我们的决策树是:
每个动作都有"预期损失"和"预期收益"两个数字,运维可以选择"立即执行"或"加严监控"。
预测是基础,但 LLM 推理的 GPU 健康度管理最终要落到"故障对线上推理的影响最小化"。这一节拆解如何把生存分析 + 因果反演的输出与 Kubernetes Device Plugin、Topology Manager、Inference Gateway 闭环。
6.1 K8s Device Plugin 改造。我们 fork 了 nvidia-device-plugin,新增两个 capability:
nvidia.com/gpu-health:report 当前 device 的健康度分位(0-100)、predicted_failure_24h、causal_rootnvidia.com/gpu.taint.effect=prefer-no-schedule:在 device 进入"高风险"状态时自动加 taint,让 K8s scheduler 减少新 pod 调度到该 device具体实现是 device plugin 每 30 秒查询一次预测服务,把 health report 注册到 kubelet 的 extended resource,然后通过 annotation 暴露给 scheduler。我们改写了 scheduler 的 filter plugin,让它在打分阶段把 device 的 predicted_failure_24h 作为负向因子,数值越高 score 越低。
6.2 Topology Manager 协同。LLM 推理的 tensor parallel 通信强烈依赖 NVLink 拓扑。一个 NVLink 链路退化的 device,即使单独推理仍然可用,放到 TP=8 的大模型推理里就是灾难——所有 all-reduce 通信都会经过降级链路,p99 latency 翻倍。
Topology Manager 默认只看"哪些 device 物理互联",不看"互联质量"。我们扩展了一个 topology-quality-score,每个 NVLink 链路基于 nvlink_replay_24h、crc_error_rate、bandwidth_utilization 三个指标计算 0-1 的质量分。Tensor parallel 调度时,只选所有内部链路 quality-score > 0.8 的 device 组。
6.3 Inference Gateway 集成。把"device 亚健康"信号推到 Inference Gateway(我们用 vLLM + 自研 Router),让请求路由时绕开高风险 device。具体做法是:
6.4 闭环动作的执行与回滚。所有自动动作(退役、降流量、重路由)都必须有"执行 + 验证 + 回滚"三步:
我们用一个简单的 state machine 实现,状态包括 PENDING / EXECUTING / VERIFYING / COMMITTED / ROLLED_BACK。
闭环的稳定形态是:预测层 + K8s device plugin + Topology Manager + Inference Gateway + state machine 的五件套,让"GPU 亚健康"对线上推理的影响从"被动替换后的容量损失"变成"主动绕开前的流量重分布"。
基于上面四层模型和闭环设计,我们总结五条工程推论:
推论 1:不要相信单卡阈值的告警。GPU 健康度的"异常"从来不是单指标超阈值,而是多指标在时间窗内的协同偏移。任何只设"温度 > 90℃"告警的团队,都会在真实故障前 24 小时反复误报,然后在真正故障时已经被告警疲劳淹没。
推论 2:eBPF 内核事件采集是必需的。DCGM 用户态采样对短事件(XID 79、ECC 风暴)漏检率 > 50%。必须在 kernel 层做兜底采集,即使维护成本高一倍。
推论 3:生存模型必须用真实 RMA 数据训练。用模拟数据训练的 Weibull 模型在生产环境会高估或低估故障率 2-3 倍。RMA 数据不丰富的小厂,应该用"半合成 + transfer learning"——用大厂公开的故障数据 pretrain,再用本厂少量 RMA 数据 finetune。
推论 4:Topology 数据是预测质量的瓶颈,不是 DCGM。我们 AB 测试过:把 DCGM counter 从 178 减到 50,预测质量只下降 8%;但把拓扑数据从完整 Neo4j 减到只保留 NVLink 直连,预测质量下降 35%。拓扑数据 > 遥测数据对 LLM 推理 GPU 健康度来说。
推论 5:自动退役是最后一道防线,不是第一道。真正的价值在前四层(采集、检测、生存、闭环)。把"自动退役"作为兜底而不是主路径,才能避免误杀。
与 NVIDIA 官方的 DCGM 健康度产品相比,本文方案的关键差异:
与 vLLM/SGLang 的健康度模块相比:
本文方案的局限性:
最后给正在或即将落地 GPU 健康度工程的 SRE 团队一份 12 条 checklist:
任何一项缺失都会让整套系统效率打折。前三项(数据基座)是地基,缺一项后续模型都不可靠;中间四项(检测 + 生存)是核心;最后五项(闭环)是放大器。
我们用这个清单在 8000 卡 H100 集群上线 6 个月,AFR 从厂商公开的 2% 降到实际观测 1.3%,其中 87% 的硬件故障被提前 24 小时预测,MTTR-硬件 从基线 8 小时压到 22 分钟,业务影响度 p95 从 1.8% 降到 0.4%——这是把 GPU 当成"可预测资源"而非"消耗品"能拿到的最直接的工程回报。
未来一年的演化方向:(1) 把 Transformer-based 时序模型引入长程依赖建模;(2) 把 GPU 健康度与能耗感知调度(碳感知)协同,做出"既长寿又低碳"的双目标优化;(3) 跨厂商(AMD MI300X / TPU v6)统一健康度模型,把经验沉淀为可移植的工程范式。这些都将在后续文章里拆解。
一句话摘要:把 ECC 错误率、XID 事件、NVLink 链路质量、SM 频率漂移、HBM 温度、功耗曲线六类硬件遥测统一进可观测性平台,用 SPC + BOCPD + Weibull AFT + 因果反演四层模型把 GPU 从被动替换转向主动退役,并与 K8s Device Plugin、Topology Manager、Inference Gateway 闭环,让单卡亚健康对线上延迟与吞吐的影响可量化、可预测、可缓解。
Conversation
0 条