小路带你看大厂架构：NVIDIA Attribution，训练任务挂了，先问它到底从哪坏起 分布式训练出故障时最折磨人的不是故障本身，而是症状满屏：一个 G… · @Zen_with_AI · TwKit

@Zen_with_AI

小路带你看大厂架构：NVIDIA Attribution，训练任务挂了，先问它到底从哪坏起 分布式训练出故障时最折磨人的不是故障本身，而是症状满屏：一个 GPU 或者 fabric 事件会在其他 rank 上表现为 NCCL 报错、调度状态变化、成千上万条下游消息。日志里最后那条异常只说明任务在哪里停下，没说明故障从哪里开始，工程师只能凭经验反向追。 NVIDIA Attribution 把视角放在整个 workload 上。Blueprint 先按调度标识或者执行窗口加节点分配定出一次 workload attempt，再从应用日志、syslog、GPU 驱动和 Fabric Manager 消息、调度历史、节点与网络指标里抽出这个 workload 作用域的 Observation；Service 用确定性规则走四步：定范围、采观测、抽事件并关联、回一张结构化结论，里面有最终状态、归因域、症状、受影响节点，以及采集覆盖和误差记录。 原文的例子：node-02 的 XID 149 解码出来是 NVLink 信号完整性问题，定为根因，其他节点的 NCCL 报错降级保留在证据链里，不丢弃。证据不足时它给 unattributed，多因并存时归因域标 ambiguous，不硬凑一个结论。NVIDIA 称这套系统内部生产用了多年，每周处理数百万 workload、覆盖数十万 GPU；现在开源，Service 是 HTTP 封装，Blueprint 是 Python 编排，连接器覆盖 Slurm、Kueue、静态输入、Loki、本地文件、K8s Pod 日志和 PromQL，输出到 stdout、SQLite 和只读 dashboard。规则可以自己扩展，改规则随 Service 一起发版。 https://developer.nvidia.com/blog/diagnose-distributed-ai-workload-failures-with-nvidia-attribution/

曝光 300 · 评论 1 · 点赞 1 · 书签 1