Laat uw AI-workload uw cloudfactuur exploderen?

Wij geloven er heilig in dat elk bedrijf in de komende paar jaar een Machine Learning (ML)-bedrijf zal zijn. Naarmate organisaties ML omarmen, is een van de belangrijkste uitdagingen waarmee ze worden geconfronteerd het beheren van de bijbehorende cloudkosten. Het uitvoeren van AI/ML-workloads in de cloud kan snel duur worden, maar met zorgvuldige planning en optimalisatie is het mogelijk om deze kosten aanzienlijk te verlagen.

In dit blogbericht verkennen we verschillende strategieën om u te helpen uw AI-infrastructuur te optimaliseren, waardoor uw cloudkosten uiteindelijk worden verlaagd zonder dat dit ten koste gaat van de prestaties of schaalbaarheid. Hieronder staan de brede categorieën om te overwegen:

1. Meet en koppel kosten aan de juiste eigenaar
2. Verlaag compute-kosten door spot- / reserved instances te gebruiken
3. Kies de juiste deployment-architectuur
4. Implementeer autoscaling
5. Colocatie van compute en data
6. Stap over op gehoste notebooks met automatische stopfunctie in plaats van een toegewezen VM voor elke ontwikkelaar
7. Gebruik waar mogelijk checkpointing om langlopende training-jobs te hervatten
8. Efficiënt GPU-gebruik

Meet en koppel kosten aan de juiste eigenaar

Na met heel wat organisaties te hebben samengewerkt en uit onze eigen ervaring, blijkt dat een groot deel van de kosten simpelweg ontstaat door menselijke fouten, zoals het vergeten uit te schakelen van VM's en services, of een onjuist architectuurontwerp dat extra kosten met zich meebrengt. Volledig inzicht hebben in wie wat bezit en welke kosten worden gemaakt op team- of projectbasis helpt om kosteneffecten sneller op te sporen en zorgt ervoor dat iedereen verantwoordelijk is voor zijn eigen projecten.

Wat je niet meet, kun je niet verbeteren

De allereerste stap bij het optimaliseren van een ML-workload is het beginnen met meten en toewijzen van de kosten. Hieronder vindt u enkele initiatieven die u kunt nemen:

1. Houd kosten bij op het niveau van elke microservice, elk project of elk team.
2. Bied kostentransparantie aan alle ontwikkelaars en zorg ervoor dat zij in staat worden gesteld om kosten te begrijpen en te verlagen.
3. Stel waarschuwingen (alerts) in voor cloudkosten.
4. Gebruik tools zoals Infracost.io om de kosten van de infrastructuur te meten vóór het provisionen als u Terraform gebruikt.

Verlaag compute-kosten

ML-workloads brengen enorme compute-kosten met zich mee, voornamelijk omdat ze hoge compute-bronnen vereisen - hetzij hoge CPU-vereisten of GPU's, die beide erg duur blijken te zijn. Hieronder staan enkele stappen die u kunt nemen om de compute-kosten te verlagen:

1. Model Distillation en Pruning om de resourcevereisten van uw model te verminderen
2. Gebruik Reserved en Spot instances om de kosten te verlagen. Volgens Amazon kunnen EC2 Spot Instances u potentieel tot 90% besparen op wat u anders aan On-Demand Instances zou uitgeven.
3. Kies de juiste resource-configuratie: We hebben vaak gezien dat ML-teams de resources voor ML-services en training-jobs overprovisionen. Dit kan betekenen dat u het verkeerde instance-type kiest als u met VM's werkt, of de verkeerde CPU- en geheugenvereisten kiest. Het is belangrijk om inzicht te krijgen in de aangevraagde en gebruikte CPU/geheugen om de waarden te kunnen afstemmen voor optimale kosten.

👉

Spot Instance: Met een Spot Instance krijgt u toegang tot ongebruikte EC2-capaciteit tegen een sterk gereduceerd tarief.

Wanneer u een Spot Instance start, geeft u een maximumprijs op die u bereid bent per uur te betalen. Als de Spot-prijs voor het gewenste instance-type en de Availability Zone lager is dan uw maximumprijs, wordt uw instance gestart. Als de Spot-prijs voor dat instance-type en die Availability Zone echter stijgt tot boven uw maximumprijs, kan uw instance worden beëindigd met een opzegtermijn van twee minuten.

👉

Reserved Instance: Hierbij verbindt u zich ertoe om gedurende een bepaalde periode een bepaalde hoeveelheid EC2-capaciteit te gebruiken. In ruil daarvoor ontvangt u een aanzienlijke korting op de On-Demand-prijs van die capaciteit.

We hebben een vergelijkende studie uitgevoerd in US East (N. Virginia) en ontdekten dat:

1. Spot instances beschikbaar waren tegen een 44%-62% goedkoper tarief.
2. 1-jarige reserved instances beschikbaar zijn tegen een 14% - 37% goedkoper tarief.

Kies de optimale deployment-architectuur

Verschillende use-cases in ML vereisen verschillende architecturen, en het kiezen van het verkeerde ontwerp kan hier leiden tot enorme verschillen in kosten. Enkele van de meest voorkomende use-cases en fouten die we hebben gezien zijn:

1. Realtime Inference: In dit geval is de latency van de model-inference korter dan 1-2 seconden (vaak in de orde van milliseconden) en is het verkeersvolume hoog. Het model moet worden geïmplementeerd als een realtime autoscaling API en we hebben meestal gemerkt dat requests/second een betere metriek is voor autoscaling dan CPU of geheugen in veel ML-use-cases. Als het verkeersvolume piekerig is (zoals 2-3 uur per dag) en het model klein is, blijkt serverless deployment (AWS Lambda) een kosteneffectievere manier van deployment te zijn.
2. Async Inference: In dit geval kan de verwerkingslogica enkele seconden duren en moet er een queue worden ingericht voor betere betrouwbaarheid - anders leidt dit tot fouten en verlies van bedrijfsresultaten. Voor autoscaling is de lengte van de queue een goede metriek in deze use-cases.
3. Meerdere kleine modellen met piekerig verkeer: Dit is een veelvoorkomende use-case bij veel bedrijven waar modellen klantspecifiek zijn. In dit geval is er een groot aantal modellen, ontvangt elk van hen een kleine hoeveelheid verkeer en zijn de latency-verwachtingen vrij laag. In dit geval host één container meerdere modellen en worden de modellen dynamisch in het geheugen geladen en ontladen op basis van de behoefte. Er zijn hier uitdagingen met betrekking tot welke modellen al in welke pods zijn geladen, en de requests moeten dienovereenkomstig worden gerouteerd.
4. Resource-intensieve onregelmatige verwerking / cron-jobs: Dit kan de use-case zijn als modellen dynamisch worden getraind op basis van bepaalde gebruikersacties. In dit geval werkt async inference mogelijk niet omdat de verwerkingstaak enkele minuten kan duren. In dit geval moet de verwerking als jobs worden ingediend bij een workflow orchestrator en moeten de realtime updates van de job naar een notificatie-queue worden gestuurd.

Vaak kan het modelleren van een van de use-cases in een verkeerde architectuur leiden tot verlies van betrouwbaarheid, extra latency of hoge cloudfacturen.

Implementeer Autoscaling

Mensen gaan ervan uit dat autoscaling alleen nuttig is wanneer er een hoog verkeersvolume is en machines op- of afgeschaald moeten worden op basis van het inkomende verkeer. We willen het concept van autoscaling echter ook uitbreiden naar dev-ontwikkelomgevingen om kosten te besparen. Enkele gebieden waar autoscaling kan helpen om drastisch op de kosten te besparen zijn:

1. Schaal uw compute-behoefte automatisch op basis van de vraag: Maak gebruik van de auto-scaling-mogelijkheden om de omvang van uw infrastructuur dynamisch aan te passen op basis van de vraag van de workload. Door automatisch op of af te schalen, kunt u het resourcegebruik optimaliseren en de kosten verlagen tijdens periodes van lage activiteit. Identificeer geschikte drempelwaarden en triggers voor schalen op basis van uw workloadpatronen om te zorgen voor een optimale allocatie van resources.
2. Schaal infrastructuur af naar nul wanneer deze niet in gebruik is (bijv. dev-instances 's nachts): Een deel van de infrastructuur in een organisatie is niet nodig als er geen gebruikers zijn. Het implementeren van een systeem om de compute-infrastructuur naar nul te schalen wanneer deze niet nodig is, kan een aanzienlijke besparing opleveren voor een organisatie.
3. Vraag instance-reservering aan bij uw cloudprovider: Het aanvragen van reserved instances bij uw cloudprovider kan u goede kortingen opleveren wanneer u een meer voorspelbare compute-behoefte heeft.
4. Dwing het gebruik van spot instances af voor stateless workloads: Maak gebruik van spot instances (AWS) of preemptible VM's (Google Cloud) voor fouttolerante ML-workloads. Deze instances zijn aanzienlijk goedkoper dan on-demand instances, waardoor u kosten kunt besparen door te bieden op ongebruikte capaciteit. Houd echter rekening met de mogelijkheid van het beëindigen van de instance en ontwerp uw infrastructuur zo dat onderbrekingen soepel worden opgevangen. Om het verschil in prijzen van on-demand en spot instances te laten zien, vergelijken we de prijzen van een T4 GPU per maand in AWS en Azure.

g4dn.xlarge : $383 (On-demand) vs $115(Spot)

NC4as T4 v3: $383 (On-demand) vs $49 (Spot)

Colocatie van compute en data

Het is belangrijk om de data en compute te coloceren, zodat we geen hoge ingress-/egress-kosten maken. Meestal houdt het trainingsproces in dat de data worden gedownload naar de machines waar het model wordt getraind. Enkele dingen om hier op te letten om onverwachte kosten te voorkomen zijn:

1. Deel data over meerdere data scientists: Het is belangrijk om één enkele kopie van de invoertrainingsdata te bewaren die door verschillende data scientists kan worden gebruikt, in plaats van voor elke data scientist een kopie te maken. Dit kan worden bereikt door een read-only volume met de data te mounten op alle trainingsmachines.
2. Verwijder ongebruikte volumes: Oftewel vergeten we de volumes te verwijderen die we hebben aangemaakt, wat leidt tot ongebruikte volumes die rondhangen en kosten veroorzaken.

Schakel notebooks automatisch uit bij inactiviteit

Data Scientists starten vaak een VM, richten daar Jupyter Notebook in, of gebruiken het via SSH in VSCode. Hoewel deze aanpak werkt, leidt dit er vaak toe dat ontwikkelaars vergeten de VM's uit te schakelen als ze klaar zijn met werken. Dit leidt tot een groot verlies aan kosten. Het is de moeite waard om te investeren in automatisch uitschakelende gehoste notebooks zodra het DS-team groeit tot meer dan 5 leden.

‍

Gehoste Jupyter Notebooks en VS Code op Kubernetes

Host Jupyter Notebooks en VS Code op Kubernetes voor een collaboratieve en toegankelijke omgeving om code te ontwikkelen, te delen en te testen.

TrueFoundry Blog Truefoundry

Efficiënt GPU-gebruik

GPU's worden veel gebruikt in ML, maar in heel weinig gevallen worden GPU's efficiënt gebruikt. Dit artikel werpt een uitstekend licht op hoe GPU's tegenwoordig voornamelijk worden gebruikt en de bijbehorende inefficiënties. Het delen van GPU's tussen workloads en efficiënte batching-technieken zijn essentieel om een GPU efficiënt te benutten.

‍

De verborgen wereld van GPU-inefficiëntie

In het vorige bericht hebben we onderzocht hoe bedrijfstransformatie in de nabije toekomst wordt bedreigd door een tekort aan GPU-aanbod. We weten dat GPU een cruciale resource is voor opkomende technologieën, dat de kosten al...

Towards Data Science Steve Golik

‍

Hoe kan TrueFoundry helpen bij het verlagen van kosten?

TrueFoundry heeft geholpen om voor al zijn klanten minimaal circa 40% op infrastructuurkosten te besparen.

Wij gebruiken Kubernetes

Kubernetes helpt kosten te verlagen door workloads efficiënt te binpacken over de nodes en te zorgen dat het cluster effectief wordt gebruikt. Dit is een geweldig artikel dat meer licht werpt op hoe Kubernetes helpt kosten te besparen

‍

De verborgen wereld van GPU-inefficiëntie

In het vorige bericht hebben we onderzocht hoe bedrijfstransformatie in de nabije toekomst wordt bedreigd door een tekort aan GPU-aanbod. We weten dat GPU een cruciale resource is voor opkomende technologieën, dat de kosten al...

Supergiant.io Kirill Goltsman

‍

Bespaar 60% op dev-kosten met tijdgebaseerde autoscaling

TrueFoundry maakt het heel eenvoudig om uw dev-instances uit te schakelen met behulp van de functie voor tijdgebaseerde autoscaling. Ontwikkelaars werken meestal ongeveer 40 uur per week, terwijl de machines bijna 128 uur per week draaien. Als we de machines effectief zouden uitschakelen, zouden we ongeveer 60% van de kosten kunnen besparen.

Schakel notebooks automatisch uit bij inactiviteit

Truefoundry stelt data scientists in staat om op elk notebook een inactiviteitstime-out in te stellen, waarna het notebook automatisch wordt uitgeschakeld.

Dit helpt veel kosten te besparen, vooral als notebooks op GPU's draaien.

Eenvoudig te gebruiken spot instances

Truefoundry maakt het heel eenvoudig om spot- / on-demand instances te gebruiken voor ontwikkelaars. Ontwikkelaars en data scientists kennen hun applicaties het beste - dus laten we het aan hen over om de beste keuze te bepalen voor hun applicaties.

Het toont u ook de afwegingen in kosten tussen spot- en on-demand instances, zodat u de juiste keuze kunt maken volgens uw use-case.

Resource-quota voor teams / ontwikkelaars

Truefoundry stelt u in staat om CPU-, geheugen- en GPU-quota in te stellen voor verschillende teams en ontwikkelaars. Dit geeft leiders zicht op de kostentoewijzing over teams heen en beschermt ook tegen fouten van ontwikkelaars door hen niet toe te staan de toegewezen limieten te overschrijden.

Inzichten met betrekking tot kostenoptimalisatie

Truefoundry toont u automatisch de aanbevolen CPU- en geheugenbronnen voor uw service door het verbruik van de service over de afgelopen dagen te analyseren. Momenteel adviseert het de voorgestelde CPU- en geheugenaanvragen en -limieten - in de toekomst zijn we echter ook van plan om u automatisch de autoscaling-strategie en de juiste architectuur aan te bevelen.

Doe de assessment

Wilt u beoordelen hoe u de kosten van AI-workloads kunt optimaliseren? We hebben een eenvoudig uit te voeren assessment van 5 minuten gemaakt.

‍

We beloven het gepersonaliseerde rapport met u te delen.