Compute Engine インスタンスと Slurm クラスタをモニタリングする

クラスタ化された GPU

このドキュメントでは、Cloud Monitoring ダッシュボードを使用して、予約で制限された容量を使用して作成した A4X Max、A4X、A4、A3 Ultra、A3 Mega インスタンスをモニタリングする方法について説明します。これらのダッシュボードを使用すると、スタンドアロンの Compute Engine インスタンスまたは Slurm クラスタのパフォーマンスのボトルネックを特定してトラブルシューティングを行い、ワークロードのダウンタイムを最小限に抑えることができます。

カスタム ダッシュボードを作成するか、事前構築済みの Monitoring ダッシュボードを使用すると、次のことをモニタリングできます。

• コンピューティング インスタンスの健全性

• GPU パフォーマンス

• ネットワーク伝送効率

• ブロックとサブブロック間のネットワーク効率

• 機械学習（ML）ワークロードの効率

• ストラグラー検出

• 応答しないワークロードの検出

Cluster Director でクラスタをモニタリングするには、事前構築されたダッシュボードでクラスタのパフォーマンスをモニタリングするをご覧ください。

始める前に

ワークロードをモニタリングする前に、次の手順を完了します（まだ完了していない場合）。

• モニタリング可能なワークロードをデプロイする。サポートされているワークロードについては、このドキュメントの制限事項をご覧ください。ワークロードをデプロイする方法については、デプロイ オプションの概要をご覧ください。

• ワークロードのモニタリング用の Google Cloud サービスについて学習する:

  • このドキュメントの指標では、Monitoring ダッシュボードを使用します。モニタリング ダッシュボード、モニタリングの保持期間、モニタリングの料金について学習する。

  • Straggler 検出では、Cloud Logging にログエントリも提供されます。Logging インターフェース、Logging の保持期間、Logging の料金について学習します。

Google Cloud コンソールを使用して Google Cloud サービスと API にアクセスする場合、認証を設定する必要はありません。

制限事項

• このドキュメントの指標は、次の条件をすべて満たすコンピューティング インスタンスで実行されるワークロードでのみサポートされます。

  • コンピューティング インスタンスは、スタンドアロンの Compute Engine インスタンスとして作成するか、Slurm クラスタの一部として作成する必要があります。
  • コンピューティング インスタンスは、予約に制限された容量を使用して作成されている必要があります。
  • コンピューティング インスタンスは、A4X Max、A4X、A4、A3 Ultra、A3 Mega のマシンシリーズを使用する必要があります。
    • ただし、遅延検出は、A3 Mega マシンシリーズを使用する仮想マシン（VM）インスタンスもサポートしています。
  注意: A4X Max、A4X、A4、A3 Ultra、A3 Mega 以外のマシンシリーズでも指標が表示されることがありますが、それらの指標は正しくない可能性があります。
• インフラストラクチャ指標の既知の問題:

  • 一部のコンピューティング インスタンスでは GPU Power Consumption 指標が表示されない場合があります。
  • 一部のコンピューティング インスタンスでは、GPU Temperature 指標または GPU Thermal Margin 指標が表示されないか、指標の代わりに NaN が表示されることがあります。
  • 指標が収集されてから 7 分間は、 Google Cloud コンソールに表示されないことがあります。
  • A4X Max、A4X、A4、A3 Ultra、A3 Mega 以外のマシンシリーズでは、指標が正しく表示されないことがあります。

このドキュメントの指標は、次の条件をすべて満たすコンピューティング インスタンスで実行されるワークロードでのみサポートされます。

• コンピューティング インスタンスは、スタンドアロンの Compute Engine インスタンスとして作成するか、Slurm クラスタの一部として作成する必要があります。
• コンピューティング インスタンスは、予約済み容量を使用して作成されている必要があります。
• コンピューティング インスタンスは、A4X Max、A4X、A4、A3 Ultra、A3 Mega のマシンシリーズを使用する必要があります。

ML ワークロードの指標をモニタリングするには、ワークロードのモニタリングを設定する必要があります。

ストラグラー検出の制限事項

遅延検出指標には、次の追加の制限があります。

• A3 Mega 以外のサポートされているマシンシリーズの場合、遅延検出は、Collective Communication Analyzer（CoMMA）ライブラリを有効にして NCCL テレメトリーを Google Cloud サービスにエクスポートするコンピューティング インスタンスのみをサポートします。詳細については、CoMMA の概要をご覧ください。
• 通常、Straggler の検出には最長で 10 分かかります。
• このドキュメントの他の指標とは異なり、プロジェクトの straggler 検出指標をクラスタ、ブロック、サブブロック、コンピューティング インスタンスでフィルタすることはできません。ただし、遅延検出ログのクエリは、遅延の疑いがある 1 つ以上のコンピューティング インスタンスの ID でフィルタできます。

注意: 次のような遅延検出を使用すると、偽陽性または偽陰性が表示されることがあります。

• Straggler 検出ログは、Straggler 検出をサポートしていない実行中のコンピューティング インスタンスが Straggler の疑いがないことを報告します。
• 多くの ML ワークロードではストラグラー検出の精度は高いですが、複雑な通信パターンを持つワークロードでは精度が低くなる可能性があります。

したがって、他の指標でワークロードに問題が発生していることが示されている場合にのみ、疑わしい遅延を処理することをおすすめします。ワークロードの全体的なパフォーマンスが満足のいくものである場合は、対応は推奨されません。

応答しないワークロードの検出の制限事項

応答しないワークロード検出指標は、Collective Communication Analyzer（CoMMA）ライブラリを使用して NCCL テレメトリーを Google Cloud サービスにエクスポートするコンピューティング インスタンスのみをサポートします。詳細については、CoMMA の概要をご覧ください。

必要なロール

AI Hypercomputer ワークロードの指標をモニタリングするために必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。

• Cloud Monitoring で指標を表示するには: プロジェクトに対するモニタリング編集者 （roles/monitoring.editor）
• Logging で遅延検出ログを表示するには: プロジェクトに対するログビューア （roles/logging.viewer）

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

これらの事前定義ロールには、AI Hypercomputer ワークロードの指標をモニタリングするために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

AI Hypercomputer ワークロードの指標をモニタリングするには、次の権限が必要です。

• ダッシュボードを表示する: プロジェクトに対する monitoring.dashboards.get
• ダッシュボードを作成する: プロジェクトの monitoring.dashboards.create
• ログエントリを表示する: プロジェクトに対する logging.logEntries.list

カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

利用可能な指標

ユースケースに応じて、次の指標を使用して、コンピューティング インスタンスと Slurm クラスタをモニタリングできます。

• コンピューティング インスタンスに接続された GPU の健全性、パフォーマンス、ネットワーク パフォーマンスをモニタリングするには、インフラストラクチャ指標をご覧ください。

• ML ワークロードの GPU の効率をモニタリングするには、ML ワークロードの指標をご覧ください。

• パフォーマンスが遅い ML ワークロードで、遅延の原因となっている可能性のあるコンピューティング インスタンスをモニタリングするには、遅延検出指標をご覧ください。

これらの指標を表示する方法については、このドキュメントの指標を可視化するをご覧ください。

インフラストラクチャ指標

コンピューティング インスタンスに接続された GPU の健全性、パフォーマンス、ネットワーク パフォーマンスをモニタリングするには、次の指標を使用します。

• GPU の健全性指標

• GPU パフォーマンス指標

• GPU ネットワーク パフォーマンス指標

• トップオブラック（ToR）スイッチの指標

• GPU の致命的なエラーの指標

Compute Engine で使用可能な指標の概要については、Google Cloud 指標をご覧ください。

GPU の健全性指標

GPU の健全性をモニタリングするには、次の指標を使用します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
マシンのステータス	machine/machine_status	A4X Max、A4X、A4、A3 Ultra、A3 Mega	コンピューティング インスタンスが使用するマシンが正常かどうか。または、マシンが異常で修復が必要かどうか。
NVSwitch ステータス	instance/gpu/nvswitch_status	A4X Max、A4X、A4、A3 Ultra、A3 Mega	コンピューティング インスタンスにアタッチされた NVIDIA GPU の NVLink スイッチで問題が発生しているかどうか。
VM インフラストラクチャの健全性	instance/gpu/infra_health	A4X、A4、A3 Ultra、A3 Mega	コンピューティング インスタンスが実行されているクラスタ、ブロック、サブブロック、ホストの健全性。この指標でコンピューティング インスタンスのインフラストラクチャが異常であることが示されている場合、指標には問題の説明も含まれます。
VM 障害予測スコア	instance/gpu/failure_prediction_score	A4X、A4、A3 Ultra、A3 Mega	コンピューティング インスタンスが実行されているホストが、今後 5 時間以内にパフォーマンスが低下する可能性。値は 0.0～1.0 の範囲で指定できます。値が一定期間 1.0 に近いほど、コンピューティング インスタンスが劣化する可能性が高くなります。その場合は、ジョブを別のコンピューティング インスタンスに移動し、コンピューティング インスタンスで問題が発生した場合は、そのホストに障害があると報告することをおすすめします。

GPU パフォーマンス指標

GPU のパフォーマンスをモニタリングするには、次の指標を使用します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
累積コンテキスト使用率	instance/gpu/accumulated_context_utilization_seconds	A4X Max、A4X、A4、A3 Ultra、A3 Mega	GPU がワークロードの処理に費やした合計時間（秒単位）。
GPU 消費電力	instance/gpu/power_consumption	A4X Max、A4X、A4、A3 Ultra、A3 Mega	ホスト上の個々の GPU で消費される電力（ワット単位）と 10 進数値。複数の GPU が接続されているコンピューティング インスタンスの場合、この指標はホスト上の各 GPU の消費電力を個別に提供します。
SM 使用率	instance/gpu/sm_utilization	A4X Max、A4X、A4、A3 Ultra、A3 Mega	ゼロ以外の値は、GPU のストリーミング マルチプロセッサ（SM）がアクティブに使用されていることを示します。
GPU の温度	instance/gpu/temperature	A4X Max、A4X、A4、A3 Ultra、A3 Mega	ホスト上の個々の GPU の温度（摂氏（℃）および 10 進数値）。複数の GPU が接続されているコンピューティング インスタンスの場合、この指標はホスト上の各 GPU の温度を個別に提供します。
GPU サーマル マージン	instance/gpu/tlimit	A4X Max、A4X、A4、A3 Ultra、A3 Mega	個々の GPU が高温のために速度を落とす必要が生じるまでの、摂氏（℃）の温度余裕と 10 進数値。複数の GPU が接続されているコンピューティング インスタンスの場合、この指標はホスト上の各 GPU の熱ヘッドルームを個別に提供します。

GPU ネットワーク パフォーマンス指標

GPU のネットワーク パフォーマンスをモニタリングするには、次の指標を使用します。バックエンドの ToR ネットワーク スイッチをモニタリングするには、ToR スイッチの指標をご覧ください。

名前	指標タイプ	サポートされているマシンシリーズ	説明
Link Carrier Changes	instance/gpu/link_carrier_changes	A4X、A4、A3 Ultra、A3 Mega	ネットワーク リンクのキャリアが 1 分間に変更される頻度。
ネットワーク RTT	instance/gpu/network_rtt	A4X、A4、A3 Ultra、A3 Mega	ネットワーク データが送信元と宛先の間を移動するラウンドトリップ時間（マイクロ秒単位）。
ブロック間のネットワーク トラフィック	instance/gpu/network/inter_block_tx	A4X、A4、A3 Ultra、A3 Mega	ブロック間のネットワーク トラフィックのバイト数。
サブブロック間のネットワーク トラフィック	instance/gpu/network/inter_subblock_tx	A4X、A4、A3 Ultra、A3 Mega	サブブロック間のネットワーク トラフィックのバイト数。
サブブロック内のネットワーク トラフィック	instance/gpu/network/intra_subblock_tx	A4X、A4、A3 Ultra、A3 Mega	単一のサブブロック内のネットワーク トラフィックのバイト数。
NVLink アクティブ速度	instance/gpu/nvlink_active_speed	A4X Max、A4X、A4、A3 Ultra、A3 Mega	現在のアクセスリンク ポート速度（GBps）。
スループット Rx バイト数	instance/gpu/throughput_rx_bytes	A4X、A4、A3 Ultra、A3 Mega	ネットワーク トラフィックから受信したバイト数。
スループット Tx バイト数	instance/gpu/throughput_tx_bytes	A4X、A4、A3 Ultra、A3 Mega	ネットワーク トラフィックに送信されたバイト数。

ToR スイッチの指標

A4X Max クラスタと A4X クラスタでは、バックエンド ToR ネットワーク スイッチのテレメトリーをモニタリングして、分散 ML トレーニング中に次の操作を行うことができます。

• スイッチとポートの健全性を監視します。
• 利用可能な帯域幅容量とバッファキューの深さを評価します。
• パケットの破棄、エラー、インターフェースのフラップ、輻輳管理イベントを診断します。

これらの指標では、compute.googleapis.com/NetworkSwitch モニタリング対象リソースタイプと compute.googleapis.com/ 指標タイプの接頭辞が使用されます。Metrics Explorer で、NetworkSwitch リソースタイプ（compute.googleapis.com/NetworkSwitch）を選択します。

スイッチの指標は、次のカテゴリに分類されます。

スイッチの健全性とステータス指標

このセクションに記載されている指標を使用して、次のことを行います。

• スイッチ ポートの動作ステータスを確認します。
• スイッチの CPU とメモリ使用率をモニタリングします。
• 起動時間を確認して、予期しない再起動を検出します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
ポートのステータス	network_switch/port_status	A4X Max または A4X	ネットワーク スイッチの物理インターフェース（ポート）の動作ステータスを示します。指標値は常に 1 です。実際の状態は status ラベル（UP や DOWN など）で提供されます。 キーラベル: port_identifier、status、peer_target_identifier、peer_port_identifier、subblock_id、block_id、reservation_id、switch_type。
CPU 使用率	network_switch/cpu_utilization	A4X Max または A4X	ネットワーク スイッチの CPU 使用率。0.0～1.0 の割合で測定されます。 キーラベル: subblock_id、block_id、reservation_id、switch_type。
Memory used	network_switch/memory_used	A4X Max または A4X	ネットワーク スイッチで使用されているメモリ（バイト単位）。 キーラベル: subblock_id、block_id、reservation_id、switch_type。
合計メモリ	network_switch/total_memory_bytes	A4X Max または A4X	ネットワーク スイッチの合計メモリ容量（バイト単位）。 キーラベル: subblock_id、block_id、reservation_id、switch_type。
起動時間	network_switch/boot_time_in_ns	A4X Max または A4X	ネットワーク スイッチの起動タイムスタンプ（Unix エポックからのナノ秒数）。 キーラベル: subblock_id、block_id、reservation_id、switch_type。

スイッチの容量とキューの指標

ベースラインと使用可能なネットワーク容量を追跡し、スイッチのバッファキューの深さとキューのドロップをモニタリングするには、次の指標を使用します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
ベースライン容量	network_switch/baseline_capacity_kbps	A4X Max または A4X	スーパーブロックへの ToR スイッチ接続のベースライン帯域幅の合計容量（キロビット/秒（kbit/秒））。 キーラベル: subblock_id、block_id、reservation_id、switch_type。
実効容量	network_switch/effective_capacity_kbps	A4X Max または A4X	スーパーブロックへの ToR スイッチ接続の使用可能な運用容量（キロビット / 秒（kbit/秒））。この指標は、リンクの劣化またはオフラインによって発生した容量の減少を反映します。 キーラベル: subblock_id、block_id、reservation_id、switch_type。
下り（外向き）最大キュー深度	network_switch/egress_max_queue_depth	A4X Max または A4X	最新の測定サイクルで観測された最大キュー深度。 キーラベル: port_identifier、queue_name、subblock_id、block_id、reservation_id、switch_type。
下り（外向き）キューのドロップ	network_switch/egress_queue_drops_count	A4X Max または A4X	キューの輻輳またはバッファの枯渇により、下り（外向き）キューからドロップされたパケットの累積数。 キーラベル: port_identifier、queue_name、subblock_id、block_id、reservation_id、switch_type。
バッファ破棄数	network_switch/in_buffer_discards	A4X Max または A4X	バッファ オーバーフローが原因で入力時に破棄された受信パケットの累積数。 キーラベル: port_identifier、peer_target_identifier、peer_port_identifier、subblock_id、block_id、reservation_id、switch_type。

スイッチのドロップ、エラー、フロー制御の指標

このセクションの指標を使用して、分散トレーニングの停止や、集団通信のタイムアウト（NCCL ウォッチドッグのタイムアウトなど）を引き起こす可能性のある次の問題を診断します。

• パケットの破棄、伝送エラー、物理リンクのフラップ。
• 前方誤り訂正（FEC）の単語エラー。
• 優先度ベースのフロー制御（PFC）の一時停止や明示的輻輳通知（ECN）のマーキングなどの輻輳管理イベント。

注: 優先度ベースのフロー制御（PFC）指標（network_switch/pfc_rx_packets_count と network_switch/pfc_tx_packets_count）は、PFC が有効になっている専用環境にのみ適用されます。

名前	指標タイプ	サポートされているマシンシリーズ	説明
インターフェース フラップ	network_switch/interface_flaps_count	A4X Max または A4X	スイッチポート インターフェースでの物理リンク状態の移行（UP と DOWN の間のフラップ）の累積カウント。 キーラベル: port_identifier、subblock_id、block_id、reservation_id、switch_type。
Fec 単語エラー	network_switch/fec_word_error_count	A4X Max または A4X	前方誤り訂正（FEC）ワードエラーの累積数。correctable ブール値ラベル（true または false）を使用して、修正可能なエラーと修正不可能なエラーを区別します。 キーラベル: port_identifier、correctable、subblock_id、block_id、reservation_id、switch_type。
ECN マーク付きパケット	network_switch/ecn_marked_packets_count	A4X Max または A4X	バッファしきい値の超過により明示的輻輳通知（ECN）ビットでマークされたパケットの累積数。 キーラベル: port_identifier、subblock_id、block_id、reservation_id、switch_type。
Pfc rx パケット	network_switch/pfc_rx_packets_count	A4X Max または A4X	ポートで受信した優先度ベースのフロー制御（PFC）一時停止フレームの累積数。 注: PFC が有効になっている専用環境にのみ適用されます。 キーラベル: port_identifier、priority_index、subblock_id、block_id、reservation_id、switch_type。
Pfc tx パケット	network_switch/pfc_tx_packets_count	A4X Max または A4X	受信トラフィックを調整するためにポートから送信された Priority-based Flow Control（PFC）一時停止フレームの累積数。 注: PFC が有効になっている専用環境にのみ適用されます。 キーラベル: port_identifier、queue_name、subblock_id、block_id、reservation_id、switch_type。
QoS 送信パケット	network_switch/qos_tx_packets	A4X Max または A4X	指定されたキューで送信された Quality of Service（QoS）パケットの累積数。 キーラベル: port_identifier、queue_name、subblock_id、block_id、reservation_id、switch_type。
受信パケット数	network_switch/in_packets_count	A4X Max または A4X	スイッチポートで受信した受信パケットの累積数。 キーラベル: port_identifier、subblock_id、block_id、reservation_id、switch_type。
エラーあり	network_switch/in_errors	A4X Max または A4X	エラーが発生して配信されなかった受信パケットの累積数。 キーラベル: port_identifier、peer_target_identifier、peer_port_identifier、subblock_id、block_id、reservation_id、switch_type。
[Discards]（破棄）	network_switch/in_discards	A4X Max または A4X	破棄された有効な受信パケットの累積数（バッファ容量の不足など）。 キーラベル: port_identifier、peer_target_identifier、peer_port_identifier、subblock_id、block_id、reservation_id、switch_type。
出力エラー	network_switch/out_errors	A4X Max または A4X	エラーが原因で送信に失敗したアウトバウンド パケットの累積数。 キーラベル: port_identifier、peer_target_identifier、peer_port_identifier、subblock_id、block_id、reservation_id、switch_type。
アウト ディスカード	network_switch/out_discards	A4X Max または A4X	エラーが検出されなかったにもかかわらず破棄されるように選択されたアウトバウンド パケットの累積数。 キーラベル: port_identifier、peer_target_identifier、peer_port_identifier、subblock_id、block_id、reservation_id、switch_type。
インバウンド バイト数	network_switch/in_bytes_count	A4X Max または A4X	スイッチポートで受信した受信バイトの累積数。 キーラベル: port_identifier、subblock_id、block_id、reservation_id、switch_type。
アウトバウンド バイト数	network_switch/out_bytes_count	A4X Max または A4X	スイッチポートから送信されたアウトバウンド バイトの累積数。 キーラベル: port_identifier、subblock_id、block_id、reservation_id、switch_type。

GPU 致命的エラー指標

GPU で発生し、コンピューティング インスタンスの停止を強制したり、パフォーマンスに悪影響を及ぼす可能性のあるエラーをモニタリングするには、次の指標を使用します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
NVLink ランタイム エラー	instance/gpu/nvlink_runtime_error	A4X Max または A4X	NVLink ランタイム エラーが発生したかどうか。
修正不可能な DRAM ECC エラー	instance/gpu/dram_uncorrectable_ecc_error_count	A4X Max または A4X	GPU のダイナミック ランダム アクセス メモリ（DRAM）内の修正不可能な誤り訂正コード（ECC）の数。
修正不可能な DRAM 行の再マッピング数	instance/gpu/dram_uncorrectable_row_remapping_count	A4X Max または A4X	GPU DRAM の修正不可能なエラーからの行の再マッピング数。
修正不可能な DRAM 行の再マッピングに失敗しました	instance/gpu/dram_row_remapping_failed	A4X Max または A4X	次のいずれかの問題により、GPU DRAM の行のマッピングが失敗したかどうか: メモリバンクにすでに 8 つの訂正不可能なエラー行が再マッピングされているため、メモリバンクの再マッピングの試行が失敗しました。 行がすでに再マッピングされているため、行の再マッピングの試行が失敗しました。 合計 512 回のリマッピングが発生したため、リマッピングの試行が失敗しました。
修正不可能な PCIe エラー	instance/gpu/pcie_fatal_error_count	A4X Max または A4X	訂正不可能な Peripheral Component Interconnect Express（PCIe）エラーの数。
修正不可能なキャッシュ ECC エラー	instance/gpu/cache_uncorrectable_ecc_error_count	A4X Max または A4X	キャッシュ メモリ内の修正不可能な ECC の数。

ML ワークロードの指標

ML ワークロードの生産性（特にスループット）をモニタリングするには、次の指標を使用します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
生産的な時間	workload/goodput_time	A4X、A4、A3 Ultra、A3 Mega	ワークロードがグッドプット アクティビティに費やした時間（秒単位）。これらのアクティビティは、モデルのトレーニング中のフォワード パスやバックワード パスなど、有用なコアタスクです。
非生産的な時間	workload/badput_time	A4X、A4、A3 Ultra、A3 Mega	ワークロードが badput アクティビティに費やした時間（秒）。これらのアクティビティは、トレーニング用のデータの読み込みや前処理などのオーバーヘッド タスクです。

ストラグラー検出指標

Straggler 検出指標は、疑わしい Straggler を特定して特定するのに役立ちます。ストラグラーは、最終的にワークロード全体を遅くする単一障害点であり、クラッシュしない障害です。

VM の遅延タスクの検出をモニタリングするには、次の指標を使用します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
Suspected Stragglers	instance/gpu/straggler_status	A4X、A4、A3 Ultra、A3 Mega	ワークロードのパフォーマンスに影響する遅延 VM として疑われる VM かどうか。他の指標でワークロードに問題が発生していることが示されている場合にのみ、遅延していると思われるタスクに対処することをおすすめします。

また、A4X、A4、A3 Ultra、A3 Mega インスタンスのログエントリで、遅延検出指標を確認することもできます。たとえば、次のクエリを使用できます。

説明	クエリ
特定の VM の遅延が疑われるログ。このクエリを使用して、プロジェクト内の特定のワークロードにストラグラーの疑いがあるかどうかを確認します。	logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID" INSTANCE_ID は、VM の ID に置き換えます。指定する VM を追加するごとに、次の条件をクエリに追加します。 OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
プロジェクトの遅延検出からのすべてのログ。このクエリを使用して、疑わしい遅延が検出されなかった場合に、遅延検出サービスが実行されているかどうかを確認します。（制限により、特定の VM で疑わしい遅延のないログをフィルタすることはできません）。	logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

ストラグラー検出指標は、次の理由から、大規模な ML ワークロードに特に役立ちます。

• 大規模な ML ワークロードは、遅延の影響を受けやすい。大規模な ML ワークロードでは、同期型の超分散コンピューティングが使用されます。（つまり、同時に実行される相互依存性の高いコンポーネントが多数存在します）。このアーキテクチャでは、大規模な ML ワークロードが、遅延などの単一障害点の影響を受けやすくなります。

• 大規模な ML ワークロードでストラグラーを特定することは非常に困難です。参考として、単一障害点には次の 2 種類があることを考慮してください。

  • 停止障害: システム全体を停止させる障害（ホストエラーやメンテナンス イベントなど）。検出と解決は比較的簡単です。

  • slow failures: クラッシュせずにパフォーマンスが大幅に低下する障害。特定とデバッグが非常に困難です。

  遅延障害の性質上、特に大規模な同期ワークロードでは、遅延を検出して特定することが本質的に困難です。

応答しないワークロードの検出指標

応答しないワークロードの検出指標は、次の作業に役立ちます。

• ワークロード全体が停止したことを通知する（NCCL ハングと呼ばれることもあります）
• ワークロードが停止した理由（プロセス クラッシュやネットワークの停止など）を把握する

コンピューティング インスタンスの応答しないワークロードを検出して診断するには、次の指標を使用します。

名前	指標タイプ	サポートされているマシンシリーズ	説明
NCCL テレメトリーを使用して検出された応答しないワークロード イベント	instance/gpu/nccl_hang	A4X Max、A4X、A4、A3 Ultra	検出された無応答のワークロード イベントの数（時系列）。

応答しないワークロードの検出を有効にする

応答しないワークロードの検出を有効にするには、ハートビート テレメトリー（ワークロードが実行中であることを示す定期的な ping 信号）で CoMMA を有効にする必要があります。最近のバージョンの CoMMA では、これはデフォルトで有効になっています。ただし、NICCL/gIB バンドルのバージョン 1.1.1 以降の CoMMA バージョンを使用している場合は、手動でハートビート テレメトリーを有効にする必要があります。使用している NICCL/gIB バンドルのバージョンを確認するには、NCCL と gIB のバージョンを確認するをご覧ください。

CoMMA のハートビート テレメトリーを手動で有効にするには、トレーニング環境で次の環境変数を指定します。

NCCL_PROFILER_HEARTBEAT=true

NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL=10s

NCCL_PROFILER_HEARTBEAT を使用してハートビート テレメトリーをオンまたはオフにし、NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL を使用してハートビート テレメトリーの頻度を指定します。詳細については、CoMMA 環境変数をご覧ください。

応答しないワークロードの検出をオフにする

応答しないワークロードの検出をオフにするには、トレーニング環境で次の環境変数を指定して、CoMMA でハートビート テレメトリーをオフにします。

NCCL_PROFILER_HEARTBEAT=false

ワークロードが応答しない理由を理解する

ワークロードが応答しない理由を把握するには、次の手順でラベル hang_reason の値を確認します。

1. Google Cloud コンソールで Metrics explorer のページに移動します。

   [Metrics Explorer] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。

2. 次の指標を検索します。

   compute.googleapis.com/instance/gpu/nccl_hang
   

3. [集計] 機能を使用して、次のラベルを選択します。

   • instance_id
   • hang_reason

次の表に、ラベルの可能な値、ワークロードに関するそれらの値の意味、推奨される次のステップを示します。

ラベルの値	説明	推奨される次のステップ
MissingHeartbeatIssue	1 つ以上のランクでハートビート テレメトリーが停止しました。これは通常、致命的なプロセスまたはノードのクラッシュを示します。	インスタンスにまだアクセスできるかどうかを確認します。 ワークロード プロセスがクラッシュしたかどうかを確認します。 システムログで、dmesg などのメモリ不足（OOM）イベントを確認します。 ハードウェア障害または NVIDIA XID エラーを探します。
StalledRankIssue	ハートビート テレメトリーは引き続き受信されますが、NCCL オペレーションでランクが進行しません。	アプリレベルのオペレーションで発生する可能性のあるデッドロックを調査します。 アプリケーション プロセスが、計算やチェックポイントなど、他のプロセスとの通信を妨げるオペレーションで停止していないか確認します。
MissingCommunicatorIssue	NCCL 通信に属するすべてのランクが進行を停止しました。	ワークロードが中断されたか、NCCL 通信が突然終了した可能性があります。この VM インスタンスでワークロードが中断なく実行されることを想定している場合は、ワークロードが異常に中断またはシャットダウンされていないかどうかを確認します。
NoHangIssue	デフォルト値。問題は検出されませんでした。	必要なご対応は特にありません。

指標を表示

コンピューティング インスタンスと Slurm クラスタの指標を表示するには、次のように Monitoring ダッシュボードを使用します。

• インフラストラクチャの指標と遅延検出の指標を表示するには、次の操作を行います。

  • インフラストラクチャの健全性とパフォーマンスの概要をすばやく確認する場合や、既存のダッシュボードをカスタマイズする場合は、事前構築済みダッシュボードを使用します。

  • 特定のモニタリング ニーズに合わせて、カスタム ダッシュボードを作成します。

• ML ワークロード指標を表示するには、ワークロードのモニタリングを設定する方法に関するドキュメントをご覧ください。

• ストラグラー検出のログを表示するには、ストラグラー検出ログを表示します。

ダッシュボードの使用時に問題が発生した場合は、パフォーマンスの低下のトラブルシューティングをご覧ください。

事前構築済みのダッシュボードを使用する

AI Hypercomputer 用に事前構築された Monitoring ダッシュボードを使用して、コンピューティング インスタンスと Slurm クラスタの指標を表示できます。事前構築されたダッシュボードのコピーを作成し、ニーズに合わせて変更することもできます。

AI Hypercomputer 用の事前構築済みダッシュボードを使用する手順は次のとおりです。

1. Google Cloud コンソールで [ダッシュボード] ページに移動します。

   [ダッシュボード] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。

2. [名前] 列で、表示する指標に基づいて、次のいずれかのダッシュボードの名前をクリックします。

   • コンピューティング インスタンスの健全性、GPU パフォーマンス、ストラグラーの検出をモニタリングするには、Cluster Director Health Monitoring ダッシュボードを使用します。

     これらの指標を使用して問題を特定して分析する方法については、GCE Interactive Playbook - Cluster Director Health Monitoring プレイブック ダッシュボードもご覧ください。

   • ネットワーク伝送効率をモニタリングするには、Cluster Director Transmission Efficiency ダッシュボードを使用します。

   • ブロックとサブブロック間のネットワーク効率をモニタリングするには、Cluster Director Block Network ダッシュボードを使用します。

     これらの指標を使用して問題を特定して分析する方法については、GCE インタラクティブ プレイブック - Cluster Director ブロック ネットワーク プレイブック ダッシュボードもご覧ください。

   選択したダッシュボードの詳細ページが開きます。ツールバーの期間セレクタを使用すると、データの期間を変更できます。

3. 省略可: ダッシュボードのコピーを作成してニーズに合わせてカスタマイズするには、 [ダッシュボードをコピー] をクリックします。

カスタム ダッシュボードを作成する

カスタムのモニタリング ダッシュボードを作成する手順は次のとおりです。

1. モニタリングする指標を選択します。まだ確認していない場合は、このドキュメントの使用可能な指標をご覧ください。

2. カスタム ダッシュボードを作成して管理する。

遅延検出ログを表示する

ログ エクスプローラを使用して遅延検出ログを表示する手順は次のとおりです。

1. Google Cloud コンソールで、セグメント [ログ エクスプローラ] ページに移動します。

   [ログ エクスプローラ] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Logging] の結果を選択します。

   デフォルトでは、このページはプロジェクト内のすべてのログをクエリします。[クエリを停止] をクリックします。

2. ツールバーの期間セレクタを使用して、分析する期間を選択します。

3. [クエリ] ペインに、遅延検出ログのクエリを入力します。

4. [クエリを実行] をクリックします。

以下に、遅延検出ログエントリの例を示します。

  {
    ...
    "jsonPayload": {
      ...
      "@type": "type.googleapis.com/ml.aitelemetry.performancedebugging.output.NetworkStragglersOutput",
      "suspectedStragglersDetection": {
        "numNodes": 4,
        "nodes": [
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_1"
          },
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_2"
          },
          {
            "instanceId": "INSTANCE_ID_3",
            "latencyMs": 4
          },
          {
            "instanceId": "INSTANCE_ID_4",
            "latencyMs": 0
          }
        ],
        "message": "Suspected stragglers detected."
      }
    },
    "resource": {
      "type": "project",
      "labels": {
        "project_id": "PROJECT_NUMBER"
      }
    },
    ...
    "severity": "INFO",
    "logName": "projects/PROJECT_ID/logs/compute.googleapis.com%2Fworkload_diagnostic",
    ...
  }
  

このログエントリには次のフィールドが含まれます。

• numNodes: プロジェクトで検出された、疑わしいストラグラー コンピューティング インスタンスの数。この例では、4 つの疑わしいストラグラー コンピューティング インスタンスが検出されています。
• instanceId: 疑わしいストラグラーとして検出されたコンピューティング インスタンスの ID。

次のステップ

• VM の観察とモニタリング
• Google Cloud サービスのダッシュボードをカスタマイズする
• パフォーマンスの低下に関するトラブルシューティング