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 ダッシュボードを使用します。Monitoring ダッシュボード、Monitoring の保持期間、Monitoring の料金について学習する。

  • ストラグラー検出では、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 が表示される場合もあります。
  • 指標が収集されてから Google Cloud コンソールに表示されるまでに、最長で 7 分かかることがあります。
  • A4X Max、A4X、A4、A3 Ultra、A3 Mega 以外のマシンシリーズでは、誤った指標が表示されることがあります。

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

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

ストラグラー検出指標には、次の追加の制限があります。

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

注意: ストラグラー検出を使用すると、次のような偽陽性または偽陰性が発生することがあります。

• ストラグラー検出ログには、ストラグラー検出をサポートしていない実行中のコンピューティング インスタンスは、ストラグラーの疑いがないことが報告されます。
• ストラグラー検出は多くの 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 で消費される電力（ワット（W）単位、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 の変更	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	1 つのサブブロック内のネットワーク トラフィックのバイト数。
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/s））。 キーラベル: subblock_id、block_id、reservation_id、switch_type。
実効容量	network_switch/effective_capacity_kbps	A4X Max または A4X	スーパーブロックへの ToR スイッチ接続の使用可能な運用容量（キロビット/秒（kbit/s））。この指標は、リンクの劣化またはオフラインによる容量の減少を反映しています。 キーラベル: 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 受信パケット	network_switch/pfc_rx_packets_count	A4X Max または A4X	ポートで受信した優先度ベースのフロー制御（PFC）一時停止フレームの累積数。 注: PFC が有効になっている専用環境にのみ適用されます。 キーラベル: port_identifier、priority_index、subblock_id、block_id、reservation_id、switch_type。
PFC 送信パケット	network_switch/pfc_tx_packets_count	A4X Max または A4X	受信トラフィックをスロットリングするためにポートから送信された優先度ベースのフロー制御（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。
破棄	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	ワークロードがバッドプット アクティビティに費やす時間（秒）。これらのアクティビティは、トレーニング用のデータの読み込みや前処理などのオーバーヘッド タスクです。

ストラグラー検出指標

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

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

名前	指標タイプ	サポートされているマシンシリーズ	説明
ストラグラーの疑い	instance/gpu/straggler_status	A4X、A4、A3 Ultra、A3 Mega	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 種類があります。

  • 停止障害: システム全体を停止させる障害。たとえば、ホストエラーやメンテナンス イベントなどです。比較的簡単に検出して解決できます。

  • 低速障害: クラッシュを伴わずにパフォーマンスの深刻な低下を引き起こす障害。特定とデバッグが非常に困難です。

  ストラグラーは、障害の発生が遅いため、特に大規模な同期ワークロードでは、本質的に気づきにくく、特定が困難です。

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

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

• ワークロード全体が停止したときに通知する（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 の健全性モニタリング ダッシュボードを使用します。

     これらの指標を使用して問題を特定して分析する方法については、GCE インタラクティブ ハンドブック - Cluster Director の健全性モニタリングのハンドブック ダッシュボードもご覧ください。

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

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

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

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

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

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

カスタムの Monitoring ダッシュボードを作成する方法は次のとおりです。

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 サービスのダッシュボードをカスタマイズする
• パフォーマンスの低下に関するトラブルシューティング