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 GPU inactivas. Aprovisione cómputo justo a tiempo, procese la carga de trabajo y desmántela, convirtiendo el gasto de capital en un costo operativo por trabajo.

June 18, 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 Necesita Esto

Su carga de trabajo es de ráfagas — trabajos de codificación de video que se disparan cuando se carga contenido, ejecuciones de entrenamiento de ML que necesitan 8 GPUs durante 4 horas y luego nada, trabajos de inferencia por lotes activados por eventos de negocio, o pipelines de renderizado que se ejecutan durante la noche. Usted está sobre-aprovisionado (pagando por recursos inactivos el 80% del tiempo) o sub-aprovisionado (los trabajos se acumulan en cola durante horas en los picos). Necesita una arquitectura que aprovisione exactamente la capacidad de cómputo que necesita, cuando la necesita, y la libere cuando el trabajo se completa — sin la penalización de 'arranque en frío' que hace que 'escala a cero' sea poco práctico para cargas de trabajo de GPU.

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

Resumen del Patrón

La arquitectura de escalado on-off gestiona los recursos de cómputo mediante agrupación en pools 'calientes/fríos' (warm/cold pooling), aprovisionamiento impulsado por colas de trabajo y desmantelamiento automatizado. Un pool caliente mantiene un pequeño número de instancias preinicializadas listas para uso inmediato. Un pool frío aprovisiona capacidad adicional a partir de instancias spot/preemptible cuando la demanda excede la del pool caliente. Un orquestador de trabajos enruta el trabajo a las instancias disponibles, monitorea el progreso, maneja los reintentos en caso de expulsión de spot y activa la reducción de escala cuando la cola se vacía. El patrón es particularmente crítico para cargas de trabajo de GPU donde el arranque en frío (descarga de contenedor + carga de modelo) puede tomar de 3 a 10 minutos.

Arquitectura de Referencia

El sistema se centra en una cola de trabajos (SQS, Redis, o personalizada) que almacena en búfer las solicitudes de trabajo entrantes. Un controlador de escalado monitorea la profundidad de la cola y aprovisiona instancias del pool caliente primero, luego del pool frío (instancias spot). Cada instancia de trabajador extrae trabajos de la cola, ejecuta la carga de trabajo (codificación, entrenamiento, inferencia), informa su finalización y regresa al pool o termina. Un gestor de puntos de control maneja la expulsión de spot guardando el estado intermedio en S3, permitiendo que los trabajos se reanuden en una instancia diferente sin empezar de nuevo.

Componentes Centrales
  • Job Queue & Scheduler: Cola de trabajos priorizada con límites de concurrencia configurables por tipo de trabajo. Soporta ejecución retrasada, colas de mensajes fallidos (dead-letter queues) para trabajos fallidos y carriles de prioridad (los trabajos express obtienen instancias del pool caliente, los trabajos estándar usan el pool frío). AWS SQS, BullMQ on 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 comprobaciones de estado aprobadas. 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 de demanda históricos
  • Cold Pool Provisioner: Aprovisiona capacidad adicional de instancias spot (AWS), VMs preemptible (GCP) o proveedores de GPU serverless (RunPod, Modal, Salad). Maneja las notificaciones de interrupción de spot migrando los trabajos a instancias disponibles. Utiliza una estrategia diversificada de tipos de instancia (múltiples tipos de GPU, múltiples AZs) para maximizar la disponibilidad de spot
  • Checkpoint & Recovery: Para trabajos de larga duración (entrenamiento de ML, codificación de video grande), el checkpointing periódico guarda el estado intermedio en S3. En caso de expulsión de spot, el trabajo se vuelve a encolar y se reanuda desde el último punto de control. Para trabajos cortos (< 10 min), el costo del checkpointing excede el costo de reinicio — estos trabajos simplemente se reintentan desde cero

Decisiones de Diseño y Compromisos

Tamaño del Pool Caliente
El tamaño del pool caliente es un compromiso entre el costo (pagar por instancias inactivas) y la latencia (tiempo de arranque en frío para el primer trabajo). MicrocosmWorks dimensiona los pools calientes basándose en los patrones de llegada de la cola: si los trabajos llegan continuamente durante el horario comercial, el pool caliente cubre el rendimiento promedio; el pool frío cubre los picos. Si los trabajos llegan en ráfagas impredecibles, mantenemos un pool caliente más pequeño y aceptamos la latencia de arranque en frío para los primeros trabajos en ráfaga mientras el pool frío se aprovisiona.
Instancias Spot vs. GPU Serverless (RunPod/Modal)
Las instancias Spot son más baratas por hora, pero requieren que usted gestione el aprovisionamiento, el manejo de desalojos y el ciclo de vida de la instancia. Los proveedores de GPU serverless (RunPod Serverless, Modal, Banana) manejan el aprovisionamiento y ofrecen facturación por segundo, pero a una tasa por segundo de cómputo más alta. MicrocosmWorks utiliza instancias spot para cargas de trabajo predecibles y de larga duración (>30 min) y GPU serverless para trabajos cortos y con ráfagas (<10 min) donde el sobrecosto de aprovisionamiento sería dominante.
Agresividad de la Reducción de Escala
Reduzca la escala demasiado rápido y pagará penalizaciones de arranque en frío cuando llegue el siguiente trabajo. Reduzca la escala demasiado lento y pagará por instancias inactivas. MicrocosmWorks implementa una estrategia de "enfriamiento con decaimiento": después de que la cola se vacía, las instancias permanecen 'calientes' durante un período configurable (predeterminado: 10 minutos). Si no llegan nuevos trabajos, las instancias se reducen progresivamente (50% a los 10 min, el resto a los 30 min). El período de enfriamiento es ajustable y se autoajusta basándose en las estadísticas de tiempo entre llegadas.
Optimización de Carga de Modelos de GPU
Para la inferencia de ML, el cuello de botella del arranque en frío suele ser la carga del modelo (descarga desde S3 + carga en la memoria de la GPU), no el inicio del contenedor. MicrocosmWorks optimiza esto mediante: (a) pre-cargando modelos en imágenes de contenedor (para modelos pequeños), (b) usando almacenamiento NVMe compartido entre instancias con caché de modelos (para modelos grandes), y (c) manteniendo instancias de pool caliente con modelos precargados en la memoria de la GPU.

Opciones Tecnológicas

CapaTecnologías
CómputoAWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal
OrquestaciónKubernetes (Karpenter para autoscaling), AWS Batch, custom job orchestrator
Cola de TrabajosAWS SQS, BullMQ (Redis), Temporal, Celery
AlmacenamientoS3 (checkpoints, model artifacts), NVMe (model cache), EFS (shared workspace)
MonitoreoCloudWatch/Prometheus (queue depth, instance utilization, job latency), custom cost dashboards

Cuándo Usar / Cuándo Evitar

Usar CuandoEvitar Cuando
La carga de trabajo es de ráfagas — la demanda máxima es 5 veces o más la demanda promedioEl tráfico es constante y predecible — las instancias reservadas de tamaño adecuado son más baratas
Trabajos de GPU/alto cómputo que son caros cuando están inactivosLa carga de trabajo es un procesamiento ligero de CPU que se adapta a serverless (Lambda)
Los trabajos pueden tolerar un arranque en frío de 1-5 minutos para el aprovisionamiento del pool fríoSe requiere una latencia de inicio de trabajo de sub-segundo — necesita infraestructura siempre activa
La optimización de costos es una preocupación principal y el precio spot ofrece ahorros del 60-90%Una interrupción de spot causaría pérdida de datos que el checkpointing no puede mitigar

Nuestro Enfoque

MicrocosmWorks diseña el escalado on-off con una perspectiva de "costo por trabajo" — 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 el SLA de latencia requerido. Nuestras implementaciones incluyen paneles de costos en tiempo real que muestran el costo por trabajo, la utilización de la infraestructura y los ahorros de spot. Hemos construido infraestructura de GPU on-off que redujo los costos de procesamiento de video en un 70% en comparación con las instancias reservadas, y clústeres de entrenamiento de ML que aprovisionan 64 GPUs para una ejecución de entrenamiento de 4 horas y las liberan automáticamente.

Planes Relacionados

  • Orquestación de Clústeres de GPU para Cargas de Trabajo de IA — Aprovisionamiento y orquestación de GPU para entrenamiento de ML
  • Sistema de Videovigilancia de IA en Tiempo Real — Inferencia en ráfagas para eventos de análisis de video
  • Generador de Momentos Destacados Deportivos en Vivo — Procesamiento de video basado en eventos con cómputo en ráfagas

Casos de Estudio Relacionados

  • Procesamiento de Video con Patrón On-Off — Aprovisionamiento de GPU con pools calientes/fríos para cargas de trabajo de codificación de video
  • Plataforma de Codificación de Video — Codificación serverless y basada en spot con pools de trabajadores autoescalados
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 intensivas por lotes o periódicas suelen ver una reducción del 60-80% en los costos de la nube después de implementar la escalada on-off, porque los recursos de cómputo solo se ejecutan durante las ventanas de procesamiento activas en lugar de 24/7. Diseñamos políticas de escalada basadas en la telemetría de uso real; por ejemplo, una pipeline de procesamiento de datos que se ejecuta durante 4 horas diarias 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 los ahorros exactos antes de que comience cualquier implementación.

Los tiempos de cold-start varían de 2-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 carga de modelos grandes, y MicrocosmWorks utiliza varias técnicas para minimizar este retraso. Implementamos escalada predictiva que activa recursos antes de la demanda anticipada utilizando patrones de tráfico históricos y eventos programados, y usamos pre-descarga de imágenes de contenedores y reservas de pools calientes para cargas de trabajo sensibles a la latencia. Para aplicaciones que no pueden tolerar ningún arranque en frío, mantenemos una línea base cálida mínima que escala agresivamente cuando llega la demanda.

MicrocosmWorks implementa autoescalado reactivo con políticas de escalada 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 reducción más graduales que incluyen períodos de enfriamiento para evitar el 'thrashing'. Configuramos buffers de sobreaprovisionamiento durante los eventos de escalada para que el sistema anticipe un crecimiento continuo en lugar de perseguir la demanda instancia por instancia. Para picos verdaderamente impredecibles como ventas flash o eventos virales, preaprovisionamos capacidad utilizando disparadores impulsados por eventos de su calendario de marketing u operaciones.

MicrocosmWorks aplica la escalada on-off a las bases de datos utilizando ofertas de bases de datos serverless como Aurora Serverless, Neon o PlanetScale que escalan el cómputo a cero durante los períodos de inactividad mientras mantienen el almacenamiento persistente e instantáneamente disponible. Para cargas de trabajo con estado que no pueden usar bases de datos serverless, implementamos escalada de réplicas de lectura que añade y elimina réplicas según la carga de consultas, manteniendo siempre una instancia primaria mínima en ejecución. Este enfoque híbrido brinda a los clientes los beneficios de costos de la escalada 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 fallidos de escalado y la brecha entre la capacidad deseada y la real en tiempo real utilizando paneles de Grafana o Datadog. Configuramos alertas multicanal para fallas de escalado, utilización alta sostenida que sugiere que el límite de escalado es demasiado bajo y anomalías de costos que indican una escalada descontrolada. Nuestros runbooks incluyen remediación automatizada para modos de falla 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.