NVIDIA将故障归因系统NVIDIA Attribution开源
NVIDIA技术博客称，该系统已在NVIDIA AI基础设施中生产使用多年，每周分析数百万个工作负载、覆盖数十万块GPU；它把日志、指标、遥测和调度状态关联起来，输出结构化诊断，而不是逐个排查节点事件。
AI解读：据NVIDIA的说法，该系统分析故障时以工作负载为范围，而非孤立的节点事件；它关联日志、指标、遥测与调度状态，返回包含结果、根因、受影响节点、支撑症状和证据链的结构化诊断。
该表述来自公司自身，博客未给出准确率或恢复时间等效果数据。
系统由Attribution Service与Attribution Blueprint两部分组成，共用同一归因引擎。Service通过HTTP API提供归因能力，Blueprint负责对接集群调度器与遥测源并写出结果。
归因依赖确定性的规则来判断事件时序与相互作用，从而区分下游症状与引发故障的事件。博客指出，归因质量取决于底层遥测的质量与完整度；证据不足时，诊断会把原因标为不确定，而不是强行给出结论。
开源后，团队可为新的故障模式添加规则、为自有调度器和遥测后端编写连接器，并把结果接入事件、恢复和集群管理系统。规则随Service发布，不通过HTTP API动态上传。
NVIDIA在技术博客中宣布，其工作负载级故障归因系统NVIDIA Attribution已开源。博客称该系统已在NVIDIA AI基础设施的生产环境中使用多年，每周分析数百万个工作负载、覆盖数十万块GPU。
系统做什么
NVIDIA把Attribution描述为工作负载级的故障归因系统。分布式AI任务中，一块GPU或网络结构的事件可能在其它rank上表现为NCCL错误、调度器状态变化以及大量下游消息；报出的异常只说明工作负载在哪里停下，不说明故障从哪里开始。
系统关联工作负载范围内的日志、指标、遥测和调度状态，返回结构化诊断，包含结果、根因、受影响节点、支撑症状和证据链。NVIDIA称，确定性规则让结果可复现、可定制，结构化输出便于接入现有的健康与恢复系统。
博客给出的边界是：Attribution解释工作负载为何失败并提供证据，与就绪检查、持续健康监控、基础设施修复和工作负载重启系统互补。
四步流程与一个示例
按博客描述，流程分四步：Blueprint通过调度器标识或显式执行窗口与节点分配确定工作负载一次尝试；日志与指标连接器生成工作负载范围的Observation记录；Service调用归因引擎提取并关联GPU XID、NCCL失败、调度器状态转换、指标条件等事件；Blueprint把判定与终态、归因域、症状、受影响节点和采集覆盖情况合并输出。
示例是一个多rank训练任务：一块GPU出现硬故障（XID 149），其它rank随后出现NCCL错误。系统跨节点关联事件，把该XID认定为根因，将三个NCCL错误保留为症状链中的证据，并指出责任节点，最终把工作负载报告为硬件故障，而非一组独立的通信错误。
博客说明，被降级的症状仍以“interesting”保留原始来源，可供检查。当多种原因都符合证据时，归因域会标记为ambiguous；诊断会记录这一区分，反映不确定性。
部署形态与限制
Attribution包含两个可部署组件：Attribution Service和Attribution Blueprint，两者共用核心归因引擎。Service是核心引擎的自托管HTTP封装，接收规范化观测，为每个工作负载返回一个判定；Blueprint是Python参考编排器，负责发现工作负载、解析执行上下文、运行采集器、调用Service、补充判定并写出结果，还提供一个只读仪表盘。
博客称Blueprint是供使用者按自身环境定制的参考实现，自带Slurm、Kueue和静态输入的上下文连接器，Loki、本地文件、Kubernetes Pod日志和PromQL指标的日志与指标连接器，以及stdout和SQLite输出连接器。Blueprint可部署在靠近各集群数据源的位置，可每个Blueprint配专用Service，也可多个Blueprint共享一个Service。
规则方面，Service启动时加载随附的规则目录并执行内联测试用例；规则变更需提交并随Service发布，不能通过HTTP API动态上传。博客还提到一个大规模RDMA集群的使用案例：系统把端口错误、连接重置和调度器事件关联起来，识别出特定主机和交换机端口附近的模式，帮助团队定位网络结构修复与拥塞调优。该案例未给出量化效果。