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

Ce guide explique comment diagnostiquer et résoudre les problèmes courants liés aux VM Compute Engine auxquelles sont associés des GPU, y compris les erreurs matérielles et les goulots d'étranglement des performances.

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.

Pour utiliser DCGM afin de 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 Versions du pilote NVIDIA recommandées.
  • Assurez-vous d'avoir installé la dernière version de DCGM. Pour installer la dernière version, consultez 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 prochaines étapes à suivre pour résoudre le problème. L'exemple suivant montre le résultat 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 pages en attente de suppression en raison d'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 résultat, nous vous recommandons 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.

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. Cette série inclut 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 multinœud peuvent cesser de répondre ou être peu performantes. Cela se produit souvent lorsqu'un ou plusieurs nœuds sont moins 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 référence 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 dans des 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 benchmark all_reduce_perf 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 le nœud.
    • TOTAL_PROCESSES : nombre total de processus MPI à lancer sur tous les hôtes du nœud.
    • 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 un job se bloque ou affiche une bande passante de bus (busbw) nettement inférieure sur un ensemble de nœuds particulier, il est probable que cet ensemble soit défectueux.
  5. Pour subdiviser, si un ensemble de nœuds est défectueux, divisez son fichier hôte en deux et testez-le à nouveau pour affiner la recherche binaire jusqu'à identifier le nœud individuel qui se comporte mal.

Analyser les journaux NCCL

Si la méthode de référence ne permet pas d'identifier un nœud, analysez les journaux NCCL détaillés.

  1. Pour activer la journalisation du 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.

    Définir NCCL_DEBUG_FILE avec %h et %p crée des fichiers journaux uniques et non entrelacés pour chaque processus.

    Si vous exécutez une charge de travail multinœud à l'aide de mpirun, propagez 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 avant expiration 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 comptabiliser les opérations collectives, un nœud retardataire effectue moins d'opérations collectives. Nombre d'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 du processus NCCL
  4. Pour collecter davantage de données de journalisation avant l'abandon d'un job, augmentez temporairement le délai d'expiration du transfert de données : 
    export NCCL_FASTRAK_DATA_TRANSFER_TIMEOUT_MS=3600000

Surveiller la limitation thermique du GPU

Les performances des VM de la série A3 peuvent se dégrader si elles atteignent régulièrement 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 toutes 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 le résultat, une valeur de 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 diagnostics NVIDIA Data Center GPU Manager (DCGM) 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 de Warn ou Fail dans la section Thermal indique qu'une violation thermique s'est produite pendant le test. Si une violation thermique s'accompagne d'une limitation de la fréquence d'horloge, il est probable que le GPU surchauffe et nécessite une analyse plus approfondie.

Erreurs Xid

Après avoir créé une VM à laquelle sont associés des GPU, vous devez installer des pilotes d'appareils NVIDIA sur vos VM GPU afin 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.

Comment Google gère-t-il les erreurs Xid ?

Google utilise des vérifications d'état passives pour évaluer les systèmes de GPU. Si un remplacement de matériel est indiqué, Google lance automatiquement une maintenance d'urgence. Google détecte les erreurs Xid et envoie de manière proactive les machines en réparation lorsque les codes d'erreur indiquent une forte probabilité de défaillance matérielle, comme Xid 74, 79 et 140. Pour certains codes Xid, qui peuvent être dus à des problèmes logiciels ou matériels, Google utilise la reconnaissance de formes pour déclencher les réparations. Par conséquent, toutes les occurrences ne donnent pas lieu à une réparation automatique.

Types d'erreurs Xid

La liste suivante décrit les trois principales catégories d'erreurs Xid et les actions de récupération recommandées :

  • Erreurs d'application : elles indiquent des problèmes dans le code de votre application. Les erreurs d'application incluent des Xid tels que 13, 31, 94, 95 et 137, qui indiquent différents types de non-respect de l'accès à la mémoire, semblables à un défaut de segmentation. Elles n'indiquent pas d'erreur ECC. Pour résoudre ces erreurs, NVIDIA recommande d'utiliser l'une des approches de débogage suivantes :

    • Débogage direct : exécutez l'application directement dans cuda-gdb ou exécutez l'outil Compute Sanitizer memcheck.
    • Débogage post-exception : exécutez l'application avec CUDA_DEVICE_WAITS_ON_EXCEPTION=1. Lorsqu'une exception se produit, le pilote GPU gèle l'état de l'application sans la quitter, ce qui vous permet d'attacher un débogueur ultérieurement (cuda-gdb -p <PID>) pour inspecter la trace de la pile en direct.

  • Erreurs de pilote : elles indiquent des problèmes causés par le pilote de GPU NVIDIA. Pour résoudre ces erreurs, assurez-vous d'utiliser la dernière version du pilote NVIDIA. Google surveille ces erreurs et collabore avec NVIDIA pour corriger les pilotes.

  • Erreurs récupérables du micrologiciel ou du matériel : elles indiquent des erreurs du micrologiciel ou du matériel qui permettent une récupération sans remplacement du matériel. Pour résoudre ces erreurs, appliquez des mesures de récupération manuelles, comme la réinitialisation du GPU ou le redémarrage de l'instance. Les erreurs récupérables au niveau du micrologiciel ou du matériel incluent les erreurs de code de correction d'erreur (ECC, Error Correcting Code) (applicables aux Xid tels que Xid 48, 63 et 64) qui indiquent différentes étapes de détection et d'atténuation des erreurs ECC. Pour en savoir plus sur la désactivation des pages et l'atténuation des erreurs ECC, consultez les questions fréquentes sur la désactivation dynamique des pages de NVIDIA.

Examiner les messages Xid

Pour diagnostiquer rapidement la raison pour laquelle une charge de travail GPU a échoué, a cessé de répondre ou a subi une dégradation des performances, consultez les journaux du noyau de votre instance (dmesg ou /var/log/kern.log) pour y trouver des codes d'erreur NVIDIA Xid numériques.

L'examen des tableaux d'erreurs Xid dans les sous-sections suivantes vous aide immédiatement :

  • Identifier la cause première : déterminez si l'échec est dû à un bug d'application (tel qu'un accès illégal à la mémoire), à un conflit de pilote ou à un défaut matériel physique (tel que des erreurs de mémoire ECC double bit).
  • Déterminez la propriété opérationnelle : vérifiez les mesures de récupération manuelle immédiates que vous devez appliquer (par exemple, réinitialiser les GPU, redémarrer les VM ou exécuter des débogueurs) par rapport aux actions de réparation automatisées et de remplacement du matériel que Google gère activement sur l'hôte.
  • Suivez les étapes de récupération appropriées : évitez les procédures de dépannage inutiles et sachez précisément quand une récupération manuelle est suffisante et quand vous devez signaler l'hôte comme défectueux. Parfois, la récupération manuelle n'est pas suffisante, par exemple si la source de l'erreur se trouve dans le cache GPU (SRAM), qui ne peut pas être remappé, indiqué par Xid 48 avec SRAM Threshold Exceeded=Yes, ou si le GPU a épuisé sa banque de remappage, indiqué par Xid 64: All reserved rows for bank are remapped. Dans ce cas, Google détecte que le GPU est éligible au remplacement du matériel et envoie la machine en réparation de manière proactive. Si vos charges de travail rencontrent des erreurs récurrentes ou si vous constatez des erreurs de mémoire répétées, vous pouvez signaler l'hôte défectueux pour lancer une réparation ou un remplacement automatisés. Pour GKE, consultez Signaler des hôtes défectueux dans GKE.

Gestion des Xid

Les sections suivantes regroupent les messages d'erreur Xid courants par catégorie technique, ainsi que les solutions et les responsabilités officielles :

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 non corrigibles (DBE).

Ces erreurs de mémoire sont susceptibles de se produire au cours de la durée de vie d'un GPU. 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 pour les erreurs HBM (DRAM). Le routage ECC est activé par défaut. Google vous recommande vivement de le laisser activé.

Le tableau suivant liste les erreurs courantes de mémoire du GPU et leurs solutions suggérées :

Message d'erreur Xid Action du client Action Google
Xid 48: Double Bit ECC

Une erreur de mémoire à double bit (non corrigible) a été détectée par ECC. Cette erreur interrompt toujours la charge de travail en cours d'exécution et génère le Xid 48.
  1. Arrêtez vos charges de travail.
  2. En fonction de votre environnement, réinitialisez les GPU ou redémarrez la VM pour récupérer et reprendre les charges de travail :

Google surveille le moment où le GPU peut être remplacé par un autre matériel, par exemple si la banque de remappage HBM est épuisée ou si le GPU dépasse son seuil d'erreur SRAM à vie, et envoie de manière proactive la machine en réparation pour remplacer le GPU.
Xid 63: ECC page retirement or row remapping recording event

Indique qu'un événement de retrait de page dynamique ou de remappage de ligne a été enregistré en raison d'une erreur de mémoire.
  1. Arrêtez vos charges de travail.
  2. En fonction de votre environnement, réinitialisez les GPU ou redémarrez la VM pour récupérer et reprendre les charges de travail :

Google surveille les seuils d'erreur et envoie l'appareil en réparation lorsque le GPU nécessite une réparation ou un remplacement physique.
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
  1. Arrêtez vos charges de travail.
  2. En fonction de votre environnement, réinitialisez les GPU ou redémarrez la VM pour récupérer et reprendre les charges de travail :

Lorsque la banque de remappage est épuisée (All reserved rows for bank are remapped), Google détecte que le GPU peut être remplacé par un autre matériel et envoie la machine en réparation de manière proactive.

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
  1. Arrêtez vos charges de travail.
  2. En fonction de votre environnement, réinitialisez les GPU ou redémarrez la VM pour récupérer et reprendre les charges de travail :

Google envoie la machine en réparation si la banque de remappage est épuisée ou lorsque le GPU nécessite une réparation ou un remplacement physique.
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.

Aucun
Xid 94: Contained error

Indique qu'une erreur de GPU s'est produite et si elle était limitée à une seule application.

Seul, le Xid 94 n'indique pas la cause première de l'erreur. Il doit être interprété en même temps que d'autres erreurs Xid simultanées afin de déterminer la cause fondamentale.
  1. Comme l'erreur s'est produite dans une seule application, redémarrez-la pour la corriger.
  2. Si nécessaire, réinitialisez les GPU ou arrêtez vos charges de travail.
  3. Examinez les autres erreurs Xid qui se produisent en même temps pour connaître les étapes de récupération supplémentaires et déterminer la cause première.

Aucun
Xid 95: Uncontained error

Indique qu'une erreur de GPU s'est produite et n'était pas limitée à une seule application.

Seul, le Xid 95 n'indique pas la cause première de l'erreur. Il doit être interprété en même temps que d'autres erreurs Xid simultanées pour déterminer la cause fondamentale.
  1. Étant donné que l'erreur n'a pas été contenue, arrêtez vos charges de travail et réinitialisez les GPU ou redémarrez la VM pour la corriger.
  2. Examinez les autres erreurs Xid simultanées pour déterminer la cause première sous-jacente et les étapes de récupération supplémentaires.

Aucun

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 Action du client Action Google
Xid 119: GSP RPC timeout
  1. Arrêtez vos charges de travail.
  2. Consultez les branches de pilotes NVIDIA recommandées pour vous assurer d'utiliser une branche compatible et une version de pilote récente ou la plus récente. En effet, les bugs de pilote dans les versions antérieures sont une cause majeure d'erreurs GSP.
  3. Si l'erreur persiste après avoir vérifié ou mis à jour votre pilote, supprimez et recréez la VM. Si l'erreur persiste, collectez le rapport de bug NVIDIA et déposez une demande auprès du Cloud Customer Care.

Aucune. Si l'erreur persiste et que vous déposez une demande d'assistance, Google examine l'état du matériel ou du pilote via le workflow d'assistance.
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 :

Message d'erreur Xid Action du client Action Google

Xid 13: Graphics Engine Exception

Xid 31: GPU memory page fault

Xid 137: Memory access fault

Une violation d'accès à la mémoire a été détectée, analogue à un défaut de segmentation. Ces erreurs indiquent généralement un bug d'application où la mémoire GPU est consultée hors limites ou sur des tampons libérés, comme le déréférencement d'un pointeur non valide ou d'un tableau hors limites. Elles ne représentent pas d'erreurs ECC, sauf si le Xid 48 est également présent.

Pour résoudre ce problème, déboguez les erreurs d'accès à la mémoire dans votre application. Vous pouvez utiliser cuda-gdb, Compute Sanitizer ou cuda-memcheck.

Pour en savoir plus, consultez la documentation NVIDIA Xid.

Aucune. Dans de rares cas où la dégradation du matériel peut entraîner des erreurs d'accès illégal à la mémoire signalées à tort, vous pouvez utiliser le gestionnaire de GPU du centre de données NVIDIA (DCGM) pour exécuter dcgmi diag -r 3 ou dcgmi diag -r 4 pour différents niveaux de couverture et de durée des tests. Si vous identifiez un problème matériel, déposez une demande auprès du service client.

Autres messages d'erreur Xid courants

Message d'erreur Xid Action du client Action Google
Xid 74: NVLINK error
  1. Arrêtez vos charges de travail.
  2. Réinitialisez les GPU.

Aucun
Xid 79: GPU has fallen off the bus

Cela signifie que le pilote ne peut pas communiquer avec le GPU, car un problème matériel a entraîné la disparition du GPU du bus PCI.

Pour récupérer vos charges de travail, utilisez l'une des approches suivantes, selon que la maintenance d'urgence est activée ou non pour votre projet :

  • Demander une maintenance d'urgence : si une maintenance d'urgence est déployée dans votre projet, déclenchez l'événement de maintenance à votre convenance.
  • Attendre la maintenance automatique : sinon, attendez un événement de maintenance non planifié directement sur l'instance.

Google détecte que le GPU n'est plus sur le bus PCI et envoie la machine en réparation.
Xid 109: Context switch timeout

L'erreur Xid 109 est une erreur générique signalée par le pilote de GPU NVIDIA. Elle est générée lorsqu'une instance de GPU ne parvient pas à préempter ou à changer de tâche dans le délai d'attente prévu.

Google a une longue expérience dans l'étude de l'erreur Xid 109 avec NVIDIA. Les causes connues liées à des bugs de pilote sont corrigées dans les derniers pilotes. Le code d'erreur 109 n'est pas dû à un problème matériel.
  1. Arrêtez vos charges de travail.
  2. En fonction de votre environnement, réinitialisez les GPU ou redémarrez la VM pour récupérer et reprendre les charges de travail :
  3. Envisagez de passer à une version plus récente du pilote NVIDIA pour votre environnement, par exemple en installant le dernier pilote sur votre VM Compute Engine ou en mettant à niveau votre DaemonSet de pool de nœuds/pilotes GKE.

Aucun
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.
  1. Arrêtez vos charges de travail.
  2. Réinitialisez les GPU.

Aucun

Résoudre les échecs nvidia-smi après l'application de correctifs à l'OS ou la mise à niveau du noyau

Si nvidia-smi échoue avec NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver après un intervalle de maintenance, une exécution de correctifs OS ou un redémarrage de VM, vérifiez les mises en attente de votre package de noyau. Les verrous de package d'une installation de pilote précédente en mode binary peuvent empêcher l'installation des en-têtes de noyau correspondants.

Pour diagnostiquer et résoudre ce problème, sélectionnez votre système d'exploitation :

Ubuntu

  1. Vérifiez la version du noyau en cours d'exécution :

    uname -r

  2. Vérifiez si une installation de pilote précédente en mode binary a verrouillé les packages du noyau, par exemple lorsque vous utilisez des instances de calcul --force-version, --installation-branch=lts ou NVIDIA RTX Virtual Workstation (vWS) :

    apt-mark showhold

    Vérifiez si linux-image-gcp ou linux-headers-gcp est listé.

  3. Vérifiez si les en-têtes de noyau sont installés pour le noyau en cours d'exécution :

    dpkg -l | grep "linux-headers-$(uname -r)"

  4. Si les méta-packages du noyau sont retenus, supprimez les verrous de package :

    sudo apt-mark unhold linux-image-gcp linux-headers-gcp

  5. Installez les en-têtes du noyau en cours d'exécution :

    sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)

  6. Recompilez et chargez le module de noyau NVIDIA :

    • Si les sources du module DKMS sont enregistrées (vérifiez sudo dkms status) :

      sudo dkms autoinstall
sudo modprobe nvidia
nvidia-smi

    • Si sudo dkms status n'affiche aucun module NVIDIA enregistré (par exemple, si le pilote a été installé précédemment à l'aide d'un binaire .run sans --dkms), réexécutez le programme d'installation du pilote de GPU Google Cloud  :

      sudo python3 cuda_installer.pyz install_driver

Debian

  1. Vérifiez la version du noyau en cours d'exécution :

    uname -r

  2. Vérifiez si une installation de pilote précédente en mode binary a verrouillé les packages du noyau, par exemple lorsque vous utilisez des instances de calcul --force-version, --installation-branch=lts ou NVIDIA RTX Virtual Workstation (vWS) :

    apt-mark showhold

    Vérifiez si linux-image-cloud-amd64 ou linux-headers-cloud-amd64 est listé.

  3. Vérifiez si les en-têtes de noyau sont installés pour le noyau en cours d'exécution :

    dpkg -l | grep "linux-headers-$(uname -r)"

  4. Si les méta-packages du noyau sont retenus, supprimez les verrous de package :

    sudo apt-mark unhold linux-image-cloud-amd64 linux-headers-cloud-amd64

  5. Installez les en-têtes du noyau en cours d'exécution :

    sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)

  6. Recompilez et chargez le module de noyau NVIDIA :

    • Si les sources du module DKMS sont enregistrées (vérifiez sudo dkms status) :

      sudo dkms autoinstall
sudo modprobe nvidia
nvidia-smi

    • Si sudo dkms status n'affiche aucun module NVIDIA enregistré (par exemple, si le pilote a été installé précédemment à l'aide d'un binaire .run sans --dkms), réexécutez le programme d'installation du pilote de GPU Google Cloud  :

      sudo python3 cuda_installer.pyz install_driver

RHEL et Rocky Linux

  1. Vérifiez la version du noyau en cours d'exécution :

    uname -r

  2. Vérifiez si une installation de pilote précédente en mode binary a verrouillé les packages du noyau, par exemple lorsque vous utilisez des instances de calcul --force-version, --installation-branch=lts ou NVIDIA RTX Virtual Workstation (vWS) :

    grep "^exclude=.*kernel" /etc/dnf/dnf.conf

  3. Vérifiez si les en-têtes de noyau sont installés pour le noyau en cours d'exécution :

    rpm -qa | grep "kernel-devel-$(uname -r)"

  4. Si les packages du noyau sont exclus, supprimez kernel* de la ligne exclude= dans /etc/dnf/dnf.conf.

  5. Installez les en-têtes du noyau en cours d'exécution :

    sudo dnf install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r)

  6. Recompilez et chargez le module de noyau NVIDIA :

    • Si les sources du module DKMS sont enregistrées (vérifiez sudo dkms status) :

      sudo dkms autoinstall
sudo modprobe nvidia
nvidia-smi

    • Si sudo dkms status n'affiche aucun module NVIDIA enregistré (par exemple, si le pilote a été installé précédemment à l'aide d'un binaire .run sans --dkms), réexécutez le programme d'installation du pilote de GPU Google Cloud  :

      sudo python3 cuda_installer.pyz install_driver

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, A2 et G4 avec un ou plusieurs GPU associés, redémarrez la VM.
  • Pour les VM G4 avec des GPU fractionnés (moins d'un GPU associé), procédez comme suit :
    1. Supprimez la VM.
    2. Recréez la VM.
  • Pour les instances A3, A4, A4X et A4X Max, 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.
  • Pour les instances A3, A4, A4X et A4X Max sur les nœuds GKE, vous pouvez également utiliser l'outil gpu-reset-tool pour automatiser la réinitialisation de tous les GPU sur un nœud. Cet outil ne nécessite que vous spécifiiez le nom du nœud cible.

Vous pouvez également réinitialiser les GPU lorsque vous réinitialisez une VM ou arrêtez et redémarrez une VM. Pour en savoir plus sur les états du cycle de vie des VM et sur les différences entre les actions de récupération des VM, consultez Cycle de vie des instances Compute Engine et Suspendre, arrêter ou réinitialiser des instances Compute Engine.

Ouvrir un dossier d'assistance

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

  • ID du projet dans lequel se trouvent les instances concernées.
  • 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ésultats des vérifications de l'état du matériel (dcgmi, nvidia-smi).
  • La commande exacte du benchmark ou de la 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 Générer un rapport de bug NVIDIA pour les GPU Blackwell.
  • Détails sur les modifications récentes apportées à votre environnement avant l'échec.

Étapes suivantes

Consultez la section types de machines GPU.