Uppgradera till v2
Azure Machine Learnings REST-API:er för v2, Azure CLI-tillägget 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 v1-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 – detta ä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 vara allmänt tillgängliga.
Viktigt!
Nya funktioner i Azure Machine Learning lanseras endast i v2.
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 | Kommentar |
|---|---|
| REST | Få beroenden och omkostnader. Används för att skapa program på Azure Machine Learning som en plattform, direkt i programmeringsspråk utan en SDK som tillhandahålls eller enligt personliga inställningar. |
| 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. |
Mappning av Python SDK v1 till v2
Se var och en av följande artiklar för en jämförelsekodmappning för SDK v1 jämfört med v2.
| Resurser och tillgångar | Artikel |
|---|---|
| Arbetsyta | Hantering av arbetsytor i SDK v1 och SDK v2 |
| Datalager | Datalagerhantering i SDK v1 och SDK v2 |
| Data | Datatillgångar i SDK v1 och v2 |
| Compute | Beräkningshantering i SDK v1 och SDK v2 |
| Utbildning | Köra ett skript |
| Utbildning | Lokala körningar |
| Utbildning | Justering av hyperparametrar |
| Utbildning | Parallell körning |
| Utbildning | Pipelines |
| Utbildning | AutoML |
| Modeller | Modellhantering i SDK v1 och SDK v2 |
| Distribution | Uppgradera distributionsslutpunkter till SDK 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. Mer information om deras användning i v2 finns i konceptartikeln för varje entitet.
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- (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 aktiveras v1_legacy_mode flaggan automatiskt, 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
Objektlagringsdatalagertyper 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 migreringssökvägen.
En jämförelse av SDK v1- och v2-kod finns i Datalagerhantering i SDK v1 och SDK v2.
Data (datauppsättningar i v1)
Datauppsättningar byter 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-tabell (
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.
Compute
Beräkning av typ 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.
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 designer 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 designer för att skapa pipelines med hjälp av 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.
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
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 betraktas nu 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 | Kommentar |
|---|---|---|
| Lokal | ACI | Snabbtest av modelldistribution lokalt; inte för produktion. |
| Hanterad onlineslutpunkt | ACI, AKS | Distributionsinfrastruktur i företagsklass med nästan realtidssvar och massiv skalning för produktion. |
| Hanterad batchslutpunkt | ParallelRunStep i en pipeline för batchbedömning | Distributionsinfrastruktur 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.
Environment
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. När du kommer åt hemligheter från ett träningsskript kan du använda antingen den hanterade identiteten för beräkningen eller din identitet.
Mer information om Key Vault finns i Använda hemligheter för autentiseringsautentiseringsuppgifter i Azure Machine Learning-träningsjobb.
Scenarier i hela maskininlärningslivscykeln
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. Samma sak ä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. Du kan också 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.
Träning av produktionsmodell
Vi rekommenderar v2 för träning av produktionsmodeller. 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 kontrollplanskoden. 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.
MLOps (Machine Learning Operations, maskininlärningsdrift)
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 tillämpa en princip genom vilken endast ett huvudnamn för tjänsten 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 lätta att ta reda på 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 få en YAML-representation av vilken entitet som helst med CLI via az ml <entity> show --output yaml. Observera att dessa utdata har systemgenererade egenskaper som kan ignoreras eller tas bort.
Ska jag uppgradera befintlig v1-kod till v2
Du kan återanvända dina befintliga v1-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 specifika delar av din befintliga v1-kod till v2 kan du läsa jämförelselänkarna i det här dokumentet.
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 v1 Python SDK för att ändra en arbetsytas beskrivning och sedan ändra den med hjälp av v2 CLI-tillägget igen. Jobb (experiment/körningar/pipelines i v1) kan skickas till samma arbetsyta från python-SDK:t 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. Det är tekniskt 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 aktiveras v1_legacy_mode flaggan automatiskt, vilket förhindrar användning av v2-API:er. Mer information finns i konfigurera nätverksisolering med v2 .