Cómo una startup de ML redujo su factura de AWS de $22,000 corrigiendo la programación

Una startup de aprendizaje automático con ocho ingenieros recortó recientemente su factura mensual de infraestructura en la nube por casi cinco mil dólares. El equipo logró estos ahorros no reescribiendo sus modelos de inferencia ni cambiando los tipos de instancia, sino alineando su horario de uso de GPU con los patrones reales de demanda de los usuarios. Este caso destaca cómo la sincronización operativa, más que solo la eficiencia arquitectónica, impulsa diferencias significativas en los costos en entornos de nube.

Qué sucedió

La startup ejecutaba una API de inferencia en producción que servía tráfico real, lo que resultaba en una factura de AWS de $22,000 al mes. La mayor parte de este costo provenía de los recursos de cómputo de GPU utilizados para la inferencia del modelo. Cuando un consultor revisó la cuenta, esperaba encontrar hardware sobreaprovisionado o código ineficiente. En cambio, descubrió que los tipos de instancia estaban bien adaptados a la carga de trabajo y que las tasas de utilización durante las horas activas eran razonables. No había desperdicios técnicos evidentes en la arquitectura misma.

La causa raíz del alto costo era temporal, no técnica. El análisis de los registros de tráfico reveló que el noventa por ciento de todas las solicitudes de los usuarios ocurrían entre las 9:00 a.m. y las 11:00 p.m. hora del este de EE. UU. (ET). El período nocturno estaba casi silencioso, consistiendo solo en comprobaciones automáticas de salud y trabajos secundarios menores. A pesar de esta falta de demanda, las instancias de GPU funcionaban a plena capacidad y precio completo las veinticuatro horas del día. El equipo había mantenido el clúster en su tamaño máximo durante la noche porque se sentían más seguros, lo que llevaba a ocho horas de utilización cercana a cero cada noche.

Para abordar esto, el equipo implementó un programa de reducción de escala. A las 11:00 p.m. ET, el clúster de inferencia reduce su escala a un estado mínimo "caliente" (warm state). Este estado es suficiente para manejar tareas en segundo plano y responder a las comprobaciones de salud, pero consume muchos menos recursos. A las 8:00 a.m. ET, antes del aumento del tráfico matutino, el clúster vuelve a escalar hasta su capacidad completa. Todo el cambio tomó solo dos días para implementarse y probarse de manera segura.

Detalles clave

• La factura mensual de AWS de la startup era de $22,000, impulsada principalmente por los costos de cómputo de GPU para la inferencia.
• El análisis de tráfico mostró que el 90% de las solicitudes ocurrían entre las 9:00 a.m. y las 11:00 p.m. hora del este de EE. UU.
• Las instancias de GPU funcionaban a plena capacidad 24/7, a pesar de ocho horas de tráfico de usuario cercano a cero cada noche.
• La solución implicaba reducir la escala a un estado mínimo caliente a las 11:00 p.m. y aumentar la escala a las 8:00 a.m. ET.
• La implementación tardó dos días en probarse y desplegarse sin cambiar la arquitectura subyacente ni los modelos.
• El ajuste resultó en ahorros mensuales de $4,800 al igualar la asignación de recursos con la demanda real.

Antecedentes

En la computación en la nube, especialmente con hardware especializado como las GPU, los costos suelen estar vinculados al tiempo de actividad (uptime) y no solo al procesamiento activo. Muchos equipos optan por mantener los clústeres a máxima capacidad para garantizar baja latencia y alta disponibilidad, temiendo que reducir la escala pueda introducir riesgos o retrasos. Este enfoque, a menudo llamado "sobreaprovisionamiento por seguridad", puede llevar a un desperdicio significativo durante las pausas predecibles en el tráfico.

FinOps, u operaciones financieras, es la práctica de gestionar los costos en la nube mediante la colaboración entre los equipos de ingeniería y finanzas. Un principio fundamental de FinOps es igualar el gasto con el valor empresarial. En este contexto, significa asegurar que los recursos costosos solo estén funcionando cuando están sirviendo activamente a los usuarios. Las políticas de escalado automático permiten a los equipos ajustar dinámicamente los recursos basándose en el tiempo o la carga, cerrando la brecha entre la confiabilidad técnica y la eficiencia financiera.

Por qué importa

Para los equipos que gestionan su propia infraestructura de software, este caso ilustra que la optimización de costos no siempre requiere refactorizaciones complejas. Los ingenieros a menudo se centran en la eficiencia del código o la indexación de bases de datos para reducir costos, pasando por alto los horarios operativos. Cuando los patrones de tráfico son predecibles, como en aplicaciones B2B con horarios comerciales distintos, las políticas de escalado estático pueden dejar dinero sobre la mesa. Reconocer que la "seguridad" mediante una capacidad máxima constante tiene una penalización financiera directa es un cambio crucial de mentalidad para los líderes de DevOps.

Además, esta historia subraya la importancia de la toma de decisiones basada en datos en la gestión de infraestructura. Sin analizar la distribución de marcas de tiempo de las solicitudes, el equipo asumía que su alta factura estaba justificada por una demanda constante. Simplemente observando cuándo los usuarios estaban realmente activos, identificaron una clara oportunidad de ahorro. Este enfoque es aplicable a muchos servicios autoalojados donde la carga fluctúa predeciblemente, desde herramientas internas hasta APIs orientadas al cliente.

Lo que puedes hacer

• Analiza los registros de tu servicio para identificar ventanas de tráfico pico y fuera de pico, buscando patrones diarios o semanales predecibles.
• Revisa tus actuales políticas de escalado automático para ver si permiten reducciones profundas de escala durante períodos conocidos de bajo tráfico.
• Implementa una configuración de "estado caliente" que mantenga las comprobaciones esenciales de salud y los trabajadores en segundo plano activos mientras reduce los nodos de cómputo costosos.
• Prueba los eventos de escalado en un entorno de staging para asegurarte de que los tiempos de ramp-up no impacten la experiencia del usuario durante los aumentos de tráfico.
• Configura alertas para picos de tráfico inusuales fuera de las ventanas esperadas para detectar anomalías sin mantener los recursos altos permanentemente.
• Revisa regularmente tu horario de escalado a medida que cambia el comportamiento del usuario, asegurando que tu estructura de costos siga alineada con la demanda real.