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 y solucionar problemas en tu entorno de GPU, haz lo siguiente:
- 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 las versiones recomendadas de los controladores de NVIDIA.
- Asegúrate de que has instalado la versión más reciente de DCGM. Para instalar la última versión, consulta 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 para 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 del resultado puede ayudar a resolver el problema.
Solucionar problemas de rendimiento de la GPU en 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
Los trabajos de entrenamiento o de creación 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 una máquina host defectuosos ejecutando una prueba de referencia de NCCL o analizando los registros de NCCL.
Ejecutar la prueba de comparativas 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 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 MPI que se van a iniciar en todos los hosts del conjunto de nodos.NUM_GPUS_PER_NODE: el número de GPUs por nodo. En 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 los registros.NCCL_DEBUG_FILEcon%hy%p, se crearán archivos de registro únicos y no entrelazados para cada proceso.Si ejecutas una carga de trabajo de varios nodos con
mpirun, propaga estas variables a todos los nodos mediante 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 buscar 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. Recuento de entradas de
"opCount"para 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 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 máquinas virtuales de la serie A3 pueden experimentar una degradación del rendimiento si alcanzan constantemente temperaturas superiores a 87 °C bajo carga. Para comprobar si se produce limitación térmica 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 velocidad 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 o de eventos del sistema operativo de tu VM de Linux. Estos mensajes se colocan en el archivo /var/log/messages. Para obtener más información sobre los mensajes de 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 inicia el mantenimiento de emergencia automáticamente. Google detecta errores de Xid y envía de forma proactiva las máquinas a reparación cuando los códigos de error indican una alta probabilidad de fallo de hardware, como 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 Compute Sanitizer memcheck.
- 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 controlador: 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 que se pueden recuperar 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 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é ha fallado una carga de trabajo de GPU, ha dejado de responder o ha experimentado una degradación del rendimiento, consulta los registros del kernel de tu instancia (dmesg
o /var/log/kern.log) para ver los códigos de error numéricos Xid de NVIDIA.
Consultar las tablas de errores de Xid de las siguientes subsecciones te ayudará de inmediato:
- Identificar la causa principal: determina si el fallo se debe a un error de la aplicación (como un acceso no autorizado a la memoria), un conflicto de controladores o un fallo de hardware físico (como errores de memoria ECC de doble bit).
- Determina la propiedad operativa: comprueba qué medidas de recuperación manual inmediata 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 con precisión cuándo es suficiente la 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 cumple los requisitos para sustituir el hardware y envía la máquina a reparar de forma proactiva. Si tus cargas de trabajo tienen errores recurrentes o si observas fallos de memoria repetidos, puedes informar del host defectuoso para iniciar la reparación o la sustitución automáticas. 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 soluciones 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,109y149)
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 un código de corrección de errores (ECC), que detecta y corrige errores de un solo bit (SBE) y detecta e informa de errores de dos bits incorregibles (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 las versiones de GPU NVIDIA A100 y posteriores (como NVIDIA H100), se ha introducido 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 indican 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 o sustitución física. |
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 al mismo tiempo para determinar la causa fundamental. |
|
Ninguno |
Xid 95: Uncontained error
Indica que se ha producido un error de GPU y que no se ha limitado a una sola aplicación. . Por sí solo, el error Xid 95 no indica la causa principal del error, sino que debe interpretarse junto con otros errores 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 presenta 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 error de la aplicación en 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 una matriz 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 a memoria ilegales, 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 desconectado del bus PCI y envía la máquina a reparación. |
Xid 109: Context switch timeout
Xid 109 es un error genérico que informa el controlador de la GPU de NVIDIA. Se genera cuando una instancia de GPU no puede interrumpir o cambiar tareas en el periodo de tiempo de espera esperado. Google lleva mucho tiempo investigando el Xid 109 con NVIDIA. 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 problemas de nvidia-smi tras aplicar un parche al SO o 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 parcheado del SO o un reinicio de la VM, comprueba las retenciones de paquetes del kernel. Los bloqueos de paquetes de una instalación de controlador anterior en modo binary pueden impedir la instalación de encabezados de kernel coincidentes.
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 de--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 (consulta
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 de 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 de un 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 (consulta
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 de 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 de--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 del kernel, quite
kernel*de la líneaexclude=en/etc/dnf/dnf.conf.Instala los encabezados del kernel del kernel en ejecución:
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 de los módulos 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 previamente con un binario.runsin--dkms), vuelve a ejecutar el instalador del controlador de GPU de 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 Arranque seguro habilitado y nvidia-smi no puede comunicarse con el controlador de NVIDIA, es posible que Arranque seguro impida que se cargue el módulo del kernel sin firma.
Para diagnosticar y resolver 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 Instalar controladores de GPU (VMs con arranque seguro).
Restablecer GPUs
Es posible que algunos problemas requieran que restablezcas tus GPUs. Para restablecer las GPUs, sigue estos pasos:
- En el caso de las VMs N1, G2, A2 y G4 con una o varias GPUs conectadas, reinicia la VM.
- En el caso de las máquinas virtuales G4 con GPUs fraccionarias (menos de una GPU conectada), sigue estos pasos:
- En las instancias A3, A4, A4X y A4X Max, ejecuta
sudo nvidia-smi --gpu-reset.- En la mayoría de las máquinas virtuales Linux, el ejecutable
nvidia-smise encuentra en el directorio/var/lib/nvidia/bin. - En los nodos de GKE, el ejecutable
nvidia-smise encuentra en el directorio/home/kubernetes/bin/nvidia.
- En la mayoría de las máquinas virtuales Linux, el ejecutable
- En el caso de las instancias A3, A4, A4X y A4X Max de los 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 de proyecto 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 exacto de la prueba de rendimiento o de la carga de trabajo que falla.
- Archivos de registro relevantes, como los registros del motor del host y de diagnóstico. 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 realizado en tu entorno antes del fallo.
Siguientes pasos
Consulta los tipos de máquinas con GPU.