Budgetten, kosten en quota voor Azure Machine Learning op organisatieschaal beheren

Wanneer u de rekenkosten van Azure Machine Learning beheert, op organisatieschaal met veel workloads, veel teams en gebruikers, zijn er talloze beheer- en optimalisatieuitdagingen die u moet uitvoeren.

In dit artikel presenteren we aanbevolen procedures voor het optimaliseren van kosten, het beheren van budgetten en het delen van quota met Azure Machine Learning. Het is een bundeling van de ervaringen en lessen die we bij Microsoft hebben geleerd tijdens het managen van interne machine learning-teams en tijdens de samenwerking met onze klanten. U leert het volgende:

• Optimaliseer rekenresources om te voldoen aan de workloadvereisten.
• Maak optimaal gebruik van het budget van een team.
• Budgetten, kosten en quota plannen, beheren en delen op ondernemingsniveau.

Compute optimaliseren om te voldoen aan de workloadvereisten

Wanneer u een nieuw machine learning-project start, is er mogelijk verkennend werk nodig om een goed beeld te krijgen van de rekenvereisten. Deze sectie bevat aanbevelingen voor het bepalen van de juiste SKU voor virtuele machines (VM's) voor training, voor deductie of als werkstation om mee te werken.

De rekenkracht voor training bepalen

Hardwarevereisten voor uw trainingsworkload kunnen per project verschillen. Om aan deze vereisten te voldoen, biedt Azure Machine Learning Compute verschillende typen VM's:

• Algemeen gebruik: Evenwichtige CPU-geheugenverhouding.
• Geoptimaliseerd voor geheugen: Hoge geheugen-CPU-verhouding.
• Geoptimaliseerd voor rekenkracht: Hoge CPU-/geheugenverhouding.
• Rekenkracht met hoge prestaties: Lever hoogwaardige prestaties, schaalbaarheid en kostenefficiëntie voor verschillende echte HPC-workloads.
• Exemplaren met GPU's: Gespecialiseerde virtuele machines die zijn gericht op zware grafische rendering en videobewerking, evenals modeltraining en deductie (ND) met deep learning.

Mogelijk weet u nog niet wat uw rekenvereisten zijn. In dit scenario raden we u aan te beginnen met een van de volgende kosteneffectieve standaardopties. Deze opties zijn bedoeld voor lichtgewicht testen en voor trainingsworkloads.

Type	Grootte van de virtuele machine	Specificaties
CPU	Standard_DS3_v2	4 kernen, 14 gigabyte (GB) RAM, 28 GB opslag
GPU	Standard_NC6	6 kernen, 56 gigabyte (GB) RAM, 380 GB opslag, NVIDIA Tesla K80 GPU

Om de beste VM-grootte voor uw scenario te krijgen, kan dit bestaan uit vallen en opstaan. Hier volgen verschillende aspecten om rekening mee te houden.

• Als u een CPU nodig hebt:
  • Gebruik een vm die is geoptimaliseerd voor geheugen als u traint met grote gegevenssets.
  • Gebruik een vm die is geoptimaliseerd voor rekenkracht als u realtime deductie of andere latentiegevoelige taken uitvoert.
  • Gebruik een VM met meer kernen en RAM om trainingstijden te versnellen.
• Als u een GPU nodig hebt, raadpleegt u de VOOR GPU geoptimaliseerde VM-grootten voor informatie over het selecteren van een VM.
  • Als u gedistribueerde training uitvoert, gebruikt u VM-grootten met meerdere GPU's.
  • Als u gedistribueerde training uitvoert op meerdere knooppunten, gebruikt u GPU's met NVLink-verbindingen.

Terwijl u het VM-type en de SKU selecteert die het beste bij uw workload passen, evalueert u vergelijkbare VM-SKU's als een afweging tussen CPU- en GPU-prestaties en -prijzen. Vanuit het perspectief van kostenbeheer kan een taak redelijk goed worden uitgevoerd op verschillende SKU's.

Bepaalde GPU's, zoals de NC-familie, met name NC_Promo SKU's, hebben vergelijkbare mogelijkheden als andere GPU's, zoals lage latentie en de mogelijkheid om meerdere rekenworkloads parallel te beheren. Ze zijn beschikbaar tegen gereduceerde prijzen in vergelijking met sommige van de andere GPU's. Het selecteren van VM-SKU's voor de workload kan uiteindelijk aanzienlijk kosten besparen.

Een herinnering aan het belang voor gebruik is om u te registreren voor een groter aantal GPU's die niet noodzakelijkerwijs worden uitgevoerd met snellere resultaten. Zorg er in plaats daarvan voor dat de GPU's volledig worden gebruikt. Controleer bijvoorbeeld nog eens of NVIDIA CUDA nodig is. Hoewel dit mogelijk vereist is voor de uitvoering van de GPU met hoge prestaties, is het mogelijk dat uw taak er niet afhankelijk van is.

De rekenkracht voor deductie bepalen

Rekenvereisten voor deductiescenario's verschillen van trainingsscenario's. Beschikbare opties verschillen afhankelijk van of uw scenario offlinedeductie in batch vereist of onlinedeductie in realtime vereist.

Houd voor realtime deductiescenario's rekening met de volgende suggesties:

• Gebruik profileringsmogelijkheden voor uw model met Azure Machine Learning om te bepalen hoeveel CPU en geheugen u voor het model moet toewijzen wanneer u het als een webservice implementeert.
• Als u realtime deductie uitvoert, maar geen hoge beschikbaarheid nodig hebt, implementeert u naar Azure Container Instances (geen SKU-selectie).
• Als u realtime deductie uitvoert, maar hoge beschikbaarheid nodig hebt, implementeert u op Azure Kubernetes Service.
  • Als u traditionele machine learning-modellen gebruikt en 10 query's per seconde ontvangt < , begint u met een CPU-SKU. SKU's uit de F-serie werken vaak goed.
  • Als u deep learning-modellen gebruikt en 10 query's per seconde ontvangt > , probeert u een NVIDIA GPU-SKU (NCasT4_v3 vaak goed werkt) met Triton.

Houd voor scenario's met batchdeductie rekening met de volgende suggesties:

• Wanneer u Azure Machine Learning-pijplijnen gebruikt voor batchdeductie, volgt u de richtlijnen in De rekenkracht voor training bepalen om uw initiële VM-grootte te kiezen.
• Kosten en prestaties optimaliseren door horizontaal te schalen. Een van de belangrijkste methoden voor het optimaliseren van kosten en prestaties is het parallelliseren van de workload met behulp van de parallelle uitvoeringsstap in Azure Machine Learning. Met deze pijplijnstap kunt u veel kleinere knooppunten gebruiken om de taak parallel uit te voeren, zodat u horizontaal kunt schalen. Er is echter een overhead voor parallelle uitvoering. Afhankelijk van de workload en de mate van parallelle uitvoering die kan worden bereikt, kan een parallelle uitvoeringsstap al dan niet een optie zijn.

De grootte van het rekenproces bepalen

Voor interactieve ontwikkeling wordt het rekenproces van Azure Machine Learning aanbevolen. De CI (Compute Instance) biedt rekenkracht met één knooppunt dat is gebonden aan één gebruiker en kan worden gebruikt als een cloudwerkstation.

Sommige organisaties staan het gebruik van productiegegevens op lokale werkstations niet toe, hebben beperkingen afgedwongen voor de werkstationomgeving of beperken de installatie van pakketten en afhankelijkheden in de IT-omgeving van het bedrijf. Een rekenproces kan worden gebruikt als werkstation om de beperking te verhelpen. Het biedt een beveiligde omgeving met toegang tot productiegegevens en wordt uitgevoerd op installatiekopieën die worden geleverd met vooraf geïnstalleerde populaire pakketten en hulpprogramma's voor gegevenswetenschap.

Wanneer het rekenproces wordt uitgevoerd, wordt de gebruiker gefactureerd voor VM-rekenkracht, Standard Load Balancer (opgenomen regels voor lb/uitgaand verkeer en verwerkte gegevens), besturingssysteemschijf (beheerde P10-schijf van Premium SSD), tijdelijke schijf (het tijdelijke schijftype is afhankelijk van de gekozen VM-grootte) en openbaar IP-adres. Om kosten te besparen, raden we gebruikers aan het volgende te overwegen:

• Start en stop het rekenproces wanneer deze niet in gebruik is.
• Werk met een voorbeeld van uw gegevens in een rekenproces en schaal uit naar rekenclusters om te werken met uw volledige set gegevens
• Verzend experimenteertaken in de modus lokaal rekendoel op het rekenproces tijdens het ontwikkelen of testen, of wanneer u overschakelt naar gedeelde rekencapaciteit wanneer u taken op volledige schaal indient. Bijvoorbeeld veel tijdvakken, volledige gegevensset en hyperparameter zoeken.

Als u het rekenproces stopt, stopt deze de facturering voor VM-rekenuren, tijdelijke schijf en Standard Load Balancer verwerkte gegevenskosten. Houd er rekening mee dat de gebruiker nog steeds betaalt voor de besturingssysteemschijf en Standard Load Balancer opgenomen lb/uitgaande regels, zelfs wanneer het rekenproces is gestopt. Alle gegevens die op de besturingssysteemschijf zijn opgeslagen, blijven behouden door te stoppen en opnieuw op te starten.

De gekozen VM-grootte afstemmen door het rekengebruik te bewaken

U kunt informatie over uw rekengebruik en -gebruik van Azure Machine Learning bekijken via Azure Monitor. U kunt details bekijken over modelimplementatie en -registratie, quotumdetails zoals actieve en niet-actieve knooppunten, uitvoeringsdetails zoals geannuleerde en voltooide uitvoeringen en rekengebruik voor GPU- en CPU-gebruik.

Op basis van de inzichten uit de bewakingsdetails kunt u uw resourcegebruik in het hele team beter plannen of aanpassen. Als u bijvoorbeeld de afgelopen week veel niet-actieve knooppunten hebt gezien, kunt u samenwerken met de bijbehorende eigenaren van de werkruimte om de configuratie van het rekencluster bij te werken om deze extra kosten te voorkomen. Voordelen van het analyseren van de gebruikspatronen kunnen helpen bij het voorspellen van kosten en budgetverbeteringen.

U hebt rechtstreeks toegang tot deze metrische gegevens vanuit de Azure Portal. Ga naar uw Azure Machine Learning-werkruimte en selecteer Metrische gegevens onder de bewakingssectie in het linkerdeelvenster. Vervolgens kunt u details selecteren over wat u wilt weergeven, zoals metrische gegevens, aggregatie en tijdsperiode. Zie de pagina Azure Machine Learning-documentatie bewaken voor meer informatie.

Schakelen tussen lokale berekeningen in de cloud, met één knooppunt en met meerdere knooppunten tijdens het ontwikkelen

Er zijn verschillende reken- en hulpprogrammavereisten gedurende de levenscyclus van machine learning. Azure Machine Learning kan worden gekoppeld via een SDK- en CLI-interface van vrijwel elke voorkeurswerkstationconfiguratie om aan deze vereisten te voldoen.

Als u kosten wilt besparen en productief wilt werken, is het raadzaam om het volgende te doen:

• Kloon uw experimentele codebasis lokaal met behulp van Git en verzend taken naar cloud compute met behulp van de Azure Machine Learning SDK of CLI.
• Als uw gegevensset groot is, kunt u een voorbeeld van uw gegevens op uw lokale werkstation beheren, terwijl u de volledige gegevensset in de cloudopslag houdt.
• Parametereer uw experimenteercodebasis, zodat u uw taken kunt configureren voor uitvoering met een wisselend aantal tijdvakken of voor gegevenssets van verschillende grootten.
• Codeer het mappad van uw gegevensset niet. U kunt vervolgens eenvoudig dezelfde codebasis opnieuw gebruiken met verschillende gegevenssets en onder lokale en cloud uitvoeringscontext.
• Bootstrap uw experimenten in de modus lokaal rekendoel tijdens het ontwikkelen of testen, of wanneer u overschakelt naar een gedeelde rekenclustercapaciteit wanneer u taken op volledige schaal verzendt.
• Als uw gegevensset groot is, kunt u werken met een voorbeeld van gegevens op het werkstation van uw lokale of rekeninstantie, terwijl u schaalt naar cloud compute in Azure Machine Learning om te werken met uw volledige set gegevens.
• Wanneer het lang duurt voordat uw taken zijn uitgevoerd, kunt u overwegen om uw codebasis te optimaliseren voor gedistribueerde training om horizontaal uit te schalen.
• Ontwerp uw gedistribueerde trainingsworkloads voor elasticiteit van knooppunten, om flexibel gebruik van berekeningen met één en meerdere knooppunten mogelijk te maken en het gebruik van rekenkracht te vereenvoudigen.

Rekentypen combineren met behulp van Azure Machine Learning-pijplijnen

Wanneer u uw machine learning-werkstromen indelen, kunt u een pijplijn met meerdere stappen definiëren. Elke stap in de pijplijn kan worden uitgevoerd op een eigen rekentype. Hierdoor kunt u de prestaties en kosten optimaliseren om te voldoen aan verschillende rekenvereisten gedurende de levenscyclus van machine learning.

Optimaal gebruik van het budget van een team stimuleren

Hoewel budgettoewijzingsbeslissingen mogelijk buiten de controle van een afzonderlijk team vallen, is een team doorgaans in staat om hun toegewezen budget naar beste behoeften te gebruiken. Door taakprioriteit versus prestaties en kosten op een verstandige wijze in te ruilen, kan een team een hoger clustergebruik, lagere totale kosten bereiken en een groter aantal rekenuren van hetzelfde budget gebruiken. Dit kan leiden tot verbeterde teamproductiviteit.

De kosten van gedeelde rekenresources optimaliseren

De sleutel voor het optimaliseren van de kosten van gedeelde rekenresources is ervoor te zorgen dat ze volledig worden gebruikt. Hier volgen enkele tips voor het optimaliseren van uw gedeelde resourcekosten:

• Wanneer u rekenprocessen gebruikt, moet u deze alleen inschakelen wanneer u code moet uitvoeren. Sluit ze af wanneer ze niet worden gebruikt.
• Wanneer u rekenclusters gebruikt, stelt u het minimale aantal knooppunten in op 0 en het maximumaantal knooppunten op een getal dat wordt geëvalueerd op basis van uw budgetbeperkingen. Gebruik de Azure-prijscalculator om de kosten van volledig gebruik van één VM-knooppunt van uw gekozen VM-SKU te berekenen. Met automatisch schalen worden alle rekenknooppunten omlaag geschaald wanneer niemand deze gebruikt. De schaal wordt alleen omhoog geschaald tot het aantal knooppunten waarvoor u budget hebt. U kunt automatisch schalen configureren om alle rekenknooppunten omlaag te schalen.
• Bewaak uw resourcegebruik, zoals CPU-gebruik en GPU-gebruik bij het trainen van modellen. Als de resources niet volledig worden gebruikt, wijzigt u de code om resources beter te gebruiken of schaalt u omlaag naar kleinere of goedkopere VM-grootten.
• Evalueer of u gedeelde rekenresources voor uw team kunt maken om inefficiënties te voorkomen die worden veroorzaakt door clusterschaalbewerkingen.
• Time-outbeleid voor automatische schaalaanpassing van rekenclusters optimaliseren op basis van metrische gegevens over gebruik.
• Gebruik werkruimtequota om de hoeveelheid rekenresources te beheren waartoe afzonderlijke werkruimten toegang hebben.

Planningsprioriteit introduceren door clusters te maken voor meerdere VM-SKU's

Onder quotum- en budgetbeperkingen moet een team de tijdige uitvoering van taken en kosten inruilen om ervoor te zorgen dat belangrijke taken tijdig worden uitgevoerd en een budget op de best mogelijke manier wordt gebruikt.

Om het beste rekengebruik te ondersteunen, wordt teams aangeraden clusters van verschillende grootten en met lage prioriteit en toegewezen VM-prioriteiten te maken. Berekeningen met lage prioriteit maken gebruik van overtollige capaciteit in Azure en hebben daarom kortingstarieven. Aan de andere kant kunnen deze machines worden afgekeerd wanneer een vraag met een hogere prioriteit binnenkomt.

Met behulp van de clusters van verschillende grootte en prioriteit kan een notie van planningsprioriteit worden geïntroduceerd. Wanneer experimentele taken en productietaken bijvoorbeeld concurreren om hetzelfde NC GPU-quotum, kan een productietaak de voorkeur hebben om uit te voeren boven de experimentele taak. Voer in dat geval de productietaak uit op het toegewezen rekencluster en de experimentele taak op het rekencluster met lage prioriteit. Wanneer het quotum te klein is, wordt de experimentele taak overgeslagen ten gunste van de productietaak.

Naast VM-prioriteit kunt u ook taken uitvoeren op verschillende VM-SKU's. Het kan zijn dat het uitvoeren van een taak op een VM-exemplaar met een P40 GPU langer duurt dan op een V100 GPU. Omdat V100 VM-exemplaren echter bezet kunnen zijn of het quotum volledig kan worden gebruikt, is de tijd tot voltooiing op de P40 mogelijk nog steeds sneller vanuit het perspectief van de taakdoorvoer. U kunt ook overwegen om taken met een lagere prioriteit uit te voeren op minder presterende en goedkopere VM-exemplaren vanuit het oogpunt van kostenbeheer.

Een uitvoering vroegtijdig beëindigen wanneer de training niet convergeert

Wanneer u continu experimenteert om een model te verbeteren ten opzichte van de basislijn, voert u mogelijk verschillende experimentuitvoeringen uit, elk met iets andere configuraties. Voor één uitvoering kunt u de invoergegevenssets aanpassen. Voor een andere uitvoering kunt u een hyperparameterwijziging aanbrengen. Niet alle wijzigingen zijn mogelijk zo effectief als de andere. U hebt in een vroeg stadium gedetecteerd dat een wijziging niet het beoogde effect heeft op de kwaliteit van uw modeltraining. Als u wilt detecteren of de training niet convergeert, controleert u de voortgang van de training tijdens een uitvoering. Bijvoorbeeld door metrische prestatiegegevens na elk trainingstijdperk te registreren. Overweeg om de taak vroegtijdig te beëindigen om resources en budget vrij te maken voor een nieuwe proefversie.

Budgetten, kosten en quota plannen, beheren en delen

Naarmate een organisatie het aantal machine learning-use cases en -teams uitbreidt, is er meer operationele volwassenheid van IT en financiën nodig, evenals coördinatie tussen afzonderlijke machine learning-teams om efficiënte bewerkingen te garanderen. Capaciteits- en quotumbeheer op bedrijfsniveau worden belangrijk om de schaarsheid van rekenresources aan te pakken en beheeroverhead te overwinnen.

In deze sectie worden aanbevolen procedures besproken voor het plannen, beheren en delen van budgetten, kosten en quota op ondernemingsniveau. Het is gebaseerd op de lessen van het intern beheren van veel GPU-trainingsresources voor machine learning bij Microsoft.

Inzicht in resource-uitgaven met Azure Machine Learning

Een van de grootste uitdagingen als beheerder voor het plannen van rekenbehoeften is het starten van nieuwe zonder historische informatie als basislijnschatting. Praktisch gezien zullen de meeste projecten als eerste stap beginnen met een klein budget.

Om te begrijpen waar het budget naartoe gaat, is het essentieel om te weten waar azure Machine Learning-kosten vandaan komen:

• Azure Machine Learning brengt alleen kosten in rekening voor de gebruikte rekeninfrastructuur en voegt geen toeslag toe op de rekenkosten.
• Wanneer een Azure Machine Learning-werkruimte wordt gemaakt, zijn er ook enkele andere resources gemaakt om Azure Machine Learning in te schakelen: Key Vault, Application Insights, Azure Storage en Azure Container Registry. Deze resources worden gebruikt in Azure Machine Learning en u betaalt voor deze resources.
• Er zijn kosten verbonden aan beheerde berekeningen, zoals trainingsclusters, rekenprocessen en beheerde deductie-eindpunten. Met deze beheerde rekenresources moet rekening worden gehouden met de volgende infrastructuurkosten: virtuele machines, virtueel netwerk, load balancer, bandbreedte en opslag.

Bestedingspatronen bijhouden en betere rapportage bereiken met taggen

Beheerders willen vaak de kosten voor verschillende resources in Azure Machine Learning kunnen bijhouden. Tagging is een natuurlijke oplossing voor dit probleem en komt overeen met de algemene aanpak die wordt gebruikt door Azure en veel andere cloudserviceproviders. Met ondersteuning voor tags kunt u nu de uitsplitsing van de kosten op rekenniveau zien, waardoor u toegang krijgt tot een gedetailleerdere weergave om te helpen bij betere kostenbewaking, verbeterde rapportage en meer transparantie.

Met tags kunt u aangepaste tags plaatsen in uw werkruimten en berekeningen (van Azure Resource Manager-sjablonen en Azure Machine Learning-studio) om verder te filteren op deze resources in Azure Cost Management op basis van deze tags om uitgavenpatronen te observeren. Deze functionaliteit kan het beste worden gebruikt voor interne terugstortingsscenario's. Daarnaast kunnen tags handig zijn voor het vastleggen van metagegevens of details die zijn gekoppeld aan de berekening, bijvoorbeeld voor een project, een team, bepaalde factureringscode, enzovoort. Dit maakt taggen zeer nuttig voor het meten van hoeveel geld u aan verschillende resources uitgeeft en daarom meer inzicht te krijgen in uw kosten- en uitgavenpatronen in teams of projecten.

Er zijn ook systeeminjectietags geplaatst op berekeningen waarmee u op de pagina Kostenanalyse kunt filteren op de tag Rekentype om een berekeningswijze uitsplitsing van uw totale uitgaven te bekijken en te bepalen welke categorie rekenresources het grootste deel van uw kosten toewijst. Dit is met name handig om meer inzicht te krijgen in uw trainings- versus deductiekostenpatronen.

Rekengebruik beheren en beperken op basis van beleid

Wanneer u een Azure-omgeving met veel workloads beheert, kan het een uitdaging zijn om het overzicht te houden over resource-uitgaven. Azure Policy kunt u helpen bij het beheren en beheren van resource-uitgaven door bepaalde gebruikspatronen in de Azure-omgeving te beperken.

Specifiek voor Azure Machine Learning raden we u aan beleidsregels in te stellen om alleen het gebruik van specifieke VM-SKU's toe te staan. Beleidsregels kunnen helpen bij het voorkomen en beheren van de selectie van dure VM's. Beleidsregels kunnen ook worden gebruikt om het gebruik van VM-SKU's met lage prioriteit af te dwingen.

Quota toewijzen en beheren op basis van bedrijfsprioriteit

Met Azure kunt u limieten instellen voor quotumtoewijzing op het niveau van een abonnement en azure Machine Learning-werkruimte. Het beperken van wie het quotum kan beheren via op rollen gebaseerd toegangsbeheer (RBAC) van Azure kan helpen om het resourcegebruik en de voorspelbaarheid van de kosten te garanderen.

De beschikbaarheid van GPU-quotum kan schaars zijn in uw abonnementen. Om een hoog quotumgebruik voor workloads te garanderen, raden we u aan te controleren of het quotum het beste wordt gebruikt en toegewezen aan workloads.

Bij Microsoft wordt periodiek bepaald of GPU-quota het beste kunnen worden gebruikt en toegewezen aan machine learning-teams door de capaciteitsbehoeften te evalueren op basis van bedrijfsprioriteit.

Doorvoercapaciteit van tevoren

Als u een goede schatting hebt van de hoeveelheid rekenkracht die in het volgende jaar of de komende jaren wordt gebruikt, kunt u gereserveerde VM-instanties van Azure aanschaffen tegen gereduceerde kosten. Er zijn aankoopvoorwaarden van één of drie jaar. Omdat gereserveerde VM-instanties van Azure korting krijgen, kunnen er aanzienlijke kostenbesparingen zijn in vergelijking met de prijzen voor betalen per gebruik.

Azure Machine Learning ondersteunt gereserveerde rekeninstanties. Kortingen worden automatisch toegepast op beheerde berekeningen van Azure Machine Learning.

Gegevensretentie beheren

Telkens wanneer een machine learning-pijplijn wordt uitgevoerd, kunnen bij elke pijplijnstap tussenliggende gegevenssets worden gegenereerd voor het opslaan en hergebruiken van gegevens. De groei van gegevens als uitvoer van deze machine learning-pijplijnen kan een pijnpunt worden voor een organisatie die veel machine learning-experimenten uitvoert.

Gegevenswetenschappers besteden doorgaans geen tijd aan het opschonen van de tussenliggende gegevenssets die worden gegenereerd. Na verloop van tijd wordt de hoeveelheid gegevens die wordt gegenereerd, opgetellen. Azure Storage wordt geleverd met een mogelijkheid om het beheer van de levenscyclus van gegevens te verbeteren. Met Azure Blob Storage levenscyclusbeheer kunt u algemeen beleid instellen om ongebruikte gegevens te verplaatsen naar koudere opslaglagen en kosten te besparen.

Overwegingen voor optimalisatie van infrastructuurkosten

Netwerken

Azure-netwerkkosten worden gemaakt door uitgaande bandbreedte van het Azure-datacenter. Alle inkomende gegevens naar een Azure-datacenter zijn gratis. De sleutel tot het verlagen van de netwerkkosten is om waar mogelijk al uw resources in dezelfde datacenterregio te implementeren. Als u een Azure Machine Learning-werkruimte en berekening kunt implementeren in dezelfde regio met uw gegevens, kunt u profiteren van lagere kosten en hogere prestaties.

Mogelijk wilt u een privéverbinding tussen uw on-premises netwerk en uw Azure-netwerk hebben om een hybride cloudomgeving te hebben. Met ExpressRoute kunt u dit doen, maar gezien de hoge kosten van ExpressRoute is het mogelijk rendabeler om af te stappen van een hybride cloudconfiguratie en alle resources naar de Azure-cloud te verplaatsen.

Azure Container Registry

Voor Azure Container Registry zijn de bepalende factoren voor kostenoptimalisatie:

• Vereiste doorvoer voor downloads van Docker-installatiekopieën vanuit het containerregister naar Azure Machine Learning
• Vereisten voor bedrijfsbeveiligingsfuncties, zoals Azure Private Link

Voor productiescenario's waarbij hoge doorvoer of bedrijfsbeveiliging is vereist, wordt de Premium-SKU van Azure Container Registry aanbevolen.

Voor ontwikkel-/testscenario's waarbij doorvoer en beveiliging minder kritiek zijn, raden we standard-SKU of Premium-SKU aan.

De Basic-SKU van Azure Container Registry wordt niet aanbevolen voor Azure Machine Learning. Dit wordt niet aanbevolen vanwege de lage doorvoer en de lage inbegrepen opslag, die snel kan worden overschreden door de relatief grote Docker-installatiekopieën (1+ GB) van Azure Machine Learning.

Overweeg beschikbaarheid van computingtypen bij het kiezen van Azure-regio's

Wanneer u een regio voor uw berekening kiest, moet u rekening houden met de beschikbaarheid van het rekenquotum. Populaire en grotere regio's zoals VS - oost, VS - west en Europa - west hebben meestal hogere standaardquotumwaarden en een grotere beschikbaarheid van de meeste CPU's en GPU's, vergeleken met sommige andere regio's met strengere capaciteitsbeperkingen.

Lees meer

Kosten bijhouden voor bedrijfseenheden, omgevingen of projecten met behulp van de Cloud Adoption Framework

Volgende stappen

Zie Azure Machine Learning-omgevingen organiseren en instellen voor meer informatie over het organiseren en instellen van Azure Machine Learning-omgevingen.

Organiseren en instellen van Azure Machine Learning-omgevingen

Zie De Handleiding voor Machine Learning DevOps voor meer informatie over best practices voor Machine Learning DevOps met Azure Machine Learning.

DevOps-handleiding voor Machine Learning