Un nodo con ocho GPU puede funcionar durante semanas sin causar problemas y seguir siendo una pieza demasiado poco fiable para un entrenamiento que utiliza miles de máquinas al mismo tiempo. La contradicción es aparente: cuando una tarea síncrona depende de que todos sus participantes continúen disponibles, una probabilidad pequeña de fallo individual se multiplica hasta convertir las interrupciones en parte de la operación cotidiana.

Una infografía difundida estos días resume el problema con una cifra llamativa: una tasa diaria de fallo del 1,5 % por nodo produciría una probabilidad del 84,8 % de sufrir al menos una incidencia en un sistema de 1.000 GPU. El cálculo es correcto bajo unas condiciones concretas, pero otras afirmaciones de la imagen necesitan más contexto. La fiabilidad de un clúster no puede deducirse únicamente de una fórmula ni del porcentaje publicado para cada servidor.

Las claves de la fiabilidad de los clústeres GPU en 20 segundos

• Los entrenamientos distribuidos suelen sincronizar miles de GPU en cada paso.
• Un solo nodo averiado puede detener o ralentizar a todos los demás.
• Con 1.000 GPU repartidas en 125 nodos, un fallo diario del 1,5 % por nodo da un 84,9 % de probabilidad de sufrir al menos una incidencia.
• El cálculo supone fallos independientes y nodos de ocho GPU.
• En la práctica también hay errores correlacionados de red, energía, refrigeración, firmware y software.
• La fiabilidad útil se mide en tiempo efectivo de entrenamiento, no solo en disponibilidad individual.
• Detectar y aislar rápido un nodo suele ser más valioso que completar el diagnóstico antes de actuar.
• Los puntos de control reducen el trabajo perdido, pero pueden sobrecargar el almacenamiento.
• Los sistemas más recientes permiten retirar una réplica dañada mientras el resto sigue entrenando.
• La cifra de un fallo cada 30 minutos en 100.000 GPU no se deriva directamente del ejemplo del 1,5 %.

La literatura técnica confirma que las interrupciones dejan de ser excepcionales a medida que aumenta el clúster. El entrenamiento de Llama 3 sobre 16.384 GPU H100 registró 466 interrupciones durante 54 días, mientras ByteDance documentó más de un centenar de fallos en varias semanas al operar MegaScale con 12.288 GPU. Un estudio de sistemas distribuidos recopila además casos con incidencias cada uno o dos días en configuraciones de alrededor de 1.000 aceleradores.

Cómo se convierte un 1,5 % en una probabilidad del 84,9 %

La fórmula empleada en la imagen es:

P(al menos un fallo) = 1 − (1 − p)^N

En ella, p representa la probabilidad diaria de fallo de cada nodo y N el número de nodos que participan en la tarea.

Un sistema con 1.000 GPU no equivale necesariamente a 1.000 elementos independientes. Si cada servidor alberga ocho GPU, la infraestructura contiene 125 nodos. Con una tasa diaria del 1,5 % por nodo, la probabilidad de que ninguno falle es:

0,985^125 ≈ 15,1 %

La probabilidad de que falle al menos uno es, por tanto, cercana al 84,9 %. La cifra de la infografía está bien calculada si se acepta esa distribución de ocho GPU por nodo, una tasa constante y fallos independientes.

La conclusión no es que el 84,9 % de los entrenamientos vayan a fracasar por completo. Significa que, en un día cualquiera, existe esa probabilidad de que al menos uno de los 125 nodos experimente el tipo de fallo incluido en la tasa utilizada. El efecto final dependerá de la arquitectura del entrenamiento, la duración de la incidencia y la capacidad para retirar o sustituir la máquina.

También importa qué se considera un fallo. Puede tratarse de una GPU que deja de responder, un error ECC no recuperable, un problema de HBM, una pérdida de enlace NVLink, una interfaz de red degradada, un proceso bloqueado o un servidor que el operador retira preventivamente al detectar métricas anómalas.

Por eso las listas de nodos excluidos no equivalen directamente a inventarios de hardware roto. Una máquina puede apartarse por una avería confirmada, por degradación intermitente o porque su comportamiento amenaza con ralentizar a miles de aceleradores que esperan en una operación colectiva.

El trabajo realizado sobre un clúster de producción con 504 GPU Nvidia B200 ilustra esta dificultad. Sus investigadores analizaron 751 métricas de Prometheus y diez fallos identificados mediante códigos XID, pero no encontraron una única métrica que dominara de manera consistente todos los tipos de error. También observaron que tres de los 63 nodos concentraban más de la mitad de las exclusiones, señal de que los problemas no se distribuyen siempre de forma uniforme.

Esta concentración cuestiona una de las simplificaciones del cálculo inicial: la independencia. Los fallos reales pueden agruparse por lotes de hardware, versiones de firmware, temperatura, topología de red, configuración o carga de trabajo. Una avería eléctrica o de refrigeración puede afectar simultáneamente a varias máquinas, mientras un pequeño número de nodos problemáticos puede explicar gran parte de los incidentes registrados.

La cifra de un fallo cada 30 minutos necesita otro modelo

La infografía afirma que un clúster de 100.000 GPU sufriría un fallo aproximadamente cada 30 minutos. La idea general es razonable: a esa escala las incidencias son continuas. Sin embargo, esa cifra no sale de extrapolar sin más el 1,5 % diario utilizado en el ejemplo anterior.

Con ocho GPU por nodo, 100.000 aceleradores ocuparían unas 12.500 máquinas. Si cada una mantuviera una probabilidad diaria e independiente del 1,5 %, el número esperado de fallos sería de 187,5 al día. Eso equivaldría a un intervalo medio de unos 7,7 minutos, no de media hora.

Un fallo cada 30 minutos correspondería a una tasa agregada de 48 incidencias diarias y, manteniendo 12.500 nodos, a una probabilidad individual aproximada del 0,38 % al día. También podría proceder de una definición más restringida de fallo, de una arquitectura distinta o de datos operativos que no utilizan las mismas hipótesis.

La referencia indicada en la imagen para esa estimación, el trabajo arXiv:2605.09370, tampoco analiza un clúster de 100.000 GPU. El informe estudia 63 nodos con 504 B200 durante 55 días de métricas y 73 días de registros operativos. Ofrece información valiosa sobre detección, puntos de control, exclusión de nodos y reintentos, pero no respalda por sí solo el intervalo de 30 minutos atribuido a una infraestructura de 100.000 aceleradores.

Sí existe una investigación específica sobre entrenamientos del orden de 100.000 GPU. Sus autores describen una eficiencia efectiva de solo el 44 % en un enfoque completamente síncrono, debido a la frecuencia de las incidencias y al tiempo necesario para recuperarse. El sistema propuesto, denominado FT-HSDP, reduce la pausa asociada a cada recuperación de diez a tres minutos y eleva el tiempo efectivo de entrenamiento hasta el 80 %. El artículo no necesita fijar una avería cada media hora para mostrar la magnitud del problema.

El dato importante no es el intervalo exacto entre errores, que cambia según el hardware y la metodología utilizada. Lo relevante es que una arquitectura diseñada para detenerse ante cualquier fallo pierde gran parte de su capacidad útil cuando opera con decenas de miles de componentes.

La fiabilidad se construye por encima del hardware

Comprar servidores de mayor calidad ayuda, pero no resuelve por sí solo el problema. En un entrenamiento síncrono, todos los participantes intercambian gradientes o resultados intermedios. Si uno desaparece, responde tarde o pierde ancho de banda, los demás pueden quedar esperando.

La infraestructura necesita mecanismos que detecten qué nodo está causando el problema, lo retiren y reorganicen el trabajo. La velocidad de esa decisión suele pesar más que la precisión inicial del diagnóstico.

Esperar varios minutos para confirmar si el origen es la memoria, la GPU, el controlador o el enlace de red mantiene paradas máquinas cuyo coste agregado puede alcanzar cientos de miles de euros por hora. Aislar primero y analizar después permite recuperar antes la capacidad útil, siempre que exista un grupo de reserva o una arquitectura capaz de continuar con menos participantes.

Esta filosofía explica el uso de comprobaciones previas, señales de actividad, métricas de Nvidia DCGM, registros de NCCL y pruebas periódicas de red. Los sistemas buscan tanto errores evidentes como nodos rezagados que siguen funcionando, pero reducen el rendimiento de todo el grupo.

Un enlace de red parcialmente degradado puede ser especialmente dañino. Algunas bibliotecas redirigen el tráfico por otra interfaz para evitar una caída total, aunque el servidor afectado continúa dentro de la operación colectiva y puede ralentizar a los demás. Investigaciones recientes proponen algoritmos AllReduce capaces de mantener un rendimiento próximo al normal cuando uno de los nodos ha perdido parte de su ancho de banda.

El objetivo operativo deja de ser mantener todas las máquinas siempre sanas. Pasa a consistir en impedir que una máquina problemática arrastre al conjunto.

Los puntos de control salvan el entrenamiento, pero tienen un precio

La respuesta tradicional ante un fallo consiste en guardar periódicamente el estado del modelo. Cuando el trabajo se detiene, el sistema carga el último punto de control y repite el cálculo realizado desde entonces.

Guardar con más frecuencia reduce el progreso perdido, pero exige transferir grandes cantidades de datos desde las GPU hacia la memoria del servidor y después al almacenamiento. En modelos grandes, el proceso puede generar ráfagas capaces de saturar la red o el sistema de ficheros.

El estudio sobre 504 B200 analizó 523 operaciones de guardado y carga. Durante una recuperación, la lectura alcanzó solo el 21,5 % del ancho de banda máximo disponible, mientras las escrituras llegaron al 16 %. Los autores encontraron colas simultáneas en NFS, RPC y la capa de transporte, un recordatorio de que disponer de almacenamiento rápido no garantiza aprovecharlo cuando cientos de procesos acceden a la vez.

Proyectos como DLRover intentan reducir este coste guardando estados en memoria y persistiendo los datos de forma asíncrona. El repositorio del proyecto sostiene que su combinación de tolerancia a fallos y recuperación rápida elevó el goodput de un entrenamiento de GLM-65B con miles de GPU desde el 69 % hasta el 95 %. Es una cifra publicada por el propio proyecto y no una comparación independiente, pero muestra la métrica que realmente interesa: qué porcentaje del tiempo se dedica a producir pasos nuevos y útiles.

Una GPU puede aparecer ocupada mientras espera una comunicación, repite trabajo perdido o carga un punto de control. La utilización del dispositivo no es equivalente a productividad.

Del reinicio completo a la recuperación por réplicas

Los sistemas de entrenamiento más recientes intentan evitar que toda la tarea dependa de todos los nodos durante todo el tiempo.

FT-HSDP divide el trabajo en réplicas de paralelismo de datos. Cuando una GPU o un servidor falla, solo se retira la réplica que lo contiene. Las demás continúan avanzando mientras la afectada se reinicia, carga el estado y alcanza al grupo mediante un protocolo de reincorporación.

Este enfoque cambia la unidad de tolerancia a fallos. El sistema ya no trata un entrenamiento de 100.000 GPU como una única máquina gigantesca que debe estar completamente sana, sino como varios grupos capaces de soportar la pérdida temporal de uno de ellos.

La recuperación asíncrona también reduce la necesidad de reservar enormes cantidades de hardware ocioso. Sigue haciendo falta capacidad adicional para sustituir nodos, pero la reserva puede gestionarse como parte del clúster y no como una copia completa del entrenamiento.

La experiencia del clúster de 504 GPU ofrece otro dato útil: las cadenas automáticas de reintento tuvieron una tasa de éxito del 33,3 %, frente al 12,5 % de los intentos manuales, con una mediana de once minutos entre reintentos. El resultado no implica que la automatización acierte siempre, pero sí que la respuesta sistemática y repetible puede superar a la intervención improvisada.

Qué debería medir un operador de infraestructura de IA

La tasa de avería publicada para una GPU o un servidor es solo una pieza. Una explotación real necesita medir cuántas interrupciones se producen por cada mil GPU y hora, cuánto tardan en detectarse, cuánto trabajo se pierde y cuántos minutos transcurren hasta recuperar el rendimiento anterior.

También debe separar los incidentes por origen: GPU, HBM, NVLink, interfaces de red, switches, almacenamiento, alimentación, refrigeración, controladores y software. Sin esa clasificación, una mejora aparente del hardware puede quedar ocultada por un cuello de botella que se ha desplazado a otra capa.

La afirmación de que la memoria HBM superó al cómputo de la GPU como principal causa de interrupciones en un entrenamiento de 32.000 aceleradores resulta plausible por la complejidad de estas memorias apiladas, pero no aparece documentada en las referencias citadas en la infografía. Hasta disponer del informe original, conviene tratarla como una afirmación pendiente de verificar, no como una tendencia confirmada para toda la industria.

La fiabilidad de un gran clúster no se encuentra en la ficha técnica de una GPU. Se obtiene combinando observabilidad, aislamiento, capacidad de reserva, puntos de control rápidos y un modelo de entrenamiento que acepte que las máquinas fallarán.

En una infraestructura pequeña, una avería sigue siendo un incidente. En un sistema con decenas de miles de GPU es una condición normal de funcionamiento. La diferencia entre un clúster caro y uno productivo está en lo que sucede durante los minutos posteriores.

Preguntas frecuentes

¿Es correcto el 84,8 % de probabilidad de fallo para 1.000 GPU?
Sí, si se suponen 125 nodos de ocho GPU, una tasa diaria independiente del 1,5 % por nodo y la misma probabilidad para todos. El resultado es aproximadamente un 84,9 %.

¿Una incidencia en un nodo detiene siempre todo el entrenamiento?
No. Ocurre en diseños síncronos muy acoplados, pero los sistemas con réplicas tolerantes a fallos pueden retirar solo el grupo afectado mientras el resto continúa.

¿Un clúster de 100.000 GPU falla cada 30 minutos?
Puede experimentar incidencias con mucha frecuencia, pero el intervalo depende de la tasa y de qué se considere fallo. La cifra de 30 minutos no se obtiene directamente del ejemplo del 1,5 %.

¿Qué métrica describe mejor la fiabilidad del clúster?
El goodput, entendido como el porcentaje del tiempo dedicado a producir trabajo útil nuevo, resulta más representativo que la disponibilidad aislada de cada GPU.