AI 基础设施横跨计算、网络、存储、编排与应用多层，性能下降时很难判断问题出在哪一层，因为某一层看到的症状往往源自别处。NVIDIA 在技术博客中提出一套面向 AI 基础设施的可观测性框架，核心不是堆更多仪表盘，而是建立一条决策路径：把组件映射到工具，把工具收敛成少量告警，再把告警汇到一块排障大屏。
文章用一个典型场景说明难点：一个分布式训练作业已经跑了三天，GPU 利用率与排队时间都正常，吞吐却下降了六小时；最终定位到一条 InfiniBand 链路的误码率缓慢升高。这是典型的“灰色故障”——硬件已经退化，但系统并不报告为宕机。训练采用整体同步并行模型，一个慢 rank 就会拖住整个作业；链路层重传让该 rank 在 NCCL all-reduce 中停顿，吞吐跌到最慢者的水平，其余 rank 随之阻塞。
因此，选型前要先列出会悄悄消耗 GPU 小时的故障域：平台健康（风扇、电源、BMC、机箱、CPU、内存、本地存储）、GPU 健康与性能（利用率、温度、功耗、XID/ECC、NVLink 吞吐）、网络（InfiniBand 或以太网的链路完整性、拥塞、交换机与线缆，以及机架级 NVLink）、集群与作业（调度、预留、已分配但空闲的 GPU、排队时间）、推理服务（延迟、成功率、缓存行为）。
工具映射上，NVIDIA 给出的原则是最少工具覆盖全部必需项：GPU 指标优先用 DCGM 导出到 Prometheus，DGX 类节点的系统健康仍交给 NVSM；InfiniBand 用 UFM，Spectrum 以太网与 RoCE 用 NetQ，两种网络并存时才同时部署；机架级 NVLink 需要 NMX，经典多节点 NVLink 拓扑则由 DCGM 覆盖；BCM 定位为集群与作业聚合面，不替代底层计数器；Run:ai 与 NIM 只在调度公平性或推理 SLO 成为一等需求时引入。
告警要绑定服务级指标与明确动作，而不是导出所有计数器。文章建议从一组 top-k 指标起步：平台的 SPD_FAN_*、PWR_*、TEMP_*；GPU 的 DCGM_FI_DEV_GPU_UTIL、MEM_COPY_UTIL、POWER_USAGE、XID_ERRORS；InfiniBand 的 PortXmitDataExtended、SymbolErrorCounterExtended、Effective_BER、Total_Raw_BER、Chip_Temp；以及 BCM 或 Slurm 的作业与预留信号，用于把硬件告警关联到实际业务影响。
落地时采用两层监控：第一层是一块 Grafana 大屏，先回答“故障在 GPU、节点还是网络”；第二层再进入 UFM、BCM 等厂商界面做根因分析。验收标准很具体：每个在范围内的故障域至少有一个完全支持的工具，每条告警都有负责人与处置动作，GPU、节点与网络信号共享同一时间轴。NVIDIA 的提醒是，可观测性成熟度不看仪表盘数量，而看信号能否在大量算力被浪费之前指出故障组件与下一步动作。
WeChat
Profile