NVIDIA 开源分布式AI工作负载故障归因方法：从级联症状中分离根因

在大规模分布式AI工作负载中，一个GPU或一条NVLink链路的硬故障往往不会只在一个节点上留下痕迹。它会让同一工作负载中其他rank的NCCL通信集体失败，调度器记录状态转换，监控系统报告网络指标异常。运维团队面对的是散布在数十甚至数百个节点上的报错信息，而真正需要修复的可能只是其中一台机器上的一个端口。NVIDIA 将其内部长期使用的故障归因系统以 NVIDIA Attribution 的名称开源，试图把这类排查从人工逐节点读日志变成可复现的规则化诊断。

Attribution 的核心设计决策是工作负载中心而非节点中心。它不单独回答这台GPU出了什么问题而是回答这个工作负载为什么失败了。分析范围由调度器标识或显式的执行窗口和节点分配确定，然后从应用日志、系统日志、GPU驱动消息、Fabric Manager输出、调度器历史和节点网络指标中收集与该工作负载相关的观测记录。

归因过程分四个阶段。第一阶段确定工作负载边界。第二阶段收集观测。第三阶段由归因引擎提取事件并通过确定性规则评估它们的时序和交互关系，将下游症状与引发故障的初始事件分开。第四阶段返回结构化结果，包含工作负载终态、归因域、根因节点、支持症状列表和采集器覆盖记录。

文章给出一个合成示例来演示这一流程。在一个多rank训练负载中，应用日志包含三条不同的NCCL错误，node-02的系统日志包含XID 149及其错误字解码为NVLink信号完整性问题。提取阶段将原始日志转为带来源的类型化事件。过滤阶段中，一条名为HandleXidBurstEvents的EARLY规则读取XID突发证据，解码错误字，在node-02上发出信号完整性归因事件，三条NCCL事件保持不变。最终细化阶段中，Xid149AndNvlinkFiltering规则保留信号完整性症状并将其他节点的症状降级，Gb200PriorityRootCause规则进一步缩减活跃症状集，结果映射产出硬件故障归因。NCCL报错并未被删除，而是作为 interesting 证据保留，仍可检视。

这一方法的关键边界在于遥测质量。文章明确指出，当多个原因都能匹配现有证据时，归因域标记为不确定；诊断质量取决于底层遥测的完整程度，系统不会将不完整证据强行转化为确定性结论。生产规模数据——每周分析数百万工作负载、覆盖数十万GPU、在大型RDMA集群中识别出围绕特定主机和交换机端口的故障模式——均为NVIDIA自报，未见独立复现。

架构上，系统分为Attribution Service和Attribution Blueprint两个可部署组件。Service是核心归因引擎的HTTP封装，接收标准化观测并返回单一判定。Blueprint是Python参考编排器，负责发现工作负载、解析执行上下文、运行采集器、调用Service、丰富判定结果并写入输出。Blueprint内置Slurm、Kueue和静态输入的执行上下文连接器，以及Loki、本地文件、Kubernetes pod日志和PromQL指标的日志与度量连接器。规则以声明式配置和Python形式签入代码仓库，随Service一起发布，不通过HTTP API动态上传。

对基础设施团队而言，这一开源的意义在于将故障模式编码一次、跨工作负载和集群复用的可能性。开发者可以为新故障模式添加规则，为自有调度器和遥测后端实现连接器，并将归因结果接入事件管理、恢复和机群管理系统。下游系统消费terminal_state和sub_domain字段，不再需要解析产品特定日志格式。