NCCL Inspector と Prometheus を用いたリアルタイムパフォーマンス監視と高速デバッグ

分散型ディープラーニングは、[NVIDIA Collective Communication Library (NCCL)](https://developer.nvidia.com/nccl) を用いた高速で信頼性の高い GPU 間通信に依存しています。トレーニングが低速化すると、その原因を特定し、次に何をすべきかを判断することが困難になります。問題が発生する範囲は、計算処理、通信プロセス、特定のランク（rank）、あるいは基盤となるハードウェア全体に及ぶ可能性があります。 NVIDIA NCCL Inspector は、NCCL 通信パフォーマンスの軽量かつ継続的なレポートを提供することで、トラブルシューティングを加速します。これは各ランクにおける操作タイプ、サイズ、帯域幅を追跡し、今回の最新機能強化により、最小限のオーバーヘッドでリアルタイム分析を可能にします。 また、最適なトレーニングレシピの決定にも役立ちます。[以前の投稿](https://developer.nvidia.com/blog/enhancing-communication-observability-of-ai-workloads-with-nccl-inspector/) では NCCL Inspector のオフラインモードについて紹介しました。微細な分析は詳細データ調査の標準的な手法として残りますが、本稿ではリアルタイム監視という新機能を紹介します。NCCL Inspector を Prometheus Exporter と統合することで、ユーザーのインフラストラクチャダッシュボード内で直接ライブ時系列可視化が可能になりました。 ## NCCL Inspector のデプロイメントアーキテクチャ NCCL 2.30 では、AI ワークロードにおける NCCL のリアルタイムパフォーマンス監視のための主要な機能強化として**Prometheus Mode**が導入されました。NCCL Inspector は、図 1 および図 2 に示す 2 つのモードで動作します。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/NCCL-Inspector-JSON-Mode-Architecture-Shared-Storage-Output-Files.webp)*図 1. JSON モード（デフォルト/オフラインモード）における NCCL Inspector* JSON モードは、データ収集フェーズとデータ分析フェーズの 2 つの段階で動作します。まず、データ収集フェーズでは各ランクからのパフォーマンスメトリクスが生成され、個別に JSON ファイルとして保存されます（通常は共有ストレージ上）。次に、データ分析フェーズでこのデータを処理します。この手法は処理がリアルタイムで行われないため、「オフライン」として分類されます。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/NCCL-Inspector-Prometheus-Mode-Real-Time-Grafana-Architecture.webp)*図 2. リアルタイム Prometheus モードにおける NCCL Inspector* この新機能では、NCCL Inspector のメトリクスを Prometheus と統合し、Grafana ダッシュボードでの可視化に適した時系列データに変換します。Prometheus モードは、JSON モードで以前必要だった大容量のストレージ要件を不要にします。このメトリクスデータは、ノードエクスポートア（node exporter）によって Prometheus—a scalable, cloud-native platform（スケーラブルなクラウドネイティブプラットフォーム）へ転送されます。NCCL ジョブ出力ファイルは連続的に上書きされるように設計されています。ノードエクスポートアがメトリクスを収集した後、ディスク上にデータを保持する必要はなくなります。 ## Prometheus モードの実験的セットアップ NCCL Inspector プロファイラープラグインを設定するには、まずプラグインをビルドし、以下の必須環境変数を設定する必要があります： NCCL_PROFILER_PLUGIN=/path/to/nccl/plugins/profiler/inspector/libnccl-profiler-inspector.so NCCL_INSPECTOR_ENABLE=1 NCCL_INSPECTOR_DUMP_THREAD_INTERVAL_MICROSECONDS=3000000 NCCL_INSPECTOR_PROM_DUMP=1 NCCL_INSPECTOR_DUMP_DIR=/path/to/node/exporter/log/location ダンプスレッド間隔とダンプディレクトリは、使用するノードエクスプローターに応じて設定および調整する必要があります。設定が完了すると、NCCL Inspector がプロセスを開始し、集合通信のパフォーマンスを**NCCL_INSPECTOR_DUMP_DIR**にダンプします。その後、Prometheus Node Exporter がこれらのメトリクスを Prometheus 時系列データベースへ送信します。最後に、これらの時系列メトリクスは Graphana を用いてダッシュボードグラフとしてレンダリングされます。 ジョブ実行時には、メトリクスが以下の形式のファイルに保存されます：nccl_inspector_metrics_.prom GPU の UUID がファイル名に含まれるのは、マルチユーザー環境では CUDA デバイス ID が重複する可能性があるためです。** ** NCCL ジョブ出力ファイルは Prometheus 公開形式（Prometheus exposition format）です。各メトリクスには、NCCL バージョン、Slurm ジョブ ID、ノード、GPU、コミュニケーター名、ノード数、ランク数、メッセージサイズなどのコンテキストがラベル付けされています。以下に例を示します： nccl_p2p_bus_bandwidth_gbs{version="v5.1",slurm_job_id="1670760",node="nvl72033-T01",gpu="GPU0",comm_name="unknown",n_nodes="1",nranks="64",p2p_operation="Send",message_size="1-2MB"} 19.1634 nccl_p2p_exec_time_microseconds{version="v5.1",slurm_job_id="1670760",node="nvl72033-T01",gpu="GPU0",comm_name="unknown",n_nodes="1",nranks="64",p2p_operation="Send",message_size="1-2MB"} 92.8984 nccl_p2p_bus_bandwidth_gbs{version="v5.1",slurm_job_id="1670760",node="nvl72033-T01",gpu="GPU0",comm_name="unknown",n_nodes="1",nranks="64",p2p_operation="Recv",message_size="1-2MB"} 19.2396 nccl_p2p_exec_time_microseconds{version="v5.1",slurm_job_id="1670760",node="nvl72033-T01",gpu="GPU0",comm_name="unknown",n_nodes="1",nranks="64",p2p_operation="Recv",message_size="1-2MB"} 92.5781 nccl_bus_bandwidth_gbs{version="v5.1",slurm_job_id="1670760",node="nvl72033-T01",gpu="GPU0",comm_name="unknown",n_nodes="4",nranks="32",collective="ReduceScatter"(集約散乱),message_size="134-135MB",algo_proto="RING_SIMPLE"} 44.1181 nccl_collective_exec_time_microseconds{version="v5.1",slurm_job_id="1670760",node="nvl72033-T01",gpu="GPU0",comm_name="unknown",n_nodes="4",nranks="32",collective="ReduceScatter"(集約散乱),message_size="134-135MB",algo_proto="RING_SIMPLE"} 104164 これらのメトリクスが Prometheus データベースに格納された後、次のステップは Grafana でそれらを可視化することです。 ## 時系列に基づく Grafana ダッシュボード 図 3 は、Prometheus のラベルを NVLink 集約ダッシュボードと混合（つまり、ネットワーク＋NVLink 集約）に分類して使用した場合の、時系列ダッシュボードの例を示しています。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/NCCL-AllGather-NVLink-Bus-Bandwidth-Grafana-Dashboard.webp)*図 3. NVIDIA NVLink のみの通信グループにおける NCCL AllGather バス帯域幅（GB/s）を示す Grafana タイムシリーズダッシュボード。単一ノード（n_nodes==1）で 6 分間の観測期間にわたって計測* ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/NCCL-AllGather-Network-NVLink-Bus-Bandwidth-Grafana-Dashboard.webp)*図 4. マルチノード環境（n_nodes==4）における NCCL AllGather バス帯域幅（GB/s）を示す Grafana タイムシリーズダッシュボード。IB/RoCE/EFA を含むネットワーク通信と NVLink 通信を併用したケースで、6 分間の観測期間にわたって計測* ## NCCL Inspector のユースケース トラブルシューティングのワークフローを実証するために、以下の 2 つのユースケースでは、ダッシュボードが根本原因の特定をどのように加速するかを示します。 ## リアルタイム可視化 長時間実行される AI ワークロードにおけるパフォーマンスの低下の原因究明には、ライブダッシュボードを活用してください。ダッシュボード上の変化を観察し、ジョブレベルでの性能劣化と、その背後にある NCCL やネットワーク層のメトリクスを相関させることで、異常が発生した箇所に基づいた標的型のトラブルシューティングが可能になります。この戦略を実証するために、チームは大規模な大規模言語モデル（LLM）の前学習ジョブを実行しました。 タイムライン A：通常のワークフロー** 図 5 は、実験の 1 つにおける混合ネットワーク＋NVLink コレクティブの AllGather バス帯域幅を示しています。この AI 前学習ワークロードの計算性能は*約 310 TFLOPs/GPU*でした。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/NCCL-AllGather-Normal-Workflow-Network-NVLink-Dashboard.webp)*図 5. 4 ノードにおける通常の AI プリートレーニングワークフロー中の混合ネットワーク＋NVLink コミュニケータに対する NCCL AllGather バス帯域幅（GB/s）を示す Grafana タイムシリーズダッシュボード。観測された計算性能は約 310 TFLOPs/GPU に相当*。 **タイムライン B: ネットワーク起因の遅延** 人工的なネットワーク制約を導入した後、混合ネットワーク＋NVLink の集合通信における AllGather バス帯域幅（BusBw）は、計算性能が GPU あたり約 268 TFLOPs に低下し（ベースラインと比較して約 13% の劣化）、その傾向を示しました。 この例は、リアルタイムダッシュボードが混合トランスポート（ネットワーク＋NVLink）の集合通信パフォーマンスの観測性を向上させ、根本原因の特定を迅速化し、平均修復時間（MTTR: Mean Time To Resolution）を短縮できることを示しています。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/NCCL-AllGather-Network-Slowdown-Performance-Degradation-Dashboard.webp)*図 6. タイムライン B（ネットワーク起因の遅延シナリオ）中の混合ネットワーク＋NVLink コミュニケータに対する NCCL AllGather バス帯域幅（GB/s）を示す Grafana タイムシリーズダッシュボード*。 ## パフォーマンスの帰属分析 もう一つのユースケースとして、特定の期間におけるパフォーマンス劣化を分析する支援を行う NCCL Inspector があります。例えば、ある実験では以下のように一時的に性能が低下しました： [2026-03-19 14:39:47.098640] -> GPU あたりのスループット：約 314 TFLOP/s/GPU [2026-03-19 14:40:48.696103] -> GPU あたりのスループット：約 295 TFLOP/s/GPU [2026-03-19 14:42:00.816450] -> GPU あたりのスループット：約 289 TFLOP/s/GPU [2026-03-19 14:44:02.304347] -> GPU あたりのスループット：約 311 TFLOP/s/GPU 次に、観測された性能劣化が、この期間中にネットワークの異常と相関しているかどうかを確認します。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/NCCL-ReduceScatter-NVLink-Performance-Attribution-Dashboard.webp)*図 7. 2026 年 3 月 1 日の性能アトリビューション調査中の NVLink のみを使用するコミュニケータにおける NCCL ReduceScatter バス帯域幅 (GB/s) を示す Grafana タイムシリーズダッシュボード* ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/NCCL-ReduceScatter-Network-NVLink-Performance-Degradation-Dashboard.webp)*図 8. 同じく 2026 年 3 月 19 日の性能アトリビューション調査期間中の、ネットワークと NVLink を組み合わせたコミュニケータにおける NCCL ReduceScatter バス帯域幅 (GB/s) を示す Grafana タイムシリーズダッシュボード* このダッシュボードは、混合トランスポート通信（ネットワークベースおよび NVLink ベースのコレクティブ）において性能劣化が生じていることを示しています。この相関関係から、根本原因がネットワーク上の断絶または輻輳であることがわかります。これにより、ホスト単位およびネットワークごとのカウンターを詳細に調査し、どの箇所で遅延が発生したかを特定することが可能になります。 ## リアルタイム観測性のための次のステップ Prometheus との統合を備えた NCCL Inspector の導入は、AI ワークロードのパフォーマンス分析におけるネットワークの可観測性を強化するために設計されています。この強力な組み合わせにより、パフォーマンス分析に対するより科学的なアプローチが可能になります。ユーザーは、実行中のワークロードの実時間パフォーマンス特性をデバッグ・理解し、遅延の原因を特定し、パラメータを微調整し、詳細なメトリクスを用いてその結果生じるパフォーマンスの変化を測定することができます。 ## 始め方 GitHub の

NCCL Inspector と Prometheus を用いたリアルタイムパフォーマンス監視と高速デバッグ

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

関連記事

調べる

選ぶ

サイト