Was ist das On-Off-Scaling-Muster, und wann ist es besser als traditionelles Auto-Scaling für AI-Workloads?

MicrocosmWorks entwickelte das On-Off-Scaling-Muster für Workloads, die vorhersagbare Bursts von GPU-intensiver Verarbeitung gefolgt von langen Leerlaufzeiten aufweisen, wo traditionelles Auto-Scaling Geld verschwendet, indem es während der Leerlaufzeiten eine minimale Kapazität aufrechterhält. Anstatt warm laufende Instanzen zu behalten, provisioniert das Muster GPU-Infrastruktur On-Demand, wenn ein Verarbeitungsauftrag eintrifft, führt den Workload aus und beendet die Infrastruktur vollständig, wenn die Arbeit erledigt ist, wodurch nahezu null Kosten während der Leerlaufperioden erzielt werden.

Wie minimiert das On-Off-Muster Cold-Start-Verzögerungen beim Provisioning von GPU-Instanzen für zeitkritische AI-Verarbeitung?

MicrocosmWorks reduzierte die Cold-Start-Zeiten auf unter 60 Sekunden, indem optimierte Container-Images mit allen AI-Modellgewichten und Abhängigkeiten vorgefertigt und in einer Registry gespeichert wurden, die geografisch nahe an der Compute-Region liegt. Die Orchestrierungsschicht verwendet prädiktives Provisioning für geplante Workloads, startet die Infrastruktur 2-3 Minuten vor der erwarteten Nachfrage, und für unvorhersehbare Workloads stellt das System Aufträge in eine Queue und sendet Benachrichtigungen über den Verarbeitungsstart, damit Benutzer wissen, dass ihre Anfrage bearbeitet wird.

Wie viel Kostenersparnis liefert das On-Off-Muster im Vergleich zum kontinuierlichen Betrieb von GPU-Instanzen?

MicrocosmWorks dokumentierte Kostenreduktionen von 70-90 % für Kunden, deren AI-Videoverarbeitungs-Workloads 2-6 Stunden pro Tag laufen, im Vergleich zum Betrieb von 24/7 GPU-Instanzen. Die Einsparungen ergeben sich aus der Bezahlung nur der tatsächlichen Verarbeitungszeit plus weniger Minuten Startup- und Teardown-Overhead, und das Muster ist besonders effektiv für Workflows wie nächtliche Batch-Videoverarbeitung, On-Demand-Transkodierung oder ereignisgesteuerte AI-Analyse, bei denen die Auslastung von Natur aus intermittierend ist.

Kann das On-Off-Muster Workloads bewältigen, die Hunderte von Videos parallel verarbeiten müssen?

Ja, MicrocosmWorks implementierte eine Fan-Out-Architektur innerhalb des On-Off-Musters, die bei großen Batch-Jobs mehrere GPU-Worker parallel provisioniert, Videodateien mithilfe einer Job-Queue auf die Worker verteilt und alle Worker herunterfährt, sobald der Batch abgeschlossen ist. Das System verfolgt den Fortschritt pro Video und behandelt individuelle Videofehler mit Wiederholungslogik, ohne den Rest des Batchs zu blockieren, und konsolidiert die Ergebnisse an einem einzigen Ausgabeort für die weiterführende Nutzung.

Was kostet die Implementierung des On-Off-Scaling-Musters für AI- und Videoverarbeitungs-Workloads?

MicrocosmWorks implementiert On-Off-Scaling-Architekturen zu Entwicklungsraten von 25-45 $/Std., wobei eine produktionsreife Implementierung einschließlich Job-Orchestrierung, Infrastruktur-Provisioning, Monitoring und Fehlerbehandlung typischerweise in 3-5 Wochen geliefert wird. Die Entwicklungsinvestition amortisiert sich in der Regel innerhalb von 1-2 Monaten allein durch die GPU-Kostenersparnisse, insbesondere für Organisationen, die derzeit Always-On-GPU-Instanzen betreiben, die mehr als 50 % des Tages im Leerlauf sind.

On-Off Scaling Pattern for AI & Video Processing Workload...

On-Off-Skalierungsmuster für AI- und Videoverarbeitungs-Workloads

Eine KI-gestützte Videoverarbeitungsplattform musste hochvariable Workloads bewältigen – von null Aufträgen außerhalb der Geschäftszeiten bis zu Hunderten gleichzeitiger Videoverarbeitungs- und AI-Inferenzaufgaben während Spitzenzeiten – ohne für ungenutzte GPU- und Compute-Ressourcen bezahlen zu müssen.

Ihr Projekt besprechen

Wir implementierten ein On-Off-Skalierungsmuster – eine hybride Architektur, bei der Compute-Ressourcen just-in-time für aktive Workloads bereitgestellt und bei Untätigkeit vollständig freigegeben werden, mit warm pools für latenzkritische Aufgaben und cold pools für Batch-Jobs.

Architektur

Job Queue: Datenbankgestützte Job Queue mit Prioritätsklassifizierung
Orchestrator: Dienst zur Verwaltung des Ressourcen-Lebenszyklus und des Job-Routings
GPU Workers (AI): Cloud GPU Pods für Inferenz (Objekterkennung, Transkription, Sprechererkennung)
CPU Workers (Video): Cloud VMs für Videokodierung und -rendering
Warm Pool: Vorinitialisierte Instanzen für latenzkritische Jobs (< 30s Startzeit)
Cold Pool: On-Demand-Instanzen für Batch-/Massenverarbeitung (2-5 Min. Startzeit akzeptabel)

Implementierung des On-Off-Musters

Ressourcen-Lebenszyklus-Zustände

Ressourcen durchlaufen einen definierten Lebenszyklus: von vollständig freigegeben (null Kosten), über die Bereitstellung und das Warmlaufen (Modellladen, Health Checks), zu den Zuständen bereit und in Verarbeitung, dann durch ein Cooldown-Fenster, bevor sie wieder freigegeben werden.

Warm Pool Strategie

Für latenzkritische Verarbeitung (benutzergesteuert, erwartet Ergebnisse innerhalb von Minuten):

Während der Geschäftszeiten einen minimalen warm pool von Instanzen aufrechterhalten
AI-Modelle beim Container-Start vorladen
Eingehende Jobs zuerst an warm instances weiterleiten
Zusätzliche warm instances hochskalieren, wenn die Warteschlangentiefe den Schwellenwert überschreitet
Konfigurierbarer Cooldown-Timer hält Instanzen zwischen sporadischen Jobs am Leben

Cold Pool Strategie

Für die Batch-Verarbeitung (nächtliche Bulk-Jobs, nicht dringende Neu-Kodierungen):

Standardmäßig keine Instanzen aktiv
Job Queue löst die Bereitstellung aus, wenn Batch-Jobs eingereicht werden
Bulk-optimierte Instanzen für Durchsatz über Latenz
Sofort nach Abschluss des Batches beenden
Spot-/Preemptible-Instanzen für erhebliche Kosteneinsparungen nutzen

Job-Klassifizierung & -Routing

Jobs werden automatisch nach Priorität und Typ klassifiziert und dann an den entsprechenden Pool weitergeleitet:

Hochprioritäre benutzergesteuerte AI-Aufgaben werden an warm GPU pools weitergeleitet
Kritische Echtzeit-Aufgaben werden an always-on dedizierte Instanzen weitergeleitet
Mittelprioritäre Kodierungsaufgaben werden an warm oder cold CPU pools weitergeleitet
Niedrigprioritäre Batch-Aufgaben werden an cold spot/preemptible instances weitergeleitet

Orchestrator-Logik

Scale-Up-Trigger

Warteschlangentiefe überschreitet konfigurierbaren Schwellenwert
Durchschnittliche Wartezeit überschreitet SLA für die Prioritätsstufe
Geplantes Hochfahren vor bekannten Spitzenzeiten
Manueller Trigger über admin API für erwartete Verkehrsspitzen

Scale-Down-Trigger

Keine Jobs verarbeitet während der Dauer des Cooldown-Fensters
Geplantes Herunterfahren nach Spitzenzeiten
Alle in der Warteschlange befindlichen Jobs abgeschlossen, ohne neue Einreichungen
Kostenschwelle für den Abrechnungszeitraum erreicht

Health & Recovery

Regelmäßige Health Probes auf allen aktiven Instanzen
Fehlerhafte Instanzen werden automatisch ersetzt
Fehlgeschlagene Jobs werden mit Wiederholungszähler neu in die Warteschlange gestellt und an eine andere Instanz weitergeleitet
Dead Letter Queue für Jobs, die die maximale Anzahl von Wiederholungen überschreiten

Kostenfaktor

Das On-Off-Muster erzielte eine Kostensenkung von ungefähr 70% im Vergleich zu einer always-on festen Infrastruktur, indem es ungenutzte Compute-Ressourcen außerhalb der Spitzenzeiten eliminierte, Ressourcen pro Job-Typ richtig dimensionierte und Spot-Instanzen für Batch-Workloads nutzte.

Hauptmerkmale

Keine Leerlaufkosten — Ressourcen werden vollständig freigegeben, wenn keine Jobs verarbeitet werden
Warm Pools — Vorinitialisierte Instanzen für latenzkritische Workloads
Cold Pools — On-Demand-Bereitstellung für Batch-Jobs zu geringsten Kosten
Job-Klassifizierung — Automatisches Routing basierend auf Priorität, Typ und Latenzanforderungen
Cooldown Windows — Konfigurierbares Idle-Timeout verhindert vorzeitiges Scale-Down zwischen Bursts
Spot/Preemptible Support — Batch-Jobs werden an rabattierte Instanzen weitergeleitet, um erhebliche Einsparungen zu erzielen
Health & Recovery — Automatischer Ersatz fehlerhafter Instanzen mit Job-Wiederwarteschlangen
Scheduled Scaling — Bekannte Verkehrsmuster mit zeitbasierten Bereitstellungsregeln antizipieren

On-Off-Skalierungsmuster für AI- und Videoverarbeitungs-Workloads

Die Herausforderung

Unsere Lösung

Architektur

Implementierung des On-Off-Musters

Ressourcen-Lebenszyklus-Zustände

Warm Pool Strategie

Cold Pool Strategie

Job-Klassifizierung & -Routing

Orchestrator-Logik

Scale-Up-Trigger

Scale-Down-Trigger

Health & Recovery

Kostenfaktor

Hauptmerkmale

Ergebnisse

Technologie-Stack

caseStudyDetail.more Fallstudien

Nutzung von RunPod für skalierbare, kostengünstige AI-Inferenz

KI-gestützte Rechnungsverarbeitung mit OCR und QuickBooks-Integration

Bereit, Ihr Unternehmen zu transformieren?

Clientseitige Anzeigeninsertion (CSAI) mit SCTE-35 Marker-Parsing & Multi-Plattform-Player-Integration

Häufig gestellte Fragen