Calcula el impuesto por caídas antes de tu próxima expansión de clúster GPU

El dilema es claro: añade capacidad GPU redundante y paga por energía en espera, o acepta latencia de conmutación y paga en créditos SLA. La aritmética va antes que la opinión. Impuesto por caídas = consumo de cómputo (GPU $/hr x tamaño del clúster x MTTR esperado) + energía redundante $/month + capacidad en espera $/month + penalización por conmutación - créditos SLA/ingresos salvados. Si el impuesto por caídas > costo de un clúster más pequeño y de recuperación más rápida, estás comprando disponibilidad que no necesitas, y el clúster más pequeño gana; si el impuesto por caídas < costo de un clúster más pequeño y de recuperación más rápida, la expansión es una compra de confiabilidad, no una decisión de capacidad.

Una interrupción de servicios públicos afectó a muchos clientes y luego se restableció; usa ese evento como ancla de MTTR/créditos SLA para la fórmula. La energía externa puede fallar de formas que tu clúster no puede prevenir por completo, y el costo de esa falla no es solo el tiempo de inactividad.

Un centro de exámenes en Jaipur tuvo fallas internas de energía durante los exámenes, atribuidas a problemas eléctricos locales desconocidos. Para una plataforma de ML, mapea la interrupción a las cuatro líneas de costo: el enrutamiento degradado del modelo es el término de capacidad en espera, la caché obsoleta es el término de consumo de cómputo, las colas agotadas son la penalización por conmutación, y la carga de soporte es el término de penalización.

Costos

Divide el impuesto por caídas en cuatro líneas de costo. La primera es el consumo de cómputo durante la recuperación: GPUs que están encendidas pero no sirven, más el tiempo para calentar cachés, recargar pesos y restaurar tráfico. La segunda es la energía redundante: alimentadores adicionales, interruptores, capacidad de UPS y margen de refrigeración que existen solo para sobrevivir a una falla. La tercera es la capacidad en espera: GPUs inactivas, nodos de repuesto o una segunda región que deben mantenerse lo suficientemente actualizados para tomar tráfico. La cuarta es el término de penalización: solicitudes fallidas, créditos SLA, suscripciones perdidas y el tiempo de ingeniería dedicado a demostrar que el incidente no fue tu culpa.

No trates estos como presupuestos separados. Interactúan. Más capacidad en espera puede reducir MTTR, pero eleva el piso mensual. Más energía redundante puede reducir la probabilidad de una pérdida total del sitio, pero también puede ocultar un componente fallando hasta que la falla sea peor. La fórmula fuerza la comparación. Si tu MTTR esperado es largo, el término de consumo de cómputo domina. Si tu flota en espera es grande, el piso mensual domina. Si tus créditos SLA son pequeños, el término de ingresos salvados es débil, y el impuesto por caídas parece peor de lo que sugiere tu panel.

Servicio

La arquitectura de servicio decide cuánto del impuesto por caídas puedes evitar. Un solo centro de datos con una sola ruta de energía tiene un modo de falla simple: la ruta falla, y tu tiempo de recuperación es el tiempo para restaurar energía o redirigir tráfico. Un diseño de múltiples rutas puede reducir ese tiempo, pero cuesta más en energía, refrigeración y complejidad operativa. La respuesta correcta depende del término de penalización, no del deseo de un diagrama de arquitectura limpio.

Usa tres comprobaciones numéricas antes de expandir. Primero, mide la latencia de conmutación bajo una simulación real de pérdida de energía, no una partición de red. Si el clúster no puede detectar la pérdida, drenar tráfico y restaurar el servicio rápidamente, la capacidad en espera no está reduciendo el impuesto por caídas; simplemente está ahí. Segundo, precia la flota en espera como una línea mensual de energía/refrigeración, incluyendo energía y refrigeración, no solo alquiler de GPU. Tercero, compara la penalización de latencia de conmutación con el costo de mantener un clúster más pequeño con recuperación más rápida. Si el clúster más pequeño se recupera en un tiempo que evita la mayoría de los créditos SLA, el clúster más grande puede estar pagando por disponibilidad que nunca se usa.

Para SRE de inferencia, la regla práctica es tratar la energía como una dependencia de primera clase. Registra eventos de energía, disparos de interruptores, transiciones de UPS y fallas de refrigeración con la misma gravedad que las fallas de GPU. Si un evento de energía puede tumbar un pool de servicio, debe estar en el cálculo del impuesto por caídas. Si no puede, documenta por qué, y mantén el presupuesto de redundancia lo suficientemente pequeño como para no distorsionar el costo de inferencia.

Modelos

La elección del modelo cambia el impuesto por caídas de formas fáciles de pasar por alto. Un modelo grande puede necesitar más GPUs, un calentamiento más largo y más memoria para recargar, lo que eleva el término de consumo de cómputo. Un modelo más pequeño o cuantizado puede servir el mismo tráfico con menos capacidad, recuperación más corta y menor costo en espera. El dilema no es solo precisión. Es el costo de estar no disponible mientras el modelo se recupera.

Antes de la próxima expansión, ejecuta la fórmula con tu pila de servicio real. Usa la tarifa real de GPU, el tamaño real del clúster, el MTTR medido y la exposición real a créditos SLA. Si el impuesto por caídas es alto, pregunta si la solución es más capacidad o recuperación más rápida. Más capacidad es un instrumento tosco. Recuperación más rápida es uno más afilado: mejores comprobaciones de salud, conmutación más limpia, radio de impacto más pequeño y una ruta en espera que realmente puede tomar tráfico. El objetivo no es eliminar cada falla de energía. El objetivo es hacer que el costo de la próxima falla sea un número que puedas defender, no una sorpresa a posteriori.