On-Off Skaleringsmønster for AI- og videobehandlingsarbejdsbelastninger
En AI-drevet videobehandlingsplatform skulle håndtere meget varierende arbejdsbelastninger — fra nul opgaver i lavtrafiktider til hundredvis af samtidige videobehandlings- og AI-inferensopgaver i spidsbelastningstider — uden at betale for inaktive GPU- og beregningsressourcer.
Diskuter Dit Projekt
Udfordringen
AI- og videobehandlingsarbejdsbelastninger er iboende uregelmæssige og dyre:
- GPU-instanser er dyre, uanset om de behandler opgaver eller er inaktive
- Videoenkodning, transskription og AI-inferens kræver forskellige ressourceprofiler
- Forholdet mellem spidsbelastning og laveste punkt var 50:1 — 200+ opgaver under spidsbelastning, næsten nul over natten
- Traditionel automatisk skalering var for langsom (5-10 minutter "cold start") for tidskritiske brugeranmodninger
- Fast infrastruktur provisioneret til spidsbelastning medførte 80%+ spild i lavtrafiktider
Vores Løsning
Vi implementerede et On-Off skaleringsmønster — en hybrid arkitektur, hvor beregningsressourcer provisioneres just-in-time til aktive arbejdsbelastninger og fuldt deallokeres, når de er inaktive, med warm pools til latenstidskritiske opgaver og cold pools til batchjobs.
Arkitektur
- Jobkø: Databaseunderstøttet jobkø med prioritetsklassifikation
- Orkestrator: Tjeneste, der administrerer ressourcelivscyklus og jobrouting
- GPU Workers (AI): Cloud GPU pods til inferens (objektdetektering, transskription, højttalerdetektering)
- CPU Workers (Video): Cloud VM'er til videoenkodning og rendering
- Warm Pool: Forudinitialiserede instanser til latenstidskritiske jobs (< 30 sekunders opstart)
- Cold Pool: On-demand instanser til batch-/massebehandling (2-5 minutters opstart acceptabel)
On-Off Mønsterimplementering
Ressourcelivscyklustilstande
Ressourcer gennemgår en defineret livscyklus: fra fuldt deallokeret (nul omkostninger), gennem provisionering og "warming" (modeller indlæses, sundhedstjek), til klar- og behandlingstilstande, derefter gennem et "cooldown window", før de vender tilbage til deallokeret.
Warm Pool-strategi
For latenstidskritisk behandling (brugerinitieret, forventer resultater inden for få minutter):
- Oprethold en minimum warm pool af instanser i arbejdstiden
- Forudindlæs AI-modeller ved container-opstart
- Ruter indgående jobs til varme instanser først
- Skaler ud yderligere varme instanser, når kødybden overskrider tærsklen
- Konfigurerbar "cooldown timer" holder instanser aktive mellem sporadiske jobs
Cold Pool-strategi
For batchbehandling (massejobs over natten, ikke-presserende re-enkodninger):
- Nul instanser kører som standard
- Jobkøen udløser provisionering, når batchjobs indsendes
- Bulk-optimerede instanser for gennemstrømning frem for latenstid
- Afslut straks efter batch er fuldført
- Brug spot-/preemptible-instanser for betydelige omkostningsbesparelser
Jobklassifikation og -routing
Jobs klassificeres automatisk efter prioritet og type og rutes derefter til den passende pool:
- Høj prioritet brugerinitierede AI-opgaver rutes til varme GPU-pools
- Kritiske realtidstasks rutes til altid-aktive dedikerede instanser
- Medium prioritet enkodningsopgaver rutes til varme eller kolde CPU-pools
- Lav prioritet batch-opgaver rutes til kolde spot-/preemptible-instanser
Orkestratorlogik
Opskaleringsudløsere
- Kødybden overskrider konfigurerbar tærskel
- Gennemsnitlig ventetid overskrider SLA for prioritetsniveauet
- Planlagt opskalering før kendte spidsbelastningstider
- Manuel udløser via admin API for forventede trafikspidser
Nedskaleringsudløsere
- Ingen jobs behandlet i løbet af "cooldown window"
- Planlagt nedlukning efter spidsbelastningstider
- Alle køede jobs afsluttet uden nye indsendelser
- Omkostningstærskel nået for faktureringsperioden
Sundhed og gendannelse
- Regelmæssige sundhedstjek på alle aktive instanser
- Usunde instanser udskiftes automatisk
- Mislykkede jobs genkøes med genforsøgstæller og rutes til en anden instans
- Dead letter queue for jobs, der overskrider maks. antal genforsøg
Omkostningspåvirkning
On-Off mønsteret leverede cirka 70% omkostningsreduktion vs. altid-aktiv fast infrastruktur ved at eliminere inaktiv "compute" i lavtrafiktider, tilpasse ressourcer pr. jobtype og udnytte spotinstanser til batch-arbejdsbelastninger.
Nøglefunktioner
- Nul tomgangsomkostning — Ressourcer fuldt deallokeret, når de ikke behandler jobs
- Warm Pools — Forudinitialiserede instanser til latenstidskritiske arbejdsbelastninger
- Cold Pools — On-demand provisionering for batchjobs til laveste omkostning
- Jobklassifikation — Automatisk routing baseret på prioritet, type og latenstidskrav
- Cooldown Windows — Konfigurerbar "idle timeout" forhindrer for tidlig nedskalering mellem bursts
- Spot/Preemptible Support — Batchjobs rutes til nedsatte instanser for betydelige besparelser
- Sundhed og gendannelse — Automatisk udskiftning af usunde instanser med jobgenkøning
- Planlagt skalering — Forudse kendte trafikmønstre med tidsbaserede provisioneringsregler
Resultater
Teknologistak
caseStudyDetail.more Casestudier
Udforsk flere af vores tekniske implementeringer
Udnyttelse af RunPod til skalerbar, omkostningseffektiv AI-inferens
En AI-drevet videoanalyseplatform havde brug for højtydende GPU-beregning til objektgenkendelse og inferens i realtid på tværs af flere samtidige videostrømme – uden de uoverkommelige omkostninger ved dedikerede GPU-servere, der kører 24/7.
Kickly: AI-drevet projektplatform for startups
Kickly er en AI-drevet projektstyringsplatform bygget til startups – der kombinerer smart opgaveautomatisering, teamsamarbejde og sporing af fremskridt i realtid i ét produkt.
Klar til at Transformere Din Virksomhed?
Lad os drøfte, hvordan vi kan anvende lignende løsninger til dine udfordringer.