En esta guía se describe cómo diagnosticar y resolver problemas habituales de las máquinas virtuales de Compute Engine que tienen GPUs conectadas, incluidos los errores de hardware y los cuellos de botella de rendimiento.
Solucionar problemas de máquinas virtuales con GPU mediante NVIDIA DCGM
NVIDIA Data Center GPU Manager (DCGM) es un paquete de herramientas para gestionar y monitorizar las GPUs de centros de datos de NVIDIA en entornos de clústeres.
Para usar DCGM para solucionar problemas en tu entorno de GPU, sigue estos pasos:
- Asegúrate de que estás usando el controlador de NVIDIA recomendado más reciente para el modelo de GPU que está conectado a tu VM. Para consultar las versiones de los controladores, consulta Versiones recomendadas de controladores de NVIDIA.
- Asegúrate de haber instalado la versión más reciente de DCGM. Para instalar la versión más reciente, consulta el artículo sobre la instalación de DCGM.
Diagnosticar problemas
Cuando ejecutas un comando de diagnóstico de dcgmi, los problemas que se notifican incluyen los pasos que debes seguir para pasar a la acción con el problema. En el siguiente ejemplo se muestra el resultado procesable del comando 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
}
]
}
.........
En el fragmento de salida anterior, puedes ver que GPU 0 tiene retiradas de páginas pendientes debido a un error no recuperable. El resultado proporcionó el error_id único y consejos sobre cómo depurar el problema. En este ejemplo de resultado, te recomendamos que vacíes la GPU y reinicies la VM. En la mayoría de los casos, seguir las instrucciones de esta sección de la salida puede ayudar a resolver el problema.
Solucionar problemas de rendimiento de las GPUs de las máquinas virtuales A3
La serie de máquinas A3 está disponible con GPUs NVIDIA H200 o H100. Esta serie incluye los tipos de máquina A3 Ultra (H200), A3 Mega (H100), A3 High (H100) y A3 Edge (H100).
Identificar un nodo defectuoso
Las tareas de entrenamiento o de comparativas a gran escala en un clúster de GPUs de varios nodos pueden dejar de responder o tener un rendimiento deficiente. Esto suele ocurrir porque uno o varios nodos tienen un rendimiento inferior y ralentizan toda la operación. En esta sección se describe cómo identificar un nodo o un host defectuosos, ya sea ejecutando una prueba comparativa de NCCL o analizando los registros de NCCL.
Ejecutar prueba de comparativa de NCCL
Para identificar el grupo de nodos que provoca el fallo, prueba sistemáticamente subconjuntos de tu clúster con comparativas de NCCL, como all_reduce_perf.
- Para identificar tus conjuntos de nodos, agrupa tus nodos en conjuntos lógicos, como particiones en Slurm.
- Para crear archivos de host, crea un archivo de host independiente para cada conjunto de nodos, donde se indiquen los nombres de host y el número de GPUs por nodo. El número de ranuras que especifiques dependerá del número de GPUs de tu tipo de máquina virtual A3. Por ejemplo, las máquinas virtuales
a3-highgpu-8gtienen 8 GPUs, por lo que debes especificarslots=8. - Para ejecutar comparativas, ejecuta la comparativa
all_reduce_perfen cada conjunto de nodos por separado.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_NODEHaz los cambios siguientes:
HOSTFILE_NAME: el nombre del archivo de host que contiene la lista de nodos y el número de GPUs por nodo del conjunto de nodos.TOTAL_PROCESSES: número total de procesos de MPI que se van a lanzar en todos los hosts del conjunto de nodos.NUM_GPUS_PER_NODE: el número de GPUs por nodo. Para todos los tipos de máquinas A3, este valor es8.
- Para analizar los resultados, si un trabajo se bloquea o muestra un ancho de banda de bus (
busbw) significativamente menor en un conjunto de nodos concreto, es probable que ese conjunto sea defectuoso. - Para subdividir, si un conjunto de nodos es defectuoso, divide su archivo de host por la mitad y vuelve a probar para acotar la búsqueda binaria hasta que identifiques el nodo que no funciona correctamente.
Analizar registros de NCCL
Si el método de comparativas no identifica un nodo, analiza los registros detallados de NCCL.
- Para habilitar el registro de depuración, define las siguientes variables de entorno en la sesión de shell en la que quieras ejecutar tu carga de trabajo:
export NCCL_DEBUG=INFO export NCCL_DEBUG_SUBSYS=INIT,NET,COLL export NCCL_DEBUG_FILE="LOG_DIRECTORY/nccl_log.%h.%p"Sustituye
Si se defineLOG_DIRECTORYpor el directorio en el que quieras almacenar tus registros.NCCL_DEBUG_FILEcon%hy%p, se crean archivos de registro únicos y no intercalados para cada proceso.Si ejecutas una carga de trabajo de varios nodos con
mpirun, propaga estas variables a todos los nodos con la marca-x. Por ejemplo:mpirun -x NCCL_DEBUG -x NCCL_DEBUG_SUBSYS -x NCCL_DEBUG_FILE ... - Para encontrar el primer error, usa el siguiente comando para encontrar los eventos de tiempo de espera agotado o de fallo más antiguos en todos los archivos de registro:
grep "NCCL WARN.*NET/FasTrak" LOG_DIRECTORY/* | sed 's/.*NET\/FasTrak\(.*\)/\1/g' \ | sort | head -n 20Sustituye
LOG_DIRECTORYpor el directorio donde se almacenan tus registros. - Para contar las operaciones colectivas, un nodo rezagado completa menos operaciones colectivas. Contar
"opCount"entradas de clasificaciones sospechosas:grep "opCount" LOG_DIRECTORY/nccl_log.HOSTNAME.PID | wc -lHaz los cambios siguientes:
LOG_DIRECTORY: el directorio donde se almacenan tus registrosHOSTNAME: el nombre de host del nodoPID: el ID de proceso del proceso de NCCL
- Para recoger más datos de registro antes de que se cancele una tarea, aumenta temporalmente el tiempo de espera de la transferencia de datos:
export NCCL_FASTRAK_DATA_TRANSFER_TIMEOUT_MS=3600000
Monitorizar la limitación térmica de la GPU
Las VMs de la serie A3 pueden experimentar una degradación del rendimiento si alcanzan de forma constante temperaturas superiores a 87 °C con carga. Para comprobar si hay limitaciones térmicas de la GPU en los nodos de un clúster, usa nvidia-smi o dcgmi.
Usar nvidia-smi
Para comprobar la temperatura actual y el estado de limitación de todas las GPUs de un nodo, ejecuta el siguiente comando:
nvidia-smi --query-gpu=timestamp,name,pci.bus_id,temperature.gpu,clocks_throttle_reasons.hw_slowdown --format=csv
En el resultado, un valor de Active en la columna clocks_throttle_reasons.hw_slowdown indica que la GPU se está limitando debido a las altas temperaturas.
Usar dcgmi
El paquete de diagnóstico de NVIDIA Data Center GPU Manager (DCGM) incluye comprobaciones de infracciones térmicas. Para ejecutar un diagnóstico de nivel 1, ejecuta el siguiente comando:
dcgmi diag -r 1
Si aparece Warn o Fail en la sección Thermal, significa que se ha producido una infracción térmica durante la prueba. Si una infracción térmica va acompañada de una limitación de la frecuencia de reloj, es probable que la GPU se esté sobrecalentando y requiera más investigación.
Errores de Xid
Después de crear una VM que tenga GPUs conectadas, debes instalar los controladores de dispositivos NVIDIA en tus VMs de GPU para que tus aplicaciones puedan acceder a las GPUs. Sin embargo, a veces estos controladores devuelven mensajes de error.
Un mensaje Xid es un informe de errores del controlador de NVIDIA que se muestra en el registro del kernel del sistema operativo o en el registro de eventos de tu VM de Linux. Estos mensajes se colocan en el archivo /var/log/messages. Para obtener más información sobre los mensajes Xid, incluidas las posibles causas, consulta la documentación de NVIDIA.
Cómo gestiona Google los errores de Xid
Google usa comprobaciones de estado pasivas para evaluar los sistemas de GPU. Si se indica que se debe sustituir el hardware, Google iniciará automáticamente el mantenimiento de emergencia. Google detecta los errores de Xid y envía de forma proactiva las máquinas a reparar cuando los códigos de error indican una alta probabilidad de fallo de hardware, como los errores de Xid 74, 79 y 140. En el caso de algunos códigos Xid, como pueden deberse a problemas de software o de hardware, Google utiliza la coincidencia de patrones para activar las reparaciones, por lo que no todas las incidencias se reparan automáticamente.
Tipos de errores de Xid
En la siguiente lista se describen las tres categorías principales de errores de Xid y las acciones de recuperación recomendadas:
Errores de aplicación: indican problemas en el código de la aplicación. Entre los errores de aplicación se incluyen los Xids, como Xid 13, 31, 94, 95 y 137, que indican varios tipos de infracciones de acceso a la memoria, similares a un fallo de segmentación. No indican un error de ECC. Para solucionar estos errores, NVIDIA recomienda usar uno de los siguientes métodos de depuración:
- Depuración directa: ejecuta la aplicación directamente en cuda-gdb o ejecuta la herramienta memcheck de Compute Sanitizer.
- Depuración posterior a la excepción: ejecuta la aplicación con
CUDA_DEVICE_WAITS_ON_EXCEPTION=1. Cuando se produce una excepción, el controlador de la GPU congela el estado de la aplicación sin salir para que puedas adjuntar un depurador más tarde (cuda-gdb -p <PID>) e inspeccionar el rastreo de la pila en tiempo real.
Errores de controladores: indican problemas causados por el controlador de la GPU NVIDIA. Para solucionar estos errores, asegúrate de que estás usando la versión más reciente del controlador de NVIDIA. Google monitoriza estos errores y colabora con NVIDIA para corregir los controladores.
Errores de firmware o hardware recuperables: indican errores de firmware o hardware que se pueden recuperar sin sustituir el hardware. Para resolver estos errores, aplica medidas de recuperación manuales, como restablecer la GPU o reiniciar la instancia. Entre los errores de firmware o hardware recuperables se incluyen los errores de código de corrección de errores (ECC) (aplicables a Xids como Xid 48, 63 y 64) que indican varias fases de detección y mitigación de errores de ECC. Para obtener más información sobre la retirada de páginas y la mitigación de errores de ECC, consulta las preguntas frecuentes sobre la retirada dinámica de páginas de NVIDIA.
Revisar mensajes de Xid
Para diagnosticar rápidamente por qué una carga de trabajo de GPU ha fallado, ha dejado de responder o ha experimentado una degradación del rendimiento, consulta los registros de kernel de tu instancia (dmesg o /var/log/kern.log) para ver los códigos de error numéricos de NVIDIA Xid.
Consultar las tablas de errores de Xid en las siguientes secciones te ayudará a:
- Identificar la causa principal: determina si el fallo se debe a un error de la aplicación (como un acceso no permitido a la memoria), un conflicto de controladores o un fallo de hardware físico (como errores de memoria ECC de doble bit).
- Determinar la propiedad operativa: comprueba qué medidas de recuperación manual inmediatas debes aplicar, como restablecer las GPUs, reiniciar las VMs o ejecutar depuradores, en comparación con las acciones de reparación automatizada y sustitución de hardware que Google gestiona activamente en el host.
- Sigue los pasos de recuperación correctos: evita procedimientos innecesarios de solución de problemas y sabe exactamente cuándo es suficiente con una recuperación manual y cuándo debes informar de que el host está defectuoso. A veces, la recuperación manual no es suficiente. Por ejemplo, si el origen del error está en la caché de la GPU (SRAM), que no se puede reasignar, lo que se indica mediante
Xid 48conSRAM Threshold Exceeded=Yes, o si la GPU ha agotado su banco de reasignación, lo que se indica medianteXid 64: All reserved rows for bank are remapped. En estos casos, Google detecta que la GPU es apta para la sustitución del hardware y envía la máquina a reparar de forma proactiva. Si tus cargas de trabajo presentan errores recurrentes o si observas fallos de memoria repetidos, puedes informar del host defectuoso para iniciar la reparación o la sustitución automatizadas. En el caso de GKE, consulta cómo informar de hosts defectuosos en GKE.
Gestión de Xid
En las siguientes secciones se agrupan los mensajes de error de Xid habituales por categoría técnica, junto con sus resoluciones y responsabilidades autorizadas:
- Errores de memoria de GPU (Xids
48,63,64,92,94,95) - Errores del procesador del sistema de GPU (GSP) (Xids
119,120) - Errores de acceso ilegal a la memoria (Xids
13,31,137) - Otros mensajes de error de Xid habituales (Xids
74,79,109,149)
Errores de memoria de la GPU
La memoria de la GPU es la memoria disponible en una GPU que se puede usar para almacenar datos temporalmente. La memoria de la GPU está protegida con el código de corrección de errores (ECC), que detecta y corrige los errores de un solo bit (SBE), y detecta y notifica los errores de doble bit no corregibles (DBE).
Se espera que estos errores de memoria se produzcan durante la vida útil de una GPU. Antes del lanzamiento de las GPUs NVIDIA A100, se admitía la retirada dinámica de páginas. En el caso de las GPUs NVIDIA A100 y versiones posteriores (como NVIDIA H100), se introduce la recuperación de errores de reasignación de filas para los errores de HBM (DRAM). El ECC está habilitado de forma predeterminada y Google recomienda encarecidamente mantenerlo habilitado.
En la siguiente tabla se enumeran los errores de memoria de GPU habituales y las soluciones sugeridas:
| Mensaje de error de Xid | Acción de un cliente | Acción de Google |
|---|---|---|
Xid 48: Double Bit ECC
El ECC ha detectado un error de memoria de doble bit (no corregible). Este error siempre interrumpe la carga de trabajo en ejecución y genera el Xid 48. |
|
Google monitoriza cuándo se puede sustituir el hardware de la GPU (por ejemplo, si se ha agotado el banco de reasignación de HBM o si la GPU supera el umbral de errores de SRAM de su vida útil) y envía la máquina de forma proactiva para que se repare y se sustituya la GPU. |
Xid 63: ECC page retirement or row remapping recording
event
Indica que se ha registrado un evento de retirada de página dinámica o de reasignación de filas debido a un error de memoria. |
|
Google monitoriza los umbrales de error y envía la máquina a reparar cuando la GPU requiere una reparación física o una sustitución. |
Xid 64: ECC page retirement or row remapper recording
failure
El mensaje contiene la siguiente información: Xid 64: All reserved rows for bank are remapped
|
|
Cuando se agota el banco de reasignación ( |
Si recibes al menos dos de los siguientes mensajes de Xid juntos:
El mensaje contiene la siguiente información: Xid XX: row remap pending
|
|
Google envía la máquina a reparar si el banco de reasignación se ha agotado o cuando la GPU requiere una reparación o sustitución física. |
Xid 92: High single-bit ECC error rate |
Este mensaje de Xid se devuelve después de que el controlador de la GPU corrija un error corregible y no debería afectar a tus cargas de trabajo. Este mensaje de Xid es meramente informativo. No tienes que hacer nada. |
Ninguno |
Xid 94: Contained error
Indica que se ha producido un error de GPU y si el error se ha producido en una sola aplicación. Por sí solo, el Xid 94 no indica la causa raíz del error, sino que debe interpretarse junto con otros errores de Xid que se produzcan simultáneamente para determinar la causa fundamental. |
|
Ninguno |
Xid 95: Uncontained error
Indica que se ha producido un error de GPU que no se ha limitado a una sola aplicación. Por sí solo, el Xid 95 no indica la causa raíz del error, sino que debe interpretarse junto con otros errores de Xid que se produzcan al mismo tiempo para determinar la causa fundamental. |
|
Ninguno |
Errores de GSP
Un procesador de sistema de GPU (GSP) es un microcontrolador que se ejecuta en GPUs y gestiona algunas de las funciones de gestión de hardware de bajo nivel.
| Mensaje de error de Xid | Acción de un cliente | Acción de Google |
|---|---|---|
Xid 119: GSP RPC timeout |
|
Ninguno Si el error persiste y presentas un caso de asistencia, Google investigará el estado del hardware o del controlador a través del flujo de trabajo de asistencia. |
Xid 120: GSP error |
Errores de acceso ilegal a la memoria
Se devuelven los siguientes XIDs cuando las aplicaciones tienen fallos de acceso ilegal a la memoria:
| Mensaje de error de Xid | Acción de un cliente | Acción de Google |
|---|---|---|
|
Se ha detectado una infracción de acceso a la memoria, similar a un fallo de segmentación. Estos errores suelen indicar un fallo de la aplicación por el que se accede a la memoria de la GPU fuera de los límites o en búferes liberados, como la desreferenciación de un puntero no válido o un array fuera de los límites. No representan errores de ECC a menos que también esté presente el Xid 48. |
Para solucionar este problema, depura los fallos de acceso a la memoria de tu aplicación. Puedes usar cuda-gdb, Compute Sanitizer o cuda-memcheck. Para obtener más información, consulta la documentación de NVIDIA Xid. |
Ninguno En casos excepcionales en los que la degradación del hardware pueda provocar errores de acceso ilegal a la memoria, puedes usar NVIDIA Data Center GPU Manager (DCGM) para ejecutar |
Otros mensajes de error de Xid habituales
| Mensaje de error de Xid | Acción de un cliente | Acción de Google |
|---|---|---|
Xid 74: NVLINK error |
|
Ninguno |
Xid 79: GPU has fallen off the bus
Esto significa que el controlador no puede comunicarse con la GPU porque un problema de hardware ha provocado que la GPU desaparezca del bus PCI. |
Para recuperar tus cargas de trabajo, usa uno de los siguientes métodos, en función de si el mantenimiento de emergencia está habilitado en tu proyecto:
|
Google detecta que la GPU se ha caído del bus PCI y envía la máquina a reparar. |
Xid 109: Context switch timeout
Xid 109 es un error genérico que registra el controlador de la GPU de NVIDIA y que se genera cuando una instancia de GPU no puede adelantarse o cambiar de tarea dentro del periodo de tiempo de espera previsto. Google lleva mucho tiempo investigando el error Xid 109 con NVIDIA, y las causas conocidas de los errores de los controladores se han corregido en los controladores más recientes. El error Xid 109 no se debe a un problema de hardware. |
|
Ninguno |
Xid 149 que mencione 0x02a, como en el siguiente ejemplo:
Esto indica que hay un problema conocido que afecta al firmware de las GPUs NVIDIA B200. |
|
Ninguno |
Solucionar un fallo de nvidia-smi después de aplicar un parche al SO o de actualizar el kernel
Si nvidia-smi falla con NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver después de una ventana de mantenimiento, una ejecución de parches del SO o un reinicio de la VM, comprueba los paquetes de kernel retenidos. Los bloqueos de paquetes de una instalación de controladores anterior en el modo binary pueden impedir la instalación de los encabezados de kernel correspondientes.
Para diagnosticar y solucionar este problema, selecciona tu sistema operativo:
Ubuntu
Comprueba la versión del kernel que se está ejecutando:
uname -rComprueba si una instalación anterior del controlador en modo
binaryha bloqueado los paquetes del kernel, como cuando usas instancias de computación--force-version,--installation-branch=ltso NVIDIA RTX Virtual Workstation (vWS):apt-mark showholdComprueba si aparece
linux-image-gcpolinux-headers-gcp.Comprueba si las cabeceras del kernel están instaladas en el kernel que se está ejecutando:
dpkg -l | grep "linux-headers-$(uname -r)"Si los metapaquetes del kernel están retenidos, elimina los bloqueos de paquetes:
sudo apt-mark unhold linux-image-gcp linux-headers-gcpInstala las cabeceras del kernel que se está ejecutando:
sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)Recompila y carga el módulo de kernel de NVIDIA:
Si las fuentes del módulo DKMS están registradas (comprueba
sudo dkms status):sudo dkms autoinstall sudo modprobe nvidia nvidia-smiSi
sudo dkms statusno muestra ningún módulo de NVIDIA registrado (por ejemplo, si el controlador se ha instalado anteriormente con un binario.runsin--dkms), vuelve a ejecutar el instalador del controlador de GPU Google Cloud :sudo python3 cuda_installer.pyz install_driver
Debian
Comprueba la versión del kernel que se está ejecutando:
uname -rComprueba si una instalación anterior del controlador en modo
binaryha bloqueado los paquetes del kernel, como cuando usas instancias de computación--force-version,--installation-branch=ltso NVIDIA RTX Virtual Workstation (vWS):apt-mark showholdComprueba si aparece
linux-image-cloud-amd64olinux-headers-cloud-amd64.Comprueba si las cabeceras del kernel están instaladas en el kernel que se está ejecutando:
dpkg -l | grep "linux-headers-$(uname -r)"Si los metapaquetes del kernel están retenidos, elimina los bloqueos de paquetes:
sudo apt-mark unhold linux-image-cloud-amd64 linux-headers-cloud-amd64Instala las cabeceras del kernel que se está ejecutando:
sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)Recompila y carga el módulo de kernel de NVIDIA:
Si las fuentes del módulo DKMS están registradas (comprueba
sudo dkms status):sudo dkms autoinstall sudo modprobe nvidia nvidia-smiSi
sudo dkms statusno muestra ningún módulo de NVIDIA registrado (por ejemplo, si el controlador se ha instalado anteriormente con un binario.runsin--dkms), vuelve a ejecutar el instalador del controlador de GPU Google Cloud :sudo python3 cuda_installer.pyz install_driver
RHEL y Rocky Linux
Comprueba la versión del kernel que se está ejecutando:
uname -rComprueba si una instalación anterior del controlador en modo
binaryha bloqueado los paquetes del kernel, como cuando usas instancias de computación--force-version,--installation-branch=ltso NVIDIA RTX Virtual Workstation (vWS):grep "^exclude=.*kernel" /etc/dnf/dnf.confComprueba si las cabeceras del kernel están instaladas en el kernel que se está ejecutando:
rpm -qa | grep "kernel-devel-$(uname -r)"Si se excluyen los paquetes de kernel, elimina
kernel*de la líneaexclude=en/etc/dnf/dnf.conf.Instala las cabeceras del kernel que se está ejecutando:
sudo dnf install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r)Recompila y carga el módulo de kernel de NVIDIA:
Si las fuentes del módulo DKMS están registradas (comprueba
sudo dkms status):sudo dkms autoinstall sudo modprobe nvidia nvidia-smiSi
sudo dkms statusno muestra ningún módulo de NVIDIA registrado (por ejemplo, si el controlador se ha instalado anteriormente con un binario.runsin--dkms), vuelve a ejecutar el instalador del controlador de GPU Google Cloud :sudo python3 cuda_installer.pyz install_driver
Solución de problemas de arranque seguro
Si instalas el controlador de NVIDIA en una instancia de computación con el arranque seguro habilitado y nvidia-smi no puede comunicarse con el controlador de NVIDIA, es posible que el arranque seguro bloquee la carga del módulo de kernel sin firmar.
Para diagnosticar y solucionar este problema, sigue estos pasos:
Comprueba si el arranque seguro ha rechazado el módulo de kernel porque falta la firma o no es válida:
sudo dmesg | grep -iE 'secure boot|nvidia'
Si el arranque seguro ha bloqueado el módulo, firma manualmente los módulos de controladores y registra tu clave de propietario de la máquina (MOK), o bien usa una imagen de SO con módulos de kernel firmados previamente. Para obtener instrucciones, consulta el artículo Instalar controladores de GPU (VMs con arranque seguro).
Restablecer GPUs
Es posible que tengas que restablecer las GPUs para solucionar algunos problemas. Para restablecer las GPUs, sigue estos pasos:
- En el caso de las máquinas virtuales N1, G2, A2 y G4 con una o varias GPUs conectadas, reinicia la máquina virtual.
- En el caso de las máquinas virtuales G4 con GPUs fraccionarias (menos de una GPU conectada), sigue estos pasos:
- En el caso de las instancias A3, A4, A4X y A4X Max, ejecuta
sudo nvidia-smi --gpu-reset.- En la mayoría de las VMs de Linux, el ejecutable
nvidia-smise encuentra en el directorio/var/lib/nvidia/bin. - En el caso de los nodos de GKE, el ejecutable
nvidia-smise encuentra en el directorio/home/kubernetes/bin/nvidia.
- En la mayoría de las VMs de Linux, el ejecutable
- En el caso de las instancias A3, A4, A4X y A4X Max en nodos de GKE, también puedes usar la herramienta gpu-reset-tool para automatizar el restablecimiento de todas las GPUs de un nodo. Esta herramienta solo requiere que especifiques el nombre del nodo de destino.
También se restablecen las GPUs cuando restableces una VM o cuando detienes y reinicias una VM. Para obtener más información sobre los estados del ciclo de vida de las máquinas virtuales y las diferencias entre las acciones de recuperación de máquinas virtuales, consulta Ciclo de vida de las instancias de Compute Engine y Suspender, detener o restablecer instancias de Compute Engine.
Enviar una solicitud de asistencia
Si no puedes resolver los problemas siguiendo las instrucciones de esta página, reúne la siguiente información y abre un caso de asistencia:
- ID del proyecto en el que se encuentran las instancias afectadas.
- Lista de todos los nombres o IDs de instancia del clúster.
- Lista de nodos sospechosos identificados mediante la solución de problemas.
- Registros de NCCL completos y no intercalados con los ajustes de depuración habilitados.
- Resultados de las comprobaciones del estado del hardware (
dcgmi,nvidia-smi). - Comando de comparativa o de carga de trabajo exacto que está fallando.
- Archivos de registro pertinentes, como los registros de diagnóstico y del motor de host. Para recogerlos, ejecuta
gather-dcgm-logs.sh, que se encuentra en/usr/local/dcgm/scriptsen las instalaciones predeterminadas. - Informe de errores de NVIDIA. Ejecuta
nvidia-bug-report.sh. En el caso de las GPUs Blackwell, sigue las instrucciones de la sección Generar un informe de errores de NVIDIA para GPUs Blackwell. - Detalles sobre los cambios recientes que se hayan hecho en tu entorno antes del fallo.
Siguientes pasos
Consulta los tipos de máquinas con GPU.