Bezahlen Sie nicht für inaktive GPUs. Stellen Sie Rechenleistung just-in-time bereit, verarbeiten Sie die Workload und fahren Sie sie wieder herunter – wodurch Investitionsausgaben zu laufenden Kosten pro Auftrag werden.
Ihre Workload ist sprunghaft – Video-Encoding-Aufträge, die bei Uploads ansteigen, ML-Trainingsläufe, die 8 GPUs für 4 Stunden benötigen und dann nichts, Batch Inference-Jobs, die durch Geschäftsereignisse ausgelöst werden, oder Rendering-Pipelines, die über Nacht laufen. Sie sind entweder überversorgt (zahlen 80 % der Zeit für inaktive Ressourcen) oder unterversorgt (Jobs stehen während Spitzenzeiten stundenlang in der Warteschlange). Sie benötigen eine Architektur, die genau die Rechenleistung bereitstellt, die Sie benötigen, wenn Sie sie benötigen, und diese freigibt, wenn der Auftrag abgeschlossen ist – ohne die Kaltstartstrafe, die „scale to zero“ für GPU-Workloads unpraktisch macht.
Explore more design patterns and system architectures
Unsere Architekten können Ihnen helfen, Systeme mit diesem Muster für Ihre spezifischen Anforderungen zu entwerfen und zu erstellen.
Kontakt aufnehmen
Die On-Off-Skalierungsarchitektur verwaltet Rechenressourcen durch Warm-/Kalt-Pooling, Job-Queue-gesteuerte Bereitstellung und automatisiertes Herunterfahren. Ein Warm Pool unterhält eine kleine Anzahl vorinitialisierter Instanzen, die sofort einsatzbereit sind. Ein Cold Pool stellt zusätzliche Kapazitäten aus Spot-/Preemptible-Instanzen bereit, wenn die Nachfrage den Warm Pool übersteigt. Ein Job Orchestrator leitet Aufträge an verfügbare Instanzen weiter, überwacht den Fortschritt, handhabt Wiederholungen bei Spot Eviction und löst eine Skalierung nach unten aus, wenn die Warteschlange leer ist. Das Muster ist besonders kritisch für GPU-Workloads, bei denen der Kaltstart (Container-Pull + Modell-Laden) 3-10 Minuten dauern kann.
Das System konzentriert sich auf eine Job Queue (SQS, Redis oder benutzerdefiniert), die eingehende Arbeitsanfragen puffert. Ein Scaling Controller überwacht die Warteschlangentiefe und stellt Instanzen zuerst aus dem Warm Pool und dann aus dem Cold Pool (Spot-Instanzen) bereit. Jede Worker Instance zieht Jobs aus der Warteschlange, führt die Workload aus (Encoding, Training, Inference), meldet den Abschluss und kehrt zum Pool zurück oder wird beendet. Ein Checkpoint Manager handhabt Spot Eviction, indem er den Zwischenzustand in S3 speichert, sodass Jobs auf einer anderen Instanz fortgesetzt werden können, ohne von vorne zu beginnen.

System Architecture Overview
| Schicht | Technologien |
|---|---|
| Rechenleistung | AWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal |
| Orchestrierung | Kubernetes (Karpenter für Autoscaling), AWS Batch, benutzerdefinierter Job Orchestrator |
| Job Queue | AWS SQS, BullMQ (Redis), Temporal, Celery |
| Speicher | S3 (Checkpoints, Modell-Artefakte), NVMe (Modell-Cache), EFS (gemeinsamer Arbeitsbereich) |
| Monitoring | CloudWatch/Prometheus (Warteschlangentiefe, Instanzauslastung, Job-Latenz), benutzerdefinierte Kosten-Dashboards |
| Verwenden, wenn | Vermeiden, wenn |
|---|---|
| Workload ist sprunghaft – Spitzennachfrage ist 5x+ der durchschnittlichen Nachfrage | Traffic ist stetig und vorhersehbar – richtig dimensionierte Reserved Instances sind günstiger |
| GPU-/High-Compute-Jobs, die im Leerlauf teuer sind | Die Workload ist leichte CPU-Verarbeitung, die für Serverless (Lambda) geeignet ist |
| Jobs können 1-5 Minuten Kaltstart für die Cold Pool-Bereitstellung tolerieren | Job-Startlatenz im Sub-Sekundenbereich ist erforderlich – Sie benötigen Always-On-Infrastruktur |
| Kostenoptimierung ist ein Hauptanliegen und Spot-Preise bieten 60-90% Ersparnisse | Spot-Unterbrechung würde Datenverlust verursachen, den Checkpointing nicht mindern kann |
MW entwickelt On-Off-Skalierung unter dem Blickwinkel der „Kosten pro Job“ – wir modellieren die Gesamtkosten für die Verarbeitung einer Arbeitseinheit (ein Video, ein Trainingslauf, eine Batch Inference) über verschiedene Skalierungsstrategien hinweg und wählen diejenige, die die Kosten bei der erforderlichen Latenz-SLA minimiert. Unsere Implementierungen umfassen Echtzeit-Kosten-Dashboards, die Kosten pro Job, Infrastrukturnutzung und Spot-Einsparungen anzeigen. Wir haben On-Off-GPU-Infrastruktur aufgebaut, die die Videoverarbeitungskosten um 70 % im Vergleich zu Reserved Instances reduziert hat, und ML-Trainingscluster, die 64 GPUs für einen 4-stündigen Trainingslauf bereitstellen und diese automatisch wieder freigeben.
Sicherheit ist kein Feature, das man nach dem Launch hinzufügt. Es ist eine architektonische Eigenschaft – entweder wurde das System dafür konzipiert, oder eben nicht.
Kunden von MicrocosmWorks mit Batch-lastigen oder periodischen Workloads erzielen in der Regel 60-80% Cloud-Kostenreduzierungen nach der Implementierung von On-Off-Skalierung, da Compute-Ressourcen nur während aktiver Verarbeitungsfenster laufen statt 24/7. Wir entwickeln Skalierungsrichtlinien basierend auf tatsächlicher Nutzungs-Telemetrie – zum Beispiel zahlt eine Datenverarbeitungspipeline, die täglich 4 Stunden läuft, nur für diese 4 Stunden anstatt für die vollen 24 Stunden. Unsere Architekten analysieren Ihre Workload-Muster während einer Discovery-Phase, um genaue Einsparungen zu prognostizieren, bevor eine Implementierung beginnt.
Cold-Start-Zeiten variieren von 2-3 Sekunden für containerisierte Anwendungen auf vorgewärmten Node-Pools bis zu 5-10 Minuten für Workloads, die spezialisierte GPU-Instanzen oder das Laden großer Modelle erfordern, und MicrocosmWorks verwendet mehrere Techniken, um diese Verzögerung zu minimieren. Wir implementieren prädiktive Skalierung, die Ressourcen vor erwarteter Nachfrage mithilfe historischer Traffic-Muster und geplanter Ereignisse hochfährt, und wir nutzen Container-Image-Pre-Pulling sowie Warm-Pool-Reservierungen für latenzempfindliche Workloads. Für Anwendungen, die keinen Cold Start tolerieren können, halten wir eine minimale warme Basislinie aufrecht, die bei eintreffender Nachfrage aggressiv hochskaliert.
MicrocosmWorks implementiert reaktive Auto-Skalierung mit aggressiven Scale-up-Richtlinien, die durch Queue-Tiefe, CPU-Auslastung oder benutzerdefinierte Anwendungsmetriken ausgelöst werden, kombiniert mit graduelleren Scale-down-Richtlinien, die Cooldown-Perioden beinhalten, um Thrashing zu vermeiden. Wir konfigurieren Over-Provisioning-Puffer während Scale-up-Ereignissen, sodass das System kontinuierliches Wachstum antizipiert, anstatt die Nachfrage Instanz für Instanz zu verfolgen. Für wirklich unvorhersehbare Spitzen wie Flash Sales oder virale Ereignisse pre-provisionieren wir Kapazität mithilfe ereignisgesteuerter Trigger aus Ihrem Marketing- oder Operations-Kalender.
MicrocosmWorks wendet On-Off-Skalierung auf Datenbanken an, indem es serverlose Datenbankangebote wie Aurora Serverless, Neon oder PlanetScale nutzt, die Compute-Ressourcen in Leerlaufzeiten auf null skalieren, während der Speicher persistent und sofort verfügbar bleibt. Für zustandsbehaftete Workloads, die keine serverlosen Datenbanken nutzen können, implementieren wir Read-Replica-Skalierung, die Replicas basierend auf der Query-Last hinzufügt und entfernt, während eine minimale primäre Instanz immer läuft. Dieser hybride Ansatz bietet Kunden die Kostenvorteile der Skalierung für ihre Daten-Tier, ohne die Komplexität der Verwaltung des Datenbankstatus während der Shutdown- und Neustart-Zyklen.
MicrocosmWorks implementiert eine umfassende Skalierungs-Observability, die Instanzzahlen, Skalierungsereignislatenz, fehlgeschlagene Skalierungsversuche und die Diskrepanz zwischen gewünschter und tatsächlicher Kapazität in Echtzeit mithilfe von Grafana- oder Datadog-Dashboards verfolgt. Wir konfigurieren Mehrkanal-Alerts für Skalierungsfehler, anhaltend hohe Auslastung, die darauf hindeutet, dass die Skalierungsobergrenze zu niedrig ist, und Kostenanomalien, die auf eine außer Kontrolle geratene Skalierung hinweisen. Unsere Runbooks beinhalten automatisierte Behebung für gängige Fehlerursachen wie das Erreichen von Cloud Provider Instanzlimits oder das Auftreten von Fehlern aufgrund unzureichender Kapazität in bestimmten Availability Zones.