Netflix ha publicado detalles sobre cómo mantiene en funcionamiento sus flotas de GPU bajo cargas de trabajo de entrenamiento e inferencia de IA a gran escala, tratando las fallas de hardware no como una molestia de infraestructura, sino como un problema de sistemas distribuidos que hay que resolver con ingeniería. La compañía informa una disponibilidad de nodos GPU superior al 99.95% y una tasa de éxito de trabajos que subió de aproximadamente 98% a más del 99.5%, según el reporte de InfoQ sobre el artículo técnico de Netflix.

El problema central, tal como lo describe InfoQ, es que un trabajo de entrenamiento grande puede ejecutarse durante semanas en cientos de GPU con cada worker operando en sincronía perfecta, de modo que una sola GPU fallida, un adaptador de red degradado o una máquina lenta pueden estancar o arrastrar hacia abajo todo el trabajo. Una verificación de salud convencional en la nube confirma que una máquina virtual está en ejecución y es accesible, pero Netflix descubrió que eso no dice nada sobre si sus GPU pueden realmente sostener una carga de trabajo distribuida: una GPU puede responder normalmente a una consulta de estado y aun así fallar una vez que se asigna memoria o comienza un cómputo sostenido. Un adaptador de red puede, de igual manera, estar presente pero funcionando con menos enlaces de los esperados, permitiendo que las operaciones colectivas continúen con un ancho de banda severamente reducido mientras parece saludable desde el exterior.

Netflix construyó su plataforma de cómputo GPU sobre Kubernetes, usando NVIDIA DCGM para verificaciones a nivel de dispositivo que cubren errores de GPU, memoria, interconexión y condiciones térmicas, junto con verificaciones del estado y la cantidad de interfaces Elastic Fabric Adapter de alta velocidad. Un agente de nodo de Kubernetes traduce estas verificaciones en condiciones de nodo sobre las que los controladores pueden actuar. Las verificaciones están diseñadas para fallar de forma cerrada: si una herramienta de diagnóstico se cuelga, el tiempo de espera resultante marca la máquina como no saludable en lugar de permitir que una verificación rota reporte éxito en silencio, y Netflix mantiene rutas de respaldo a través de los registros del kernel para los casos en que el mecanismo normal de diagnóstico de GPU se rompe por sí mismo.

La detección es solo la primera mitad del diseño. Los controladores de Netflix responden de forma progresiva en lugar de reemplazar de inmediato toda una máquina: un problema transitorio inicialmente solo bloquea trabajo nuevo mientras los trabajos existentes siguen ejecutándose; si la condición persiste, la máquina se drena y sus cargas de trabajo se trasladan a otro lugar. Las opciones de remediación van desde terminar un único trabajo problemático o reiniciar una GPU, hasta reiniciar o reemplazar por completo la máquina, y esto se integra con las capacidades de autorreparación de nodos de Karpenter, con Netflix añadiendo políticas sobre cuánto tiempo tolerar un tipo de falla determinado y qué porción del clúster puede interrumpirse a la vez.

Dado que las fallas de hardware no pueden eliminarse, la plataforma de entrenamiento de Netflix está construida para que recuperarse de ellas sea barato. Los trabajos grandes usan checkpointing y workers elásticos para que el entrenamiento se reanude desde el último checkpoint saludable tras la pérdida de una máquina, con reintento automático en caso de falla, mientras que las fallas a nivel de aplicación se clasifican por separado para que el sistema no siga reiniciando a ciegas trabajos que fallan por un error de software genuino y no por hardware. Netflix también trata el propio trabajo de entrenamiento como un sistema distribuido a monitorear, buscando no solo máquinas muertas sino también un único rank lento que arrastra al resto de un trabajo síncrono: una GPU no tiene que fallar por completo para hundir el throughput.

En el lado de la inferencia, Netflix está usando la capacidad Multi-Instance GPU de NVIDIA para permitir que cargas de trabajo más pequeñas compartan una GPU con aislamiento a nivel de memoria entre inquilinos, mejorando la utilización frente a dedicar una GPU completa por carga de trabajo, y la compañía afirma que está trabajando hacia Kubernetes Dynamic Resource Allocation para una colocación más expresiva y consciente de la topología de GPU, adaptadores de red y CPU dentro de una máquina. El reporte de InfoQ también señala el trabajo paralelo de Meta en este espacio: Meta usa sus propios diagnósticos de hardware, remediación automatizada, checkpointing y recuperación rápida, con un enfoque en detectar corrupción silenciosa de datos en clústeres de IA muy grandes, y Meta reporta que las fallas de hardware representaron más del 66% de las interrupciones de entrenamiento en su experiencia con Llama 3, una cifra que subraya por qué ambas compañías están invirtiendo tan intensamente en el manejo de fallas en lugar de simplemente comprar más capacidad.

Lo que notablemente está ausente del reporte de InfoQ es cualquier cifra de costo para esta capa de confiabilidad: ningún número sobre la cantidad de personal de ingeniería, la sobrecarga de infraestructura, o lo que la tasa de fallas alternativa le habría costado a Netflix en tiempo de entrenamiento desperdiciado. El artículo tampoco especifica el tamaño del clúster, la escala del modelo, ni qué cargas de trabajo (entrenamiento versus inferencia) experimentaron qué mejora, dejando el salto de 98% a 99.5% algo subespecificado en cuanto a su alcance.

Para los equipos que operan sus propios grandes clústeres de GPU, la lección operativa es que las verificaciones de liveness no son verificaciones de salud: una máquina que responde a pings no es lo mismo que una máquina que puede sostener comunicación colectiva a ancho de banda completo, y cerrar esa brecha requiere diagnósticos a nivel de dispositivo, tiempos de espera que fallan de forma cerrada, y remediación gradual construida directamente en el scheduler en lugar de añadida después de los hechos.