Hantera budgetar, kostnader och kvoter för Azure Machine Learning i organisationsskala

När du hanterar beräkningskostnader från Azure Machine Learning, i organisationsskala med många arbetsbelastningar, många team och användare, finns det många hanterings- och optimeringsutmaningar att arbeta igenom.

I den här artikeln presenterar vi metodtips för att optimera kostnader, hantera budgetar och dela kvoter med Azure Machine Learning. Informationen bygger på våra erfarenheter och lärdomar av att köra maskininlärningsteam internt på Microsoft i samarbete med våra kunder. Du lär dig följande:

Optimera beräkning för att uppfylla arbetsbelastningskrav

När du startar ett nytt maskininlärningsprojekt kan undersökande arbete behövas för att få en bra bild av beräkningskraven. Det här avsnittet innehåller rekommendationer om hur du kan fastställa rätt SKU för virtuella datorer (VM) för träning, för slutsatsdragning eller som en arbetsstation att arbeta från.

Fastställa beräkningsstorleken för träning

Maskinvarukraven för din träningsarbetsbelastning kan variera från projekt till projekt. För att uppfylla dessa krav erbjuder Azure Machine Learning-beräkning olika typer av virtuella datorer:

  • Generell användning: Balanserat förhållande mellan processor och minne.
  • Minnesoptimerad: Högt förhållande mellan minne och CPU.
  • Beräkningsoptimerad: Hög cpu-till-minne-förhållande.
  • Beräkning med höga prestanda: Leverera prestanda i ledarskapsklass, skalbarhet och kostnadseffektivitet för olika verkliga HPC-arbetsbelastningar.
  • Instanser med GPU:er: Specialiserade virtuella datorer som är avsedda för tung grafisk rendering och videoredigering, samt modellträning och slutsatsdragning (ND) med djupinlärning.

Du kanske ännu inte vet vilka dina beräkningskrav är. I det här scenariot rekommenderar vi att du börjar med något av följande kostnadseffektiva standardalternativ. De här alternativen är för enkel testning och för träningsarbetsbelastningar.

Typ Storlek för virtuell dator Specifikationer
Processor Standard_DS3_v2 4 kärnor, 14 GB RAM-minne, 28 GB lagringsutrymme
GPU Standard_NC6 6 kärnor, 56 GB RAM-minne, 380 GB lagringsutrymme, NVIDIA Tesla K80 GPU

För att få den bästa VM-storleken för ditt scenario kan det bestå av utvärderingsversion och fel. Här är flera aspekter att tänka på.

  • Om du behöver en CPU:
    • Använd en minnesoptimerad virtuell dator om du tränar på stora datauppsättningar.
    • Använd en beräkningsoptimerad virtuell dator om du utför inferenser i realtid eller andra svarstidskänsliga uppgifter.
    • Använd en virtuell dator med fler kärnor och RAM-minne för att påskynda träningstiderna.
  • Om du behöver en GPU kan du läsa GPU-optimerade VM-storlekar för information om hur du väljer en virtuell dator.
    • Om du utför distribuerad träning använder du VM-storlekar som har flera GPU:er.
    • Om du utför distribuerad träning på flera noder använder du GPU:er som har NVLink-anslutningar.

När du väljer den VM-typ och SKU som passar bäst för din arbetsbelastning utvärderar du jämförbara VM-SKU:er som en kompromiss mellan PROCESSOR- och GPU-prestanda och priser. Ur ett kostnadshanteringsperspektiv kan ett jobb köras någorlunda bra på flera SKU:er.

Vissa GPU:er, till exempel NC-familjen, särskilt NC_Promo SKU:er, har liknande förmågor som andra GPU:er, till exempel låg svarstid och möjlighet att hantera flera beräkningsarbetsbelastningar parallellt. De är tillgängliga till rabatterade priser jämfört med några av de andra GPU:erna. Om du väljer VM-SKU:er i arbetsbelastningen kan kostnaden minska avsevärt i slutändan.

En påminnelse om vikten av användning är att registrera sig för ett större antal GPU:er inte nödvändigtvis körs med snabbare resultat. Kontrollera i stället att GPU:erna används fullt ut. Dubbelkolla till exempel behovet av NVIDIA CUDA. Även om det kan krävas för GPU-körning med höga prestanda kanske ditt jobb inte är beroende av det.

Fastställa beräkningsstorleken för slutsatsdragning

Beräkningskraven för slutsatsdragningsscenarier skiljer sig från träningsscenarier. Tillgängliga alternativ skiljer sig åt beroende på om ditt scenario kräver offline-slutsatsdragning i batch eller kräver online-slutsatsdragning i realtid.

För scenarier med slutsatsdragning i realtid bör du överväga följande förslag:

  • Använd profileringsfunktioner i din modell med Azure Machine Learning för att avgöra hur mycket processor och minne du behöver allokera för modellen när du distribuerar den som en webbtjänst.
  • Om du gör en slutsatsdragning i realtid men inte behöver hög tillgänglighet distribuerar du till Azure Container Instances (inget SKU-val).
  • Om du gör realtidsinferens men behöver hög tillgänglighet distribuerar du till Azure Kubernetes Service.
    • Om du använder traditionella maskininlärningsmodeller och tar emot < 10 frågor/sekund börjar du med en CPU-SKU. F-seriens SKU:er fungerar ofta bra.
    • Om du använder djupinlärningsmodeller och får > 10 frågor/sekund kan du prova en NVIDIA GPU SKU (NCasT4_v3 fungerar ofta bra) med Triton.

För scenarier med batchinferens bör du överväga följande förslag:

  • När du använder Azure Machine Learning-pipelines för batchinferens följer du anvisningarna i Fastställa beräkningsstorleken för träning för att välja din ursprungliga VM-storlek.
  • Optimera kostnader och prestanda genom att skala horisontellt. En av de viktigaste metoderna för att optimera kostnader och prestanda är att parallellisera arbetsbelastningen med hjälp av parallella körningssteg i Azure Machine Learning. Med det här pipelinesteget kan du använda många mindre noder för att köra uppgiften parallellt, vilket gör att du kan skala vågrätt. Det finns dock en overhead för parallellisering. Beroende på arbetsbelastningen och graden av parallellitet som kan uppnås kan ett parallellt körningssteg vara ett alternativ.

Fastställa storleken för beräkningsinstansen

För interaktiv utveckling rekommenderas Azure Machine Learnings beräkningsinstans. Erbjudandet för beräkningsinstanser (CI) ger beräkning med en nod som är bunden till en enskild användare och som kan användas som en molnarbetsstation.

Vissa organisationer tillåter inte användning av produktionsdata på lokala arbetsstationer, har framtvingade begränsningar för arbetsstationsmiljön eller begränsar installationen av paket och beroenden i företagets IT-miljö. En beräkningsinstans kan användas som en arbetsstation för att övervinna begränsningen. Den erbjuder en säker miljö med åtkomst till produktionsdata och körs på avbildningar som levereras med populära paket och verktyg för datavetenskap som är förinstallerade.

När beräkningsinstansen körs debiteras användaren för VM-beräkning, Standard Load Balancer (inklusive regler för lb/utgående trafik och data som bearbetas), OS-disk (Premium SSD-hanterad P10-disk), tempdisk (tempdisktypen beror på den valda VM-storleken) och den offentliga IP-adressen. För att spara kostnader rekommenderar vi att användarna överväger:

  • Starta och stoppa beräkningsinstansen när den inte används.
  • Arbeta med ett exempel på dina data på en beräkningsinstans och skala ut till beräkningskluster för att arbeta med din fullständiga uppsättning data
  • Skicka experimenteringsjobb i lokalt beräkningsmålläge på beräkningsinstansen när du utvecklar eller testar, eller när du växlar till delad beräkningskapacitet när du skickar jobb i full skala. Till exempel många epoker, fullständig uppsättning data och hyperparametersökning.

Om du stoppar beräkningsinstansen stoppas faktureringen för beräkningstimmar för virtuella datorer, temporär disk och Standard Load Balancer databearbetade kostnader. Observera att användaren fortfarande betalar för OS-disken och Standard Load Balancer inkluderade lb/outbound-regler även när beräkningsinstansen stoppas. Alla data som sparas på OS-disken sparas genom stopp och omstarter.

Justera den valda VM-storleken genom att övervaka beräkningsanvändningen

Du kan visa information om din Azure Machine Learning-beräkningsanvändning och -användning via Azure Monitor. Du kan visa information om modelldistribution och registrering, kvotinformation som aktiva och inaktiva noder, körningsinformation som avbrutna och slutförda körningar samt beräkningsanvändning för GPU- och CPU-användning.

Baserat på insikterna från övervakningsinformationen kan du planera eller justera resursanvändningen i hela teamet. Om du till exempel ser många inaktiva noder under den senaste veckan kan du arbeta med motsvarande arbetsyteägare för att uppdatera konfigurationen av beräkningsklustret för att förhindra den här extra kostnaden. Fördelarna med att analysera användningsmönstren kan hjälpa dig med prognostiseringskostnader och budgetförbättringar.

Du kan komma åt dessa mått direkt från Azure Portal. Gå till din Azure Machine Learning-arbetsyta och välj Mått under övervakningsavsnittet på den vänstra panelen. Sedan kan du välja information om vad du vill visa, till exempel mått, aggregering och tidsperiod. Mer information finns på sidan Övervaka Azure Machine Learning-dokumentation .

Diagram över Azure Monitor-mått för Azure Machine Learning

Växla mellan lokal molnberäkning med en nod och flera noder medan du utvecklar

Det finns olika beräknings- och verktygskrav under hela maskininlärningslivscykeln. Azure Machine Learning kan gränssnittshanteras med via ett SDK- och CLI-gränssnitt från praktiskt taget vilken arbetsstationskonfiguration som helst för att uppfylla dessa krav.

För att spara kostnader och arbeta produktivt rekommenderar vi att du:

  • Klona din experimenteringskodbas lokalt med hjälp av Git och skicka jobb till molnberäkning med hjälp av Azure Machine Learning SDK eller CLI.
  • Om din datauppsättning är stor bör du överväga att hantera ett exempel på dina data på din lokala arbetsstation, samtidigt som du behåller hela datamängden på molnlagringen.
  • Parametrisera din experimenteringskodbas så att du kan konfigurera dina jobb så att de körs med ett varierande antal epoker eller på datauppsättningar av olika storlekar.
  • Hårdkoda inte mappsökvägen för datauppsättningen. Du kan sedan enkelt återanvända samma kodbas med olika datauppsättningar och under lokal och molnbaserad körningskontext.
  • Startar experimenteringsjobben i lokalt beräkningsmålläge när du utvecklar eller testar, eller när du växlar till en delad beräkningsklusterkapacitet när du skickar jobb i full skala.
  • Om datauppsättningen är stor kan du arbeta med ett exempel på data på din lokala arbetsstation eller beräkningsinstansarbetsstation, samtidigt som du skalar till molnberäkning i Azure Machine Learning för att arbeta med din fullständiga uppsättning data.
  • När det tar lång tid att köra dina jobb bör du överväga att optimera kodbasen för distribuerad träning så att du kan skala ut horisontellt.
  • Utforma dina distribuerade träningsarbetsbelastningar för nod elasticitet, för att tillåta flexibel användning av beräkning med en nod och flera noder och enkel användning av beräkning som kan föregripas.

Kombinera beräkningstyper med hjälp av Azure Machine Learning-pipelines

När du samordnar dina arbetsflöden för maskininlärning kan du definiera en pipeline med flera steg. Varje steg i pipelinen kan köras med sin egen beräkningstyp. På så sätt kan du optimera prestanda och kostnader för att uppfylla olika beräkningskrav under maskininlärningslivscykeln.

Få bästa möjliga användning av ett teams budget

Även om budgetallokeringsbeslut kan vara utom kontroll över ett enskilt team, är ett team vanligtvis bemyndigat att använda sin tilldelade budget efter sina bästa behov. Genom att byta bort jobbprioritet kontra prestanda och kostnader på ett klokt sätt kan ett team uppnå högre klusteranvändning, sänka den totala kostnaden och använda ett större antal beräkningstimmar från samma budget. Detta kan leda till förbättrad teamproduktivitet.

Optimera kostnaderna för delade beräkningsresurser

Nyckeln för att optimera kostnaderna för delade beräkningsresurser är att se till att de används till sin fulla kapacitet. Här följer några tips för att optimera dina delade resurskostnader:

  • När du använder beräkningsinstanser aktiverar du dem bara när du har kod att köra. Stäng av dem när de inte används.
  • När du använder beräkningskluster anger du det minsta antalet noder till 0 och det maximala antalet noder till ett tal som utvärderas baserat på dina budgetbegränsningar. Använd Priskalkylatorn för Azure för att beräkna kostnaden för full användning av en VM-nod för den valda virtuella datorns SKU. Autoskalning skalar ned alla beräkningsnoder när det inte finns någon som använder den. Den skalas bara upp till det antal noder som du har budget för. Du kan konfigurera automatisk skalning för att skala ned alla beräkningsnoder.
  • Övervaka resursanvändningen, till exempel CPU-användning och GPU-användning när du tränar modeller. Om resurserna inte används fullt ut ändrar du koden för att bättre använda resurser eller skala ned till mindre eller billigare VM-storlekar.
  • Utvärdera om du kan skapa delade beräkningsresurser för ditt team för att undvika ineffektivitet i databehandlingen som orsakas av klusterskalningsåtgärder.
  • Optimera principer för automatisk skalning av beräkningskluster baserat på användningsstatistik.
  • Använd kvoter för arbetsytor för att styra mängden beräkningsresurser som enskilda arbetsytor har åtkomst till.

Introducera schemaläggningsprioritet genom att skapa kluster för flera VM-SKU:er

Under kvot- och budgetbegränsningar måste ett team kompromissa med körningen av jobb i tid jämfört med kostnaden, för att säkerställa att viktiga jobb körs i tid och att en budget används på bästa möjliga sätt.

För bästa beräkningsanvändning rekommenderas team att skapa kluster av olika storlekar och med låg prioritet och dedikerade VM-prioriteringar. Lågprioriterade beräkningar använder överskottskapacitet i Azure och har därför rabatterade priser. På nackdelen kan dessa datorer föregripas när en fråga med högre prioritet kommer in.

Med hjälp av kluster med varierande storlek och prioritet kan en uppfattning om schemaläggningsprioritet införas. När till exempel experimentella jobb och produktionsjobb konkurrerar om samma NC GPU-kvot kan ett produktionsjobb ha företräde att köra över det experimentella jobbet. I så fall kör du produktionsjobbet i det dedikerade beräkningsklustret och det experimentella jobbet i beräkningsklustret med låg prioritet. När kvoten misslyckas kommer det experimentella jobbet att föregripas till förmån för produktionsjobbet.

Överväg att köra jobb på olika VM-SKU:er bredvid VM-prioritet. Det kan vara så att ett jobb tar längre tid att köra på en VM-instans med en P40 GPU än på en V100 GPU. Men eftersom V100 VM-instanser kan vara upptagen eller kvoten används fullt ut, kan tiden för att slutföra P40 fortfarande vara snabbare ur ett jobbdataflödesperspektiv. Du kan också överväga att köra jobb med lägre prioritet på mindre högpresterande och billigare VM-instanser ur ett kostnadshanteringsperspektiv.

Avsluta en körning tidigt när träningen inte konvergerar

När du kontinuerligt experimenterar för att förbättra en modell mot baslinjen kan du köra olika experimentkörningar, var och en med lite olika konfigurationer. För en körning kan du justera indatauppsättningarna. För en annan körning kan du göra en ändring av hyperparametern. Alla ändringar kan inte vara lika effektiva som de andra. Du upptäcker tidigt att en ändring inte hade den avsedda effekten på kvaliteten på modellträningen. Övervaka träningsförloppet under en körning för att identifiera om träningen inte konvergerar. Genom att till exempel logga prestandamått efter varje träningsepoken. Överväg att avsluta jobbet tidigt för att frigöra resurser och budget för en annan utvärderingsversion.

Planera, hantera och dela budgetar, kostnader och kvoter

I takt med att en organisation ökar antalet användningsfall och team för maskininlärning krävs en ökad operativ mognad från IT och ekonomi samt samordning mellan enskilda maskininlärningsteam för att säkerställa effektiv drift. Kapacitets- och kvothantering i företagsskala blir viktiga för att hantera brist på beräkningsresurser och övervinna hanteringskostnader.

I det här avsnittet beskrivs metodtips för planering, hantering och delning av budgetar, kostnader och kvoter i företagsskala. Den baseras på lärdomar från hantering av många GPU-utbildningsresurser för maskininlärning internt på Microsoft.

Förstå resursutgifter med Azure Machine Learning

En av de största utmaningarna som administratör för planering av beräkningsbehov är att börja nytt utan historisk information som baslinjeuppskattning. På ett praktiskt sätt kommer de flesta projekt att utgå från en liten budget som ett första steg.

För att förstå vart budgeten är på väg är det viktigt att veta var Azure Machine Learning-kostnaderna kommer ifrån:

  • Azure Machine Learning debiterar endast för beräkningsinfrastruktur som används och lägger inte till någon tilläggsavgift för beräkningskostnader.
  • När en Azure Machine Learning-arbetsyta skapas finns det också några andra resurser som har skapats för att aktivera Azure Machine Learning: Key Vault, Application Insights, Azure Storage och Azure Container Registry. Dessa resurser används i Azure Machine Learning och du betalar för dessa resurser.
  • Det finns kostnader som är associerade med hanterad beräkning, till exempel träningskluster, beräkningsinstanser och hanterade slutpunkter för slutsatsdragning. Med dessa hanterade beräkningsresurser finns det följande infrastrukturkostnader att ta hänsyn till: virtuella datorer, virtuellt nätverk, lastbalanserare, bandbredd och lagring.

Spåra utgiftsmönster och få bättre rapportering med taggning

Administratörer vill ofta kunna spåra kostnader för olika resurser i Azure Machine Learning. Taggning är en naturlig lösning på det här problemet och överensstämmer med den allmänna metod som används av Azure och många andra molntjänstleverantörer. Med stöd för taggar kan du nu se kostnadsuppdelning på beräkningsnivå, vilket ger dig åtkomst till en mer detaljerad vy för att hjälpa till med bättre kostnadsövervakning, förbättrad rapportering och större transparens.

Med taggning kan du placera anpassade taggar på dina arbetsytor och beräkningar (från Azure Resource Manager-mallar och Azure Machine Learning-studio) för att ytterligare filtrera på dessa resurser i Azure Cost Management baserat på dessa taggar för att observera utgiftsmönster. Den här funktionen kan användas bäst för interna scenarier för återbetalning av avgifter. Dessutom kan taggar vara användbara för att samla in metadata eller information som är associerad med beräkningen, t.ex. ett projekt, ett team, viss faktureringskod osv. Detta gör taggning mycket fördelaktigt för att mäta hur mycket pengar du spenderar på olika resurser och därmed få djupare insikter om dina kostnads- och utgiftsmönster i team eller projekt.

Det finns också systeminmatade taggar som placeras på beräkningar som gör att du kan filtrera på sidan Kostnadsanalys efter taggen "Beräkningstyp" för att se en beräkningsvis uppdelning av dina totala utgifter och avgöra vilken kategori av beräkningsresurser som kan tillskrivas de flesta av dina kostnader. Detta är särskilt användbart för att få mer insyn i dina tränings- och slutsatsdragningskostnadsmönster.

Skärmbild av kostnadsanalysvyn filtrerad efter beräkningstyp.

Styra och begränsa beräkningsanvändningen efter princip

När du hanterar en Azure-miljö med många arbetsbelastningar kan det vara en utmaning att behålla översikten över resursutgifter. Azure Policy kan hjälpa dig att kontrollera och styra resursutgifter genom att begränsa specifika användningsmönster i Azure-miljön.

Specifikt för Azure Machine Learning rekommenderar vi att du konfigurerar principer som endast tillåter användning av specifika VM-SKU:er. Principer kan hjälpa dig att förhindra och kontrollera valet av dyra virtuella datorer. Principer kan också användas för att framtvinga användning av vm-SKU:er med låg prioritet.

Allokera och hantera kvot baserat på affärsprioritet

Med Azure kan du ange gränser för kvotallokering på en prenumerations- och Azure Machine Learning-arbetsytenivå. Att begränsa vem som kan hantera kvoter via rollbaserad åtkomstkontroll i Azure (RBAC) kan bidra till att säkerställa resursutnyttjande och kostnadsförutsägbarhet.

Tillgängligheten för GPU-kvoten kan vara knapp i dina prenumerationer. För att säkerställa hög kvotanvändning mellan arbetsbelastningar rekommenderar vi att du övervakar om kvoten används bäst och tilldelas mellan arbetsbelastningar.

På Microsoft bestäms regelbundet om GPU-kvoter används bäst och allokeras mellan maskininlärningsteam genom att utvärdera kapacitetsbehov mot affärsprioritet.

Checka in kapacitet i förväg

Om du har en bra uppskattning av hur mycket beräkning som ska användas under nästa år eller de närmaste åren kan du köpa Azure Reserved VM Instances till en rabatterad kostnad. Det finns köpvillkor på ett eller tre år. Eftersom Azure Reserved VM Instances rabatteras kan det finnas betydande kostnadsbesparingar jämfört med betala per användning-priser.

Azure Machine Learning stöder reserverade beräkningsinstanser. Rabatter tillämpas automatiskt mot azure machine learning-hanterad beräkning.

Hantera datakvarhållning

Varje gång en maskininlärningspipeline körs kan mellanliggande datamängder genereras vid varje pipelinesteg för cachelagring av data och återanvändning. Tillväxten av data som utdata från dessa maskininlärningspipelines kan bli en smärtpunkt för en organisation som kör många maskininlärningsexperiment.

Dataexperter ägnar vanligtvis inte sin tid åt att rensa de mellanliggande datamängder som genereras. Med tiden kommer mängden data som genereras att summeras. Azure Storage har en funktion för att förbättra hanteringen av datalivscykeln. Med hjälp av Azure Blob Storage livscykelhantering kan du konfigurera allmänna principer för att flytta data som inte används till kallare lagringsnivåer och spara kostnader.

Överväganden för kostnadsoptimering för infrastruktur

Nätverk

Kostnaden för Azure-nätverk tillkommer från utgående bandbredd från Azure-datacentret. Alla inkommande data till ett Azure-datacenter är kostnadsfria. Nyckeln för att minska nätverkskostnaden är att distribuera alla dina resurser i samma datacenterregion när det är möjligt. Om du kan distribuera Azure Machine Learning-arbetsyta och beräkning i samma region som har dina data kan du få lägre kostnad och högre prestanda.

Du kanske vill ha en privat anslutning mellan ditt lokala nätverk och ditt Azure-nätverk för att ha en hybridmolnmiljö. Med ExpressRoute kan du göra det, men med tanke på de höga kostnaderna för ExpressRoute kan det vara mer kostnadseffektivt att flytta från en hybridmolnkonfiguration och flytta alla resurser till Azure-molnet.

Azure Container Registry

För Azure Container Registry omfattar de avgörande faktorerna för kostnadsoptimering:

  • Nödvändigt dataflöde för nedladdning av Docker-avbildningar från containerregistret till Azure Machine Learning
  • Krav för företagssäkerhetsfunktioner, till exempel Azure Private Link

För produktionsscenarier där högt dataflöde eller företagssäkerhet krävs rekommenderas Premium-SKU:n för Azure Container Registry.

För utvecklings-/testscenarier där dataflöde och säkerhet är mindre kritiska rekommenderar vi antingen Standard SKU eller Premium SKU.

Grundläggande SKU för Azure Container Registry rekommenderas inte för Azure Machine Learning. Det rekommenderas inte på grund av dess låga dataflöde och låga lagringsutrymme, som snabbt kan överskridas av Azure Machine Learnings relativt stora (1+ GB) Docker-avbildningar.

Överväg att använda tillgänglighet för databehandlingstyper när du väljer Azure-regioner

När du väljer en region för din beräkning bör du ha tillgängligheten för beräkningskvoten i åtanke. Populära och större regioner som USA, östra, USA, västra och Europa, västra tenderar att ha högre standardkvotvärden och större tillgänglighet för de flesta processorer och GPU:er, jämfört med vissa andra regioner med strängare kapacitetsbegränsningar.

Läs mer

Spåra kostnader mellan affärsenheter, miljöer eller projekt med hjälp av Cloud Adoption Framework

Nästa steg

Mer information om hur du organiserar och konfigurerar Azure Machine Learning-miljöer finns i Organisera och konfigurera Azure Machine Learning-miljöer.

Mer information om metodtips för Machine Learning DevOps med Azure Machine Learning finns i Machine Learning DevOps-guide.