No pague por GPUs inactivas. Provisión de cómputo justo a tiempo, procesamiento de la carga de trabajo y desmantelamiento, convirtiendo el gasto de capital en un costo operativo por tarea.

Su carga de trabajo es irregular — tareas de codificación de video que se disparan cuando se sube contenido, ejecuciones de entrenamiento de ML que necesitan 8 GPUs durante 4 horas y luego nada, tareas de inferencia por lotes activadas por eventos de negocio, o pipelines de renderizado que se ejecutan durante la noche. Usted está sobreaprovisionado (pagando por recursos inactivos el 80% del tiempo) o subaprovisionado (las tareas se encolan durante horas en los picos). Necesita una arquitectura que aprovisione exactamente el cómputo que necesita, cuando lo necesita, y lo libere cuando la tarea finalice — sin la penalización por arranque en frío que hace que "scale to zero" sea poco práctico para las GPU workloads.
Explore more design patterns and system architectures
Nuestros arquitectos pueden ayudarle a diseñar y construir sistemas utilizando este patrón para sus requisitos específicos.
Ponte en ContactoLa arquitectura de escalado on-off gestiona los recursos de cómputo a través de un pooling en caliente/frío, aprovisionamiento impulsado por cola de tareas y desmantelamiento automatizado. Un warm pool mantiene un pequeño número de instancias preinicializadas listas para uso inmediato. Un cold pool aprovisiona capacidad adicional a partir de instancias spot/preemptible cuando la demanda excede el warm pool. Un job orchestrator enruta el trabajo a las instancias disponibles, monitorea el progreso, maneja los reintentos en caso de spot eviction y activa el scale-down cuando la cola se vacía. El patrón es particularmente crítico para las GPU workloads donde el cold start (container pull + model loading) puede tomar de 3 a 10 minutos.
El sistema se centra en una job queue (SQS, Redis o personalizada) que almacena en búfer las solicitudes de trabajo entrantes. Un scaling controller monitorea la profundidad de la cola y aprovisiona instancias del warm pool primero, y luego del cold pool (instancias spot). Cada worker instance extrae tareas de la cola, ejecuta la carga de trabajo (codificación, entrenamiento, inferencia), informa su finalización y regresa al pool o termina. Un checkpoint manager maneja la spot eviction guardando el estado intermedio en S3, permitiendo que las tareas se reanuden en una instancia diferente sin empezar de nuevo.
| Capa | Tecnologías |
|---|---|
| Compute | AWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal |
| Orchestration | Kubernetes (Karpenter para autoscaling), AWS Batch, job orchestrator personalizado |
| Job Queue | AWS SQS, BullMQ (Redis), Temporal, Celery |
| Storage | S3 (checkpoints, artefactos de modelos), NVMe (model cache), EFS (espacio de trabajo compartido) |
| Monitoring | CloudWatch/Prometheus (profundidad de la cola, utilización de la instancia, job latency), paneles de control de costos personalizados |
| Usar Cuando | Evitar Cuando |
|---|---|
| La carga de trabajo es irregular — la demanda pico es 5x+ la demanda promedio | El tráfico es constante y predecible — las instancias reservadas de tamaño adecuado son más baratas |
| GPU/high-compute jobs que son caras cuando están inactivas | La carga de trabajo es procesamiento ligero de CPU que se adapta a serverless (Lambda) |
| Las tareas pueden tolerar 1-5 minutos de cold start para el aprovisionamiento del cold pool | Se requiere Sub-second job start latency — necesita una infraestructura siempre activa |
| La optimización de costos es una preocupación principal y el spot pricing ofrece un ahorro del 60-90% | La Spot interruption causaría pérdida de datos que el checkpointing no puede mitigar |
MW diseña escalado on-off con una óptica de "cost per job" — modelamos el costo total de procesar una unidad de trabajo (un video, una ejecución de entrenamiento, una inferencia por lotes) a través de diferentes estrategias de escalado y elegimos la que minimiza el costo con la latency SLA requerida. Nuestras implementaciones incluyen paneles de control de costos en tiempo real que muestran el per-job cost, la utilización de la infraestructura y los spot savings. Hemos construido infraestructura on-off para GPU que redujo los costos de procesamiento de video en un 70% en comparación con las instancias reservadas, y ML training clusters que aprovisionan 64 GPUs para una ejecución de entrenamiento de 4 horas y las liberan automáticamente.
La seguridad no es una característica que se añade después del lanzamiento. Es una propiedad arquitectónica: o el sistema fue diseñado para ella, o no lo fue.
Los clientes de MicrocosmWorks con cargas de trabajo pesadas por lotes o periódicas normalmente ven reducciones del 60-80% en los costos de la nube después de implementar el escalado on-off, porque los recursos informáticos solo se ejecutan durante las ventanas de procesamiento activas en lugar de 24/7. Diseñamos políticas de escalado basadas en la telemetría de uso real—por ejemplo, una pipeline de procesamiento de datos que se ejecuta durante 4 horas al día solo paga por esas 4 horas en lugar de las 24 completas. Nuestros arquitectos analizan sus patrones de carga de trabajo durante una fase de descubrimiento para proyectar ahorros exactos antes de que comience cualquier implementación.
Los tiempos de arranque en frío varían de 2 a 3 segundos para aplicaciones en contenedores en pools de nodos precalentados a 5-10 minutos para cargas de trabajo que requieren instancias de GPU especializadas o la carga de modelos grandes, y MicrocosmWorks utiliza varias técnicas para minimizar este retraso. Implementamos escalado predictivo que activa recursos antes de la demanda anticipada utilizando patrones de tráfico históricos y eventos programados, y utilizamos pre-extracción de imágenes de contenedores y reservas de pools en caliente para cargas de trabajo sensibles a la latencia. Para aplicaciones que no pueden tolerar ningún arranque en frío, mantenemos una base de referencia mínima en caliente que escala agresivamente cuando llega la demanda.
MicrocosmWorks implementa autoescalado reactivo con políticas de escalado ascendente agresivas activadas por la profundidad de la cola, la utilización de la CPU o métricas de aplicación personalizadas, combinadas con políticas de escalado descendente más graduales que incluyen períodos de enfriamiento para evitar el 'thrashing'. Configuramos búferes de sobreaprovisionamiento durante los eventos de escalado ascendente para que el sistema anticipe un crecimiento continuo en lugar de perseguir la demanda una instancia a la vez. Para picos verdaderamente impredecibles como ventas flash o eventos virales, preaprovisionamos capacidad utilizando activadores basados en eventos de su calendario de marketing u operaciones.
MicrocosmWorks aplica on-off scaling a las bases de datos utilizando ofertas de bases de datos serverless como Aurora Serverless, Neon o PlanetScale que escalan la computación a cero durante los períodos de inactividad, mientras mantienen el almacenamiento persistente y disponible al instante. Para cargas de trabajo con estado que no pueden usar bases de datos serverless, implementamos el escalado de réplicas de lectura que añade y elimina réplicas basado en la carga de consultas, mientras se mantiene una instancia primaria mínima siempre en ejecución. Este enfoque híbrido ofrece a los clientes los beneficios de costos del escalado para su capa de datos sin la complejidad de gestionar el estado de la base de datos durante los ciclos de apagado y reinicio.
MicrocosmWorks implementa una observabilidad de escalado integral que rastrea el número de instancias, la latencia de los eventos de escalado, los intentos de escalado fallidos y la brecha entre la capacidad deseada y la real en tiempo real utilizando paneles de Grafana o Datadog. Configuramos alertas multicanal para fallos de escalado, una alta utilización sostenida que sugiere que el límite de escalado es demasiado bajo y anomalías de costos que indican un escalado descontrolado. Nuestros runbooks incluyen remediación automatizada para modos de fallo comunes, como alcanzar los límites de instancias del proveedor de la nube o encontrar errores de capacidad insuficiente en zonas de disponibilidad específicas.