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.

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.
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 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.
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.
| Capa | Tecnologías |
|---|---|
| Cómputo | AWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal |
| Orquestación | Kubernetes (Karpenter para autoscaling), AWS Batch, custom job orchestrator |
| Cola de Trabajos | AWS SQS, BullMQ (Redis), Temporal, Celery |
| Almacenamiento | S3 (checkpoints, model artifacts), NVMe (model cache), EFS (shared workspace) |
| Monitoreo | CloudWatch/Prometheus (queue depth, instance utilization, job latency), custom cost dashboards |
| Usar Cuando | Evitar Cuando |
|---|---|
| La carga de trabajo es de ráfagas — la demanda máxima es 5 veces o más la demanda promedio | El 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 inactivos | La 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ío | Se 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 |
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.
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 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.