AWS incorpora 3 comprobaciones al entrenamiento de modelos para detectar errores silenciosos de las GPU

El entrenamiento avanza, la curva de pérdida tiene el aspecto habitual y las GPU no notifican problemas. Sin embargo, un acelerador ya ha calculado un número incorrecto y las demás réplicas del modelo lo han incorporado a la actualización conjunta. El equipo sigue consumiendo tiempo de cómputo, aunque el resultado del entrenamiento podría haberse deteriorado. AWS ha explicado cómo buscar estos fallos dentro del propio bucle de entrenamiento de PyTorch DDP: repetir parte de los cálculos en otro nodo y comparar los resultados.

Es un análisis técnico útil para los equipos que entrenan modelos en varios nodos con GPU. Incluye código para las comprobaciones y un procedimiento de recuperación mediante SageMaker HyperPod. La idea principal va más allá de un proveedor de nube concreto: que no haya advertencias de hardware no significa que los cálculos sean correctos.

Cómo un error se propaga a todas las réplicas

En el entrenamiento con paralelismo de datos, varias réplicas del modelo procesan distintos lotes de ejemplos. Después, el sistema calcula la media de sus gradientes, los valores que se utilizan para actualizar los pesos. Cada réplica recibe el mismo valor medio y realiza la misma actualización.

Supongamos que tres GPU calculan gradientes de 0,20, 0,40 y 0,30. La media es 0,30. Pero si un fallo hace que el segundo acelerador devuelva 4,00 en lugar de 0,40, las tres réplicas recibirán una media incorrecta. Tras la actualización, sus pesos seguirán coincidiendo. Una simple comparación entre réplicas indicará que todo está en orden, aunque el error ya se haya propagado.

Las comprobaciones habituales protegen otras partes del sistema. Las de memoria ayudan a detectar datos corruptos en la memoria; las de red, errores de transmisión. La suma de comprobación de un modelo guardado confirma la integridad del archivo. Sin embargo, un archivo escrito correctamente puede contener pesos corrompidos por un cálculo anterior.

Para ilustrar la magnitud del problema, AWS cita datos del entrenamiento de Llama 3 405B: durante 54 días, Meta atribuyó a la corrupción silenciosa de datos seis de las 419 interrupciones inesperadas. Esta estadística recoge los casos detectados que pudieron vincularse a un fallo y no revela la frecuencia de todos los errores que pasan inadvertidos.

Tres comprobaciones en el bucle de entrenamiento

La primera comprobación busca NaN e Inf en los gradientes locales antes de calcular la media y después verifica el resultado de esa operación antes de actualizar los pesos. Así se puede detener el paso antes de que un valor claramente incorrecto pase a formar parte del modelo. Pero un número como 4,00 parece perfectamente válido y superará esta comprobación.

Para detectarlo hace falta la segunda comprobación: en determinados pasos, cada GPU vuelve a procesar un microlote de otro nodo. Si los mismos datos y condiciones producen resultados diferentes, hay motivos para investigar. Se comparan el valor de la función de pérdida y unas huellas compactas de los gradientes. El sistema necesita un tercer nodo para resolver las comparaciones ambiguas.

La tercera comprobación se ejecuta después de la actualización: compara las huellas de los pesos de las distintas réplicas del modelo. Si una réplica difiere de una mayoría estricta, se puede identificar la instancia sospechosa. Esta comprobación se realiza periódicamente y antes de guardar un punto de control, para evitar que la corrupción detectada quede incorporada a la siguiente copia guardada.

Cuando se genera una alerta, el equipo detiene el entrenamiento, identifica el nodo al que pertenece el proceso sospechoso e impide que se le asignen nuevas tareas. Después examina las métricas, ejecuta pruebas de diagnóstico si es necesario y sustituye el nodo tras revisarlo. La propuesta es reanudar el entrenamiento desde un punto de control guardado antes del intervalo sospechoso.

Qué tener en cuenta antes de implantarlo

AWS probó la solución en cuatro nodos con 32 GPU NVIDIA H100, inyectando errores por software. Las pruebas también se repitieron en tres nodos, el mínimo que requiere el sistema propuesto. Estos ensayos muestran cómo se comportan las comprobaciones en los escenarios definidos, pero no demuestran que puedan detectar cualquier fallo de hardware.

También hay puntos ciegos concretos. Un número finito incorrecto generado dentro de la operación de cálculo de la media puede superar todas las comprobaciones. La repetición de cálculos solo verifica determinados pasos y requiere datos reproducibles; la comparación de gradientes también depende de cálculos deterministas. Que las huellas compactas coincidan constituye un indicio sólido de que los tensores son iguales, pero no una demostración matemática.

La conclusión práctica: en los entrenamientos distribuidos costosos conviene comprobar los propios resultados de los cálculos y preparar la recuperación de antemano. Se puede empezar buscando NaN e Inf antes de actualizar y guardar. Después, medir el coste de repetir cálculos con la carga de trabajo propia y decidir con qué frecuencia realizar la auditoría. Los puntos de control deben almacenarse fuera del nodo que pueda sustituirse: sus discos locales se destruyen al reemplazarlo.