Las verificaciones de salud de GPU de Databricks detectan fallos silenciosos en menos de cinco minutos

Ejecutar un trabajo de entrenamiento con 1.024 GPUs durante 30 días tiene un 57% de posibilidades de encontrar al menos una falla de hardware. Con 256 GPUs se reduce al 19%. Databricks publicó un desglose detallado de su pila de confiabilidad de GPU esta semana — el primero de una serie — que cubre clasificación de fallos, pruebas de estrés y verificaciones de salud en múltiples etapas en toda la flota que sirve 125 billones de tokens por mes.

Databricks divide los fallos de GPU en tres categorías. Los trabajos bloqueados son los más fáciles: un timeout del reloj de vigilancia NCCL mata la ejecución inmediatamente y el entrenamiento se reinicia desde el punto de control. El timeout en sí no revela nada sobre la causa subyacente — el diagnóstico requiere rastrear capas de hardware, fabric, sistema de archivos y software. Los ralentizamientos silenciosos son más difíciles. Una GPU degradada mantiene el progreso del entrenamiento y la pérdida tendiendo hacia abajo, pero el rendimiento se ve limitado por el nodo más lento. Los síntomas aparecen en señales de hardware: razones de estrangulamiento DCGM para eventos térmicos, métricas de salud de enlace InfiniBand para degradación, contadores de ancho de banda de memoria mientras se acumulan fallos ECC. La corrupción numérica es la más difícil. ECC captura y corrige muchos fallos transitorios de forma transparente, pero cuando falla, el entrenamiento continúa con valores incorrectos — manifestándose como pérdida NaN, convergencia inestable o regresiones de calidad del modelo solo visibles en tiempo de evaluación.

Las matemáticas impulsan la prioridad. Databricks modela cada GPU con una tasa de fallo anualizada del 1%. En 30 días, 256 GPUs enfrentan ~19% de posibilidades de al menos un fallo; 1.024 GPUs enfrentan ~57%. Estos no son riesgos extremos — son realidad operativa de base. La infraestructura de entrenamiento debe ser tolerante a fallos por diseño, no por excepción.

Databricks expone fallos temprano ejecutando cargas de trabajo exigentes en hardware de cliente: aprendizaje por refuerzo para KARL (su modelo de codificación agéntica), tuberías de evaluación agéntica y sistemas de inteligencia de documentos. Las cargas de trabajo RL ejercen presión en la pila combinando entrenamiento, inferencia y cálculo de recompensa en bucles ajustados en muchas GPUs, golpeando casos extremos de fabric, térmicos y de comunicación colectiva que cargas de trabajo más ligeras pierden. Un ejemplo reciente: una ejecución de entrenamiento falló con un timeout NCCL después de siete horas. La investigación lo rastreó hasta un único puerto InfiniBand que se había degradado después de una recuperación — pero no produjo errores registrados. Solo la caída de rendimiento activó el timeout.

Capturar tales fallos requiere investigación en cada fase del ciclo de vida del nodo. La verificación de salud en múltiples etapas de Databricks valida el hardware de GPU antes de que comiencen los trabajos, monitorea la degradación silenciosa bajo carga e investiga la salud del fabric NCCL entre nodos entre trabajos. En el lado de inferencia — enrutando tráfico para endpoints Kimi, Qwen, OpenAI, Gemini y Claude — las propias verificaciones de salud fallan bajo carga pesada: las verificaciones vencen, matando servidores saludables mediante sondeos de vivacidad falsos. La solución: asignar tráfico de verificación de salud la prioridad de programación más alta. La recuperación entonces se ejecuta en menos de cinco minutos: detectar bloqueo, matar servidor no saludable, reiniciar. Los bloqueos falsos cayeron de varios por semana a cero.

La cifra del 80% en el título necesita precisión. Se refiere a ahorros de costos de GPU del escalado automático basado en unidad de modelo versus provisionamiento estático, no a MTTR. La asignación de pico estático es insostenible; la asignación dinámica mantiene los recuentos de réplicas cercanos a la demanda real para cargas de trabajo variables. La ganancia de latencia real es el ciclo de recuperación de menos de cinco minutos. Ambos números provienen de la misma plataforma pero resuelven problemas diferentes: la eficiencia de costos y la tolerancia a fallos están vinculadas solo en que el sobreaprovisionamiento estático no compra confiabilidad.

Los equipos de plataforma que ejecutan clústeres con cientos de GPUs necesitan monitoreo de señales de hardware — métricas DCGM, salud de enlace, ancho de banda de memoria — no solo observabilidad a nivel de trabajo. El estrangulamiento térmico se parece a un trabajo lento. Un puerto InfiniBand degradado se parece a ruido. Los fallos corregidos por ECC se ven como nada hasta que importan. Las verificaciones de salud son tan buenas como su prioridad de programación y amplitud de investigación.