MicrocosmWorksInnovando y Arquitectando el Cosmos Digital
Acerca deContacto
MicrocosmWorksInnovando y Arquitectando el Cosmos Digital

Ofreciendo soluciones de TI que importan. Nos apasiona la tecnología, la seguridad y ayudar a las empresas a crecer a través de una infraestructura de TI confiable e innovadora.

[email protected]
+91 7011868196
New Delhi, India

Centro de Crecimiento de IA

Centro de IAInnovación para StartupsAcelerador Empresarial

Soluciones

Todas las SolucionesAplicaciones de Bienestar y FitnessPlataforma de Video con IADesarrollo de Agentes de IA

Recursos

PerspectivasGuías de la IndustriaPlanos de Casos de UsoPatrones de ArquitecturaEstudios de Caso

Compañía

Sobre NosotrosContactoNuestro Trabajo

Servicios

Consultoría DigitalInfraestructura en la NubeDesarrollo SaaSDesarrollo de IATecnología de Video
Desarrollo ERPPersonalización de ZohoDesarrollo de OdooIntegración de SalesforceDesarrollo de CRM Personalizado
Integración de QuickBooksSoluciones IoTDesarrollo de Blockchain
Consultoría de CiberseguridadSoporte IT - L3

© 2026 MicrocosmWorks. Todos los derechos reservados.

Política de PrivacidadTérminos de Servicio
Volver a Patrones de Arquitectura
InfrastructureAdvanced

Arquitectura de Escalado On-Off

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.

June 22, 2026
|
2 topics covered
Discuta Esta Arquitectura
on-off-scaling-architecture.webp
Infrastructure
Category
Advanced
Complexity
IA/ML, Medios y Entretenimiento
Industries
2+
Technologies

Cuándo lo Necesita

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.

Related Architecture Patterns

Explore more design patterns and system architectures

cloud-native-infrastructure.webp
Infrastructure

Infraestructura Cloud-Native

Infraestructura con versiones, probada y desplegada como código de aplicación, porque tu plataforma es tan fiable como lo que hay debajo.

EnterpriseView
security-first-architecture.webp

¿Necesita Ayuda Para Implementar Esta Arquitectura?

Nuestros arquitectos pueden ayudarle a diseñar y construir sistemas utilizando este patrón para sus requisitos específicos.

Ponte en Contacto

Visión General del Patrón

La 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.

Arquitectura de Referencia

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.

Componentes Principales
  • Job Queue & Scheduler: Cola de tareas priorizada con límites de concurrencia configurables por tipo de tarea. Soporta ejecución retrasada, dead-letter queues para tareas fallidas y carriles de prioridad (las tareas express obtienen instancias del warm pool, las tareas estándar usan el cold pool). AWS SQS, BullMQ en Redis, o Temporal para flujos de trabajo complejos
  • Warm Pool Manager: Mantiene N instancias preinicializadas con modelos cargados en la memoria de la GPU, contenedores en ejecución y controles de salud superados. Las instancias ciclan a través de: inactivo → asignado → procesando → inactivo. El tamaño del pool es configurable por hora del día (más grande durante el horario comercial, más pequeño durante la noche) y ajustable según los patrones históricos de demanda
  • Cold Pool Provisioner: Aprovisiona capacidad adicional de instancias spot (AWS), VMs preemptible (GCP) o proveedores de GPU sin servidor (RunPod, Modal, Salad). Maneja las spot interruption notifications migrando las tareas a las instancias disponibles. Utiliza una estrategia de tipo de instancia diversificada (multiple GPU types, multiple AZs) para maximizar la spot availability
  • Checkpoint & Recovery: Para tareas de larga duración (entrenamiento de ML, codificación de video grande), el periodic checkpointing guarda el estado intermedio en S3. En caso de spot eviction, la tarea se reenfielada y se reanuda desde el último checkpoint. Para tareas cortas (< 10 min), el costo del checkpointing excede el costo de reiniciar — estas tareas simplemente reintentan desde cero

Decisiones de Diseño y Compromisos

Warm Pool Size
El warm pool es un compromiso entre el costo (pagar por instancias inactivas) y la latencia (cold start time para la primera tarea). MW dimensiona los warm pools basándose en los patrones de llegada a la cola: si las tareas llegan continuamente durante el horario comercial, el warm pool cubre el rendimiento promedio; el cold pool cubre los picos. Si las tareas llegan en picos impredecibles, mantenemos un warm pool más pequeño y aceptamos la cold-start latency para las primeras tareas del pico mientras el cold pool se aprovisiona.
Spot Instances vs. Serverless GPU (RunPod/Modal)
Las instancias spot son más baratas por hora, pero requieren que usted gestione el aprovisionamiento, el manejo de la eviction y el ciclo de vida de la instancia. Los proveedores de Serverless GPU (RunPod Serverless, Modal, Banana) gestionan el aprovisionamiento y ofrecen facturación por segundo, pero a una tarifa por segundo de cómputo más alta. MW utiliza instancias spot para cargas de trabajo predecibles y de larga duración (>30 min) y Serverless GPU para tareas cortas y con picos (<10 min) donde la sobrecarga de aprovisionamiento dominaría.
Scale-Down Aggressiveness
Si realiza un scale down demasiado rápido, pagará cold-start penalties cuando llegue la siguiente tarea. Si realiza un scale down demasiado lento, pagará por instancias inactivas. MW implementa una estrategia de "cooldown with decay": después de que la cola se vacía, las instancias permanecen 'warm' durante un período configurable (predeterminado: 10 minutos). Si no llegan nuevas tareas, las instancias se reducen progresivamente (50% a los 10 min, el resto a los 30 min). El cooldown period es ajustable y se autoajusta según las estadísticas de tiempo entre llegadas.
GPU Model Loading Optimization
Para la ML inference, el cold-start bottleneck es a menudo la carga de modelos (descarga de S3 + carga en la memoria de la GPU), no el arranque del contenedor. MW optimiza esto mediante: (a) pre-baking de modelos en imágenes de contenedores (para modelos pequeños), (b) uso de shared NVMe storage a través de instancias con model caching (para modelos grandes), y (c) manteniendo instancias del warm pool con modelos precargados en la memoria de la GPU.

Opciones Tecnológicas

CapaTecnologías
ComputeAWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal
OrchestrationKubernetes (Karpenter para autoscaling), AWS Batch, job orchestrator personalizado
Job QueueAWS SQS, BullMQ (Redis), Temporal, Celery
StorageS3 (checkpoints, artefactos de modelos), NVMe (model cache), EFS (espacio de trabajo compartido)
MonitoringCloudWatch/Prometheus (profundidad de la cola, utilización de la instancia, job latency), paneles de control de costos personalizados

Cuándo Usar / Cuándo Evitar

Usar CuandoEvitar Cuando
La carga de trabajo es irregular — la demanda pico es 5x+ la demanda promedioEl 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 inactivasLa 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 poolSe 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

Nuestro Enfoque

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.

Planos Relacionados

  • GPU Cluster Orchestration for AI Workloads — GPU provisioning y orchestration para ML training
  • Real-Time AI Video Surveillance System — Burst inference para eventos de análisis de video
  • Live Sports Highlight Generator — procesamiento de video basado en eventos con burst compute

Casos de Estudio Relacionados

  • On-Off Pattern Video Processing — GPU provisioning con warm/cold pools para cargas de trabajo de codificación de video
  • Video Encoding Platform — codificación serverless y basada en spot con autoscaled worker pools
Related Technologies
Soluciones en la NubeDesarrollo de IA
Infrastructure

Arquitectura Primero en Seguridad

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.

EnterpriseView
serverless-first-architecture.webp
Infrastructure

Arquitectura Serverless-First

Paga solo por lo que usas, escala a cero cuando no lo necesites y deja de gestionar servidores por completo, pero sé consciente de cuándo la economía deja de ser favorable.

AdvancedView

Preguntas Frecuentes

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.