Betal ikke for inaktive GPU'er. Fremskaf compute just-in-time, behandl arbejdsbyrden, og nedlæg den igen — hvilket omdanner kapitaludgifter til en driftsomkostning per job.

Din arbejdsbyrde er "bursty" — videokodningsjobs, der stiger voldsomt, når indhold uploades, ML training kørsler, der kræver 8 GPU'er i 4 timer og derefter intet, batch inference jobs udløst af forretningshændelser, eller rendering pipelines, der kører natten over. Du er enten over-provisioneret (betaler for inaktive ressourcer 80 % af tiden) eller under-provisioneret (jobs står i kø i timevis i spidsbelastningsperioder). Du har brug for en arkitektur, der fremskaffer præcis den compute, du har brug for, når du har brug for den, og frigiver den, når jobbet er fuldført — uden den "cold-start"-straf, der gør "scale to zero" upraktisk for GPU-arbejdsbyrder.
Explore more design patterns and system architectures
Vores arkitekter kan hjælpe dig med at designe og bygge systemer ved hjælp af dette mønster til dine specifikke krav.
Kom i KontaktOn-off skaleringsarkitektur administrerer compute-ressourcer gennem warm/cold pooling, jobkø-drevet provisionering og automatiseret nedlæggelse. En warm pool opretholder et lille antal forud-initialiserede instanser klar til øjeblikkelig brug. En cold pool provisionerer yderligere kapacitet fra spot/preemptible instanser, når efterspørgslen overstiger den varme pulje. En job orchestrator dirigerer arbejde til tilgængelige instanser, overvåger fremskridt, håndterer genforsøg ved spot-opsigelse og udløser nedskalering, når køen tømmes. Mønsteret er særligt kritisk for GPU-arbejdsbyrder, hvor "cold start" (container pull + model loading) kan tage 3-10 minutter.
Systemet centrerer sig om en jobkø (SQS, Redis eller brugerdefineret), der buffer indkommende arbejdsanmodninger. En scaling controller overvåger kødybde og provisionerer instanser først fra "warm pool", derefter fra "cold pool" (spot instances). Hver worker instance trækker jobs fra køen, udfører arbejdsbyrden (encoding, training, inference), rapporterer færdiggørelse og vender tilbage til puljen eller terminerer. En checkpoint manager håndterer spot-opsigelse ved at gemme mellemliggende tilstand til S3, hvilket gør det muligt for jobs at genoptage på en anden instans uden at starte forfra.
| Lag | Teknologier |
|---|---|
| Compute | AWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal |
| Orchestration | Kubernetes (Karpenter for autoscaling), AWS Batch, brugerdefineret job orchestrator |
| Jobkø | AWS SQS, BullMQ (Redis), Temporal, Celery |
| Storage | S3 (checkpoints, model artifacts), NVMe (model cache), EFS (shared workspace) |
| Overvågning | CloudWatch/Prometheus (kødybde, instansudnyttelse, job latency), brugerdefinerede omkostningsdashboards |
| Brug når | Undgå når |
|---|---|
| Arbejdsbyrden er "bursty" — spidsbelastning er 5x+ gennemsnitlig efterspørgsel | Trafikken er stabil og forudsigelig — korrekt dimensionerede reserved instances er billigere |
| GPU/high-compute jobs, der er dyre, når de er inaktive | Arbejdsbyrden er letvægts CPU-behandling, der passer til serverless (Lambda) |
| Jobs kan tolerere 1-5 minutters "cold start" for "cold pool" provisionering | Sub-sekund jobstart latency er påkrævet — du har brug for always-on infrastruktur |
| Omkostningsoptimering er en primær bekymring, og spot pricing tilbyder 60-90% besparelser | Spot interruption ville forårsage datatab, som checkpointing ikke kan afhjælpe |
MW designer on-off skalering med en "pris per job"-linse – vi modellerer den samlede omkostning ved at behandle én arbejdsenhed (én video, én træningskørsel, én batch inference) på tværs af forskellige skaleringsstrategier og vælger den, der minimerer omkostningerne ved den påkrævede latency SLA. Vores implementeringer inkluderer realtidsomkostningsdashboards, der viser omkostninger per job, infrastrukturudnyttelse og spotbesparelser. Vi har bygget on-off GPU-infrastruktur, der reducerede video processing-omkostninger med 70 % sammenlignet med reserved instances, og ML training-klynger, der provisionerer 64 GPU'er til en 4-timers træningskørsel og frigiver dem automatisk.
Sikkerhed er ikke en funktion, du tilføjer efter lancering. Det er en arkitektonisk egenskab – enten er systemet designet til det, eller også er det ikke.
MicrocosmWorks-kunder med batch-tunge eller periodiske arbejdsbelastninger oplever typisk 60-80% reduktioner i cloud-omkostninger efter implementering af on-off skalering, fordi compute-ressourcer kun kører under aktive behandlingsvinduer i stedet for 24/7. Vi designer skaleringspolitikker baseret på faktisk brugstelemetri — for eksempel betaler en dataprocesseringspipeline, der kører 4 timer dagligt, kun for disse 4 timer i stedet for de fulde 24. Vores arkitekter analyserer jeres arbejdsbelastningsmønstre under en opdagelsesfase for at projicere nøjagtige besparelser, før nogen implementering påbegyndes.
Cold-start tider varierer fra 2-3 sekunder for containeriserede applikationer på forvarmede node pools til 5-10 minutter for arbejdsbelastninger, der kræver specialiserede GPU-instanser eller indlæsning af store modeller, og MicrocosmWorks anvender flere teknikker til at minimere denne forsinkelse. Vi implementerer prædiktiv skalering, der starter ressourcer op før forventet efterspørgsel ved hjælp af historiske trafikmønstre og planlagte begivenheder, og vi bruger container image pre-pulling og warm pool reservationer til latensfølsomme arbejdsbelastninger. For applikationer, der ikke kan tolerere nogen cold start, opretholder vi en minimal varm baseline, der skalerer aggressivt op, når efterspørgsel opstår.
MicrocosmWorks implementerer reaktiv auto-skalering med aggressive scale-up politikker udløst af kødybde, CPU-udnyttelse eller brugerdefinerede applikationsmetrikker, kombineret med mere gradvise scale-down politikker, der inkluderer cooldown-perioder for at undgå thrashing. Vi konfigurerer over-provisionering buffere under scale-up begivenheder, så systemet forudser fortsat vækst snarere end at jagte efterspørgsel én instans ad gangen. For ægte uforudsigelige spidser som flash sales eller virale begivenheder, forudprovisionerer vi kapacitet ved hjælp af event-drevne triggere fra jeres marketing- eller driftskalender.
MicrocosmWorks anvender on-off skalering på databaser ved hjælp af serverless database-tilbud som Aurora Serverless, Neon eller PlanetScale, der skalerer compute til nul i inaktive perioder, samtidig med at lagring holdes persistent og øjeblikkeligt tilgængelig. For stateful arbejdsbelastninger, der ikke kan bruge serverless databaser, implementerer vi read-replica skalering, der tilføjer og fjerner replikaer baseret på forespørgselsbelastning, samtidig med at en minimal primær instans altid kører. Denne hybridtilgang giver kunderne omkostningsfordelene ved skalering for deres data-tier uden kompleksiteten ved at administrere databasestatus under nedluknings- og genstarts-cyklusser.
MicrocosmWorks implementerer omfattende skalerings-observability, der sporer instansantal, skaleringsevent-latency, mislykkede skaleringsforsøg og forskellen mellem ønsket og faktisk kapacitet i realtid ved hjælp af Grafana eller Datadog dashboards. Vi konfigurerer multi-kanal alarmer for skaleringsfejl, vedvarende høj udnyttelse, der antyder, at skaleringsloftet er for lavt, og omkostningsanomalier, der indikerer løbsk skalering. Vores runbooks inkluderer automatiseret afhjælpning for almindelige fejltyper som at ramme cloud provider instansgrænser eller støde på utilstrækkelige kapacitetsfejl i specifikke availability zones.