用NVIDIA Attribution诊断分布式AI工作负载故障

在分布式AI工作负载中，单一错误可能引发一连串连锁症状。一次GPU或网络故障事件可能表现为其他计算节点上的NCCL错误、调度器状态变化以及成千上万条下游消息。系统报告的异常信息只能显示工作负载在何处停止运行，却无法揭示故障真正的起点。

本文将介绍如何在样本工作负载证据上运行NVIDIA Attribution，检查诊断结果，并探究归因规则如何识别故障模式。

NVIDIA Attribution能够关联工作负载范围内的日志、指标、遥测数据以及调度器状态，并返回一份结构化诊断报告，其中包含故障结果、根本原因、受影响节点、支持性症状以及证据链。以工作负载为中心的分析方式，意味着在整个工作负载的上下文环境中审视故障，而非将其视为孤立的节点事件。确定性规则确保结果可复现且可定制，结构化输出则便于与现有的健康监测和恢复系统集成。

NVIDIA的健康与弹性软件帮助团队保持AI工作负载的持续运行。NVIDIA Attribution解释工作负载失败的原因，并提供证据以指导下一步行动。它与就绪性检查、持续健康监测以及负责修复基础设施、重启工作负载的系统形成互补。

NVIDIA Attribution是NVIDIA AI基础设施中广泛使用的以工作负载为中心的故障归因系统，现已开源。

该系统已在NVIDIA AI基础设施的生产环境中运行多年，每周分析数十万个GPU上运行的数百万个工作负载。在一个大型基于RDMA的集群中，该系统成功关联了端口错误、连接重置以及调度器事件，识别出围绕特定主机和交换机端口的故障模式，帮助团队有针对性地进行网络修复和拥塞调优。

该系统包含两个可部署组件：NVIDIA Attribution Service和NVIDIA Attribution Blueprint，两者均基于同一个核心归因引擎构建。Service组件通过REST API提供归因能力；Blueprint组件则负责连接集群调度器和遥测数据源与Service，并写入诊断结果。

将工作负载证据转化为单一诊断结果

NVIDIA Attribution Service每次分析一个工作负载尝试。Blueprint负责收集工作负载上下文和证据，Service负责提取和关联事件，随后Blueprint返回结构化结果。

整个流程分为四个阶段：

界定工作负载范围。Blueprint通过调度器标识符或明确的执行窗口和节点分配来识别工作负载尝试。

收集观测数据。日志和指标连接器从应用日志、系统日志、GPU驱动程序和Fabric Manager消息、调度器历史记录、节点与网络指标中生成工作负载范围内的观测记录。

提取和关联事件。Service调用归因引擎识别重要事件，例如GPU XID错误、NCCL故障、调度器状态转换以及指标异常情况。确定性规则评估这些事件的时序和相互作用，将下游症状与导致故障的根本事件区分开来，并识别出根本原因。

返回结构化结果。Blueprint将诊断结论与工作负载结果（terminal_state）、归因域（sub_domain）、症状、受影响节点，以及采集器覆盖情况和错误记录整合在一起。

从应用日志到归因分析

以下是一个实例演示，展示如何提取证据、解读事件，并保留能够解释分布式工作负载故障的症状信息。

假设一个多节点训练工作负载中，某个GPU遭遇硬件故障（例如XID 149错误），随后其他计算节点上陆续出现NCCL错误。NVIDIA Attribution会跨节点关联这些事件，将XID错误识别为根本原因，在症状链中保留NCCL故障信息，并明确指出责任节点。该工作负载被报告为硬件故障，而不是一系列独立的通信错误。

一次失败的集合通信操作可能在多个节点上留下错误报告。这些报告显示了工作负载在何处察觉到问题。为了解释故障原因，NVIDIA Attribution将这些报告与其他来源的证据相结合，并综合评估所有症状。

在这个合成的工作负载示例中，应用日志包含三种不同的NCCL错误。node-02节点上的系统日志包含XID 149错误，其错误代码可解码为NVLink信号完整性问题。我们将跟踪这一证据在规则处理管道中的流转过程。

通过提取阶段解读日志

提取阶段是首先运行的阶段，它处理原始输入日志并生成供后续阶段处理的结构化事件。

在过滤阶段解码NVLink证据

过滤规则读取并写入事件流。处于EARLY阶段的HandleXidBurstEvents规则读取XID突发证据，解码错误代码，并针对node-02节点生成信号完整性问题的归因事件。在此步骤中，三个NCCL事件保持不变。

图中将解码后的症状简写为XID-149.4信号完整性问题。过滤器同时会生成解析器信息供检查。

将各项症状精炼为单一归因结果

该框架将事件具体化为各节点的症状，对每个节点进行症状清理，并将存留的症状汇总为一个覆盖整个工作负载的症状集合。在本例中，所有四个候选症状都达到了最终精炼阶段。

Xid149AndNvlinkFiltering规则保留了信号完整性症状，并降级处理其他节点症状。Gb200PriorityRootCause规则则缩减整个工作负载级别的活跃症状集合。随后，结果映射阶段生成硬件故障的归因结论。

归因结果最终指向node-02节点和信号完整性问题。NCCL报告仍然是有价值的证据：降级处理会保留其原始来源标记为“值得关注”，以便后续仍可检查这些信息。

当多种原因都符合现有证据时，sub_domain字段会标记为模糊不确定。归因的质量取决于底层遥测数据的质量和完整性。诊断结果会记录这种不确定性，正确反映实际情况中的模糊性，而不是将不完整的证据强行转化为确定性诊断结论。

Service与Blueprint架构

归因引擎包含规则引擎和核心归因逻辑。Attribution Service通过HTTP API暴露这些逻辑，而Blueprint负责处理特定集群的集成工作。这种分离设计使团队能够在不同集群中应用相同的归因逻辑，同时针对各自环境调整调度器、遥测和输出连接器。

Attribution Service：这是一个围绕核心归因引擎构建的自托管HTTP封装层，接收标准化的观测数据，并为每个工作负载返回一条诊断结论。

Attribution Blueprint：这是一个基于Python的参考编排器，负责发现工作负载、解析执行上下文、运行采集器、调用Service、丰富诊断结果、写入AttributionBlueprintResult，并提供一个只读的仪表盘。它旨在作为参考实现，供实践者根据自身环境进行定制。

Blueprint随附以下组件：

针对Slurm、Kueue以及静态输入的执行上下文连接器

针对Loki、本地文件、Kubernetes Pod日志以及PromQL指标的日志与指标连接器

针对标准输出和SQLite的输出连接器

Blueprint可以在每个集群的数据源附近运行，可以为每个Blueprint配置专用的Attribution Service，也可以让多个Blueprint共享同一个Service。在部署方式的定制上拥有较高灵活性，例如采用一对一或一对多的架构。下游系统只需消费terminal_state和sub_domain字段，而无需解析特定产品的日志格式。

将Attribution扩展到你的基础设施

开源NVIDIA Attribution使基础设施团队能够一次性编码某种故障模式，并将其应用于多个工作负载和集群。开发者可以为新的故障模式添加规则，为自己的调度器和遥测后端实现连接器，并将AttributionBlueprintResult记录导入事件处理、恢复和集群管理系统。由于扩展功能使用相同的ExecutionContext、Observation以及结果契约，新的集成能够直接接入同一套诊断处理流程。

实操演示

前文示例展示了GPU故障如何导致多个节点出现NCCL错误。在本次实操演示中，你将使用NVIDIA Attribution分析一次记录的训练工作负载中的NVLink错误证据。你将运行随附的示例，检查诊断结果和原始证据，并研究缩小症状报告范围的具体规则。随后，你将使用NVIDIA恢复指南确定针对受影响节点的下一步操作。

本次演示使用两个组件：

Attribution Service负责运行分析规则。

Attribution Blueprint负责读取工作负载上下文和日志，调用Service，并将结果存储供本地仪表盘检查。

样本证据已随代码仓库提供，因此你可以在连接实际集群之前先完成分析流程的学习。

运行示例工作流程

NVIDIA Attribution快速入门指南将在Docker中构建Attribution Service和仪表盘，然后使用Blueprint处理代码仓库中已提交的样本工作负载证据。你需要安装Docker和uv软件包管理器。

克隆代码仓库并运行示例工作流程（具体命令参见原始代码仓库文档）。

打开本地地址即可检查每个工作负载的诊断结果、受影响节点、支持性症状以及证据链。

规则引擎使用已纳入版本控制的声明式规则和Python规则。以下这条生产规则能够识别应用日志中无效的Pyxis参数，并附带了同位置的测试用例。

服务启动时，会加载内置的规则目录并评估内联测试用例。规则变更会随同Service一起提交和发布；规则不会通过HTTP API动态上传。代码仓库中的规则编写指南详细说明了如何选择合适的规则形式、注册新症状、添加测试，以及验证完整的规则目录。

开始使用

克隆NVIDIA Attribution代码仓库，并按照快速入门指南运行示例，检查其诊断结果。要在自己的基础设施中使用Attribution，请参阅Blueprint配置参考文档，了解调度器和遥测连接器的相关内容，并学习如何为新的证据模式添加提取器规则。

致谢

Aaron Blakeman、Ajay Hotchandani、Alex Shaposhnikov、Ashwin Poojary、Ben Gueret、Chunyang Sheng、Dorrin Poorkay、Gargi Prasad、Felix Abecassis、Grace Tan、Jason Sewall、Mayuri Gupta、Pasha Shamis、Pavan Kumar Gondhi、Piero Orderique、Rahul Kandu、Rakesh Konda和Sirshak Das为NVIDIA Attribution的开发及本文的撰写做出了贡献。