NVIDIAが、分散AIジョブの障害の根本原因を探すツールをオープンソース化
11月2日、NVIDIAは技術ブログでNVIDIA Attributionのオープンソース化を発表しました。同社が自社のAIインフラで使っていると説明するシステムです。複数のGPUマシンにまたがって動く1つのジョブについて、ログ、メトリクス、スケジューラーの状態を集め、結果を構造化して返します。内容は、結末、根本原因、影響を受けたノード、付随する症状、証拠の連なりです。
背景と情報源
記事の例では、あるノードのNVLink(GPU同士をつなぐ高速の接続)の信号品質の問題が根本原因と特定され、ほかのrank(同じジョブの並列プロセス)で出たNCCL(GPUがデータをやり取りするためのライブラリ)のエラーは、付随する症状として残されます。流れは4段階で、ジョブの範囲を決め、観測を集め、あらかじめ決めたルールでイベントを抽出・突き合わせ、結果を返します。システムは、REST API(ほかのプログラムがネットワーク越しにサービスを呼び出すための入口)を提供するAttribution Serviceと、Pythonで書かれた参考用のオーケストレーターAttribution Blueprintで構成されます。Blueprintには、ジョブスケジューラーのSlurmとKueue、ログ保管のLoki、Kubernetesのpod(一緒に動くコンテナの集まり)のログ、PromQL(メトリクスの問い合わせ言語)で取るメトリクスへのコネクターが用意されています。ルールはソースコードに記述されてServiceと一緒に配布され、API経由で動的にアップロードはされません。NVIDIAは、このシステムが毎週数百万件のジョブを、数十万基のGPUにわたって分析していると述べています。
記事によると、1つの障害が別の場所で大量のメッセージを引き起こすことがあるため、最後の例外の行はジョブが止まった場所を示すだけで、壊れた場所とは限りません。SlurmやKueueでGPUクラスターを運用するチームにとっては、NVIDIAのクイックスタートに沿って試せる型です。クラスターを運用していない人には、今のところやることはありません。
NVIDIA以外のチームが自分のクラスターで動かせるか、ルールが記事の例以外の障害にも対応しているかを見守る必要があります。記事は診断の正答率を挙げていないため、手作業での原因探しと比べられる数字はまだありません。