Bezahlen Sie nicht für ungenutzte GPUs. Stellen Sie Rechenressourcen Just-in-Time bereit, verarbeiten Sie die Workload und fahren Sie sie wieder herunter – so werden Investitionsausgaben (CAPEX) zu betrieblichen Kosten pro Auftrag (OPEX).
Ihre Workload ist stoßweise – Video-Encoding-Aufträge, die Spitzen aufweisen, wenn Inhalte hochgeladen werden, ML-Trainingsläufe, die 8 GPUs für 4 Stunden benötigen und dann nichts mehr, Batch-Inferenzaufträge, die durch Geschäftsereignisse ausgelöst werden, oder Rendering-Pipelines, die über Nacht laufen. Sie sind entweder überdimensioniert (bezahlen 80% der Zeit für ungenutzte Ressourcen) oder unterdimensioniert (Aufträge stauen sich während Spitzenzeiten stundenlang). 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 Kaltstart-Penalty, 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-Warteschlangen-gesteuerte Bereitstellung und automatisierte Beendigung. Ein warm pool hält eine kleine Anzahl vorinitialisierter Instanzen bereit für den sofortigen Einsatz. Ein cold pool stellt zusätzliche Kapazität von Spot-/Preemptible-Instanzen bereit, wenn die Nachfrage den warm pool übersteigt. Ein job orchestrator leitet Aufgaben an verfügbare Instanzen weiter, überwacht den Fortschritt, handhabt Wiederholungsversuche bei Spot-Eviction und löst die Skalierung nach unten aus, wenn die Warteschlange leer ist. Das Muster ist besonders kritisch für GPU-Workloads, bei denen der Kaltstart (container pull + model loading) 3-10 Minuten dauern kann.
Das System zentriert sich um eine job queue (SQS, Redis oder custom), die eingehende Arbeitsanfragen puffert. Ein scaling controller überwacht die Warteschlangentiefe und stellt Instanzen zuerst aus dem warm pool, dann aus dem cold pool (spot instances) bereit. Jede worker instance zieht Aufträge aus der Warteschlange, führt die Workload (encoding, training, inference) aus, 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, wodurch Aufträge auf einer anderen Instanz ohne Neuanfang fortgesetzt werden können.

System Architecture Overview
| Schicht | Technologien |
|---|---|
| Rechenleistung | AWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal |
| Orchestrierung | Kubernetes (Karpenter for autoscaling), AWS Batch, benutzerdefinierter job orchestrator |
| Job-Warteschlange | AWS SQS, BullMQ (Redis), Temporal, Celery |
| Speicher | S3 (Checkpoints, Modellartefakte), NVMe (Modell-Cache), EFS (gemeinsamer Arbeitsbereich) |
| Überwachung | CloudWatch/Prometheus (Warteschlangentiefe, Instanzenauslastung, Job-Latenz), benutzerdefinierte Kosten-Dashboards |
| Verwenden, wenn | Vermeiden, wenn |
|---|---|
| Die Workload stoßweise ist — die Spitzennachfrage das 5-fache der durchschnittlichen Nachfrage übersteigt | Der Traffic stetig und vorhersehbar ist — richtig dimensionierte Reserved Instances günstiger sind |
| GPU-/High-Compute-Jobs bei Leerlauf teuer sind | Die Workload eine leichte CPU-Verarbeitung ist, die für Serverless (Lambda) geeignet ist |
| Jobs einen Kaltstart von 1-5 Minuten für die cold pool Bereitstellung tolerieren können | Sub-Sekunden-Job-Startlatenz erforderlich ist — Sie Always-on-Infrastruktur benötigen |
| Kostenoptimierung ein Hauptanliegen ist und Spot Pricing 60-90% Einsparungen bietet | Spot-Unterbrechungen zu Datenverlust führen würden, den Checkpointing nicht mindern kann |
MW entwirft On-Off-Skalierung mit dem Fokus auf "Kosten pro Auftrag" – wir modellieren die Gesamtkosten der Verarbeitung einer Arbeitseinheit (ein Video, ein Trainingslauf, eine Batch-Inferenz) ü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 Auftrag, Infrastrukturauslastung und Spot-Einsparungen anzeigen. Wir haben On-Off-GPU-Infrastruktur aufgebaut, die die Videoverarbeitungskosten um 70% im Vergleich zu Reserved Instances reduzierte, und ML-Trainingscluster, die 64 GPUs für einen 4-stündigen Trainingslauf bereitstellen und sie 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-intensiven oder periodischen Workloads sehen typischerweise 60-80% Cloud-Kostenreduzierungen nach der Implementierung von On-Off-Skalierung, da Rechenressourcen nur während aktiver Verarbeitungsfenster anstatt 24/7 laufen. Wir entwerfen Skalierungsrichtlinien basierend auf der tatsächlichen Nutzungstelemetrie – zum Beispiel zahlt eine Datenverarbeitungs-Pipeline, die täglich 4 Stunden läuft, nur für diese 4 Stunden anstatt für die vollen 24. Unsere Architekten analysieren Ihre Workload-Muster während einer Evaluierungsphase, um genaue Einsparungen zu prognostizieren, bevor eine Implementierung beginnt.
Kaltstartzeiten 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 nutzt mehrere Techniken, um diese Verzögerung zu minimieren. Wir implementieren prädiktive Skalierung, die Ressourcen vor der erwarteten Nachfrage basierend auf historischen Traffic-Mustern und geplanten Ereignissen hochfährt, und wir nutzen Container-Image-Pre-Pulling sowie Warm-Pool-Reservierungen für latenzempfindliche Workloads. Für Anwendungen, die keinen Kaltstart tolerieren können, halten wir eine minimale warme Basislinie aufrecht, die aggressiv hochskaliert, wenn Nachfrage entsteht.
MicrocosmWorks implementiert reaktives Auto-Scaling mit aggressiven Scale-up-Richtlinien, die durch Warteschlangentiefe, CPU-Auslastung oder benutzerdefinierte Anwendungsmetriken ausgelöst werden, kombiniert mit sanfteren Scale-down-Richtlinien, die Cooldown-Perioden beinhalten, um Thrashing zu vermeiden. Wir konfigurieren Over-Provisioning-Puffer während Scale-up-Ereignissen, damit das System ein anhaltendes Wachstum antizipiert, anstatt der Nachfrage Instanz für Instanz hinterherzujagen. Für wirklich unvorhersehbare Spitzen wie Flash Sales oder virale Ereignisse provisionieren wir Kapazität vorab unter Verwendung 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 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 Replikate basierend auf der Abfragelast hinzufügt und entfernt, während eine minimale primäre Instanz stets läuft. Dieser hybride Ansatz bietet Kunden die Kostenvorteile der Skalierung für ihre Datenschicht, ohne die Komplexität der Verwaltung des Datenbankzustands während Herunterfahr- und Neustartzyklen.
MicrocosmWorks implementiert umfassende Skalierungs-Observability, die Instanzanzahlen, die Latenz von Skalierungsereignissen, fehlgeschlagene Skalierungsversuche und die Lücke zwischen gewünschter und tatsächlicher Kapazität in Echtzeit mithilfe von Grafana- oder Datadog-Dashboards verfolgt. Wir konfigurieren Mehrkanal-Alarme für Skalierungsfehler, anhaltend hohe Auslastung, die darauf hindeutet, dass die Skalierungsobergrenze zu niedrig ist, und Kostenanomalien, die eine unkontrollierte Skalierung anzeigen. Unsere Runbooks beinhalten eine automatisierte Fehlerbehebung für häufige Fehlermodi, wie das Erreichen von Instanzlimits des Cloud-Anbieters oder das Auftreten von Fehlern bei unzureichender Kapazität in bestimmten Availability Zones.