Memantau instance Compute Engine dan cluster Slurm

GPU yang dikelompokkan

Dokumen ini menjelaskan cara menggunakan dasbor Cloud Monitoring untuk memantau instance A4X Max, A4X, A4, A3 Ultra, dan A3 Mega yang Anda buat menggunakan kapasitas terikat reservasi. Dengan menggunakan dasbor ini, Anda dapat mengidentifikasi dan memecahkan masalah hambatan performa di instance Compute Engine mandiri atau cluster Slurm, sehingga meminimalkan waktu non-operasional dalam workload Anda.

Dengan membuat dasbor kustom atau menggunakan dasbor Monitoring bawaan, Anda dapat memantau hal berikut:

• Kondisi instance komputasi

• Performa GPU

• Efisiensi transmisi jaringan

• Efisiensi jaringan di antara blok dan sub-blok

• Efisiensi workload machine learning (ML)

• Deteksi keterlambatan

• Deteksi workload yang tidak responsif

Untuk memantau cluster Cluster Director, lihat Memantau performa cluster dengan dasbor bawaan.

Sebelum memulai

Sebelum memantau workload, jika Anda belum melakukannya, selesaikan langkah-langkah berikut:

• Deploy workload yang dapat Anda pantau. Untuk mempelajari workload mana yang didukung, lihat batasan dalam dokumen ini. Untuk mempelajari cara men-deploy workload, lihat Ringkasan opsi deployment.

• Pelajari Google Cloud layanan untuk memantau workload:

  • Metrik dalam dokumen ini menggunakan dasbor Monitoring. Pelajari Dasbor Monitoring, Periode retensi Monitoring, dan Harga Monitoring.

  • Deteksi keterlambatan juga menyediakan entri log di Cloud Logging. Pelajari Antarmuka logging, Periode retensi logging, dan Harga logging.

Saat menggunakan konsol Google Cloud untuk mengakses layanan Google Cloud dan API, Anda tidak perlu menyiapkan autentikasi.

Batasan

• Metrik dalam dokumen ini hanya didukung untuk workload yang berjalan di instance komputasi yang memenuhi semua kriteria berikut:

  • Instance komputasi harus dibuat sebagai instance Compute Engine mandiri atau sebagai bagian dari cluster Slurm.
  • Instance komputasi harus dibuat menggunakan kapasitas terikat reservasi.
  • Instance komputasi harus menggunakan seri mesin A4X Max, A4X, A4, A3 Ultra, atau A3 Mega.
    • Namun, deteksi keterlambatan juga mendukung instance virtual machine (VM) yang menggunakan seri mesin A3 Mega.
  Perhatian: Meskipun metrik mungkin muncul untuk seri mesin selain A4X Max, A4X, A4, A3 Ultra, atau A3 Mega, metrik tersebut mungkin salah.
• Masalah umum untuk metrik infrastruktur:

  • Beberapa instance komputasi mungkin tidak menampilkan metrik GPU Power Consumption.
  • Beberapa instance komputasi mungkin tidak menampilkan metrik GPU Temperature atau GPU Thermal Margin, atau mungkin menampilkan NaN, bukan metrik.
  • Metrik mungkin tidak muncul di konsol Google Cloud hingga tujuh menit setelah dikumpulkan.
  • Anda mungkin melihat metrik yang salah untuk seri mesin selain A4X Max, A4X, A4, A3 Ultra, atau A3 Mega.

Metrik dalam dokumen ini hanya didukung untuk workload yang berjalan di instance komputasi yang memenuhi semua kriteria berikut:

• Instance komputasi harus dibuat sebagai instance Compute Engine mandiri atau sebagai bagian dari cluster Slurm.
• Instance komputasi harus dibuat menggunakan kapasitas yang dicadangkan.
• Instance komputasi harus menggunakan seri mesin A4X Max, A4X, A4, A3 Ultra, atau A3 Mega.

Untuk memantau metrik workload ML, Anda harus menyiapkan pemantauan untuk workload Anda.

Batasan deteksi keterlambatan

Metrik deteksi lambat memiliki batasan tambahan berikut:

• Untuk seri mesin yang didukung selain A3 Mega, deteksi straggler hanya mendukung instance komputasi yang mengaktifkan library Collective Communication Analyzer (CoMMA) untuk mengekspor telemetri NCCL ke layanan Google Cloud . Untuk mengetahui informasi selengkapnya, lihat Ringkasan CoMMA.
• Deteksi keterlambatan biasanya memerlukan waktu hingga 10 menit untuk melaporkan keterlambatan.
• Tidak seperti metrik lainnya dalam dokumen ini, Anda tidak dapat memfilter metrik deteksi keterlambatan untuk project menurut cluster, blok, sub-blok, atau instance komputasi. Namun, Anda dapat memfilter kueri untuk log deteksi straggler berdasarkan ID satu atau beberapa instance komputasi yang diduga straggler.

Perhatian: Anda mungkin melihat positif palsu atau negatif palsu saat menggunakan deteksi lambat seperti, tetapi tidak terbatas pada, berikut ini:

• Log deteksi keterlambatan melaporkan bahwa instance komputasi yang sedang berjalan yang tidak mendukung deteksi keterlambatan tidak dicurigai sebagai keterlambatan.
• Meskipun deteksi lambat akurat untuk banyak beban kerja ML, ketidakakuratan lebih mungkin terjadi untuk beban kerja dengan pola komunikasi yang kompleks.

Oleh karena itu, sebaiknya Anda menindaklanjuti pencilan yang dicurigai hanya jika metrik lain menunjukkan bahwa beban kerja mengalami masalah. Jika tidak, jika performa keseluruhan workload memuaskan, maka tidak ada tindakan yang disarankan.

Batasan deteksi workload yang tidak responsif

Metrik deteksi workload yang tidak responsif hanya mendukung instance komputasi yang menggunakan library Collective Communication Analyzer (CoMMA) untuk mengekspor telemetri NCCL ke layanan Google Cloud . Untuk mengetahui informasi selengkapnya, lihat Ringkasan CoMMA.

Peran yang diperlukan

Untuk mendapatkan izin yang Anda perlukan untuk memantau metrik untuk beban kerja AI Hypercomputer, minta administrator untuk memberi Anda peran IAM berikut:

• Untuk melihat metrik di Cloud Monitoring: Monitoring Editor (roles/monitoring.editor) di project
• Untuk melihat log deteksi keterlambatan di Logging: Logs Viewer (roles/logging.viewer) di project

Untuk mengetahui informasi selengkapnya tentang pemberian peran, lihat Mengelola akses ke project, folder, dan organisasi.

Peran bawaan ini berisi izin yang diperlukan untuk memantau metrik untuk workload AI Hypercomputer. Untuk melihat izin yang benar-benar diperlukan, perluas bagian Izin yang diperlukan:

Izin yang diperlukan

Izin berikut diperlukan untuk memantau metrik untuk workload AI Hypercomputer:

• Untuk melihat dasbor: monitoring.dashboards.get pada project
• Untuk membuat dasbor: monitoring.dashboards.create pada project
• Untuk melihat entri log: logging.logEntries.list pada project

Anda mungkin juga bisa mendapatkan izin ini dengan peran khusus atau peran bawaan lainnya.

Metrik yang tersedia

Bergantung pada kasus penggunaan, metrik berikut tersedia untuk memantau instance komputasi dan cluster Slurm:

• Untuk memantau kondisi, performa, dan performa jaringan GPU yang terpasang ke instance komputasi Anda, lihat Metrik infrastruktur.

• Untuk memantau efisiensi GPU dalam workload ML Anda, lihat Metrik workload ML.

• Untuk memantau instance komputasi yang diduga lambat dalam workload ML dengan performa yang lambat, lihat Metrik deteksi lambat.

Untuk mempelajari cara melihat metrik ini, lihat Memvisualisasikan metrik dalam dokumen ini.

Metrik infrastruktur

Untuk memantau kondisi, performa, dan performa jaringan GPU yang terpasang ke instance komputasi, Anda dapat menggunakan metrik berikut:

• Metrik kesehatan GPU

• Metrik performa GPU

• Metrik performa jaringan GPU

• Metrik switch top-of-rack (ToR)

• Metrik error fatal GPU

Untuk mengetahui ringkasan metrik yang tersedia di Compute Engine, lihat metrik Google Cloud .

Metrik kesehatan GPU

Untuk memantau kondisi GPU Anda, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Status Mesin	machine/machine_status	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Apakah mesin yang digunakan instance komputasi dalam kondisi baik, atau mesin dalam kondisi tidak baik dan memerlukan perbaikan.
Status NVSwitch	instance/gpu/nvswitch_status	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Apakah NVLink Switch pada GPU NVIDIA yang terpasang ke instance komputasi mengalami masalah.
Kesehatan Infrastruktur VM	instance/gpu/infra_health	A4X, A4, A3 Ultra, atau A3 Mega	Kesehatan cluster, blok, sub-blok, dan host tempat instance komputasi Anda berjalan. Jika metrik ini menunjukkan bahwa infrastruktur instance komputasi tidak dalam kondisi baik, maka metrik ini juga menjelaskan masalahnya.
Skor Prediksi Kegagalan VM	instance/gpu/failure_prediction_score	A4X, A4, A3 Ultra, atau A3 Mega	Kemungkinan host tempat instance komputasi berjalan mengalami penurunan performa dalam lima jam ke depan. Nilainya dapat berkisar antara 0.0 dan 1.0. Semakin dekat nilai tetap ke 1.0 selama jangka waktu yang konsisten, semakin besar kemungkinan instance komputasi akan mengalami penurunan performa. Dalam hal ini, sebaiknya pindahkan tugas ke instance komputasi lain dan, jika Anda mengalami masalah dengan instance komputasi, laporkan host-nya sebagai rusak.

Metrik performa GPU

Untuk memantau performa GPU, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Penggunaan Konteks yang Terakumulasi	instance/gpu/accumulated_context_utilization_seconds	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Total waktu, dalam detik, saat GPU sibuk memproses workload.
Konsumsi Daya GPU	instance/gpu/power_consumption	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Daya dalam watt (W) dan dalam nilai desimal yang dikonsumsi pada GPU individual di host. Untuk instance komputasi dengan beberapa GPU yang terpasang, metrik ini memberikan konsumsi daya secara terpisah untuk setiap GPU di host.
Penggunaan SM	instance/gpu/sm_utilization	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Nilai non-nol menunjukkan bahwa multiprosesor streaming (SM) di GPU Anda sedang aktif digunakan.
Suhu GPU	instance/gpu/temperature	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Suhu dalam Celsius (℃) dan dalam nilai desimal GPU individual di host. Untuk instance komputasi dengan beberapa GPU yang terpasang, metrik ini memberikan suhu secara terpisah untuk setiap GPU di host.
Margin Termal GPU	instance/gpu/tlimit	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Ruang cadangan termal dalam Celsius (℃) dan dalam nilai desimal yang dimiliki setiap GPU sebelum perlu melambat karena suhu tinggi. Untuk instance komputasi dengan beberapa GPU yang terpasang, metrik memberikan ruang cadangan termal secara terpisah untuk setiap GPU di host.

Metrik performa jaringan GPU

Untuk memantau performa jaringan GPU Anda, gunakan metrik berikut. Untuk memantau switch jaringan ToR backend, lihat Metrik switch ToR.

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Perubahan Operator Tertaut	instance/gpu/link_carrier_changes	A4X, A4, A3 Ultra, atau A3 Mega	Seberapa sering operator link jaringan berubah dalam satu menit.
RTT Jaringan	instance/gpu/network_rtt	A4X, A4, A3 Ultra, atau A3 Mega	Waktu perjalanan pulang-pergi, yang diukur dalam mikrodetik, untuk data jaringan yang melakukan perjalanan antara sumber dan tujuan.
Traffic Jaringan di Antar-Blok	instance/gpu/network/inter_block_tx	A4X, A4, A3 Ultra, atau A3 Mega	Jumlah byte traffic jaringan di antara blok.
Traffic Jaringan di Antar-Sub-blok	instance/gpu/network/inter_subblock_tx	A4X, A4, A3 Ultra, atau A3 Mega	Jumlah byte traffic jaringan di antara sub-blok.
Traffic Jaringan di Dalam Sub-blok	instance/gpu/network/intra_subblock_tx	A4X, A4, A3 Ultra, atau A3 Mega	Jumlah byte traffic jaringan dalam satu sub-blok.
Kecepatan Aktif NVLink	instance/gpu/nvlink_active_speed	A4X Max, A4X, A4, A3 Ultra, atau A3 Mega	Kecepatan port link akses saat ini, dalam GBps.
Throughput Byte Rx	instance/gpu/throughput_rx_bytes	A4X, A4, A3 Ultra, atau A3 Mega	Jumlah byte yang diterima dari traffic jaringan.
Throughput Tx Bytes	instance/gpu/throughput_tx_bytes	A4X, A4, A3 Ultra, atau A3 Mega	Jumlah byte yang ditransmisikan ke traffic jaringan.

Metrik peralihan ToR

Untuk cluster A4X Max dan A4X, Anda dapat memantau telemetri switch jaringan ToR backend untuk melakukan hal berikut selama pelatihan ML terdistribusi:

• Amati kondisi switch dan port.
• Evaluasi kapasitas bandwidth yang tersedia dan kedalaman antrean buffer.
• Mendiagnosis pembuangan paket, error, fluktuasi antarmuka, dan peristiwa pengelolaan kemacetan.

Metrik ini menggunakan jenis resource yang dipantau compute.googleapis.com/NetworkSwitch dan awalan jenis metrik compute.googleapis.com/. Di Metrics Explorer, pilih jenis resource NetworkSwitch (compute.googleapis.com/NetworkSwitch).

Metrik peralihan disusun ke dalam kategori berikut:

Mengganti metrik kesehatan dan status

Gunakan metrik yang tercantum di bagian ini untuk melakukan hal berikut:

• Verifikasi status operasional port switch.
• Pantau pemakaian CPU dan memori Switch.
• Periksa waktu booting untuk mendeteksi reboot yang tidak terduga.

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Status transfer	network_switch/port_status	A4X Max atau A4X	Menunjukkan status operasional antarmuka fisik (port) pada switch jaringan. Nilai metrik selalu 1 untuk agregasi; status sebenarnya diberikan dalam label status (seperti UP atau DOWN). Label utama: port_identifier, status, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Pemakaian CPU	network_switch/cpu_utilization	A4X Max atau A4X	Penggunaan CPU switch jaringan, diukur sebagai pecahan dari 0.0 hingga 1.0. Label utama: subblock_id, block_id, reservation_id, switch_type.
Memori yang digunakan	network_switch/memory_used	A4X Max atau A4X	Memori yang digunakan oleh switch jaringan, dalam byte. Label utama: subblock_id, block_id, reservation_id, switch_type.
Total memori	network_switch/total_memory_bytes	A4X Max atau A4X	Total kapasitas memori switch jaringan, dalam byte. Label utama: subblock_id, block_id, reservation_id, switch_type.
Waktu booting	network_switch/boot_time_in_ns	A4X Max atau A4X	Stempel waktu booting switch jaringan, dalam nanodetik sejak epoch Unix. Label utama: subblock_id, block_id, reservation_id, switch_type.

Metrik kapasitas dan antrean switch

Untuk melacak kapasitas jaringan dasar versus yang dapat digunakan dan memantau kedalaman antrean buffer dan pelepasan antrean di switch, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Kapasitas dasar	network_switch/baseline_capacity_kbps	A4X Max atau A4X	Total kapasitas bandwidth dasar yang potensial dari koneksi switch ToR ke superblock, dalam kilobit per detik (kbit/dtk). Label utama: subblock_id, block_id, reservation_id, switch_type.
Kapasitas efektif	network_switch/effective_capacity_kbps	A4X Max atau A4X	Kapasitas operasional yang dapat digunakan dari koneksi switch ToR ke superblock, dalam kilobit per detik (kbit/s). Metrik ini mencerminkan pengurangan kapasitas yang disebabkan oleh link yang rusak atau offline. Label utama: subblock_id, block_id, reservation_id, switch_type.
Kedalaman antrean maksimum keluar	network_switch/egress_max_queue_depth	A4X Max atau A4X	Kedalaman antrean maksimum yang diamati selama siklus pengukuran terbaru. Label utama: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Pelepasan antrean keluar	network_switch/egress_queue_drops_count	A4X Max atau A4X	Jumlah kumulatif paket yang dihapus dari antrean keluar karena kemacetan antrean atau kehabisan buffer. Label utama: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Dalam penghapusan buffer	network_switch/in_buffer_discards	A4X Max atau A4X	Jumlah kumulatif paket masuk yang dihapus di ingress karena buffer meluap. Label utama: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.

Metrik pelepasan, kesalahan, dan kontrol alur pengalihan

Gunakan metrik di bagian ini untuk mendiagnosis masalah berikut, yang dapat menyebabkan pelatihan terdistribusi terhenti atau waktu tunggu komunikasi kolektif habis (seperti waktu tunggu watchdog NCCL habis):

• Penghapusan paket, error transmisi, dan fluktuasi link fisik.
• Kesalahan kata koreksi kesalahan penerusan (FEC).
• Peristiwa pengelolaan kemacetan, seperti jeda Priority-based Flow Control (PFC) dan penandaan Explicit Congestion Notification (ECN).

Catatan: Metrik Kontrol Alur berbasis Prioritas (PFC) (network_switch/pfc_rx_packets_count dan network_switch/pfc_tx_packets_count) hanya berlaku untuk lingkungan khusus tempat PFC diaktifkan.

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Penutup antarmuka	network_switch/interface_flaps_count	A4X Max atau A4X	Jumlah kumulatif transisi status link fisik (flaps antara UP dan DOWN) pada antarmuka port switch. Label utama: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Error kata-kata tidak senonoh	network_switch/fec_word_error_count	A4X Max atau A4X	Jumlah kumulatif error kata Koreksi Error Terusan (FEC). Gunakan label boolean correctable (true atau false) untuk membedakan antara error yang dapat diperbaiki dan error yang tidak dapat diperbaiki. Label utama: port_identifier, correctable, subblock_id, block_id, reservation_id, switch_type.
Paket yang ditandai ECN	network_switch/ecn_marked_packets_count	A4X Max atau A4X	Jumlah kumulatif paket yang ditandai dengan bit Pemberitahuan Kemacetan Eksplisit (ECN) karena batas buffer terlampaui. Label utama: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Pfc rx packets	network_switch/pfc_rx_packets_count	A4X Max atau A4X	Jumlah kumulatif frame jeda Priority-based Flow Control (PFC) yang diterima di port. Catatan: Hanya berlaku untuk lingkungan khusus tempat PFC diaktifkan. Label utama: port_identifier, priority_index, subblock_id, block_id, reservation_id, switch_type.
Paket tx Pfc	network_switch/pfc_tx_packets_count	A4X Max atau A4X	Jumlah kumulatif frame jeda Priority-based Flow Control (PFC) yang dikirim dari port untuk membatasi traffic masuk. Catatan: Hanya berlaku untuk lingkungan khusus tempat PFC diaktifkan. Label utama: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Paket tx QoS	network_switch/qos_tx_packets	A4X Max atau A4X	Jumlah kumulatif paket Quality of Service (QoS) yang ditransmisikan di antrean yang ditentukan. Label utama: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Jumlah paket masuk	network_switch/in_packets_count	A4X Max atau A4X	Jumlah kumulatif paket masuk yang diterima di port switch. Label utama: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Dalam error	network_switch/in_errors	A4X Max atau A4X	Jumlah kumulatif paket masuk yang diterima dengan error yang mencegah pengiriman paket tersebut. Label utama: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Di Sampah	network_switch/in_discards	A4X Max atau A4X	Jumlah kumulatif paket masuk yang valid yang dibuang (misalnya, karena kurangnya ruang buffer). Label utama: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Error keluar	network_switch/out_errors	A4X Max atau A4X	Jumlah kumulatif paket keluar yang gagal ditransmisikan karena error. Label utama: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Buang keluar	network_switch/out_discards	A4X Max atau A4X	Jumlah kumulatif paket keluar yang dipilih untuk dibuang meskipun tidak ada error yang terdeteksi. Label utama: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Jumlah byte masuk	network_switch/in_bytes_count	A4X Max atau A4X	Jumlah kumulatif byte masuk yang diterima di port switch. Label utama: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Jumlah byte keluar	network_switch/out_bytes_count	A4X Max atau A4X	Jumlah kumulatif byte keluar yang ditransmisikan dari port switch. Label utama: port_identifier, subblock_id, block_id, reservation_id, switch_type.

Metrik error fatal GPU

Untuk memantau error yang dialami GPU Anda dan yang dapat menyebabkan instance komputasi Anda berhenti, atau berdampak negatif pada performanya, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Error runtime NVLink	instance/gpu/nvlink_runtime_error	A4X Max atau A4X	Apakah terjadi error runtime NVLink.
Error ECC DRAM yang tidak dapat dikoreksi	instance/gpu/dram_uncorrectable_ecc_error_count	A4X Max atau A4X	Jumlah kode koreksi error (ECC) yang tidak dapat dikoreksi dalam memori akses acak dinamis (DRAM) GPU.
Jumlah pemetaan ulang baris DRAM yang tidak dapat dikoreksi	instance/gpu/dram_uncorrectable_row_remapping_count	A4X Max atau A4X	Jumlah pemetaan ulang baris dari error yang tidak dapat dikoreksi di DRAM GPU.
Pemetaan ulang baris DRAM yang tidak dapat dikoreksi gagal	instance/gpu/dram_row_remapping_failed	A4X Max atau A4X	Apakah pemetaan ulang baris di DRAM GPU gagal karena salah satu masalah berikut: Upaya pemetaan ulang pada bank memori gagal karena bank memori sudah memiliki delapan baris error yang tidak dapat dikoreksi yang dipetakan ulang. Upaya pemetaan ulang pada baris gagal karena baris sudah dipetakan ulang. Upaya pemetaan ulang gagal karena total 512 pemetaan ulang telah terjadi.
Error PCIe yang tidak dapat diperbaiki	instance/gpu/pcie_fatal_error_count	A4X Max atau A4X	Jumlah error Peripheral Component Interconnect Express (PCIe) yang tidak dapat dikoreksi.
Error ECC cache yang tidak dapat dikoreksi	instance/gpu/cache_uncorrectable_ecc_error_count	A4X Max atau A4X	Jumlah ECC yang tidak dapat dikoreksi dalam memori cache.

Metrik workload ML

Untuk memantau produktivitas—khususnya, goodput—beban kerja ML Anda, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Waktu produktif	workload/goodput_time	A4X, A4, A3 Ultra, atau A3 Mega	Waktu, dalam detik, yang dihabiskan workload untuk aktivitas goodput. Aktivitas ini adalah tugas inti yang berguna, seperti penerusan maju atau penerusan mundur selama pelatihan model.
Waktu tidak produktif	workload/badput_time	A4X, A4, A3 Ultra, atau A3 Mega	Waktu, dalam detik, yang dihabiskan workload untuk aktivitas badput. Aktivitas ini adalah tugas tambahan, seperti memuat atau melakukan prapemrosesan data untuk pelatihan.

Metrik deteksi straggler

Metrik deteksi keterlambatan membantu Anda melihat dan menentukan lokasi keterlambatan yang dicurigai. Straggler adalah kegagalan titik tunggal yang tidak menyebabkan error dan pada akhirnya memperlambat seluruh beban kerja.

Untuk memantau deteksi VM yang lambat, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Diduga Tertinggal	instance/gpu/straggler_status	A4X, A4, A3 Ultra, atau A3 Mega	Apakah VM dicurigai sebagai VM yang lambat dan memengaruhi performa workload. Sebaiknya Anda menindaklanjuti dugaan keterlambatan hanya jika metrik lain menunjukkan bahwa workload mengalami masalah.

Anda juga dapat melihat metrik deteksi lambat di entri log untuk instance A4X, A4, A3 Ultra, atau A3 Mega. Misalnya, Anda dapat menggunakan kueri berikut:

Deskripsi	Kueri
Log dengan straggler yang dicurigai untuk VM tertentu. Gunakan kueri ini untuk memeriksa apakah ada straggler yang dicurigai untuk workload tertentu di project Anda.	logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID" Ganti INSTANCE_ID dengan ID VM. Untuk setiap VM tambahan yang ingin Anda tentukan, tambahkan kondisi berikut ke kueri: OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
Semua log dari deteksi keterlambatan untuk project Anda. Gunakan kueri ini untuk memverifikasi apakah layanan deteksi keterlambatan berjalan saat tidak ada keterlambatan yang dicurigai. (Karena keterbatasan, Anda tidak dapat memfilter log tanpa VM yang diduga lambat berdasarkan VM tertentu.)	logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

Metrik deteksi keterlambatan sangat membantu untuk beban kerja ML skala besar karena alasan berikut:

• Workload ML berskala besar sangat rentan terhadap tugas yang tertunda. Workload ML berskala besar menggunakan komputasi sinkron dan terdistribusi secara masif. (Dengan kata lain, aplikasi ini memiliki banyak komponen yang sangat saling bergantung dan berjalan secara bersamaan.) Arsitektur ini membuat workload ML skala besar sangat rentan terhadap kegagalan satu titik seperti straggler.

• Melihat dan menemukan penyebab keterlambatan dalam workload ML berskala besar sangatlah sulit. Sebagai referensi, pertimbangkan bahwa ada dua jenis kegagalan titik tunggal:

  • kegagalan penghentian: Kegagalan yang menyebabkan seluruh sistem berhenti; misalnya error host dan peristiwa pemeliharaan. Error ini relatif mudah dideteksi dan diselesaikan.

  • kegagalan lambat: Kegagalan yang menyebabkan penurunan performa yang parah tanpa error. Bug ini sangat sulit untuk diidentifikasi dan di-debug.

  Karena sifat kegagalannya yang lambat, straggler sulit untuk diperhatikan dan diidentifikasi, terutama dalam workload sinkron berskala besar.

Metrik deteksi workload yang tidak responsif

Metrik deteksi beban kerja yang tidak responsif membantu Anda melakukan hal berikut:

• Melihat saat seluruh workload terhenti (terkadang disebut sebagai NCCL hang)
• Pahami alasan beban kerja terhenti, seperti apakah disebabkan oleh error proses atau jaringan yang terhenti

Untuk mendeteksi dan mendiagnosis workload yang tidak responsif untuk instance komputasi Anda, gunakan metrik berikut:

Nama	Jenis metrik	Seri mesin yang didukung	Deskripsi
Peristiwa workload tidak responsif yang terdeteksi menggunakan telemetri NCCL	instance/gpu/nccl_hang	A4X Max, A4X, A4, dan A3 Ultra	Jumlah peristiwa beban kerja tidak responsif yang terdeteksi, sebagai deret waktu.

Mengaktifkan deteksi workload yang tidak responsif

Untuk mengaktifkan deteksi workload yang tidak responsif, Anda harus mengaktifkan CoMMA dengan telemetri detak jantung, sinyal ping berkala yang menunjukkan bahwa workload sedang berjalan. Untuk CoMMA versi terbaru, fitur ini diaktifkan secara default. Namun, jika Anda menggunakan CoMMA versi 1.1.1 dari paket NICCL/gIB, Anda harus mengaktifkan telemetri detak jantung secara manual. Untuk memverifikasi versi paket NICCL/gIB yang Anda gunakan, lihat Memeriksa versi NCCL dan gIB.

Untuk mengaktifkan telemetri detak jantung secara manual untuk CoMMA, tentukan variabel lingkungan berikut di lingkungan pelatihan Anda:

NCCL_PROFILER_HEARTBEAT=true

NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL=10s

Gunakan NCCL_PROFILER_HEARTBEAT untuk mengaktifkan atau menonaktifkan telemetri detak jantung, dan NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL untuk menentukan frekuensi telemetri detak jantung. Untuk mengetahui informasi selengkapnya, lihat Variabel lingkungan CoMMA.

Menonaktifkan deteksi workload yang tidak responsif

Untuk menonaktifkan deteksi beban kerja yang tidak responsif, nonaktifkan telemetri detak jantung di CoMMA dengan menentukan variabel lingkungan berikut di lingkungan pelatihan Anda:

NCCL_PROFILER_HEARTBEAT=false

Memahami alasan beban kerja tidak responsif

Untuk memahami alasan workload tidak merespons, periksa nilai label hang_reason dengan menyelesaikan langkah-langkah berikut:

1. Di konsol Google Cloud , buka halaman  Metrics explorer:

   Buka Metrics explorer

   Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.

2. Cari metrik berikut:

   compute.googleapis.com/instance/gpu/nccl_hang
   

3. Gunakan fitur Agregasi, lalu pilih label berikut:

   • instance_id
   • hang_reason

Tabel berikut mencantumkan kemungkinan nilai untuk label, arti nilai tersebut terkait workload Anda, dan langkah berikutnya yang direkomendasikan.

Nilai label	Deskripsi	Rekomendasi langkah selanjutnya
MissingHeartbeatIssue	Telemetri detak jantung telah berhenti untuk satu atau beberapa peringkat, yang biasanya menunjukkan proses fatal atau error node.	Verifikasi apakah instance masih dapat dijangkau. Verifikasi apakah proses workload telah error. Periksa peristiwa kehabisan memori (OOM), seperti dmesg, di log sistem. Cari kegagalan hardware atau error XID NVIDIA.
StalledRankIssue	Telemetri detak jantung masih diterima, tetapi peringkat tidak berkembang pada operasi NCCL.	Menyelidiki potensi kebuntuan dalam operasi tingkat aplikasi. Periksa apakah proses aplikasi macet dalam operasi yang mencegahnya berkomunikasi dengan orang lain, seperti komputasi atau checkpointer.
MissingCommunicatorIssue	Semua peringkat yang termasuk dalam komunikator NCCL telah berhenti berkembang.	Workload Anda mungkin terganggu, atau komunikator NCCL-nya mungkin ditutup tiba-tiba. Jika Anda mengharapkan workload berjalan tanpa gangguan di instance VM ini, periksa apakah workload telah terganggu atau dimatikan secara tidak normal.
NoHangIssue	Nilai default. Tidak ada masalah yang terdeteksi.	Anda tidak perlu melakukan tindakan apa pun.

Lihat metrik

Untuk melihat metrik instance komputasi dan cluster Slurm, gunakan dasbor Monitoring sebagai berikut:

• Untuk melihat metrik infrastruktur dan metrik deteksi keterlambatan, Anda dapat melakukan hal berikut:

  • Untuk ringkasan cepat tentang kondisi dan performa infrastruktur Anda, atau untuk menyesuaikan dasbor yang ada, gunakan dasbor bawaan.

  • Untuk kebutuhan pemantauan tertentu, buat dasbor kustom.

• Untuk melihat metrik workload ML, lihat dokumentasi tentang cara menyiapkan pemantauan untuk workload Anda.

• Untuk melihat log dari deteksi straggler, lihat log deteksi straggler.

Jika Anda mengalami masalah saat menggunakan dasbor, lihat Memecahkan masalah performa lambat.

Menggunakan dasbor bawaan

Anda dapat menggunakan dasbor Monitoring yang telah dibuat sebelumnya untuk AI Hypercomputer guna melihat metrik untuk instance komputasi dan cluster Slurm. Anda juga dapat membuat salinan dasbor bawaan dan mengubahnya agar sesuai dengan kebutuhan Anda.

Untuk menggunakan dasbor bawaan untuk AI Hypercomputer, lakukan hal berikut:

1. Di konsol Google Cloud , buka halaman  Dashboards:

   Buka Dasbor

   Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.

2. Di kolom Nama, klik nama salah satu dasbor berikut berdasarkan metrik yang ingin Anda lihat:

   • Untuk memantau kondisi instance komputasi, performa GPU, dan deteksi straggler, gunakan dasbor Cluster Director Health Monitoring.

     Untuk mengetahui informasi selengkapnya tentang cara menggunakan metrik ini untuk mengidentifikasi dan menganalisis masalah, gunakan juga dasbor playbook GCE Interactive Playbook - Cluster Director Health Monitoring.

   • Untuk memantau efisiensi transmisi jaringan, gunakan dasbor Efisiensi Transmisi Cluster Director.

   • Untuk memantau efisiensi jaringan di antara blok dan sub-blok, gunakan dasbor Cluster Director Block Network.

     Untuk mengetahui informasi selengkapnya tentang cara menggunakan metrik ini untuk mengidentifikasi dan menganalisis masalah, gunakan juga dasbor playbook GCE Interactive Playbook - Cluster Director Block Network.

   Halaman detail dasbor yang Anda pilih akan terbuka. Anda dapat menggunakan pemilih rentang waktu di toolbar untuk mengubah rentang waktu data.

3. Opsional: Untuk membuat salinan dasbor dan menyesuaikannya agar sesuai dengan kebutuhan Anda, klik Salin dasbor.

Membuat dasbor kustom

Untuk membuat dasbor Monitoring kustom, lakukan hal berikut:

1. Pilih metrik yang akan dipantau. Jika belum, lihat Metrik yang tersedia dalam dokumen ini.

2. Membuat dan mengelola dasbor kustom.

Melihat log deteksi straggler

Untuk melihat log deteksi keterlambatan menggunakan Logs Explorer, selesaikan langkah-langkah berikut:

1. Di konsol Google Cloud , buka segmen halaman Logs Explorer:

   Buka Logs Explorer

   Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Logging.

   Halaman ini mengkueri semua log di project Anda secara default. Klik Hentikan kueri.

2. Gunakan pemilih rentang waktu di toolbar untuk memilih rentang waktu yang ingin Anda analisis.

3. Di panel Query, masukkan kueri untuk log deteksi straggler.

4. Klik Run Query.

Berikut adalah contoh entri log deteksi keterlambatan.

  {
    ...
    "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",
    ...
  }
  

Entri log ini mencakup kolom berikut:

• numNodes: Jumlah instance komputasi yang diduga lambat yang terdeteksi dalam project. Dalam contoh ini, empat instance komputasi yang diduga tertinggal telah terdeteksi.
• instanceId: ID instance komputasi yang terdeteksi sebagai straggler yang dicurigai.

Langkah berikutnya

• Mengamati dan memantau VM
• Menyesuaikan dasbor untuk Google Cloud layanan
• Memecahkan masalah performa yang lambat