Respuesta a Incidentes para Clústeres GPU: Guías de Procedimientos para Escenarios de Fallas Comunes
Actualizado el 8 de diciembre de 2025
Actualización de diciembre de 2025: Las fallas de refrigeración líquida ahora encabezan la categoría de incidentes para clústeres GPU modernos: fallas de CDU, detección de fugas, problemas de calidad del refrigerante. El tiempo de inactividad de H100/H200 cuesta entre $25-40K por GPU-día, haciendo crítica la respuesta rápida. Las plataformas AIOps (PagerDuty, Datadog) están integrando runbooks específicos para GPU. Los frameworks de entrenamiento elástico reducen el radio de impacto de las fallas de GPU. La optimización de frecuencia de checkpoints (10-15 min) minimiza la pérdida de entrenamiento por incidentes.
Cuando 500 GPUs H100 se desconectan repentinamente durante una ejecución de entrenamiento crítica, cada segundo cuesta $1,200 en tiempo de cómputo perdido. Cuando la refrigeración líquida falla en un clúster GPU de 2MW, las temperaturas aumentan 1°C cada 30 segundos hacia el apagado térmico. Cuando el fabric InfiniBand se particiona durante el entrenamiento distribuido, 10,000 horas-GPU de computación se vuelven inútiles. Estos escenarios demandan respuestas precisas y ensayadas que minimicen el daño y restauren el servicio rápidamente. Esta guía proporciona procedimientos probados en batalla para incidentes de infraestructura GPU.
Clasificación de Incidentes y Niveles de Severidad
Los incidentes de infraestructura GPU requieren clasificaciones de severidad especializadas más allá de los frameworks tradicionales de TI. Los incidentes de Severidad 1 (Crítico) involucran falla completa del clúster, riesgo de pérdida de datos o peligros de seguridad que afectan más de 100 GPUs o impacto de $50,000 por hora. Estos activan escalamiento ejecutivo inmediato, contacto con proveedores y activación de sala de guerra 24/7. El entrenamiento de GPT-4 de OpenAI experimentó tres incidentes de Severidad 1 durante seis meses, cada uno requiriendo involucramiento del CEO debido a los costos de entrenamiento de $2 millones diarios.
Los incidentes de Severidad 2 (Alto) impactan 20-100 GPUs o causan degradación del rendimiento del 50% en clústeres más grandes. El tiempo de respuesta objetivo es 15 minutos con metas de resolución de 2 horas. Estos incidentes típicamente involucran fallas parciales de refrigeración, problemas de distribución eléctrica o eventos de partición de red. La infraestructura de Meta automáticamente notifica a los ingenieros de guardia para eventos de Severidad 2, con escalamiento a arquitectos senior después de 30 minutos sin progreso.
Los incidentes de Severidad 3 (Medio) afectan menos de 20 GPUs o causan degradación del rendimiento del 25%. Estos incluyen fallas de nodos individuales, problemas de drivers o problemas de red localizados. Los objetivos de resolución se extienden a 4 horas con seguimiento al siguiente día hábil aceptable. Los sistemas automatizados manejan el 70% de los incidentes de Severidad 3 sin intervención humana a través de mecanismos de auto-reparación.
Los incidentes de Severidad 4 (Bajo) involucran fallas de GPU individuales o variaciones menores de rendimiento bajo el 10%. Estos entran en flujos de trabajo de tickets estándar con objetivos de resolución de 24 horas. La infraestructura de Anthropic automáticamente pone en cuarentena los recursos afectados, permitiendo que las cargas de trabajo de producción continúen mientras las reparaciones proceden durante ventanas de mantenimiento.
Los cálculos de impacto financiero impulsan las asignaciones de severidad. Cada GPU H100 representa una inversión de capital de $30,000 con costo operativo de $50 por hora. Las interrupciones de entrenamiento pueden invalidar días de computación valorados en millones. Lambda Labs calcula el costo del incidente como: (GPUs afectadas × tarifa por hora × duración esperada) + (tiempo de recuperación de checkpoint × costo del clúster) + (penalidades de SLA). Esta fórmula activó la clasificación de Severidad 1 para una falla de 50 GPUs debido a costos de recuperación de checkpoint de $500,000.
Procedimientos de Respuesta ante Fallas de Energía
Los escenarios de pérdida total de energía requieren reducción inmediata de carga para prevenir fallas en cascada durante la recuperación. Los sistemas UPS que soportan clústeres GPU típicamente proporcionan 5-7 minutos de autonomía a carga completa. Los primeros 30 segundos determinan la trayectoria del incidente: los interruptores de transferencia automática deben activarse, los generadores deben arrancar y los sistemas de refrigeración deben mantener operación. El procedimiento de Microsoft inicia la suspensión automática de cargas de trabajo dentro de 10 segundos de la detección del evento de energía.
La Fase 1 (0-30 segundos) se enfoca en la preservación del estado. Los trabajos de entrenamiento distribuido deben hacer checkpoint inmediatamente, requiriendo ubicaciones de checkpoint preconfiguradas con ancho de banda suficiente. El comando kubectl exec activa checkpointing de emergencia a través de los pods de Kubernetes. Los sistemas de almacenamiento cambian a modo write-through, asegurando la persistencia de datos. El equipo de red en sistemas UPS separados mantiene conectividad para gestión remota.
La Fase 2 (30 segundos - 2 minutos) involucra priorización de carga. Las cargas de trabajo no críticas terminan automáticamente basándose en clases de prioridad de pods. Las cargas de trabajo de inferencia continúan sirviendo con capacidad degradada. Los trabajos de entrenamiento guardan estado y se apagan graciosamente. Los sistemas de refrigeración reducen a operación mínima viable, manteniendo temperaturas bajo límites térmicos. Los sistemas de gestión de energía reducen 40% de la carga, extendiendo la autonomía del UPS a 15 minutos.
La Fase 3 (2-5 minutos) requiere sincronización del generador. Los interruptores de transferencia automática sincronizan la salida del generador con los sistemas UPS antes de transferir la carga. Los arranques fallidos del generador activan escalamiento inmediato con procedimientos de arranque manual. La verificación del estado del sistema de combustible asegura capacidad de autonomía de 24 horas. Los centros de datos de Google mantienen suministros de combustible de 48 horas con contratos de reabastecimiento automático activados durante cortes extendidos.
Los procedimientos de recuperación comienzan una vez que la energía estable retorna. La restauración por fases previene que la corriente de arranque simultánea sobrecargue los sistemas eléctricos. Los sistemas de almacenamiento se inicializan primero, seguidos por la infraestructura de red, luego los nodos de cómputo en incrementos del 10%. Los límites de potencia de GPU se reducen temporalmente al 80% durante la estabilización. La capacidad completa retorna después de 30 minutos de operación estable. La automatización de recuperación de CoreWeave restaura 1,000 GPUs a producción en 45 minutos después de la restauración de energía.
Respuestas ante Fallas del Sistema de Refrigeración
Las fallas de refrigeración líquida escalan rápidamente con temperaturas de GPU aumentando 20°C por minuto sin refrigeración activa. La respuesta inmediata activa throttling automático de frecuencia, reduciendo la generación de calor en 40%. El comando nvidia-smi -pl 400 reduce la potencia del H100 de 700W a 400W, ganando tiempo crítico de respuesta. La migración de cargas de trabajo a zonas no afectadas comienza automáticamente mientras los equipos de reparación se movilizan.
Las fallas del circuito primario requieren aislamiento de las secciones afectadas mientras se mantiene el flujo a las áreas operativas. Las válvulas de bypass redirigen el flujo alrededor de los componentes fallidos. Las bombas redundantes se activan, manteniendo 60% de capacidad de flujo. Las fallas de CDU (Unidad de Distribución de Refrigerante) activan cambio automático a unidades de respaldo dentro de 30 segundos. Los sistemas RSD (Rack Scale Design) de Supermicro incluyen controles de válvulas automatizados que aíslan fallas a racks individuales.
Las fallas del circuito secundario entre CDUs y torres de enfriamiento impactan instalaciones completas. Los chillers de emergencia se activan dentro de 2 minutos, proporcionando rechazo de calor temporal. El personal del centro de datos abre manualmente ventilación de emergencia, expulsando aire caliente directamente al exterior a pesar de las pérdidas de eficiencia. Unidades de refrigeración portátiles se despliegan en áreas críticas dentro de 30 minutos. La instalación de Prineville de Facebook mantiene 2MW de capacidad de refrigeración portátil para respuesta de emergencia.
La detección de fugas activa protocolos de aislamiento inmediato. Los sensores de agua debajo de los racks de GPU activan válvulas solenoides, deteniendo el flujo dentro de 500 milisegundos. Los racks afectados se apagan automáticamente mientras mantienen conectividad de red para diagnóstico remoto. Los equipos de recuperación despliegan materiales absorbentes y deshumidificadores portátiles previniendo corrosión. Los centros de datos submarinos de Microsoft usan fluidos de refrigeración dieléctricos, eliminando completamente el riesgo de daño por agua.
El aumento de refrigeración por aire soporta sistemas refrigerados por líquido durante fallas parciales. Las unidades CRAC (Computer Room Air Conditioning) aumentan la salida 50% compensando la capacidad reducida de refrigeración líquida. Los sistemas de contención de pasillo caliente se activan, mejorando la eficiencia de refrigeración 20%. Ventiladores temporales se despliegan en áreas críticas, proporcionando refrigeración puntual para racks sobrecalentados. Estas medidas mantienen operaciones durante las 4-6 horas requeridas para reparaciones de refrigeración líquida.
Partición de Red y Pérdida de Conectividad
Las particiones del fabric InfiniBand destruyen la eficiencia del entrenamiento distribuido instantáneamente. La detección automática se activa dentro de 100 milisegundos usando heartbeats del subnet manager. Los nodos afectados se ponen en cuarentena automáticamente, previniendo que actualizaciones parciales corrompan el estado del modelo. Los programadores de trabajos reciben actualizaciones de topología, reprogramando trabajo a particiones saludables. El manejo de errores de NCCL termina limpiamente las operaciones colectivas afectadas.
La recuperación requiere reconstrucción sistemática del fabric. El subnet manager opensm reconstruye tablas de enrutamiento, descubriendo rutas sobrevivientes. La operación parcial del fabric continúa con ancho de banda reducido mientras las reparaciones proceden. La degradación del ancho de enlace de 4x a 2x mantiene conectividad con 50% de reducción de ancho de banda. La infraestructura EFA (Elastic Fabric Adapter) de Amazon automáticamente enruta alrededor de las fallas, manteniendo 85% del ancho de banda agregado durante fallas de switch único.
Las fallas de red Ethernet impactan tanto las cargas de trabajo de entrenamiento como de inferencia de manera diferente. La reconvergencia de BGP (Border Gateway Protocol) se completa dentro de 30 segundos para rutas redundantes. El enrutamiento ECMP (Equal-Cost Multi-Path) distribuye el tráfico a través de los enlaces sobrevivientes. La priorización del tráfico de almacenamiento asegura que las operaciones de checkpoint se completen a pesar del ancho de banda reducido. Las políticas de Calidad de Servicio garantizan 40% del ancho de banda para operaciones críticas.
El aislamiento completo de red activa el modo de operación autónoma. Los nodos continúan computación local mientras almacenan resultados en buffer. Los trabajos de entrenamiento distribuido pausan en barreras de sincronización, preservando estado. El almacenamiento NVMe local almacena hasta 1TB de datos de checkpoint esperando restauración de conectividad. Al recuperarse la red, los datos en buffer se sincronizan automáticamente, reanudando operaciones en minutos en lugar de horas de reinicio.
Las fallas de DNS y descubrimiento de servicios previenen la programación de cargas de trabajo a pesar de la infraestructura funcional. Los servidores DNS de respaldo se activan automáticamente con valores TTL (Time To Live) de 15 segundos permitiendo actualizaciones rápidas. Los pods CoreDNS de Kubernetes se reinician en nodos no afectados dentro de 30 segundos. Las configuraciones de IP estática en runbooks de emergencia evitan DNS para acceso de gestión crítico. HashiCorp Consul proporciona resiliencia de service mesh con failover automático para descubrimiento de servicios.
Prevención de Cascada de Fallas de Hardware
Las fallas de GPU individuales pueden cascadear a través de trabajos de entrenamiento distribuido afectando cientos de dispositivos. El aislamiento inmediato previene la propagación de errores. El comando nvidia-smi drain remueve graciosamente las GPUs de los pools de recursos. Los plugins de dispositivos de Kubernetes marcan las GPUs fallidas como no saludables, previniendo nueva programación de pods. Las cargas de trabajo en ejecución migran a recursos saludables dentro de 2 minutos.
Los errores de memoria activan respuestas progresivas basadas en severidad. Los errores de bit único corregidos por ECC continúan operando con frecuencia de monitoreo aumentada. Los errores de doble bit causan migración inmediata de carga de trabajo y cuarentena de GPU. El agotamiento de retiro de páginas activa la programación de reemplazo de hardware. Los sistemas de pedidos automatizados mantienen 2% de inventario de repuesto para reemplazo rápido.
Las fallas de fuente de poder en configuraciones redundantes continúan operando a capacidad reducida. Las configuraciones N+1 pierden redundancia pero mantienen operación completa. El balanceo de carga redistribuye el consumo de energía a través de las fuentes sobrevivientes. La eficiencia cae 5-10% aumentando la generación de calor. La programación de reemplazo apunta a respuesta de 4 horas para restauración de redundancia. Los clústeres Dojo de Tesla mantienen fuentes de poder de repuesto en caliente permitiendo reemplazos de 5 minutos.
Las fallas de componentes de placa madre requieren diagnóstico cuidadoso distinguiendo fallas reparables de terminales. Los retimers PCIe ocasionalmente requieren reasentamiento, restaurando operación sin reemplazo. Las fallas de VRM (Módulo Regulador de Voltaje) pueden afectar GPUs individuales mientras otras continúan operando. Los procedimientos de recuperación de BIOS restauran firmware corrupto sin reemplazo de hardware. Los diagnósticos integrados de Dell EMC identifican fallas a nivel de componente permitiendo reparaciones dirigidas.
La prevención de cascada térmica requiere intervención agresiva. Las temperaturas de GPUs adyacentes aumentan 5-10°C cuando las vecinas fallan. La redistribución de cargas de trabajo previene la formación de puntos calientes. Las unidades de rack vacías entre hardware fallido mejoran el flujo de aire. Los enfriadores puntuales portátiles se despliegan dentro de 15 minutos para áreas críticas. Tempor
[Contenido truncado para traducción]
