Résoudre les problèmes liés aux VM GPU

Cette page explique comment résoudre les problèmes liés aux VM exécutées sur Compute Engine auxquelles sont associés des GPU.

Si vous essayez de créer une VM avec des GPU associés et que vous obtenez des erreurs, alors consultez Résoudre les erreurs de disponibilité des ressources et Résoudre les problèmes de création et de mise à jour de VM.

Résoudre les problèmes liés aux VM GPU à l'aide de NVIDIA DCGM

Le gestionnaire de GPU du centre de données (DCGM) NVIDIA est une suite d'outils permettant de gérer et de surveiller les GPU des centres de données NVIDIA dans les environnements de clusters.

Si vous souhaitez utiliser DCGM pour résoudre les problèmes dans votre environnement GPU, procédez comme suit :

• Assurez-vous d'utiliser le dernier pilote NVIDIA recommandé pour le modèle de GPU associé à votre VM. Pour consulter les versions de pilote, consultez la page Versions du pilote NVIDIA recommandées.
• Assurez-vous d'avoir installé la dernière version de DCGM. Pour installer la dernière version, consultez la section Installation de DCGM.

Diagnostiquer les problèmes

Lorsque vous exécutez une commande de diagnostic dcgmi, les problèmes signalés par l'outil de diagnostic incluent les étapes suivantes pour résoudre le problème. L'exemple suivant montre la sortie exploitable de la commande dcgmi diag -r memory -j.

{
  ........
   "category":"Hardware",
   "tests":[
      {
         "name":"GPU Memory",
         "results":[
            {
               "gpu_id":"0",
               "info":"GPU 0 Allocated 23376170169
bytes (98.3%)",
               "status":"Fail",
               ""warnings":[
                  {
                     "warning":"Pending page
retirements together with a DBE were detected on GPU 0. Drain the GPU and reset it or reboot the node to resolve this issue.",
                     "error_id":83,
                     "error_category":10,
                     "error_severity":6
                  }
               ]
            }
  .........

Dans l'extrait de sortie précédent, vous pouvez voir que GPU 0 a des suppressions de pages en attente causées par une erreur non récupérable. Le résultat a fourni le paramètre error_id unique et des conseils pour résoudre le problème. Pour cet exemple de sortie, il est recommandé de vider le GPU et de redémarrer la VM. Dans la plupart des cas, suivre les instructions de cette section du résultat peut vous aider à résoudre le problème.

Conseil avancé : Notez le niveau de gravité de l'erreur. Dans l'exemple de sortie, la valeur "error_severity":6 correspond à un DCGM_ERROR_RESET, ce qui signifie qu'une réinitialisation résout les problèmes avec cette valeur de gravité.

Pour obtenir la liste complète des error_severity valeurs, consultez la dcgmErrorSeverity_enum section du fichier GitHub dcgm_errors.

Résoudre les problèmes de performances des GPU pour les VM A3

La série de machines A3 est disponible avec des GPU NVIDIA H200 ou H100 associés. Cette série comprend les types de machines A3 Ultra (H200), A3 Mega (H100), A3 High (H100), et A3 Edge (H100).

Identifier un nœud défectueux

Les tâches d'entraînement ou de benchmark à grande échelle sur un cluster GPU à plusieurs nœuds peuvent cesser de répondre ou fonctionner mal. Cela se produit souvent parce qu'un ou plusieurs nœuds sont sous-performants et ralentissent l'ensemble de l'opération. Cette section explique comment identifier un nœud ou une machine hôte défectueux en exécutant un test de benchmark NCCL ou en analysant les journaux NCCL.

Exécuter un test de benchmark NCCL

Pour identifier le groupe de nœuds à l'origine de l'échec, testez systématiquement des sous-ensembles de votre cluster à l'aide de benchmarks NCCL tels que all_reduce_perf.

1. Pour identifier vos ensembles de nœuds, regroupez vos nœuds en ensembles logiques, par exemple, des partitions dans Slurm.
2. Pour créer des fichiers hôtes, créez un fichier hôte distinct pour chaque ensemble de nœuds, en listant les noms d'hôte et le nombre de GPU par nœud. Le nombre d'emplacements que vous spécifiez dépend du nombre de GPU de votre type de VM A3. Par exemple, les VM a3-highgpu-8g disposent de huit GPU. Vous devez donc spécifier slots=8.
3. Pour exécuter des benchmarks, exécutez le all_reduce_perf benchmark sur chaque ensemble de nœuds individuellement.

   mpirun -x LD_LIBRARY_PATH --hostfile HOSTFILE_NAME -n TOTAL_PROCESSES \
       ./build/all_reduce_perf -b 1G -e 8G -f 2 -g NUM_GPUS_PER_NODE
             

   Remplacez les éléments suivants :

   • HOSTFILE_NAME : nom du fichier hôte contenant la liste des nœuds et le nombre de GPU par nœud pour l'ensemble de nœuds.
   • TOTAL_PROCESSES : nombre total de processus MPI à lancer sur tous les hôtes de l'ensemble de nœuds.
   • NUM_GPUS_PER_NODE : nombre de GPU par nœud. Pour tous les types de machines A3, cette valeur est 8.
4. Pour analyser les résultats, si une tâche se bloque ou affiche une bande passante de bus nettement inférieure (busbw) sur un ensemble de nœuds particulier, cet ensemble est probablement défectueux.
5. Pour subdiviser, si un ensemble de nœuds est défectueux, divisez son fichier hôte en deux et re-testez pour affiner la recherche binaire jusqu'à identifier le nœud individuel qui ne fonctionne pas correctement.

Analyser les journaux NCCL

Si la méthode de benchmark n'identifie pas de nœud, analysez les journaux NCCL détaillés.

1. Pour activer la journalisation de débogage, définissez les variables d'environnement suivantes dans la session shell où vous prévoyez d'exécuter votre charge de travail :

   export NCCL_DEBUG=INFO
           export NCCL_DEBUG_SUBSYS=INIT,NET,COLL
           export NCCL_DEBUG_FILE="LOG_DIRECTORY/nccl_log.%h.%p"
           

   Remplacez LOG_DIRECTORY par le répertoire dans lequel vous souhaitez stocker vos journaux.

   La définition de NCCL_DEBUG_FILE avec %h et %p crée des fichiers journaux uniques, non entrelacés pour chaque processus.

   Si vous exécutez une charge de travail à plusieurs nœuds à l'aide de mpirun, vous devez propager ces variables à tous les nœuds à l'aide de l'indicateur -x. Par exemple :

   mpirun -x NCCL_DEBUG -x NCCL_DEBUG_SUBSYS -x NCCL_DEBUG_FILE ...
             

2. Pour trouver la première erreur, utilisez la commande suivante afin de trouver les événements de délai d'attente ou d'échec les plus anciens dans tous les fichiers journaux :

   grep "NCCL WARN.*NET/FasTrak" LOG_DIRECTORY/* | sed 's/.*NET\/FasTrak\(.*\)/\1/g' \
     | sort | head -n 20
             

   Remplacez LOG_DIRECTORY par le répertoire dans lequel vos journaux sont stockés.

3. Pour compter les opérations collectives, un nœud retardataire effectue moins d'opérations collectives. Comptez les entrées "opCount" pour les rangs suspects :

   grep "opCount" LOG_DIRECTORY/nccl_log.HOSTNAME.PID | wc -l
             

   Remplacez les éléments suivants :

   • LOG_DIRECTORY : répertoire dans lequel vos journaux sont stockés
   • HOSTNAME : nom d'hôte du nœud
   • PID : ID de processus du processus NCCL
4. Pour collecter davantage de données de journalisation avant l'abandon d'une tâche, augmentez temporairement le délai d'attente de transfert de données :

   export NCCL_FASTRAK_DATA_TRANSFER_TIMEOUT_MS=3600000
           

Surveiller la limitation thermique du GPU

Les VM de la série A3 peuvent subir une dégradation des performances si elles atteignent constamment des températures supérieures à 87 °C sous charge. Pour vérifier la limitation thermique du GPU sur les nœuds d'un cluster, utilisez nvidia-smi ou dcgmi.

Utiliser nvidia-smi

Pour vérifier la température actuelle et l'état de limitation de tous les GPU d'un nœud, exécutez la commande suivante :

nvidia-smi --query-gpu=timestamp,name,pci.bus_id,temperature.gpu,clocks_throttle_reasons.hw_slowdown --format=csv
    

Dans la sortie, la valeur Active dans la colonne clocks_throttle_reasons.hw_slowdown indique que le GPU est limité en raison de températures élevées.

Utiliser dcgmi

La suite de diagnostic du gestionnaire de GPU du centre de données (DCGM) NVIDIA inclut des vérifications des violations thermiques. Pour exécuter un diagnostic de niveau 1, exécutez la commande suivante :

dcgmi diag -r 1

Un résultat Warn ou Fail dans la section Thermal indique qu'une violation thermique s'est produite lors du test. Si une violation thermique s'accompagne de limitation de l'horloge, le GPU est probablement en surchauffe et nécessite une investigation plus approfondie.

Ouvrir une demande d'assistance

Si vous ne parvenez pas à résoudre les problèmes à l'aide des conseils de cette page, rassemblez les informations suivantes et ouvrez une demande d'assistance :

• ID du projet et liste de tous les noms ou ID d'instance dans le cluster.
• Liste des nœuds suspects identifiés lors du dépannage.
• Journaux NCCL complets et non entrelacés avec les paramètres de débogage activés.
• Résultat des vérifications de l'état du matériel (dcgmi, nvidia-smi).
• Commande exacte de benchmark ou de charge de travail qui échoue.
• Fichiers journaux adaptés tels que le moteur hôte et les journaux de diagnostic. Pour les collecter, exécutez gather-dcgm-logs.sh, situé dans /usr/local/dcgm/scripts dans les installations par défaut.
• Rapport de bug NVIDIA. Exécutez nvidia-bug-report.sh. Pour les GPU Blackwell, suivez la procédure Générer un rapport de bug NVIDIA pour les GPU Blackwell.
• Informations sur les modifications récentes apportées à votre environnement avant l'échec.

Examiner les messages Xid

Après avoir créé une VM à laquelle sont associés des GPU, vous devez installer des pilotes d'appareils NVIDIA sur vos VM GPUafin que vos applications puissent accéder aux GPU. Cependant, ces pilotes renvoient parfois des messages d'erreur.

Un message Xid est un rapport d'erreur du pilote NVIDIA affiché dans le journal de noyau du système d'exploitation ou dans le journal des événements de votre VM Linux. Ces messages sont placés dans le fichier /var/log/messages.

Pour en savoir plus sur les messages Xid, y compris les causes potentielles, consultez la documentation NVIDIA.

La section suivante fournit des conseils sur la gestion de certains messages Xid regroupés par les types les plus courants : erreurs de mémoire de GPU, erreurs de processeur système du GPU (GSP) et erreurs d'accès illégal à la mémoire.

Erreurs de mémoire du GPU

La mémoire du GPU est la mémoire disponible sur un GPU pouvant être utilisé pour le stockage temporaire de données. La mémoire du GPU est protégée par le code de correction d'erreur (ECC), qui détecte et corrige les erreurs à bit unique, et détecte et signale les erreurs à double bit (DBE).

Avant la sortie des GPU NVIDIA A100, la suppression dynamique de page était possible. Pour les versions de GPU NVIDIA A100 et ultérieures (telles que NVIDIA H100), la récupération d'erreur de remappage de ligne est introduite. Le routage ECC est activé par défaut. Nous vous recommandons vivement de laisser le chiffrement ECC activé.

Voici les erreurs courantes de mémoire du GPU et leurs solutions suggérées.

Message d'erreur Xid	Solution
Xid 48: Double Bit ECC	Arrêtez vos charges de travail. Supprimez et recréez la VM. Si l'erreur persiste, déposez une demande auprès du Cloud Customer Care.
Xid 63: ECC page retirement or row remapping recording event	Arrêtez vos charges de travail. Réinitialisez les GPU.
Xid 64: ECC page retirement or row remapper recording failure Le message contient les informations suivantes : Xid 64: All reserved rows for bank are remapped	Arrêtez vos charges de travail. Supprimez et recréez la VM. Si l'erreur persiste, déposez une demande auprès du Cloud Customer Care.
Si vous recevez au moins deux des messages Xid suivants en même temps : Xid 48 Xid 63 Xid 64 Le message contient les informations suivantes : Xid XX: row remap pending	Arrêtez vos charges de travail. Réinitialisez les GPU. La réinitialisation du GPU permet au processus de remappage des lignes et de suppression de pages de terminer et de réparer le GPU.
Xid 92: High single-bit ECC error rate	Ce message Xid est renvoyé une fois que le pilote de GPU a corrigé une erreur récupérable. Cela ne devrait pas affecter vos charges de travail. Ce message Xid n'est fourni qu'à titre d'information. Aucune action n'est requise de votre part.
Xid 94: Contained ECC error	Arrêtez vos charges de travail. Réinitialisez les GPU.
Xid 95: Uncontained ECC error	Arrêtez vos charges de travail. Réinitialisez les GPU.

Erreurs GSP

Un processeur système GPU (GSP) est un microcontrôleur qui s'exécute sur des GPU et gère certaines des fonctions de gestion matérielle de bas niveau.

Message d'erreur Xid	Solution
Xid 119: GSP RPC timeout	Arrêtez vos charges de travail. Supprimez et recréez la VM. Si l'erreur persiste, collectez le rapport de bug NVIDIA et déposez une demande auprès de Cloud Customer Care.
Xid 120: GSP error

Erreurs d'accès illégal à la mémoire

Les Xid suivants sont renvoyés lorsque les applications rencontrent des problèmes d'accès illégal à la mémoire :

• Xid 13: Graphics Engine Exception
• Xid 31: GPU memory page fault

Les erreurs d'accès à la mémoire illégales sont généralement provoquées par vos charges de travail qui tentent d'accéder à la mémoire déjà libérée ou hors limites. Cela peut être dû à des problèmes tels que le déréférencement d'un pointeur non valide ou d'un tableau de limites sortantes.

Pour résoudre ce problème, vous devez déboguer votre application. Pour déboguer votre application, vous pouvez utiliser cuda-memcheck et CUDA-GDB.

Dans certains cas très rares, la dégradation matérielle peut entraîner l'affichage d'erreurs d'accès à la mémoire illégales. Pour déterminer si le problème concerne votre matériel, utilisez le gestionnaire de GPU du centre de données (DCGM) NVIDIA. Vous pouvez exécuter dcgmi diag -r 3 ou dcgmi diag -r 4 pour exécuter différents niveaux de couverture et de durée des tests. Si vous constatez que le problème concerne le matériel, déposez une demande auprès du Cloud Customer Care.

Autres messages d'erreur Xid courants

Message d'erreur Xid	Solution
Xid 74: NVLINK error	Arrêtez vos charges de travail. Réinitialisez les GPU.
Xid 79: GPU has fallen off the bus Cela signifie que le pilote ne peut pas communiquer avec le GPU.	Redémarrez la VM.
Xid 149 qui mentionne 0x02a, comme dans l' exemple suivant : Xid (PCI:0000:c0:00): 149,NETIR_LINK_EVT Fatal XC0 i0 Link 04 (0x02a485c6 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000) Cela indique un problème connu affectant le micrologiciel des GPU NVIDIA B200.	Arrêtez vos charges de travail. Réinitialisez les GPU.

Réinitialiser les GPU

Certains problèmes peuvent vous obliger à réinitialiser vos GPU. Pour réinitialiser les GPU, procédez comme suit :

• Pour les VM N1, G2 et A2, redémarrez la VM.
• Pour les VM G4 auxquelles est associé moins d'un GPU, supprimez et recréez la VM.
• Pour les VM A3 et A4, exécutez sudo nvidia-smi --gpu-reset.
  • Pour la plupart des VM Linux, l'exécutable nvidia-smi se trouve dans le répertoire /var/lib/nvidia/bin.
  • Pour les nœuds GKE, l'exécutable nvidia-smi se trouve dans le répertoire /home/kubernetes/bin/nvidia.
  • Si vous utilisez des nœuds GKE, vous pouvez utiliser l' outil de réinitialisation des GPU pour automatiser la réinitialisation de tous les GPU d'un nœud. Cet outil ne nécessite que la spécification du nom du nœud cible.

Vous pouvez également réinitialiser les GPU lorsque vous réinitialisez une VM ou redémarrez une VM.

Si des erreurs persistent après la réinitialisation du GPU, vous devez supprimer et recréer la VM.

Si l'erreur persiste après une suppression et une recréation, déposez une demande auprès du Cloud Customer Care pour déplacer la VM vers l'étape de réparation.

Étape suivante

Consultez la section types de machines GPU.