El entrenamiento NVRx de Amazon EKS reduce la recuperación ante fallos de GPU de minutos a segundos

Amazon EKS ha integrado NVIDIA NVRx en una pila de entrenamiento reproducible que recuperó fallos de GPU inyectados en aproximadamente entre 10 y 17 segundos. El diseño de entrenamiento NVRx de Amazon EKS también mantuvo una eficiencia de checkpoints superior al 99 % en pruebas seleccionadas con entre 16 y 64 GPU H100. Estos resultados cuestionan una suposición costosa: que una recuperación fiable debe comenzar reiniciando contenedores o reconstruyendo todo el trabajo de Kubernetes.

El sistema combina PyTorch Fully Sharded Data Parallel, o FSDP, con tres capacidades diferenciadas de NVRx. Los checkpoints asíncronos alejan las escrituras de almacenamiento del bucle de entrenamiento. El reinicio dentro del proceso reconstruye el estado distribuido sin sustituir el proceso de Python. El componente ft_launcher inicia nuevos workers dentro del trabajo existente después de fallos más graves.

Por tanto, la competición relevante no es AWS frente a otro proveedor de nube. Es la recuperación consciente de la aplicación frente a la recuperación basada únicamente en infraestructura. Kubernetes sigue siendo responsable de la programación y los fallos a nivel de nodo, pero NVRx gestiona los fallos más cerca del proceso de entrenamiento. AWS afirma que esta división reduce drásticamente el tiempo que las GPU sanas y costosas pasan esperando a un par que ha fallado.

El entrenamiento NVRx de Amazon EKS traslada la recuperación al interior del trabajo

El cambio central consiste en que el fallo de un worker ya no tiene que convertirse en un evento completo del ciclo de vida del contenedor.

AWS y NVIDIA construyeron el entorno de referencia en torno a Amazon EKS, grupos de nodos GPU autogestionados y PyTorch FSDP. Su benchmark publicado utilizó instancias p5.48xlarge, cada una con ocho GPU NVIDIA H100 y 80 GB de memoria.

El clúster probado escaló de dos a ocho nodos, o de 16 a 64 GPU. Cada instancia también exponía 32 interfaces Elastic Fabric Adapter para comunicaciones de alto ancho de banda. Amazon FSx for Lustre proporcionó almacenamiento compartido para checkpoints entre los pods de entrenamiento.

NVRx, abreviatura de NVIDIA Resiliency Extension, es un paquete de Python que añade componentes de recuperación y checkpointing a las cargas de trabajo de PyTorch. No requiere una bifurcación de PyTorch, kernels personalizados ni recompilación. Los equipos pueden añadir sus capacidades de forma independiente en lugar de sustituir todo su framework de entrenamiento.

Ese diseño modular es importante porque el rendimiento de los checkpoints y la recuperación ante fallos son problemas distintos. Una carga de trabajo podría necesitar guardados más rápidos sin recuperación de procesos. Otra podría necesitar protección frente a fallos de proceso conservando su implementación actual de checkpoints.

La arquitectura de referencia trata cada capa según el alcance de su fallo. El reinicio dentro del proceso gestiona excepciones y bloqueos de comunicación que mantienen vivo al intérprete de Python. ft_launcher gestiona eventos como SIGKILL, finalizaciones por falta de memoria y algunos bloqueos a nivel de sistema operativo.

Kubernetes sigue siendo la capa exterior para fallos que eliminan un nodo completo. Este enfoque se parece a un conjunto de zonas de recuperación anidadas. Cada mecanismo interviene solo cuando el fallo cruza el límite de la capa situada bajo él.

Los pods de entrenamiento utilizan Services sin encabezado de Kubernetes para el descubrimiento de pares. Los workers se encuentran entre sí mediante DNS en lugar de direcciones IP fijas. Esta disposición ayuda a que los workers de reemplazo regresen sin exigir a los operadores que reescriban la configuración del trabajo.

AWS describió anteriormente el entrenamiento distribuido elástico en EKS mediante herramientas de PyTorch. El trabajo con NVRx acota aún más el ciclo de recuperación. Se centra en mantener productivo un trabajo activo cuando los rangos individuales fallan, se bloquean o desaparecen.

Esta distinción genera la tensión central del artículo. Kubernetes puede restaurar la infraestructura, pero la recuperación de infraestructura carece de conocimiento detallado sobre el estado del modelo, los grupos de procesos y el calendario de checkpoints. NVRx incorpora esas decisiones a la aplicación de entrenamiento.

Los checkpoints bloqueantes consumían alrededor del 40 % del tiempo total

El primer problema de rendimiento no era el cálculo de las GPU. Era el tiempo que cada rango pasaba esperando a que los datos del checkpoint llegaran al almacenamiento.

Un checkpoint síncrono pausa el entrenamiento hasta que se ha escrito el estado requerido del modelo y del optimizador. En un trabajo FSDP distribuido, esa pausa afecta a todos los rangos participantes. Las GPU sanas permanecen asignadas, pero no realizan cálculos forward ni backward durante la escritura.

AWS informó de que los checkpoints síncronos solo produjeron entre un 57 % y un 61 % de eficiencia de entrenamiento en sus pruebas de escalado. Las escrituras de almacenamiento tardaron aproximadamente 275 segundos, y esa duración se mantuvo en términos generales constante entre 16 y 64 GPU. Por tanto, añadir capacidad de cómputo no eliminó la pausa limitada por el almacenamiento.

El checkpointing asíncrono de NVRx modifica la ruta de escritura. El proceso de entrenamiento prepara el estado en la CPU y transfiere el trabajo a un proceso persistente en segundo plano. El proceso principal vuelve entonces al siguiente paso de entrenamiento mientras continúa la E/S de almacenamiento.

La implementación utiliza TorchAsyncCheckpoint y su método async_save(). Antes de iniciar otro guardado, o antes de salir, la aplicación finaliza la operación pendiente. Esa coordinación evita que un checkpoint sin terminar choque silenciosamente con el siguiente.

Los diccionarios de estado locales de FSDP refuerzan el diseño. Cada rango escribe su propio fragmento, evitando una operación all-gather y el cuello de botella de una única escritura del rango cero. La documentación de FSDP de PyTorch describe el modelo de fragmentación más amplio que distribuye los parámetros entre los workers participantes.

Con un intervalo de checkpoint de 1.000 pasos, AWS afirma que el checkpointing asíncrono de NVRx alcanzó una eficiencia de entrenamiento del 99,2 % en dos nodos. La eficiencia llegó al 99,8 % en ocho nodos. La comparación síncrona alcanzó un 60,3 % con ocho nodos.

Estas cifras son resultados de benchmarks reportados por el proveedor, no garantías para todos los modelos o configuraciones de almacenamiento. Aun así, el mecanismo que las sustenta es sencillo. Si el cálculo dura más que la escritura en almacenamiento, la operación en segundo plano puede quedar casi completamente oculta tras trabajo de entrenamiento útil.

El límite quedó claro cuando AWS aumentó la frecuencia de los checkpoints. Con ocho nodos y un checkpoint cada 100 pasos, la eficiencia síncrona cayó al 14,7 %. La eficiencia asíncrona también descendió, pero se mantuvo por encima, en un 29,6 %.

La razón fue la temporización. Cien pasos de entrenamiento tardaron aproximadamente 280 segundos, mientras que la escritura del checkpoint tardó unos 275 segundos. Casi no había ventana de cómputo disponible para ocultar la siguiente operación de almacenamiento.

Este es el límite real del checkpointing asíncrono de NVRx. La E/S asíncrona puede ocultar una escritura tras el cálculo, pero no puede hacer que el almacenamiento sea infinitamente rápido. Cuando los guardados llegan tan rápidamente como el sistema de archivos puede completarlos, la cola acaba ejerciendo presión.

Incluso con esa limitación, la capacidad cambia la forma en que los equipos pueden elegir los intervalos de checkpoint. Los sistemas síncronos fomentan menos checkpoints porque cada guardado impone un tiempo de inactividad visible. Los guardados poco frecuentes aumentan entonces la cantidad de entrenamiento perdida tras un fallo.

El checkpointing asíncrono atenúa esa disyuntiva. Los equipos pueden guardar con mayor frecuencia cuando existe suficiente cálculo entre escrituras. Un intervalo más corto reduce la distancia de reversión, mientras que la E/S solapada preserva una mayor parte de la inversión en GPU.

El resultado no es simplemente una API de checkpoints más rápida. Es un equilibrio distinto entre la eficiencia en estado estable y el progreso recuperable. Ese equilibrio se vuelve más valioso a medida que los trabajos se prolongan e implican más componentes propensos a fallos.

El reinicio dentro del proceso cuestiona el modelo de recuperación basado solo en Kubernetes

La ruta de recuperación más rápida conserva el proceso de Python y reconstruye únicamente los recursos distribuidos dañados por el fallo.

En la implementación de referencia, NVRx envuelve la función principal de entrenamiento con un controlador de reinicio dentro del proceso. Si se produce una excepción compatible, el envoltorio interrumpe el intento activo y prepara otra llamada. El proceso externo de Python permanece activo durante toda esa secuencia.

NVRx primero aborta el grupo de procesos distribuidos de PyTorch dañado. Puede recopilar trazas del registrador de vuelo, detener los backends de NCCL y destruir el grupo no válido. NCCL es la biblioteca de comunicación de NVIDIA para operaciones colectivas entre GPU.

Las comprobaciones de estado examinan después los recursos asociados a cada rango. Esas comprobaciones pueden cubrir la GPU, las conexiones NVLink, las interfaces de red y los fallos repetidos de rangos. Un controlador de reintentos limita los intentos de reinicio y determina cuántos rangos activos deben sobrevivir.

El sistema reasigna los rangos supervivientes a un grupo contiguo e inicia un nuevo rendezvous. La función de entrenamiento envuelta recrea su modelo FSDP, carga el checkpoint más reciente y reanuda el trabajo. El intérprete de Python y los objetos fuera de la función envuelta permanecen disponibles.

Esta técnica se dirige a fallos leves. Entre los ejemplos se incluyen excepciones de aplicación no controladas y bloqueos de NCCL que el watchdog puede detectar. No presupone que una excepción de Python vaya a surgir de forma fiable de cada llamada nativa bloqueada.

En su lugar, un watchdog de progreso registra la actividad entre operaciones de bytecode de Python. Un hilo de monitorización independiente comprueba el estado compartido y puede solicitar un reinicio cuando un rango deja de progresar. A continuación, el sistema coordina la interrupción entre los workers participantes.

AWS comparó este enfoque con ft_launcher y la recuperación de referencia de Kubernetes. El experimento utilizó dos nodos p5.48xlarge, 16 GPU H100 y Llama 3.1 8B bajo FSDP. El trabajo se ejecutó durante 2.000 pasos y guardó cada 500 pasos.

Los investigadores inyectaron cinco fallos deterministas en cada ejecución utilizando el mismo calendario. El reinicio dentro del proceso de NVRx se recuperó en unos 10 segundos por fallo sin reiniciar contenedores. AWS midió un 31 % de goodput de entrenamiento y un 87 % de goodput de infraestructura.

El goodput de entrenamiento mide el tiempo que produce progreso de entrenamiento válido. El goodput de infraestructura mide el tiempo en el que la infraestructura asignada permanece operativa y disponible. La diferencia entre ambos incluye trabajo que no hace avanzar el modelo, incluida la reversión y la carga de checkpoints.

La recuperación de referencia de Kubernetes tardó unos 270 segundos por fallo inyectado. Produjo un 11,5 % de goodput de entrenamiento y un 35,8 % de goodput de infraestructura en el experimento reportado. Esto hace que la comparación vaya más allá de una optimización del inicio de contenedores.

Según AWS, un rango que fallaba activaba tiempos de espera de comunicación en los rangos supervivientes. Los pods se reiniciaban entonces de forma desincronizada, provocando ciclos repetidos de tiempos de espera y comportamiento de CrashLoopBackOff. El orquestador restauraba los contenedores sin comprender cómo debía recuperarse conjuntamente el grupo de entrenamiento distribuido.

La recuperación consciente de la aplicación tiene acceso a ese contexto ausente. Sabe cuándo se detuvo el progreso, qué grupo de procesos dejó de ser válido y qué checkpoint puede reiniciar el entrenamiento. Kubernetes ve el estado de los pods y la salud de los nodos, pero no la semántica completa de un paso de entrenamiento FSDP.

Esto no hace innecesaria la recuperación de Kubernetes. Un nodo inactivo no puede conservar su intérprete, estado de CUDA ni procesos locales. El reemplazo de nodos sigue perteneciendo a la capa de clúster, y los workers recuperados siguen requiriendo datos de checkpoint persistentes.

La presión recae sobre los equipos que dependen de los reinicios de pods como única política de tolerancia a fallos. Ese enfoque sigue siendo sencillo, pero su ventana de recuperación puede desperdiciar una cantidad sustancial de tiempo de aceleradores. Los clústeres más grandes amplifican el coste porque un fallo puede dejar inactivos a muchos workers que, por lo demás, están sanos.

La tolerancia a fallos de NVRx divide los fallos leves y graves

Ningún mecanismo de reinicio único cubre todos los fallos, por lo que la tolerancia a fallos de NVRx separa la recuperación que preserva el proceso del reemplazo de workers.

El componente ft_launcher gestiona fallos que un reinicio dentro del proceso no puede superar. Entre ellos se incluyen SIGKILL, terminaciones por falta de memoria y fallos que no dejan un intérprete de Python utilizable. Sustituye a torchrun y conserva conceptos familiares de rendezvous.

Cada rango de entrenamiento crea un RankMonitorClient tras la inicialización distribuida. El cliente envía señales de vida durante el entrenamiento. Los servidores de monitorización por rango comparan esas señales con los tiempos de espera configurados para condiciones normales y de arranque inicial.

La configuración de AWS utilizó un tiempo de espera de señal de vida por rango de 900 segundos. El tiempo de espera de la señal de vida inicial fue de 1.200 segundos, lo que permitía más tiempo para la primera carga del modelo. Un intervalo de monitorización de cinco segundos controlaba la frecuencia con la que el launcher comprobaba el estado de los workers.

Estos valores son ejemplos de configuración, no recomendaciones universales. El tiempo de espera de una señal de vida debe superar el retraso legítimo más largo entre señales. Si es demasiado corto, los checkpoints lentos o la inicialización del modelo pueden parecer workers fallidos.

Cuando un worker muere o deja de responder, ft_launcher termina los workers restantes. Recupera la memoria de GPU, ejecuta otro rendezvous e inicia procesos nuevos dentro del mismo trabajo. Los nuevos workers restauran el estado desde el checkpoint más reciente.

La guía del launcher muestra el mismo patrón general en la pila NeMo RL de NVIDIA. Esta integración más amplia sugiere que NVRx está concebido como una capa de resiliencia reutilizable, no como una utilidad exclusiva de EKS.

AWS midió unos 17 segundos de recuperación por cada fallo inyectado con ft_launcher. La ejecución reportada alcanzó un goodput de entrenamiento del 25,5 % y un goodput de infraestructura del 85,9 %. Fue más lento que la recuperación dentro del proceso, pero mucho más rápido que la referencia de Kubernetes de 270 segundos.

La diferencia refleja cuánto estado conserva cada método. El reinicio dentro del proceso mantiene activos el intérprete y el proceso externo. ft_launcher debe crear nuevos workers, inicializar el estado distribuido, reconstruir el modelo y recargar un checkpoint.

La carga de checkpoints puede dominar el intervalo de recuperación a mayor escala. Una creación de procesos más rápida no elimina la necesidad de leer los fragmentos del modelo y del optimizador. Por ello, el rendimiento del sistema de archivos compartido sigue formando parte del diseño de tolerancia a fallos.

La arquitectura de entrenamiento NVRx de Amazon EKS utilizó un sistema de archivos FSx for Lustre SCRATCH_2 en la misma zona de disponibilidad que sus nodos de GPU. Esta ubicación buscaba reducir la latencia de lectura de checkpoints. Todos los workers podían acceder al mismo estado persistido tras la recuperación.

El checkpointing asíncrono de NVRx es independiente de ambas rutas de reinicio. Reduce el tiempo inactivo asociado a las escrituras y controla cuánto progreso está en riesgo. La capa de reinicio determina la rapidez con la que los workers regresan tras un fallo.

Esta separación ofrece más opciones a los operadores, pero también añade trabajo de políticas. Deben decidir qué excepciones pueden activar una recuperación dentro del proceso, cuántos reintentos son seguros y qué comprobaciones de salud deben eliminar un rango. También deben establecer los tiempos de espera de señales de vida y rendezvous.

NVIDIA califica el proyecto NVRx como experimental y en desarrollo activo. Su documentación advierte que las funciones y las interfaces pueden cambiar. Los equipos de producción deberían considerar la selección de versiones y las pruebas de actualización como parte del plan de resiliencia.

AWS utilizó NVRx 0.4.1 para reproducir su benchmark. La publicación recomienda la versión 0.6.0 con una configuración de launcher actualizada para una implementación actual. Esta distinción entre versiones importa porque los sistemas de tolerancia a fallos se sitúan directamente en rutas críticas de inicio y recuperación.

Un mecanismo de recuperación fallido puede ser peor que no tener automatización si reinicia repetidamente un trabajo irrecuperable. Los límites de reintentos, el tamaño mínimo del mundo y los contadores de fallos evitan bucles ilimitados. Los operadores siguen necesitando alertas que distingan una recuperación satisfactoria de un fallo recurrente.

El resultado del 99 % tiene límites importantes

El benchmark respalda un mecanismo sólido, pero no establece una eficiencia del 99 % para todas las cargas de trabajo de entrenamiento distribuido.

AWS probó una configuración principal de modelo, Llama 3.1 8B con PyTorch FSDP, en instancias p5 basadas en H100. Utilizó redes EFA y almacenamiento FSx for Lustre. Los distintos tamaños de modelo, rutas de almacenamiento, formatos de checkpoint y duraciones de paso cambiarán la ventana de solapamiento.

La cifra del 99 % se aplica a la eficiencia del checkpointing asíncrono en intervalos seleccionados. No describe el goodput de extremo a extremo bajo fallos repetidos. En las pruebas de fallos inyectados, el goodput de entrenamiento se mantuvo en el 31 % para la recuperación dentro del proceso y en el 25,5 % para ft_launcher.

Estos resultados inferiores no contradicen las mediciones de checkpointing. Responden a una pregunta distinta. La eficiencia asíncrona mide la sobrecarga de checkpoints durante el entrenamiento normal, mientras que el goodput incluye inyección de fallos, reversión, carga y otros trabajos de recuperación.

La frecuencia de los checkpoints también tiene un límite inevitable. Con un checkpoint cada 100 pasos, el entrenamiento asíncrono alcanzó una eficiencia del 29,6 % en lugar del 99 %. El sistema de almacenamiento estuvo ocupado casi de forma continua porque las duraciones de cómputo y escritura eran similares.

La presión de memoria también merece atención. El checkpointing asíncrono prepara los datos fuera de la operación inmediata de la GPU y asigna a un proceso en segundo plano la responsabilidad de las escrituras. Los equipos deberían medir la memoria de CPU, la profundidad de la cola y la acumulación pendiente de almacenamiento con sus diccionarios de estado reales.

La cobertura de recuperación es otro límite. El reinicio dentro del proceso no puede ayudar cuando el sistema operativo termina el worker o el nodo desaparece. ft_launcher puede reemplazar un proceso muerto, pero sigue dependiendo del trabajo, la red del clúster, el servicio de rendezvous y el almacén de checkpoints.

La pérdida de nodos sigue siendo una preocupación de Kubernetes. Una interrupción regional del almacenamiento o un checkpoint corrupto puede derrotar simultáneamente todas las capas de recuperación. La arquitectura reduce varios costes habituales de fallos, pero no elimina las dependencias compartidas.

La detección de fallos también puede generar falsos positivos. Una fase de compilación larga, una pausa en la carga de datos o un bloqueo del sistema de archivos podría superar un tiempo de espera de señal de vida agresivo. El launcher reiniciaría entonces workers sanos y descartaría progreso válido.

Los equipos necesitan datos de tiempos de espera específicos de la carga de trabajo antes de habilitar la recuperación automática. Deberían registrar los intervalos más largos de inicialización del modelo, checkpointing, validación y entrada de datos. Las pruebas deberían incluir fallos durante esas fases, no solo fallos dentro de un paso regular de entrenamiento.

El benchmark de AWS utilizó fallos deterministas inyectados. Este enfoque permite comparaciones repetibles, pero los fallos de producción son menos ordenados. Los clústeres reales pueden experimentar simultáneamente degradación de red, ralentización del almacenamiento, problemas térmicos y caídas de procesos.

La implementación de referencia ofrece a los equipos un punto de partida útil para reproducir la configuración. La reproducción en diferentes familias de instancias y escalas de modelo determinará cuán portables son las ventajas reportadas.

La complejidad operativa es la compensación final. La pila incluye Kubernetes Jobs, descubrimiento de pares basado en DNS, recursos EFA, almacenamiento compartido, wrappers de NVRx, clientes de monitorización y múltiples capas de tiempos de espera. Cada componente crea otra superficie de configuración.

Esta complejidad puede seguir estando justificada cuando una gran flota de GPU pasa minutos inactiva tras el fallo de un solo rango. Sin embargo, los trabajos más pequeños podrían aceptar una estrategia de reinicio de pods más simple. El cálculo relevante es el coste de recuperación multiplicado por la frecuencia de fallos, no el prestigio del benchmark.

Los equipos que evalúen el diseño deberían seguir tanto el goodput de entrenamiento como el de infraestructura. La utilización de GPU por sí sola puede parecer saludable mientras el modelo recarga repetidamente checkpoints antiguos. Un panel útil debe mostrar pasos completados, distancia de reversión, actualidad del checkpoint y causa del reinicio.

Las organizaciones de ingeniería también necesitan registros duraderos de estos experimentos. Una base de conocimientos de ingeniería con capacidad de búsqueda puede conectar cambios de tiempos de espera, trazas de fallos y resultados de benchmarks. Ese contexto ayuda a los equipos a evitar repetir configuraciones de recuperación fallidas.

Qué vigilar después del benchmark NVRx de Amazon EKS

La siguiente evidencia debería mostrar si el diseño conserva su ventaja en modelos más grandes, fallos reales y versiones cambiantes de NVRx.

La primera señal es una reproducción independiente más allá de 64 GPU H100. AWS probó el escalado de dos a ocho nodos, pero la frecuencia de fallos y los costes de coordinación aumentan con el tamaño del clúster. Los resultados en cientos de aceleradores revelarían mejor los límites del rendezvous y de la carga de checkpoints.

Una prueba más grande debería informar más que el tiempo medio de recuperación. La distribución importa porque recuperaciones excepcionales de cinco minutos pueden dominar la economía de una ejecución larga. Los informes deberían incluir latencia de cola, intentos de reinicio fallidos y progreso perdido por incidente.

La segunda señal es la adopción dentro de los principales frameworks de entrenamiento. NVRx ya se conecta con cargas de trabajo basadas en PyTorch y aparece en la pila de software más amplia de NVIDIA. Más integraciones nativas reducirían la cantidad de código personalizado de wrappers y launchers que los equipos deben mantener.

La adopción por parte de los frameworks reforzaría el argumento de que la tolerancia a fallos de NVRx puede convertirse en una capa de aplicación estándar. Las integraciones fragmentadas lo debilitarían, especialmente si cada framework requiere una lógica diferente de tiempos de espera, checkpoints y rendezvous.

La tercera señal es evidencia procedente de fallos de producción no controlados. La inyección determinista de fallos es necesaria para comparar, pero los incidentes de campo ponen a prueba combinaciones que los laboratorios rara vez reproducen. Los operadores deberían publicar por separado las tasas de recuperación para errores de GPU, bloqueos de NCCL, terminaciones OOM y pérdida de nodos.

Una recuperación satisfactoria debería significar más que reiniciar un proceso. El trabajo debe restaurar un estado válido, seguir produciendo actualizaciones correctas y evitar la corrupción silenciosa de checkpoints. La convergencia del modelo tras recuperaciones repetidas merece el mismo escrutinio que la velocidad de recuperación.

Para los equipos que consideren ahora el entrenamiento NVRx en Amazon EKS, el primer paso práctico es un benchmark de sombra controlado. Utilicen el modelo, tamaño de checkpoint, sistema de archivos y duración de paso reales. Comparen guardados síncronos, guardados asíncronos, recuperación mediante launcher y recuperación solo con Kubernetes bajo un mismo calendario de fallos.

Después, ajusten los intervalos de checkpoint según los tiempos de cómputo y almacenamiento observados. Si un checkpoint tarda casi tanto como el intervalo entre guardados, el solapamiento asíncrono seguirá siendo incompleto. Si el cómputo proporciona una ventana más amplia, la eficiencia reportada del 99 % resulta más plausible.

Las políticas de recuperación deberían comenzar con límites de reintentos conservadores. Registren cada motivo de reinicio y conserven las trazas de diagnóstico. Un trabajo que falla repetidamente en el mismo rango o checkpoint necesita escalamiento, no un bucle de recuperación interminable.

El trabajo de AWS y NVIDIA hace difícil ignorar una conclusión. La fiabilidad del entrenamiento distribuido no puede seguir siendo solo una preocupación de infraestructura. La aplicación entiende el progreso, la validez de los checkpoints y el estado del grupo de procesos de maneras que un orquestador no entiende.

Amazon EKS sigue proporcionando la base esencial de programación y reemplazo de nodos. NVRx añade una respuesta más rápida dentro de ese límite. Juntos, ofrecen una vía creíble para pasar de ciclos de recuperación de cuatro minutos a reinicios a escala de segundos para varias clases importantes de fallos.

La pregunta abierta es ahora operativa, más que conceptual. ¿Pueden los equipos reproducir esas ganancias con sus propios modelos, sistemas de almacenamiento y patrones reales de fallo? Esa es la prueba que debería guiar la próxima implementación de entrenamiento NVRx en Amazon EKS.