Conservar el primer fallo y su contexto
Esta guía comienza tras un lanzamiento exitoso: PyTorch ve el dispositivo y luego tu aplicación falla en un batch o un operador. Si ningún cálculo pequeño funciona, vuelve al diagnóstico inicial. En caso contrario, conserva el primer error, el número de iteración y el último paso completado. Una sucesión de mensajes tras el primer fallo puede describir sus consecuencias en lugar de varias causas independientes.
Anota la revisión del código, las versiones de Python y PyTorch, el backend, el tipo numérico y las formas de las entradas. Para los datos, prefiere un identificador interno y las dimensiones a una copia íntegra del contenido. Busca lo que distingue al batch defectuoso: longitud, objetivo ausente, último lote incompleto, aumento o rama poco usada. Este expediente permite rehacer el caso sin relanzar toda una campaña.
Localizar el lanzamiento defectuoso pese al asincronismo
En CUDA, algunas operaciones se encolan y pueden terminar después de que la función de Python retorne. Por eso, un error que surge durante una copia a CPU o una lectura de escalar puede provenir de un cálculo anterior. La documentación de PyTorch explica esta ejecución asíncrona. La línea indicada por la traza es un punto de observación que hay que examinar, no siempre la causa.
Para una reproducción corta en NVIDIA/CUDA, propón un lanzamiento separado con CUDA_LAUNCH_BLOCKING=1. Esta opción hace síncronas las llamadas y puede acercar el error a su origen. Sirve para el diagnóstico, no para la medición de tiempos. También puedes colocar sincronizaciones provisionales entre las grandes etapas para reducir el intervalo sospechoso. Retira después esta instrumentación: modifica la planificación habitual.
El siguiente comando es didáctico y no se ha ejecutado. Supone una terminal POSIX y un script train.py existente. La asignación se aplica solo a este lanzamiento; adapta la sintaxis a tu shell. No generalices esta variable de NVIDIA a una pila ROCm.
CUDA_LAUNCH_BLOCKING=1 python train.pyLeer una familia de errores sin concluir demasiado rápido
El mensaje reduce el campo de búsqueda; no sustituye a un caso reproducible. Un índice fuera de dominio, un tensor en el dispositivo equivocado y una asignación imposible requieren verificaciones distintas. Mantén la distinción entre datos inválidos, contrato del operador y entorno binario. Cambiar simultáneamente el batch, la precisión y las bibliotecas elimina esa distinción.
Tras una aserción ejecutada en el dispositivo, no intentes continuar el mismo entrenamiento en el mismo proceso. NVIDIA indica que cudaErrorAssert invalida las asignaciones existentes y obliga a terminar y relanzar el proceso. En un notebook, esto implica reiniciar el kernel antes de la reproducción corregida. Reiniciar no corrige, sin embargo, ni un objetivo erróneo ni un índice inválido.
Desplaza la tabla para leer todas las columnas.| Indicio observado | Primera verificación | Conclusión que evitar |
|---|---|---|
| device-side assert | Índices, objetivos y condiciones del operador | La GPU está forzosamente defectuosa |
| Out of memory | Formas, tiempo de vida de los tensores, memoria del proceso | Todo error de CUDA es falta de VRAM |
| Operador o kernel no disponible | Versiones, extensión, backend y dtype | Reinstalar todo al azar |
| Dispositivos diferentes | Ubicación del modelo y de cada entrada | Añadir una copia sin entender su origen |
Ejemplo trabajado: una clase 4 en un problema de cuatro clases
Tomemos un clasificador didáctico cuya salida tiene cuatro columnas. Sus clases están indexadas de 0 a 3. Un archivo de anotaciones que contenga el valor 4 puede revelar una codificación de 1 a 4 o una quinta clase inesperada. Aumentar simplemente el tamaño de salida haría desaparecer una restricción sin resolver el significado de las anotaciones.
La comprobación propuesta a continuación se aplica antes de transferir los objetivos a CPU. No se ha ejecutado. Ilustra el contrato de CrossEntropyLoss para índices de clases de tipo long, con ignore_index=-100 elegido explícitamente. No cubre los objetivos formados por distribuciones de probabilidad. En este escenario, [0, 2, 4] debe rechazarse; este resultado esperado se deduce de la regla, no se presenta como una medida.
Corrige después el mapping en la preparación de los datos y controla su biyección con los nombres de clases. No restes 1 en todas partes mientras no sepas si todas las fuentes usan la misma convención. Añade el caso defectuoso a un pequeño conjunto de verificación conservado con el proyecto.
import torch
classes = 4
ignore_index = -100
target = torch.tensor([0, 2, 4], dtype=torch.long)
if target.ndim != 1 or target.dtype != torch.long:
raise ValueError("Cibles : vecteur d’indices attendu")
valid = target[target != ignore_index]
if valid.numel() == 0:
raise ValueError("Aucune cible exploitable dans ce batch")
if bool(((valid < 0) | (valid >= classes)).any()):
raise ValueError("Indice de classe hors domaine")Reducir el programa sin borrar el desencadenante
Reproduce primero una sola entrada o un solo batch con las mismas transformaciones. Elimina el seguimiento remoto, la escritura de resultados y las ramas sin relación con el fallo. Conserva el dtype, las formas y el operador sospechosos. Si el error depende de una longitud o de una disposición de memoria concreta, un tensor arbitrario de tamaño pequeño puede que ya no lo reproduzca.
Compara una modificación a la vez: extensión opcional desactivada, operador de referencia, precisión habitual o incluso la misma operación en CPU cuando exista allí. Un éxito en CPU es un indicio, no una validación de CUDA. Para una función personalizada, anota también las hipótesis sobre strides, contigüidad y tamaños. Busca un ejemplo que falle antes de la corrección y funcione después, con una verificación de salida en lugar de solo la ausencia de excepción.
Verificar la corrección en el alcance inicial
Una corrección aceptable debe superar el caso mínimo, los casos vecinos y una porción representativa del recorrido original. Retoma en particular el último batch, una entrada corta, una entrada larga y los valores límite del mapping. Comprueba que los elementos rechazados sean identificables y que el número de entradas procesadas siga siendo el esperado. Ignorar silenciosamente las excepciones puede transformar un crash visible en un resultado incompleto.
Quita el modo de diagnóstico, parte de un proceso nuevo y confirma el comportamiento con la configuración normal. Conserva la causa, el cambio aplicado y el control de no regresión. Si habías interrumpido un entrenamiento, parte de un checkpoint coherente validado antes del error; la presencia de un archivo escrito durante un fallo no basta para garantizar su reanudación.
Saber cuándo pedir un análisis más específico
Si el mismo caso mínimo falla con entradas válidas, prepara una solicitud precisa: operación, formas, tipos, backend, versiones y primer mensaje relevante. Elimina los identificadores personales y las rutas innecesarias. Una extensión binaria puede necesitar su propia matriz de compatibilidad; el soporte general de PyTorch no valida automáticamente esa extensión.
En ROCm, PyTorch conserva la interfaz torch.cuda y los nombres de dispositivo cuda. Comprueba torch.version.hip para identificar esta pila antes de aplicar un procedimiento NVIDIA. Los mensajes, las herramientas y las opciones de diagnóstico pueden diferir. Ningún control descrito aquí demuestra la compatibilidad de los entornos preparados con una oferta de Kernodeck; usa estos criterios para precisar tu necesidad antes de elegir la GPU.