Confiabilidad de GPU: Netflix sube del 98% al 99,5% el éxito de sus trabajos de IA tratando el hardware como un problema de sistemas distribuidos

Un entrenamiento de IA puede durar semanas y correr sobre cientos de GPUs. Basta que una falle, o que un adaptador de red rinda a medias, para frenar todo el trabajo. Netflix decidió que ese riesgo no se resuelve comprando más hardware, sino diseñando mejor. Su apuesta por la confiabilidad de GPU le permite reportar más de 99,95% de disponibilidad de nodos GPU y un salto en la tasa de éxito de sus trabajos de aproximadamente 98% a más de 99,5%, según detalló InfoQ.

El razonamiento es sencillo y poco intuitivo. Los entrenamientos grandes funcionan en sincronía: todos los trabajadores avanzan al mismo ritmo, así que el más lento o el más enfermo marca la velocidad del conjunto. Y un chequeo de salud típico de la nube, que confirma que la máquina virtual está encendida y responde, no dice nada sobre si sus GPUs aguantan una carga distribuida. Netflix descubrió que una GPU puede contestar con normalidad a una consulta de estado y fallar en cuanto se le asigna memoria o empieza un cálculo sostenido. Un adaptador de red puede estar presente pero con menos enlaces de los esperados, y las operaciones colectivas siguen funcionando con un ancho de banda severamente reducido. Según el resumen de daily.dev sobre la publicación de ingeniería de Netflix, los chequeos básicos de la nube y del driver solo detectan los fallos obvios. Se les escapan los adaptadores degradados, las fallas latentes de memoria y las herramientas de diagnóstico que dejan de funcionar sin avisar.

Cómo Netflix construyó su plataforma de confiabilidad de GPU

La plataforma se apoya en Kubernetes y combina cuatro capas:

Chequeos por capas. NVIDIA DCGM vigila errores de GPU, memoria, interconexión y temperatura, mientras otros controles revisan el estado y la cantidad de interfaces Elastic Fabric Adapter. Un agente de nodo convierte los resultados en condiciones de Kubernetes sobre las que los controladores pueden actuar.

Diseño que "falla cerrado". Si una herramienta de diagnóstico se cuelga, el tiempo de espera marca la máquina como no saludable en lugar de dar por bueno un chequeo roto. Hay además rutas de respaldo basadas en logs del kernel.

Remediación progresiva. Un problema transitorio primero bloquea trabajo nuevo y deja correr el existente. Si persiste, se drena la máquina y se mueven sus cargas. Según el caso, se mata un job problemático, se resetea la GPU, se reinicia el equipo o se reemplaza. Todo se integra con la reparación automática de nodos de Karpenter, con políticas propias sobre cuánto tolerar cada falla y cuánto del clúster se puede interrumpir a la vez.

Entrenamiento tolerante a fallos. Con checkpoints y workers elásticos, un entrenamiento retoma desde el último punto sano si se pierde una máquina. Los errores de aplicación se clasifican aparte para no reiniciar sin fin un job que falla por un bug real.

Netflix también vigila el propio trabajo de entrenamiento: puede identificar un único rank lento que arrastra a los demás. Para inferencia, usa Multi-Instance GPU (MIG) de NVIDIA para que cargas pequeñas compartan una GPU con aislamiento de memoria entre inquilinos, y avanza hacia Dynamic Resource Allocation de Kubernetes para colocar GPUs, adaptadores de red y CPUs según la topología de la máquina.

La cifra más reveladora es la del éxito de los trabajos. Pasar de 98% a 99,5% parece un ajuste menor, pero equivale a reducir los trabajos fallidos en torno a un 75% (del 2% al 0,5%). Cuando cada fallo puede costar días de cómputo en cientos de GPUs, esa diferencia pesa en la factura. Netflix no está sola: Meta reportó que los fallos de hardware causaron más de 66% de las interrupciones de entrenamiento en su experiencia con Llama 3, y invierte en detectar corrupción silenciosa de datos en clústeres enormes. Para InfoQ, ambos casos muestran lo mismo: con miles de GPUs, la confiabilidad ya no consiste en mantener máquinas encendidas.

Qué puedes aplicar en tu empresa para mejorar la confiabilidad de GPU

No necesitas el tamaño de Netflix para aprovechar estas ideas. Si tu organización entrena modelos propios, hace fine-tuning o sirve inferencia en GPUs, sea en la nube o en instalaciones propias, estos pasos son un buen punto de partida:

1. Valida el hardware antes de programar trabajo. Un "está encendido" no basta. Haz pruebas que asignen memoria y ejecuten cómputo sostenido antes de admitir una máquina al clúster.
2. Diseña los chequeos para que fallen cerrados. Un diagnóstico colgado debe contar como máquina enferma, no como máquina sana.
3. Escala la respuesta. Empieza por bloquear trabajo nuevo, luego drena y, solo al final, reemplaza. Reemplazar todo de inmediato es caro y desperdicia capacidad útil.
4. Haz que recuperarse sea barato. Checkpoints frecuentes y reintentos automáticos convierten un fallo de hardware en una molestia, no en una semana perdida.
5. Separa fallos de hardware de fallos de software. Si no los distingues, reintentarás durante horas un job con un bug.
6. Mide el goodput, no solo la disponibilidad. Un nodo disponible pero lento es un costo oculto. Vigila la velocidad por trabajador y no solo si la máquina responde.
7. Mejora la utilización. Para inferencia ligera, compartir GPUs con aislamiento, como hace Netflix con MIG, evita dedicar una tarjeta entera a cada carga.

El error a evitar es tratar la fiabilidad como un tema exclusivo del proveedor de nube. Netflix parte de la premisa contraria: los fallos ocurrirán, y la ventaja competitiva está en cuánto tarda y cuánto cuesta absorberlos. Si te interesa cómo esta misma empresa afronta la complejidad operativa a escala, revisa cómo un grafo de conocimiento convierte 38 millones de eventos por segundo en diagnósticos automáticos. Y para ver qué ocurre cuando la demanda de cómputo se dispara, mira cómo Cognition multiplica por 4,8 sus tokens con Vera Rubin y CoreWeave.

Si aún no tienes miles de GPUs, el momento de aplicar estos principios es antes de tenerlas: es mucho más barato diseñar la remediación automática desde el inicio que improvisarla cuando un entrenamiento de tres semanas se cae por una tarjeta degradada. Además, si estás comparando opciones de cómputo, conviene conocer alternativas como la optimización de IA de voz con AWS Trainium, donde Deepgram procesa hasta 70% más audio por dólar.

La lección de fondo es que la confiabilidad de GPU es una decisión de arquitectura, no un detalle de operaciones. La próxima vez que un entrenamiento de tu equipo se retrase, pregúntate: ¿fue mala suerte con el hardware o una plataforma que no estaba preparada para el fallo?