En esta guía, se describe cómo diagnosticar y resolver problemas comunes con las VMs de Compute Engine que tienen GPUs conectadas, incluidos los errores de hardware y los cuellos de botella de rendimiento.
Soluciona problemas de VMs de GPU con NVIDIA DCGM
El administrador de GPU del centro de datos de NVIDIA (DCGM) es un conjunto de herramientas para administrar y supervisar las GPU del centro de datos de NVIDIA en entornos de clústeres.
Para usar DCGM y solucionar problemas en tu entorno de GPU, completa los siguientes pasos:
- Asegúrate de usar el controlador NVIDIA más reciente recomendado para el modelo de GPU conectado a tu VM. Para revisar las versiones de controlador, consulta Versiones recomendadas de controladores NVIDIA.
- Asegúrate de haber 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 dcgmi, los problemas que informa la herramienta de diagnóstico incluyen los siguientes pasos para tomar medidas. En el siguiente ejemplo, se muestra el resultado práctico 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 resultado anterior, puedes ver que GPU 0 tiene retiradas de páginas pendientes que se deben a un error no recuperable. El resultado proporcionó el error_id único y consejos para depurar el problema. Para este resultado de ejemplo, te recomendamos que desví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.
Soluciona problemas de rendimiento de la GPU en VMs A3
La serie de máquinas A3 está disponible con GPU NVIDIA H200 o H100 conectadas. Esta serie incluye los tipos de máquinas A3 Ultra (H200), A3 Mega (H100), A3 High (H100) y A3 Edge (H100).
Cómo identificar un nodo defectuoso
Los trabajos de entrenamiento o de comparativas a gran escala en un clúster de GPU de varios nodos pueden dejar de responder o tener un rendimiento deficiente. Esto suele ocurrir porque uno o más 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 anfitrión defectuosos ejecutando una prueba de comparativa de NCCL o analizando los registros de NCCL.
Ejecuta la prueba de comparativa de NCCL
Para identificar el grupo de nodos que causa la falla, 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, por ejemplo, particiones en Slurm.
- Para crear archivos host, crea un archivo host independiente para cada conjunto de nodos, en el que se indiquen los nombres de host y la cantidad de GPUs por nodo. La cantidad de ranuras que especifiques dependerá del recuento de GPU de tu tipo de VM A3. Por ejemplo, las VMs
a3-highgpu-8gtienen 8 GPUs, por lo que debes especificarslots=8. - Para ejecutar comparativas, ejecuta la comparativa
all_reduce_perfen cada conjunto de nodos de forma individual.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_NODEReemplaza lo siguiente:
HOSTFILE_NAME: Es el nombre del archivo host que contiene la lista de nodos y la cantidad de GPUs por nodo para el conjunto de nodos.TOTAL_PROCESSES: Es la cantidad total de procesos de MPI que se iniciarán en todos los hosts del conjunto de nodos.NUM_GPUS_PER_NODE: es la cantidad de GPU 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 del bus significativamente menor (
busbw) en un conjunto de nodos en particular, es probable que ese conjunto esté defectuoso. - Para subdividir, si un conjunto de nodos es defectuoso, divide su archivo de host por la mitad y vuelve a realizar la prueba para reducir la búsqueda binaria hasta que identifiques el nodo individual que no funciona correctamente.
Analiza los registros de NCCL
Si el método de comparativa no identifica un nodo, analiza los registros detallados de NCCL.
- Para habilitar el registro de depuración, establece las siguientes variables de entorno en la sesión de shell en la que planeas 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"Reemplaza
EstablecerLOG_DIRECTORYpor el directorio en el que deseas almacenar tus registros.NCCL_DEBUG_FILEcon%hy%pcrea 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 o falla 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 20Reemplaza
LOG_DIRECTORYpor el directorio en el que se almacenan tus registros. - Para contar las operaciones colectivas, un nodo rezagado completa menos operaciones colectivas. Recuento de entradas
"opCount"para los rangos de sospechosos:grep "opCount" LOG_DIRECTORY/nccl_log.HOSTNAME.PID | wc -lReemplaza lo siguiente:
LOG_DIRECTORY: Es el directorio en el que se almacenan tus registros.HOSTNAME: Es el nombre de host del nodo.PID: Es el ID del proceso de NCCL.
- Para recopilar más datos de registro antes de que se anule un trabajo, aumenta temporalmente el tiempo de espera de transferencia de datos:
export NCCL_FASTRAK_DATA_TRANSFER_TIMEOUT_MS=3600000
Supervisa la regulación térmica de la GPU
Las VMs de la serie A3 pueden experimentar una degradación del rendimiento si alcanzan temperaturas superiores a 87 °C de forma constante bajo carga. Para verificar si hay estrangulamiento térmico de la GPU en los nodos de un clúster, usa nvidia-smi o dcgmi.
Cómo usar nvidia-smi
Para verificar la temperatura actual y el estado de limitación de todas las GPUs en 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.
Uso de dcgmi
El paquete de diagnóstico del administrador de GPU del centro de datos de NVIDIA (DCGM) incluye verificaciones de incumplimientos térmicos. Para ejecutar un diagnóstico de nivel 1, ejecuta el siguiente comando:
dcgmi diag -r 1
Un resultado de Warn o Fail en la sección Thermal indica que se produjo un incumplimiento térmico durante la prueba. Si un incumplimiento térmico se acompaña de una reducción de la velocidad de reloj, es probable que la GPU se esté sobrecalentando y requiera una investigación adicional.
Errores de Xid
Después de crear una VM que tenga GPU conectadas, debes instalar los controladores del dispositivo NVIDIA en tus VMs con GPU para que tus aplicaciones puedan acceder a las GPU. Sin embargo, a veces estos controladores muestran mensajes de error.
Un mensaje Xid es un informe de error del controlador de NVIDIA que se imprime en el registro del kernel del sistema operativo o en el registro de acontecimientos de la 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 maneja Google los errores de Xid
Google usa verificaciones de estado pasivas para evaluar los sistemas de GPU. Si se indica el reemplazo de hardware, Google inicia automáticamente el mantenimiento de emergencia. Google detecta errores de Xid y envía máquinas de forma proactiva a reparación cuando los códigos de error indican una alta probabilidad de falla de hardware, como Xid 74, 79 y 140. En el caso de algunos códigos de Xid, ya que pueden deberse a problemas de software o hardware, Google usa la correlación de patrones para activar las reparaciones, por lo que no todas las ocurrencias generan una reparación automática.
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 la aplicación: Indican problemas dentro del código de la aplicación. Los errores de la aplicación incluyen Xids como Xid 13, 31, 94, 95 y 137, que indican varios tipos de incumplimiento de acceso a la memoria, similar a un error de segmentación. Estos no indican un error de ECC. Para solucionar estos errores, NVIDIA recomienda usar uno de los siguientes enfoques 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 inmoviliza el estado de la aplicación sin salir de ella para que puedas adjuntar un depurador más tarde (cuda-gdb -p <PID>) y, así, inspeccionar el seguimiento de pila en vivo.
Errores del controlador: Indican problemas causados por el controlador de la GPU de NVIDIA. Para resolver estos errores, asegúrate de usar la versión más reciente del controlador de NVIDIA. Google supervisa estos errores y colabora con NVIDIA para corregir los controladores.
Errores recuperables de firmware o hardware: Indican errores de firmware o hardware que permiten la recuperación sin reemplazo de hardware. Para resolver estos errores, aplica medidas de recuperación manuales, como restablecer la GPU o reiniciar la instancia. Los errores recuperables de firmware o hardware incluyen errores de código corrector de errores (ECC) (aplicables a Xids como Xid 48, 63 y 64) que indican varias etapas de detección y mitigación de errores de ECC. Para obtener más información sobre el retiro de páginas y la mitigación de errores de ECC, consulta las Preguntas frecuentes sobre el retiro dinámico de páginas de NVIDIA.
Revisa los mensajes de Xid
Para diagnosticar rápidamente por qué falló una carga de trabajo de GPU, dejó de responder o experimentó una degradación del rendimiento, consulta los registros del kernel de tu instancia (dmesg o /var/log/kern.log) para ver si hay códigos de error numéricos de NVIDIA Xid.
Revisar las tablas de errores de Xid en las siguientes subsecciones te ayudará de inmediato:
- Identifica la causa raíz: Determina si la falla se debe a un error de la aplicación (como un acceso ilegal a la memoria), un conflicto de controladores o una falla física del hardware (como errores de memoria ECC de doble bit).
- Determina la propiedad operativa: Verifica qué medidas de recuperación manual inmediatas debes aplicar, como restablecer GPUs, reiniciar VMs o ejecutar depuradores, en comparación con las acciones de reparación automatizada y reemplazo de hardware que Google administra de forma activa en el host.
- Toma las medidas de recuperación correctas: Evita procedimientos innecesarios para solucionar problemas y conoce con precisión cuándo es suficiente la recuperación manual y cuándo debes informar que el host es defectuoso. A veces, la recuperación manual no es suficiente, por ejemplo, si la fuente del error se encuentra en la caché de la GPU (SRAM), que no se puede reasignar, lo que se indica con
Xid 48ySRAM Threshold Exceeded=Yes, o si la GPU agotó su banco de reasignación, lo que se indica conXid 64: All reserved rows for bank are remapped. En estos casos, Google detecta que la GPU es apta para el reemplazo de hardware y envía la máquina a reparación de forma proactiva. Si tus cargas de trabajo tienen errores recurrentes o si observas fallas de memoria repetidas, puedes informar sobre el host defectuoso para iniciar la reparación o el reemplazo automáticos. En el caso de GKE, consulta Cómo informar hosts defectuosos en GKE.
Manejo de Xid
En las siguientes secciones, se agrupan los mensajes de error comunes de Xid por categoría técnica, junto con sus resoluciones y responsabilidades definitivas:
- Errores de memoria de la GPU (Xids
48,63,64,92,94,95) - Errores del procesador del sistema de la GPU (GSP) (Xids
119,120) - Errores de acceso ilegal a la memoria (XIDs
13,31,137) - Otros mensajes de error comunes de Xid (Xids
74,79,109,149)
Errores de memoria de GPU
La memoria de GPU es la memoria disponible en una GPU que se puede usar para el almacenamiento temporal de datos. La memoria de GPU está protegida con el código de corrección de errores (ECC), que detecta y corrige errores de un solo bit (SBE) y detecta y también informa errores de doble bit no corregibles (DBE).
Se espera que estos errores de memoria ocurran durante la vida útil de una GPU. Antes del lanzamiento de las GPU NVIDIA A100, se admitía la retirada dinámica de páginas. Para las versiones de GPU NVIDIA A100 y posteriores (como NVIDIA H100), se presenta la recuperación de error de reasignación de fila para los errores de HBM (DRAM). ECC está habilitado de forma predeterminada, y Google recomienda mantenerlo habilitado.
En la siguiente tabla, se enumeran los errores comunes de memoria de GPU y sus soluciones sugeridas:
| Mensaje de error de Xid | Acción del cliente | Acción de Google |
|---|---|---|
Xid 48: Double Bit ECC
El ECC detectó 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 supervisa cuándo la GPU es apta para el reemplazo de hardware, por ejemplo, si se agotó el banco de reasignación de HBM o si la GPU supera el umbral de errores de SRAM durante su vida útil, y envía de forma proactiva la máquina a reparación para reemplazar la GPU. |
Xid 63: ECC page retirement or row remapping recording
event
Indica que se registró un evento de baja de página dinámica o de reasignación de filas debido a un error de memoria. |
|
Google supervisa los umbrales de error y envía la máquina a reparación cuando la GPU requiere reparación o reemplazo físico. |
Xid 64: ECC page retirement or row remapper recording
failure
Y 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 obtienes al menos dos de los siguientes mensajes Xid juntos:
Y el mensaje contiene la siguiente información: Xid XX: row remap pending
|
|
Google envía la máquina a reparación si se agota el banco de reasignación o cuando la GPU requiere reparación o reemplazo físico. |
Xid 92: High single-bit ECC error rate |
Este mensaje Xid se muestra después de que el controlador de GPU corrige un error corregible y no debería afectar tus cargas de trabajo. Este mensaje Xid solo es informativo. No se requiere ninguna acción. |
Ninguno |
Xid 94: Contained error
Indica si se produjo un error de GPU y si el error se limitó a una sola aplicación. Por sí solo, el Xid 94 no indica la causa raíz del error. 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 produjo un error en la GPU y que no se limitó a una sola aplicación. Por sí solo, el Xid 95 no indica la causa raíz del error. Debe interpretarse junto con otros errores de Xid que se produzcan simultáneamente para determinar la causa fundamental. |
|
Ninguno |
Errores del GSP
Un procesador del sistema de GPU (GSP) es un microcontrolador que se ejecuta en GPU y controla algunas de las funciones de administración de hardware de bajo nivel.
| Mensaje de error de Xid | Acción del 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 no permitido a la memoria
Los siguientes Xids se muestran cuando las aplicaciones tienen fallas de acceso no permitido a la memoria:
| Mensaje de error de Xid | Acción del cliente | Acción de Google |
|---|---|---|
|
Se detectó un incumplimiento de acceso a la memoria, análogo a un error de segmentación. Por lo general, estos errores indican 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 un array fuera de los límites. Estos no representan errores de ECC, a menos que también esté presente el Xid 48. |
Para resolver este problema, depura las fallas de acceso a la memoria en tu aplicación. Puedes usar cuda-gdb, Compute Sanitizer o cuda-memcheck. Para obtener más detalles, consulta la documentación de NVIDIA Xid. |
Ninguno En casos excepcionales en los que la degradación del hardware podría causar errores de acceso a la memoria ilegales informados de forma incorrecta, puedes usar el administrador de GPU del centro de datos de NVIDIA (DCGM) para ejecutar |
Otros mensajes de error comunes de Xid
| Mensaje de error de Xid | Acción del 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 hizo que la GPU desapareciera del bus PCI. |
Para recuperar tus cargas de trabajo, usa uno de los siguientes enfoques, según si la emergencia de mantenimiento está habilitada para tu proyecto:
|
Google detecta que la GPU se desconectó 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 y que se genera cuando una instancia de GPU no puede interrumpir o cambiar tareas dentro del período de tiempo de espera esperado. Google tiene un largo historial de investigación del Xid 109 con NVIDIA, y las causas conocidas de errores del controlador se corrigieron en los controladores más recientes. El XID 109 no se debe a un problema de hardware. |
|
Ninguno |
Xid 149 que menciona 0x02a, como en el siguiente ejemplo:
Esto indica un problema conocido que afecta el firmware de las GPU NVIDIA B200. |
|
Ninguno |
Soluciona problemas de fallas de nvidia-smi después de aplicar parches 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 un período de mantenimiento, una ejecución de aplicación de parches del SO o un reinicio de la VM, verifica las retenciones del paquete del kernel. Los bloqueos de paquetes de una instalación anterior del controlador en modo binary pueden impedir la instalación de encabezados del kernel coincidentes.
Para diagnosticar y resolver este problema, selecciona tu sistema operativo:
Ubuntu
Verifica la versión del kernel en ejecución:
uname -rComprueba si una instalación anterior del controlador en modo
binarybloqueó los paquetes del kernel, por ejemplo, cuando usas instancias de procesamiento de--force-version,--installation-branch=ltso estaciones de trabajo virtuales (vWS) NVIDIA RTX:apt-mark showholdVerifica si aparece
linux-image-gcpolinux-headers-gcp.Verifica si los encabezados del kernel están instalados para el kernel en ejecución:
dpkg -l | grep "linux-headers-$(uname -r)"Si los metapaquetes del kernel están retenidos, quita los bloqueos de paquetes:
sudo apt-mark unhold linux-image-gcp linux-headers-gcpInstala los encabezados del kernel para el kernel en ejecución:
sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)Vuelve a compilar y cargar el módulo del kernel de NVIDIA:
Si se registran fuentes de módulos de DKMS (verifica
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 instaló anteriormente con un archivo binario.runsin--dkms), vuelve a ejecutar el instalador del controlador de GPU Google Cloud :sudo python3 cuda_installer.pyz install_driver
Debian
Verifica la versión del kernel en ejecución:
uname -rComprueba si una instalación anterior del controlador en modo
binarybloqueó los paquetes del kernel, por ejemplo, cuando usas instancias de procesamiento de--force-version,--installation-branch=ltso estaciones de trabajo virtuales (vWS) NVIDIA RTX:apt-mark showholdVerifica si aparece
linux-image-cloud-amd64olinux-headers-cloud-amd64.Verifica si los encabezados del kernel están instalados para el kernel en ejecución:
dpkg -l | grep "linux-headers-$(uname -r)"Si los metapaquetes del kernel están retenidos, quita los bloqueos de paquetes:
sudo apt-mark unhold linux-image-cloud-amd64 linux-headers-cloud-amd64Instala los encabezados del kernel para el kernel en ejecución:
sudo apt-get update && sudo apt-get install -y linux-headers-$(uname -r)Vuelve a compilar y cargar el módulo del kernel de NVIDIA:
Si se registran fuentes de módulos de DKMS (verifica
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 instaló anteriormente con un archivo 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
Verifica la versión del kernel en ejecución:
uname -rComprueba si una instalación anterior del controlador en modo
binarybloqueó los paquetes del kernel, por ejemplo, cuando usas instancias de procesamiento de--force-version,--installation-branch=ltso estaciones de trabajo virtuales (vWS) NVIDIA RTX:grep "^exclude=.*kernel" /etc/dnf/dnf.confVerifica si los encabezados del kernel están instalados para el kernel en ejecución:
rpm -qa | grep "kernel-devel-$(uname -r)"Si se excluyen los paquetes del kernel, quita
kernel*de la líneaexclude=en/etc/dnf/dnf.conf.Instala los encabezados del kernel en ejecución:
sudo dnf install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r)Vuelve a compilar y cargar el módulo del kernel de NVIDIA:
Si se registran fuentes de módulos de DKMS (verifica
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 instaló anteriormente con un archivo binario.runsin--dkms), vuelve a ejecutar el instalador del controlador de GPU Google Cloud :sudo python3 cuda_installer.pyz install_driver
Restablece las GPU
Algunos problemas pueden requerir que restablezcas tus GPU. Para restablecer las GPU, completa los siguientes pasos:
- Para las VMs N1, G2, A2 y G4 con una o más GPUs conectadas, reinicia la VM.
- Para las VMs G4 con GPUs fraccionarias (menos de una GPU conectada), completa los siguientes pasos:
- Para 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 gpu-reset-tool para automatizar el restablecimiento de todas las GPUs en un nodo. Esta herramienta solo requiere que especifiques el nombre del nodo de destino.
Como alternativa, las GPUs también se restablecen cada vez que restableces una VM o detienes y reinicias una VM. Para obtener más información sobre los estados del ciclo de vida de VM y las diferencias entre las acciones de recuperación de VM, consulta Ciclo de vida de la instancia de Compute Engine y Suspende, detén o restablece instancias de Compute Engine.
Abre un caso de asistencia
Si no puedes resolver los problemas con la guía de esta página, recopila la siguiente información y abre un caso de ayuda:
- ID del proyecto en el que se encuentran las instancias afectadas.
- Lista de todos los nombres o IDs de instancias en el clúster.
- Lista de nodos sospechosos identificados a través de la solución de problemas.
- Registros de NCCL completos y no intercalados con la configuración de depuración habilitada
- Resultados de las verificaciones de estado del hardware (
dcgmi,nvidia-smi). - Comando exacto de comparativa o carga de trabajo que falla.
- Archivos de registro pertinentes, como los registros de diagnóstico y del motor del host Para recopilarlos, 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 GPU Blackwell, sigue los pasos que se indican en Cómo generar un informe de errores de NVIDIA para las GPU Blackwell. - Detalles sobre los cambios recientes que se realizaron en el entorno antes de la falla.
¿Qué sigue?
Revisa los tipos de máquinas de GPU.