Uppgradera till v2
Azure Machine Learnings v2 REST-API:er, Azure CLI-tillägg och Python SDK ger konsekvens och en uppsättning nya funktioner för att påskynda livscykeln för maskininlärning i produktion. Den här artikeln innehåller en översikt över uppgradering till v2 med rekommendationer som hjälper dig att välja v1, v2 eller båda.
Förutsättningar
- Allmän kunskap om Azure Machine Learning och v1 Python SDK.
- Förstå vad som är v2?
Ska jag använda v2?
Du bör använda v2 om du startar ett nytt maskininlärningsprojekt eller arbetsflöde. Du bör använda v2 om du vill använda de nya funktionerna som erbjuds i v2. Här följer exempel på några funktioner:
- Hanterad slutsatsdragning
- Återanvändbara komponenter i pipelines
- Förbättrad schemaläggning av pipelines
- Instrumentpanel för ansvarsfull AI
- Register över tillgångar
Ett nytt v2-projekt kan återanvända befintliga resurser som arbetsytor och beräkning och befintliga tillgångar som modeller och miljöer som skapats med v1.
Några funktionsluckor i v2 är:
- Spark-stöd i jobb – det här är för närvarande i förhandsversion i v2.
- Publicera jobb (pipelines i v1) som slutpunkter. Du kan dock schemalägga pipelines utan att publicera.
- Stöd för SQL-/databasdatalager.
- Möjlighet att använda klassiska fördefinierade komponenter i designern med v2.
Du bör sedan se till att de funktioner du behöver i v2 uppfyller organisationens krav, till exempel att de är allmänt tillgängliga.
Viktigt
Nya funktioner i Azure Machine Learning lanseras endast i v2.
Ska jag uppgradera befintlig kod till v2
Du kan återanvända dina befintliga tillgångar i dina v2-arbetsflöden. Till exempel kan en modell som skapats i v1 användas för att utföra hanterad slutsatsdragning i v2.
Om du vill uppgradera vissa delar av din befintliga kod till v2 kan du läsa jämförelselänkarna i informationen om varje resurs eller tillgång i resten av det här dokumentet.
Vilket v2-API ska jag använda?
I v2-gränssnitt via REST API är CLI och Python SDK tillgängliga. Vilket gränssnitt du ska använda beror på ditt scenario och dina inställningar.
| API | Kommentarer |
|---|---|
| REST | Få beroenden och omkostnader. Använd för att skapa program på Azure Machine Learning som en plattform, direkt i programmeringsspråk utan ett SDK eller per personlig inställning. |
| CLI | Rekommenderas för automatisering med CI/CD eller per personlig inställning. Möjliggör snabb iteration med YAML-filer och enkel separation mellan Azure Machine Learning och ML-modellkod. |
| Python SDK | Rekommenderas för komplicerade skript (till exempel programmatiskt generera stora pipelinejobb) eller per personlig inställning. Möjliggör snabb iteration med YAML-filer eller utveckling enbart i Python. |
Kan jag använda v1 och v2 tillsammans?
v1 och v2 kan samexistera på en arbetsyta. Du kan återanvända dina befintliga tillgångar i dina v2-arbetsflöden. Till exempel kan en modell som skapats i v1 användas för att utföra hanterad slutsatsdragning i v2. Resurser som arbetsyta, beräkning och datalager fungerar i v1 och v2, med undantag. En användare kan anropa Python SDK v1 för att ändra en arbetsytas beskrivning och sedan ändra den igen med hjälp av v2 CLI-tillägget. Jobb (experiment/körningar/pipelines i v1) kan skickas till samma arbetsyta från Python SDK v1 eller v2. En arbetsyta kan ha både v1- och v2-modelldistributionsslutpunkter.
Använda v1- och v2-kod tillsammans
Vi rekommenderar inte att du använder V1- och v2-SDK:erna tillsammans i samma kod. Tekniskt sett är det möjligt att använda v1 och v2 i samma kod eftersom de använder olika Azure-namnområden. Det finns dock många klasser med samma namn i dessa namnområden (till exempel Arbetsyta, Modell) som kan orsaka förvirring och göra det svårt att läsa och felsöka kod.
Viktigt
Om din arbetsyta använder en privat slutpunkt har den v1_legacy_mode automatiskt flaggan aktiverad, vilket förhindrar användning av v2-API:er. Mer information finns i konfigurera nätverksisolering med v2 .
Resurser och tillgångar i v1 och v2
Det här avsnittet ger en översikt över specifika resurser och tillgångar i Azure Machine Learning. Se begreppsartikeln för varje entitet för mer information om deras användning i v2.
Arbetsyta
Arbetsytor behöver inte uppgraderas med v2. Du kan använda samma arbetsyta, oavsett om du använder v1 eller v2.
Om du skapar arbetsytor med automatisering bör du uppgradera koden för att skapa en arbetsyta till v2. Vanligtvis hanteras Azure-resurser via Azure Resource Manager (och Bicep) eller liknande verktyg för resursetablering. Du kan också använda CLI-filerna (v2) och YAML-filerna.
En jämförelse av SDK v1- och v2-kod finns i Arbetsytehantering i SDK v1 och SDK v2.
Viktigt
Om din arbetsyta använder en privat slutpunkt har den v1_legacy_mode automatiskt flaggan aktiverad, vilket förhindrar användning av v2-API:er. Mer information finns i konfigurera nätverksisolering med v2 .
Anslutning (arbetsyteanslutning i v1)
Arbetsyteanslutningar från v1 sparas på arbetsytan och är helt tillgängliga med v2.
En jämförelse av SDK v1- och v2-kod finns i Arbetsytehantering i SDK v1 och SDK v2.
Datalager
Datalagringstyper för objektlagring som skapats med v1 är fullt tillgängliga för användning i v2. Databasdatalager stöds inte. export till objektlagring (vanligtvis Azure Blob) är den rekommenderade migreringsvägen.
En jämförelse av SDK v1- och v2-kod finns i Datalagerhantering i SDK v1 och SDK v2.
Compute
Beräkning av typen AmlCompute och ComputeInstance är fullt tillgängliga för användning i v2.
En jämförelse av SDK v1- och v2-kod finns i Beräkningshantering i SDK v1 och SDK v2.
Slutpunkt och distribution (slutpunkt och webbtjänst i v1)
Med SDK/CLI v1 kan du distribuera modeller på ACI eller AKS som webbtjänster. Dina befintliga v1-modelldistributioner och webbtjänster fortsätter att fungera som de är, men att använda SDK/CLI v1 för att distribuera modeller på ACI eller AKS som webbtjänster är nu konsoliderat som äldre. För nya modelldistributioner rekommenderar vi att du uppgraderar till v2. I v2 erbjuder vi hanterade slutpunkter eller Kubernetes-slutpunkter. Följande tabell vägleder vår rekommendation:
| Slutpunktstyp i v2 | Uppgradera från | Kommentarer |
|---|---|---|
| Lokal | ACI | Snabbtest av modelldistribution lokalt; inte för produktion. |
| Hanterad onlineslutpunkt | ACI, AKS | Distributionsinfrastruktur i företagsklass med svar i nära realtid och massiv skalning för produktion. |
| Hanterad batchslutpunkt | ParallelRunStep i en pipeline för batchbedömning | Distributionsinfrastruktur för hanterade modeller i företagsklass med massivt parallell batchbearbetning för produktion. |
| Azure Kubernetes Service (AKS) | ACI, AKS | Hantera dina egna AKS-kluster för modelldistribution, vilket ger flexibilitet och detaljerad kontroll på bekostnad av IT-kostnader. |
| Azure Arc Kubernetes | Ej tillämpligt | Hantera dina egna Kubernetes-kluster i andra moln eller lokalt, vilket ger flexibilitet och detaljerad kontroll på bekostnad av IT-kostnader. |
En jämförelse av SDK v1- och v2-kod finns i Uppgradera distributionsslutpunkter till SDK v2. Information om migreringssteg från dina befintliga ACI-webbtjänster till hanterade onlineslutpunkter finns i vår uppgraderingsguideartikel och blogg.
Jobb (experiment, körningar, pipelines i v1)
I v2 konsolideras ”experiment”, ”körningar” och ”pipelines” till jobb. Ett jobb har en typ. De flesta jobb är command jobb som kör ett kommando, till exempel python main.py. Det som körs i ett jobb är oberoende för alla programmeringsspråk, så du kan köra bash skript, anropa python tolkar, köra en massa curl kommandon eller något annat. En annan vanlig typ av jobb är pipeline, som definierar underordnade jobb som kan ha indata-/utdatarelationer och bildar en riktad acyklisk graf (DAG).
En jämförelse av SDK v1- och v2-kod finns i
Designer
Du kan använda designern för att skapa pipelines med dina egna v2-anpassade komponenter och de nya fördefinierade komponenterna från registret. I det här fallet kan du använda v1- eller v2-datatillgångar i pipelinen.
Du kan fortsätta att använda designern för att skapa pipelines med klassiska fördefinierade komponenter och v1-datauppsättningstyper (tabell, fil). Du kan inte använda befintliga klassiska designkomponenter med v2-datatillgång.
Du kan inte skapa en pipeline med både befintliga klassiska fördefinierade designerkomponenter och anpassade v2-komponenter.
Data (datauppsättningar i v1)
Datauppsättningar byt namn till datatillgångar. Bakåtkompatibilitet tillhandahålls, vilket innebär att du kan använda V1-datauppsättningar i V2. När du använder en V1-datauppsättning i ett V2-jobb ser du att de automatiskt mappas till V2-typer på följande sätt:
- V1 FileDataset = V2-mapp (
uri_folder) - V1 TabularDataset = V2 Table (
mltable)
Observera att kompatibilitet för vidarebefordran inte tillhandahålls, vilket innebär att du inte kan använda V2-datatillgångar i V1.
Den här artikeln handlar mer om att hantera data i v2 – Läsa och skriva data i ett jobb
En jämförelse av SDK v1- och v2-kod finns i Datatillgångar i SDK v1 och v2.
Modell
Modeller som skapats från v1 kan användas i v2.
En jämförelse av SDK v1- och v2-kod finns i Modellhantering i SDK v1 och SDK v2
Miljö
Miljöer som skapats från v1 kan användas i v2. I v2 har miljöer nya funktioner som att skapa från en lokal Docker-kontext.
Hantera hemligheter
Hanteringen av Key Vault hemligheter skiljer sig avsevärt i V2 jämfört med V1. Metoderna V1 set_secret och get_secret SDK är inte tillgängliga i V2. I stället ska direkt åtkomst med Key Vault klientbibliotek användas.
Mer information om Key Vault finns i Använda hemligheter för autentiseringsuppgifter i Azure Machine Learning-träningsjobb.
Scenarier i livscykeln för maskininlärning
Det finns några scenarier som är vanliga i hela maskininlärningslivscykeln med hjälp av Azure Machine Learning. Vi ska titta på några och ge allmänna rekommendationer för uppgradering till v2.
Azure-konfiguration
Azure rekommenderar Azure Resource Manager-mallar (ofta via Bicep för enkel användning) för att skapa resurser. Detsamma är en bra metod för att skapa Azure Machine Learning-resurser.
Om ditt team bara använder Azure Machine Learning kan du överväga att etablera arbetsytan och andra resurser via YAML-filer och CLI i stället.
Prototypmodeller
Vi rekommenderar v2 för prototypmodeller. Du kan överväga att använda CLI för interaktiv användning av Azure Machine Learning, medan din modellträningskod är Python eller något annat programmeringsspråk. Alternativt kan du använda en fullstack-metod med Python enbart med hjälp av Azure Machine Learning SDK eller en blandad metod med Azure Machine Learning Python SDK- och YAML-filerna.
Utbildning av produktionsmodell
Vi rekommenderar v2 för träning av produktionsmodell. Jobb konsoliderar terminologin och ger en uppsättning konsekvens som möjliggör enklare övergång mellan typer (till exempel command till sweep) och en GitOps-vänlig process för serialisering av jobb till YAML-filer.
Med v2 bör du separera maskininlärningskoden från kontrollplanets kod. Den här separationen möjliggör enklare iteration och möjliggör enklare övergång mellan lokalt och moln. Vi rekommenderar också att du använder MLflow för spårning och modellloggning. Mer information finns i artikeln om MLflow-koncept .
Distribution av produktionsmodell
Vi rekommenderar v2 för distribution av produktionsmodell. Hanterade slutpunkter abstraherar IT-omkostnaderna och tillhandahåller en högpresterande lösning för distribution och bedömning av modeller, både för onlinescenarier (nära realtid) och batchscenarier (massivt parallella).
Kubernetes-distributioner stöds i v2 via AKS eller Azure Arc, vilket möjliggör Azure-molndistributioner och lokala distributioner som hanteras av din organisation.
Maskininlärningsåtgärder (MLOps)
Ett MLOps-arbetsflöde omfattar vanligtvis CI/CD via ett externt verktyg. Vanligtvis används en CLI i CI/CD, men du kan också anropa Python eller använda REST direkt.
Lösningsacceleratorn för MLOps med v2 utvecklas på https://github.com/Azure/mlops-v2 och kan användas som referens eller användas för installation och automatisering av maskininlärningslivscykeln.
En anteckning om GitOps med v2
Ett viktigt paradigm med v2 är serialisering av maskininlärningsentiteter som YAML-filer för källkontroll med git, vilket möjliggör bättre GitOps-metoder än vad som var möjligt med v1. Du kan till exempel framtvinga en princip som endast ett tjänsthuvudnamn som används i CI/CD-pipelines kan skapa/uppdatera/ta bort vissa eller alla entiteter, vilket säkerställer att ändringar går igenom en styrd process som pull-begäranden med nödvändiga granskare. Eftersom filerna i källkontrollen är YAML är de enkla att diffa och spåra ändringar över tid. Du och ditt team kan överväga att byta till det här paradigmet när du uppgraderar till v2.
Du kan hämta en YAML-representation av en entitet med CLI via az ml <entity> show --output yaml. Observera att dessa utdata har systemgenererade egenskaper som kan ignoreras eller tas bort.