Surveiller les instances Compute Engine et les clusters Slurm

Ce document explique comment utiliser les tableaux de bord Cloud Monitoring pour surveiller les instances A4X Max, A4X, A4, A3 Ultra et A3 Mega que vous avez créées à l'aide de la capacité liée à une réservation. Ces tableaux de bord vous aident à identifier et à résoudre les goulots d'étranglement des performances dans vos instances Compute Engine autonomes ou vos clusters Slurm, ce qui minimise les temps d'arrêt de vos charges de travail.

En créant des tableaux de bord personnalisés ou en utilisant des tableaux de bord Monitoring prédéfinis, vous pouvez surveiller les éléments suivants :

  • État de l'instance de calcul

  • Performances du GPU

  • Efficacité de la transmission réseau

  • Efficacité du réseau entre les blocs et les sous-blocs

  • Efficacité des charges de travail de machine learning (ML)

  • Détection des retardataires

  • Détection des charges de travail non réactives

Pour surveiller les clusters Cluster Director, consultez Surveiller les performances des clusters avec des tableaux de bord prédéfinis.

Avant de commencer

Avant de surveiller votre charge de travail, si vous ne l'avez pas déjà fait, suivez les étapes suivantes :

Lorsque vous utilisez la console Google Cloud pour accéder aux services Google Cloud et aux API, vous n'avez pas besoin de configurer l'authentification.

Limites

  • Les métriques de ce document ne sont compatibles qu'avec les charges de travail qui s'exécutent sur des instances de calcul répondant à tous les critères suivants :

    • Les instances de calcul doivent être créées en tant qu'instances Compute Engine autonomes ou dans un cluster Slurm.
    • Les instances de calcul doivent avoir été créées à l'aide de la capacité liée à une réservation.
    • Les instances de calcul doivent utiliser les séries de machines A4X Max, A4X, A4, A3 Ultra ou A3 Mega.
      • Toutefois, la détection des retardataires est également compatible avec les instances de machines virtuelles (VM) qui utilisent la série de machines A3 Mega.

Les métriques de ce document ne sont compatibles qu'avec les charges de travail qui s'exécutent sur des instances de calcul répondant à tous les critères suivants :

  • Les instances de calcul doivent être créées en tant qu'instances Compute Engine autonomes ou dans un cluster Slurm.
  • Les instances de calcul doivent avoir été créées à l'aide de la capacité réservée.
  • Les instances de calcul doivent utiliser les séries de machines A4X Max, A4X, A4, A3 Ultra ou A3 Mega.

Pour surveiller les métriques de charge de travail de ML, vous devez configurer la surveillance de votre charge de travail.

Limites de la détection des retardataires

Les métriques de détection des valeurs aberrantes présentent les limites supplémentaires suivantes :

  • Pour les séries de machines compatibles autres que A3 Mega, la détection des retardataires n'est compatible qu'avec les instances de calcul qui permettent à la bibliothèque Collective Communication Analyzer (CoMMA) d'exporter la télémétrie NCCL vers les services Google Cloud . Pour en savoir plus, consultez la présentation de CoMMA.
  • La détection des retardataires prend généralement jusqu'à 10 minutes.
  • Contrairement aux autres métriques de ce document, vous ne pouvez pas filtrer les métriques de détection des retardataires pour vos projets par cluster, bloc, sous-bloc ou instance de calcul. Toutefois, vous pouvez filtrer les requêtes pour les journaux de détection des retardataires par ID d'une ou plusieurs instances de calcul suspectées d'être des retardataires.

Limites de la détection des charges de travail non réactives

Les métriques de détection des charges de travail non réactives ne sont compatibles qu'avec les instances de calcul qui utilisent la bibliothèque Collective Communication Analyzer (CoMMA) pour exporter la télémétrie NCCL vers les services Google Cloud . Pour en savoir plus, consultez la présentation de CoMMA.

Rôles requis

Pour obtenir les autorisations nécessaires pour surveiller les métriques des charges de travail AI Hypercomputer, demandez à votre administrateur de vous accorder les rôles IAM suivants :

  • Pour afficher les métriques dans Cloud Monitoring : Éditeur Monitoring (roles/monitoring.editor) sur le projet
  • Pour afficher les journaux de détection des retardataires dans Logging : Lecteur de journaux (roles/logging.viewer) sur le projet

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour surveiller les métriques des charges de travail AI Hypercomputer. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour surveiller les métriques des charges de travail AI Hypercomputer :

  • Pour afficher les tableaux de bord : monitoring.dashboards.get sur le projet
  • Pour créer des tableaux de bord : monitoring.dashboards.create sur le projet
  • Pour afficher les entrées de journal : logging.logEntries.list sur le projet

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Métriques disponibles

En fonction de votre cas d'utilisation, les métriques suivantes sont disponibles pour surveiller vos instances de calcul et vos clusters Slurm :

Pour savoir comment afficher ces métriques, consultez Visualiser les métriques dans ce document.

Métriques de l'infrastructure

Pour surveiller l'état, les performances et les performances réseau des GPU associés à vos instances de calcul, vous pouvez utiliser les métriques suivantes :

Pour obtenir un aperçu des métriques disponibles dans Compute Engine, consultez MétriquesGoogle Cloud .

Métriques sur l'état du GPU

Pour surveiller l'état de vos GPU, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
État de la machine machine/machine_status A4X Max, A4X, A4, A3 Ultra ou A3 Mega Indique si la machine utilisée par l'instance de calcul est opérationnelle ou non et si elle nécessite une réparation.
État NVSwitch instance/gpu/nvswitch_status A4X Max, A4X, A4, A3 Ultra ou A3 Mega Indique si un commutateur NVLink sur un GPU NVIDIA associé à une instance de calcul rencontre des problèmes.
État de l'infrastructure des VM instance/gpu/infra_health A4X, A4, A3 Ultra ou A3 Mega État du cluster, du bloc, du sous-bloc et de l'hôte sur lesquels vos instances de calcul sont exécutées. Si cette métrique indique que l'infrastructure d'une instance de calcul n'est pas opérationnelle, elle décrit également le problème.
Score de prédiction des défaillances de VM instance/gpu/failure_prediction_score A4X, A4, A3 Ultra ou A3 Mega Probabilité que l'hôte sur lequel l'instance de calcul s'exécute se dégrade dans les cinq prochaines heures. Cette valeur peut être comprise entre 0.0 et 1.0. Plus la valeur reste proche de 1.0 pendant une période donnée, plus il est probable que l'instance de calcul se dégrade. Dans ce cas, nous vous recommandons de déplacer le job vers une autre instance de calcul et, si vous rencontrez des problèmes avec l'instance de calcul, de signaler son hôte comme défectueux.

Métriques de performances du GPU

Pour surveiller les performances de vos GPU, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Utilisation du contexte cumulé instance/gpu/accumulated_context_utilization_seconds A4X Max, A4X, A4, A3 Ultra ou A3 Mega Temps total, en secondes, pendant lequel le GPU est occupé à traiter une charge de travail.
Consommation d'énergie du GPU instance/gpu/power_consumption A4X Max, A4X, A4, A3 Ultra ou A3 Mega Puissance en watts (W) et en valeurs décimales consommée par les GPU individuels de l'hôte. Pour les instances de calcul auxquelles sont associés plusieurs GPU, la métrique fournit la consommation d'énergie séparément pour chaque GPU de l'hôte.
Utilisation du multiprocesseur de flux instance/gpu/sm_utilization A4X Max, A4X, A4, A3 Ultra ou A3 Mega Une valeur non nulle indique que les multiprocesseurs de flux (SM) de vos GPU sont activement utilisés.
Vitesse de GPU instance/gpu/temperature A4X Max, A4X, A4, A3 Ultra ou A3 Mega Température en degrés Celsius (℃) et en valeurs décimales des GPU individuels sur l'hôte. Pour les instances de calcul auxquelles sont associés plusieurs GPU, la métrique fournit la température séparément pour chaque GPU de l'hôte.
Marge thermique du GPU instance/gpu/tlimit A4X Max, A4X, A4, A3 Ultra ou A3 Mega Marge thermique en degrés Celsius (℃) et en valeurs décimales dont disposent les GPU individuels avant de devoir ralentir en raison d'une température élevée. Pour les instances de calcul auxquelles sont associés plusieurs GPU, la métrique fournit la marge thermique séparément pour chaque GPU de l'hôte.

Métriques de performances réseau des GPU

Pour surveiller les performances réseau de vos GPU, utilisez les métriques suivantes. Pour surveiller les commutateurs réseau ToR du backend, consultez Métriques des commutateurs ToR.

Nom Type de métrique Séries de machines compatibles Description
Associer les modifications de l'opérateur instance/gpu/link_carrier_changes A4X, A4, A3 Ultra ou A3 Mega Fréquence à laquelle le support de lien réseau change en une minute.
RTT du réseau instance/gpu/network_rtt A4X, A4, A3 Ultra ou A3 Mega Délai aller-retour, mesuré en microsecondes, nécessaire pour que les données réseau transitent entre une source et une destination.
Trafic réseau entre les blocs instance/gpu/network/inter_block_tx A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets de trafic réseau entre les blocs.
Trafic réseau au niveau des sous-blocs instance/gpu/network/inter_subblock_tx A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets de trafic réseau entre les sous-blocs.
Trafic réseau au niveau des sous-blocs instance/gpu/network/intra_subblock_tx A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets de trafic réseau dans un seul sous-bloc.
Vitesse active NVLink instance/gpu/nvlink_active_speed A4X Max, A4X, A4, A3 Ultra ou A3 Mega Vitesse actuelle du port de liaison d'accès, en Gbit/s.
Débit de réception en octets instance/gpu/throughput_rx_bytes A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets reçus du trafic réseau.
Débit de transmission en octets instance/gpu/throughput_tx_bytes A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets transmis au trafic réseau.

Métriques des commutateurs ToR

Pour les clusters A4X Max et A4X, vous pouvez surveiller la télémétrie du commutateur réseau ToR du backend pour effectuer les opérations suivantes lors de l'entraînement ML distribué :

  • Surveillez l'état des commutateurs et des ports.
  • Évaluez la capacité de bande passante disponible et la profondeur des files d'attente de tampon.
  • Diagnostiquez les événements de suppression de paquets, d'erreurs, de bascule d'interface et de gestion de la congestion.

Ces métriques utilisent le type de ressource surveillée compute.googleapis.com/NetworkSwitch et le préfixe de type de métrique compute.googleapis.com/. Dans l'explorateur de métriques, sélectionnez le type de ressource NetworkSwitch (compute.googleapis.com/NetworkSwitch).

Les métriques de switch sont organisées dans les catégories suivantes :

Basculer entre les métriques d'état et de santé

Utilisez les métriques listées dans cette section pour effectuer les opérations suivantes :

  • Vérifiez l'état opérationnel des ports du commutateur.
  • Surveillez l'utilisation du processeur et de la mémoire du commutateur.
  • Vérifiez les temps de démarrage pour détecter les redémarrages inattendus.
Nom Type de métrique Séries de machines compatibles Description
État du transfert network_switch/port_status A4X Max ou A4X Indique l'état opérationnel de l'interface physique (port) sur le commutateur réseau. La valeur de la métrique est toujours 1 pour l'agrégation. L'état réel est fourni dans le libellé status (par exemple, UP ou DOWN).
Libellés clés : port_identifier, status, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Utilisation du processeur network_switch/cpu_utilization A4X Max ou A4X Utilisation du processeur du commutateur réseau, mesurée sous forme de fraction de 0.0 à 1.0.
Libellés des clés : subblock_id, block_id, reservation_id, switch_type.
Memory used network_switch/memory_used A4X Max ou A4X Mémoire utilisée par le commutateur réseau, en octets.
Libellés des clés : subblock_id, block_id, reservation_id, switch_type.
Mémoire totale network_switch/total_memory_bytes A4X Max ou A4X Capacité mémoire totale du commutateur réseau, en octets.
Libellés de clé : subblock_id, block_id, reservation_id, switch_type.
Temps de démarrage network_switch/boot_time_in_ns A4X Max ou A4X Code temporel de démarrage du commutateur réseau, en nanosecondes depuis l'epoch Unix.
Libellés de clé : subblock_id, block_id, reservation_id, switch_type.
Basculer entre les métriques de capacité et de file d'attente

Pour suivre la capacité réseau de référence par rapport à la capacité réseau utilisable, et pour surveiller la profondeur des files d'attente de tampon et les pertes de files d'attente sur le commutateur, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Capacité de référence network_switch/baseline_capacity_kbps A4X Max ou A4X Capacité totale de bande passante de base potentielle d'une connexion de commutateur ToR au superbloc, en kilobits par seconde (kbit/s).
Libellés des clés : subblock_id, block_id, reservation_id, switch_type.
Capacité effective network_switch/effective_capacity_kbps A4X Max ou A4X Capacité opérationnelle utilisable d'une connexion de commutateur ToR au superbloc, en kilobits par seconde (kbit/s). Cette métrique reflète les réductions de capacité causées par des liens dégradés ou hors connexion.
Libellés des clés : subblock_id, block_id, reservation_id, switch_type.
Profondeur maximale de la file d'attente de sortie network_switch/egress_max_queue_depth A4X Max ou A4X Profondeur maximale de la file d'attente observée lors du cycle de mesure le plus récent.
Libellés clés : port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Suppression de files d'attente de sortie network_switch/egress_queue_drops_count A4X Max ou A4X Nombre cumulé de paquets supprimés des files d'attente de sortie en raison de la congestion des files d'attente ou de l'épuisement du tampon.
Libellés de clé : port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Dans les suppressions de mémoire tampon network_switch/in_buffer_discards A4X Max ou A4X Nombre cumulé de paquets entrants supprimés à l'entrée en raison d'un dépassement de capacité du tampon.
Libellés de clé : port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Métriques sur les abandons de switch, les erreurs et le contrôle de flux

Utilisez les métriques de cette section pour diagnostiquer les problèmes suivants, qui peuvent entraîner des blocages de l'entraînement distribué ou des délais d'attente de communication collective (tels que les délais d'attente du watchdog NCCL) :

  • Suppression de paquets, erreurs de transmission et instabilité de la liaison physique.
  • Erreurs de mots liées à la correction d'erreur directe (FEC).
  • Événements de gestion de la congestion, tels que les pauses du contrôle de flux basé sur la priorité (PFC) et les marquages de notification explicite de congestion (ECN).
Nom Type de métrique Séries de machines compatibles Description
Volets d'interface network_switch/interface_flaps_count A4X Max ou A4X Nombre cumulé de transitions d'état de liaison physique (flaps entre UP et DOWN) sur l'interface du port de commutateur.
Libellés de clé : port_identifier, subblock_id, block_id, reservation_id, switch_type.
Erreurs de mots Fec network_switch/fec_word_error_count A4X Max ou A4X Nombre cumulé d'erreurs de mots de correction d'erreur directe (FEC). Utilisez l'étiquette booléenne correctable (true ou false) pour faire la distinction entre les erreurs pouvant être corrigées et celles qui ne le peuvent pas.
Libellés des clés : port_identifier, correctable, subblock_id, block_id, reservation_id, switch_type.
Paquets marqués ECN network_switch/ecn_marked_packets_count A4X Max ou A4X Nombre cumulé de paquets marqués avec des bits ECN (Explicit Congestion Notification) en raison de seuils de mémoire tampon dépassés.
Libellés de clé : port_identifier, subblock_id, block_id, reservation_id, switch_type.
Pfc rx packets network_switch/pfc_rx_packets_count A4X Max ou A4X Nombre cumulé de trames de pause PFC (Priority-based Flow Control) reçues sur le port.
Remarque : Ne s'applique qu'aux environnements dédiés où PFC est activé.
Libellés des clés : port_identifier, priority_index, subblock_id, block_id, reservation_id, switch_type.
Paquets Pfc tx network_switch/pfc_tx_packets_count A4X Max ou A4X Nombre cumulé de trames de pause PFC (Priority-based Flow Control) transmises depuis le port pour limiter le trafic entrant.
Remarque : Ne s'applique qu'aux environnements dédiés où PFC est activé.
Libellés de clé : port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Paquets QoS tx network_switch/qos_tx_packets A4X Max ou A4X Nombre cumulé de paquets de qualité de service (QoS) transmis dans la file d'attente spécifiée.
Libellés clés : port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Nombre de paquets reçus network_switch/in_packets_count A4X Max ou A4X Nombre cumulé de paquets entrants reçus sur le port du commutateur.
Libellés clés : port_identifier, subblock_id, block_id, reservation_id, switch_type.
En cas d'erreur network_switch/in_errors A4X Max ou A4X Nombre cumulé de paquets entrants reçus avec des erreurs qui ont empêché leur distribution.
Libellés de clé : port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Dans la corbeille network_switch/in_discards A4X Max ou A4X Nombre cumulé de paquets entrants valides qui ont été supprimés (par exemple, en raison d'un manque d'espace tampon).
Libellés de clé : port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Erreurs de sortie network_switch/out_errors A4X Max ou A4X Nombre cumulé de paquets sortants qui n'ont pas pu être transmis en raison d'erreurs.
Libellés de clé : port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Sorties supprimées network_switch/out_discards A4X Max ou A4X Nombre cumulé de paquets sortants qui ont été choisis pour être supprimés même si aucune erreur n'a été détectée.
Libellés des clés : port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Nombre d'octets entrants network_switch/in_bytes_count A4X Max ou A4X Nombre cumulé d'octets entrants reçus sur le port du commutateur.
Libellés clés : port_identifier, subblock_id, block_id, reservation_id, switch_type.
Nombre d'octets sortants network_switch/out_bytes_count A4X Max ou A4X Nombre cumulé d'octets sortants transmis par le port de commutateur.
Libellés clés : port_identifier, subblock_id, block_id, reservation_id, switch_type.

Métriques sur les erreurs fatales du GPU

Pour surveiller les erreurs rencontrées par vos GPU et qui pourraient forcer l'arrêt de vos instances de calcul ou avoir un impact négatif sur leurs performances, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Erreur d'exécution NVLink instance/gpu/nvlink_runtime_error A4X Max ou A4X Indique si une erreur d'exécution NVLink s'est produite.
Erreurs ECC DRAM non corrigibles instance/gpu/dram_uncorrectable_ecc_error_count A4X Max ou A4X Nombre de codes de correction d'erreurs (ECC) non corrigibles dans une mémoire vive dynamique (DRAM) de GPU.
Nombre de remappages de lignes DRAM non corrigibles instance/gpu/dram_uncorrectable_row_remapping_count A4X Max ou A4X Nombre de remappages de lignes à partir d'erreurs non corrigibles dans les DRAM GPU.
Échec du remappage de ligne DRAM non corrigible instance/gpu/dram_row_remapping_failed A4X Max ou A4X Indique si le remappage d'une ligne dans les DRAM du GPU a échoué en raison de l'un des problèmes suivants :
  • Une tentative de remappage sur une banque de mémoire a échoué, car la banque de mémoire comporte déjà huit lignes d'erreurs non corrigibles remappées.
  • Une tentative de remappage d'une ligne a échoué, car la ligne était déjà remappée.
  • Une tentative de remappage a échoué, car 512 remappages au total ont eu lieu.
Erreurs PCIe non corrigibles instance/gpu/pcie_fatal_error_count A4X Max ou A4X Nombre d'erreurs PCIe (Peripheral Component Interconnect Express) non corrigibles.
Erreurs ECC de cache non corrigibles instance/gpu/cache_uncorrectable_ecc_error_count A4X Max ou A4X Nombre d'erreurs ECC non corrigibles dans la mémoire cache.

Métriques de charge de travail de ML

Pour surveiller la productivité (plus précisément, le goodput) de vos charges de travail de ML, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Temps productif workload/goodput_time A4X, A4, A3 Ultra ou A3 Mega Temps (en secondes) que la charge de travail consacre aux activités de débit utile. Il s'agit de tâches utiles et essentielles, comme un calcul au plus tôt ou au plus tard lors de l'entraînement du modèle.
Temps non productif workload/badput_time A4X, A4, A3 Ultra ou A3 Mega Temps (en secondes) que la charge de travail consacre aux activités de badput. Ces activités sont des tâches générales, comme le chargement ou le prétraitement des données pour l'entraînement.

Métriques de détection des retardataires

Les métriques de détection des retardataires vous aident à identifier et à localiser les retardataires potentiels. Les retardataires sont des défaillances ponctuelles qui ne provoquent pas de plantage, mais qui finissent par ralentir l'ensemble de la charge de travail.

Pour surveiller la détection des retardataires pour vos VM, utilisez la métrique suivante :

Nom Type de métrique Séries de machines compatibles Description
Retardataires potentiels instance/gpu/straggler_status A4X, A4, A3 Ultra ou A3 Mega Indique si une VM est suspectée d'être une VM lente qui affecte les performances de la charge de travail. Nous vous recommandons de n'agir sur les retardataires présumés que lorsque d'autres métriques indiquent que la charge de travail rencontre des problèmes.

Vous pouvez également consulter les métriques de détection des retardataires dans les entrées de journal d'une instance A4X, A4, A3 Ultra ou A3 Mega. Par exemple, vous pouvez utiliser les requêtes suivantes :

Description Requête
Journaux avec des VM spécifiques suspectées d'être à la traîne. Utilisez cette requête pour vérifier si des retardataires suspects sont présents pour une charge de travail spécifique de votre projet. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"

Remplacez INSTANCE_ID par l'ID d'une VM. Pour chaque VM supplémentaire que vous souhaitez spécifier, ajoutez la condition suivante à la requête :

    OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
Tous les journaux de détection des retardataires pour votre projet. Utilisez cette requête pour vérifier si le service de détection des retardataires est en cours d'exécution lorsqu'aucun retardataire suspect n'est détecté. (En raison des limites, vous ne pouvez pas filtrer les journaux sans retardataires suspects par VM spécifique.) 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

Les métriques de détection des tâches lentes sont particulièrement utiles pour les charges de travail de ML à grande échelle pour les raisons suivantes :

  • Les charges de travail de ML à grande échelle sont très sensibles aux tâches lentes. Les charges de travail de ML à grande échelle utilisent l'informatique synchrone et massivement distribuée. (En d'autres termes, ils comportent de nombreux composants très interdépendants qui s'exécutent simultanément.) Cette architecture rend les charges de travail de ML à grande échelle très sensibles aux points de défaillance uniques, comme les retardataires.

  • Il est très difficile de repérer et d'identifier les retardataires dans les charges de travail de ML à grande échelle. À titre d'information, sachez qu'il existe deux types de points de défaillance uniques :

    • Défaillances d'arrêt : défaillances qui entraînent l'arrêt de l'ensemble du système (par exemple, erreurs d'hôte et événements de maintenance). Elles sont relativement simples à détecter et à résoudre.

    • Échecs lents : échecs qui entraînent une dégradation importante des performances sans plantages. Ils sont très difficiles à identifier et à déboguer.

    En raison de leur nature de défaillance lente, les retardataires sont intrinsèquement difficiles à remarquer et à identifier, en particulier dans les charges de travail synchrones à grande échelle.

Métriques de détection des charges de travail qui ne répondent pas

Les métriques de détection des charges de travail non réactives vous aident à :

  • Remarquez quand une charge de travail entière est bloquée (parfois appelée blocage NCCL).
  • Comprendre pourquoi la charge de travail est bloquée, par exemple si cela est dû à un plantage de processus ou à un réseau bloqué

Pour détecter et diagnostiquer les charges de travail qui ne répondent pas pour vos instances de calcul, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Événements de charge de travail non réactifs détectés à l'aide de la télémétrie NCCL instance/gpu/nccl_hang A4X Max, A4X, A4 et A3 Ultra Nombre d'événements de charge de travail non réactive détectés, sous forme de série temporelle.

Activer la détection des charges de travail non réactives

Pour activer la détection des charges de travail qui ne répondent pas, vous devez activer CoMMA avec la télémétrie heartbeat, un signal ping périodique qui indique qu'une charge de travail est en cours d'exécution. Pour les versions récentes de CoMMA, cette option est activée par défaut. Toutefois, si vous utilisez la version de CoMMA à partir de la version 1.1.1 du bundle NICCL/gIB, vous devez activer manuellement la télémétrie heartbeat. Pour vérifier la version du bundle NICCL/gIB que vous utilisez, consultez Vérifier la version de NCCL et gIB.

Pour activer manuellement la télémétrie heartbeat pour CoMMA, spécifiez les variables d'environnement suivantes dans votre environnement d'entraînement :

NCCL_PROFILER_HEARTBEAT=true

NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL=10s

Utilisez NCCL_PROFILER_HEARTBEAT pour activer ou désactiver la télémétrie de battement de cœur, et NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL pour spécifier la fréquence de la télémétrie de battement de cœur. Pour en savoir plus, consultez Variables d'environnement CoMMA.

Désactiver la détection des charges de travail qui ne répondent pas

Pour désactiver la détection des charges de travail qui ne répondent pas, désactivez la télémétrie heartbeat dans CoMMA en spécifiant la variable d'environnement suivante dans votre environnement d'entraînement :

NCCL_PROFILER_HEARTBEAT=false

Comprendre pourquoi les charges de travail ne répondent pas

Pour comprendre pourquoi une charge de travail ne répond pas, vérifiez la valeur du libellé hang_reason en procédant comme suit :

  1. Dans la console Google Cloud , accédez à la page  Explorateur de métriques.

    Accéder à l'Explorateur de métriques

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

  2. Recherchez la métrique suivante :

    compute.googleapis.com/instance/gpu/nccl_hang

  3. Utilisez la fonctionnalité Agrégation et sélectionnez les libellés suivants :

    • instance_id
    • hang_reason

Le tableau suivant liste les valeurs possibles pour le libellé, ce qu'elles signifient concernant vos charges de travail et les prochaines étapes recommandées.

Valeur de l'étiquette Description Procédure recommandée
MissingHeartbeatIssue La télémétrie Heartbeat s'est arrêtée pour un ou plusieurs rangs, ce qui indique généralement un plantage fatal du processus ou du nœud.
  • Vérifiez si l'instance est toujours accessible.
  • Vérifiez si les processus de charge de travail ont planté.
  • Recherchez les événements de mémoire insuffisante (OOM), tels que dmesg, dans les journaux système.
  • Recherchez les défaillances matérielles ou les erreurs NVIDIA XID.
StalledRankIssue Les données de télémétrie de pulsation sont toujours reçues, mais les rangs ne progressent pas sur les opérations NCCL.
  • Examinez les éventuels blocages dans les opérations au niveau de l'application.
  • Vérifiez si le processus d'application est bloqué dans une opération qui l'empêche de communiquer avec d'autres, comme le calcul ou le point de contrôle.
MissingCommunicatorIssue Tous les rangs appartenant à un communicateur NCCL ont cessé de progresser.
  • Votre charge de travail a peut-être été interrompue ou ses communicateurs NCCL ont peut-être été fermés de manière inattendue. Si vous vous attendez à ce qu'une charge de travail s'exécute sans interruption sur cette instance de VM, vérifiez si elle a été interrompue ou arrêtée de manière anormale.
NoHangIssue Valeur par défaut. Aucun problème n'a été détecté.
  • Aucune action n'est requise.

Afficher les métriques

Pour afficher les métriques de vos instances de calcul et de vos clusters Slurm, utilisez les tableaux de bord Monitoring comme suit :

Si vous rencontrez des problèmes lorsque vous utilisez un tableau de bord, consultez Résoudre les problèmes de performances lentes.

Utiliser des tableaux de bord prédéfinis

Vous pouvez utiliser les tableaux de bord Monitoring prédéfinis pour AI Hypercomputer afin d'afficher les métriques de vos instances de calcul et de vos clusters Slurm. Vous pouvez également créer une copie d'un tableau de bord prédéfini et le modifier pour l'adapter à vos besoins.

Pour utiliser un tableau de bord prédéfini pour AI Hypercomputer :

  1. Dans la console Google Cloud , accédez à la page  Tableaux de bord :

    Accéder à la page Tableaux de bord

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

  2. Dans la colonne Nom, cliquez sur le nom de l'un des tableaux de bord suivants en fonction des métriques que vous souhaitez afficher :

    • Pour surveiller l'état des instances de calcul, les performances des GPU et la détection des tâches lentes, utilisez le tableau de bord Surveillance de l'état de Cluster Director.

      Pour savoir comment utiliser ces métriques afin d'identifier et d'analyser les problèmes, utilisez également le tableau de bord du playbook GCE Interactive Playbook – Cluster Director Health Monitoring.

    • Pour surveiller l'efficacité de la transmission réseau, utilisez le tableau de bord Efficacité de la transmission Cluster Director.

    • Pour surveiller l'efficacité du réseau entre les blocs et les sous-blocs, utilisez le tableau de bord Réseau de blocs Cluster Director.

      Pour savoir comment utiliser ces métriques afin d'identifier et d'analyser les problèmes, utilisez également le tableau de bord du playbook Playbook interactif GCE : blocage du réseau Cluster Director.

    La page d'informations du tableau de bord de votre choix s'ouvre. Vous pouvez utiliser le sélecteur de période dans la barre d'outils pour modifier la période des données.

  3. Facultatif : Pour créer une copie d'un tableau de bord et le personnaliser selon vos besoins, cliquez sur Copier le tableau de bord.

Créer des tableaux de bord personnalisés

Pour créer un tableau de bord Monitoring personnalisé :

  1. Choisissez les métriques à surveiller. Si ce n'est pas déjà fait, consultez Métriques disponibles dans ce document.

  2. Créez et gérez des tableaux de bord personnalisés.

Afficher les journaux de détection des retardataires

Pour afficher les journaux de détection des tâches lentes à l'aide de l'explorateur de journaux, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la pageExplorateur de journaux :

    Accéder à l'explorateur de journaux

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

    Par défaut, la page interroge tous les journaux de votre projet. Cliquez sur Arrêter la requête.

  2. Utilisez le sélecteur de période dans la barre d'outils pour sélectionner la période que vous souhaitez analyser.

  3. Dans le volet Requête, saisissez une requête pour les journaux de détection des retardataires.

  4. Cliquez sur Exécuter la requête.

Voici un exemple d'entrée de journal de détection de retardataires.

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

L'entrée de journal comprend les champs suivants :

  • numNodes : nombre d'instances de calcul suspectes détectées dans le projet. Dans l'exemple, quatre instances de calcul retardataires suspectes ont été détectées.
  • instanceId : ID d'une instance de calcul détectée comme un retardataire suspect.

Étapes suivantes