NVIDIA Attribution blog hero: diagnosing distributed workload failures
Figure: NVIDIA Technical Blog OG image, NVIDIA Developer Blog

要点

  • NVIDIA Technical Blog (2026-11-02) open-sources NVIDIA Attribution: correlates workload-scoped logs, metrics, telemetry, and scheduler state into a structured diagnosis (outcome, root cause, affected nodes, symptoms, evidence trail).
  • Two deployables: Attribution Service (REST around the rules engine) + Attribution Blueprint (scheduler/telemetry connectors and reference orchestrator); Slurm, Kueue, Loki, PromQL, and more.
  • Worked example: XID 149 (NVLink signal integrity) on node-02 becomes root cause; multi-rank NCCL errors are demoted to inspectable supporting symptoms; terminal state maps to hardware failure.
  • Vendor: years in production on NVIDIA AI infrastructure—millions of workloads/week across hundreds of thousands of GPUs; used on a large RDMA cluster to target host/switch port patterns.

In distributed training, what you see first is rarely the root cause. A GPU or fabric fault can surface as NCCL errors on other ranks, scheduler flips, and thousands of downstream lines; the exception shows where the job stopped, not where the failure began.

On 2026-11-02 NVIDIA’s technical blog open-sources the workload-centric attribution system it has run in-house for years, with a runnable Blueprint. The thesis: ops is missing not more raw logs, but reproducible, attempt-scoped deterministic attribution that separates root cause from cascade symptoms and emits an evidence trail recovery systems can consume.

[1]

What shipped

NVIDIA Attribution analyzes one workload attempt, not isolated node events. Four stages: scope via scheduler IDs or an explicit window/allocation; collect Observations from app logs, syslogs, driver/Fabric Manager, scheduler history, and node/network metrics; extract and correlate XID, NCCL, scheduler transitions, and metric conditions with timing rules; return terminal_state, sub_domain, symptoms, affected nodes, and collector coverage/errors.

Architecture splits Service (self-hosted HTTP) from Blueprint (Python reference orchestrator + read-only dashboard). The same engine can span clusters while connectors adapt. Downstream systems read structured fields instead of product-private log dialects.

[1]

How hard is the evidence?

The checkable mechanism evidence is a worked sample path: three distinct NCCL errors in app logs; node-02 syslogs with XID 149 whose error words decode to NVLink signal integrity; EARLY filtering emits the attribution event while leaving NCCL intact; FINAL rules (e.g. Xid149AndNvlinkFiltering, Gb200PriorityRootCause) keep the integrity symptom, demote others, and map outcome to hardware failure. Demotion still marks original NCCL sources as “interesting” for inspection. When evidence is incomplete, sub_domain can be ambiguous—the diagnosis records uncertainty instead of forcing a single cause.

Production scale claims (millions of workloads/week, hundreds of thousands of GPUs, RDMA port patterning) are vendor-stated without an independent audit in the post; the OSS repo and quickstart make the method runnable, but hit rates on external fleets remain self-proven.

[1]

Steelman and gaps

Steelman: human cross-node log reading does not scale; node health alone or in-job NVRx alone poorly answers “why did this attempt die and whom should we isolate?”; versioned deterministic rules are easier to test into a recovery loop than one-shot LLM log reading.

Gaps: rule quality tracks telemetry completeness; production numbers cannot be independently verified from the post; integration narrative with Recovery is stronger than third-party deployment detail; native Kubernetes paths are still expanding in the ecosystem. Reading this as “automatic root-cause AI” misreads it—it is rules-and-connectors engineering.

[1]

Who pays / what to watch

Idle GPUs and on-call engineers pay: every wrong root cause widens isolation and restart cost. Consumers are recovery orchestration, incident systems, and fleet management—structured terminal_state / sub_domain beats pasted NCCL stacks.

Over six months, watch external rules/connectors entering the same review stream; whether Attribution verdicts become default audit fields for NVIDIA Recovery; and adaptation cost on non-NVIDIA scheduler/log stacks.

[1]

Close

Distributed-failure narratives often stop at “NCCL blew up again.” This release reframes a missing ops layer: scope one workload attempt, demote cascade symptoms, and keep a rooted evidence trail—otherwise automated recovery only restarts the wrong hypothesis faster.

[1]