NVIDIA Attribution: 分散型AI障害の診断を支援するオープンソースツール

NVIDIAは、分散型AIワークロードの障害をエンジニアが診断できるよう支援するオープンソースプロジェクト「NVIDIA Attribution」を公開しました。2026年11月2日に発表されたこのツールは、大規模なGPUクラスタのデバッグに伴う複雑性に対応し、異なるデータソースを単一の構造化された診断結果に統合します。単純なエラー報告にとどまらず、ワークロードがなぜ失敗したのかを説明することに重点を置いています。

何が起きたか

分散型トレーニングジョブは、単一のハードウェアまたはネットワークの問題が数千もの下流症状を引き起こすカスケードエラーにより、しばしば失敗します。あるGPUでの障害が、他の多くのランク（rank）における通信タイムアウトとして現れることがあり、根本原因とノイズを区別することが困難になります。従来の監視ツールは通常、ワークロードがどこで停止したかを報告しますが、障害が発生した場所までは示さないため、調査時間が長期化しがちです。

これを解決するため、NVIDIAは社内で使用していたワークロード中心の障害帰属（failure-attribution）システムをオープンソース化しました。このツールは、何年も前からNVIDIA AIインフラストラクチャの本番環境で使用されており、週あたり数十万のGPU上で数百万件のワークロードを分析しています。ワークロードスコープ内のログ、メトリクス、テレメトリ、スケジューラの状態を相関させることで、結果、根本原因、影響を受けたノード、証拠トレイルを含む再現可能な診断を作成します。

今回のリリースには、主に展開可能な2つのコンポーネントが含まれています：Attribution ServiceとAttribution Blueprintです。ServiceはREST APIを通じてコアとなる帰属エンジンを公開し、BlueprintはPythonのリファレンスオーケストレーターとして機能します。BlueprintはクラスタスケジューラーやテレメトリソースをServiceに接続し、チームが既存のインフラストラクチャにツールを統合できるようにすることで、コアロジックの再構築を不要にします。

仕組み

帰属プロセスは、再現性を確保するために4つの決定的なステージに従います。まず、Blueprintはスケジューラの識別子や実行ウィンドウを使用して特定の試行を特定し、ワークロードのスコープを設定します。次に、アプリケーションログ、syslog、GPUドライバメッセージ、ネットワークメトリクスなど、さまざまなコネクタから観測データを収集します。これらの入力は、構造化された観測レコードとして正規化されます。

続いて、Serviceはルールエンジンを使用してイベントを抽出し、相関させます。GPU XIDs、NCCL障害、スケジューラの遷移などの重要なイベントを特定します。決定的なルールがこれらのイベントのタイミングと相互作用を評価し、下流症状と主要な原因を分離します。例えば、あるGPUが信号整合性の問題を報告し、他のランクが通信エラーを報告する場合、システムはハードウェア障害を根本原因とし、通信エラーを補足的な症状として識別します。

最後に、システムは終了状態、帰属ドメイン、影響を受けたノードを含む構造化された結果を返します。出力では、確定的な根本原因と、証拠が不完全で曖昧な状況が区別されます。この構造化された形式により、インシデント管理や自動復旧ツールなどのダウンストリームシステムが、生かつ製品固有のログを解析することなく診断結果を利用できます。

主な詳細

• システムは2つのコンポーネントで動作します：分析用のAttribution Serviceと、オーケストレーションおよびデータ収集用のAttribution Blueprintです。
• Slurm、Kueue、静的入力のための実行コンテキストコネクタに加え、Loki、ローカルファイル、Kubernetesポッドログ、PromQLのためのログおよびメトリクスコネクタをサポートしています。
• 本番環境では、ポートエラーと接続リセットを相関させることにより、特定のホストおよびスイッチポート周辺のファブリック障害パターンを識別しています。
• 帰属エンジンは、イベントのタイミングを評価するために決定的なルールを使用しており、結果の再現性を保証し、異なる環境向けにカスタマイズ可能にします。
• 出力には品質指標が含まれており、複数の原因が証拠に適合する場合の不確実性を反映し、不完全な診断に対する誤った確信を避けます。
• 開発者は、障害モード向けの新しいルールの追加や、カスタムスケジューラおよびテレメトリバックエンドのコネクタの実装により、システムを拡張できます。

なぜ重要なのか

ソフトウェアエンジニアやMLインフラリードにとって、高価なGPUリソースの高い稼働率を維持するためには、平均修復時間（MTTR）の短縮が不可欠です。分散型障害の手動デバッグは時間がかかり、エラーが生じやすく、専門家がギガバイト単位のログを精査する必要がしばしばあります。NVIDIA Attributionはこの相関処理を自動化し、チームが障害の原因を探し回るのではなく、インフラの問題の修正に集中できるようにします。明確な証拠トレイルを提供することで、ソフトウェアチームとハードウェア運用チーム間のより良いコミュニケーションも促進します。

このプロジェクトのオープンソース nature により、組織はツールを自社の特定のスタックに適応させることができます。コアロジックが統合レイヤーから分離されているため、チームは異なるクラスタ間で同じ帰属ルールを適用しつつ、データの収集および保存方法をカスタマイズできます。この柔軟性は、小規模な研究用クラスタから大規模な本番フリートまで多様な環境をサポートし、組織全体で一貫した障害分析プラクティスを可能にします。

できること

• GitHubからNVIDIA Attributionリポジトリをクローンして、ソースコードとサンプルワークロードにアクセスしてください。
• クイックスタートガイドに従い、Dockerとuvパッケージマネージャーを使用してサンプルワークフローを実行してください。
• ローカルダッシュボードで生成された診断を確認し、システムがイベントを相関させ、根本原因をどのように特定するかを理解してください。
• Blueprint設定リファレンスを確認し、SlurmやKubernetesなど、自社独自のスケジューラおよびテレメトリバックエンドを接続してください。
• 同梱されている宣言型およびPythonルールを検討し、特定のハードウェアまたはソフトウェアスタック向けに新しい障害パターンをエンコードする方法を学んでください。
• Attribution Blueprint Resultを既存のインシデント管理システムやフリート復旧システムに統合し、一般的な障害への対応を自動化してください。