Upgrade auf v2
Die REST-APIs, die Azure CLI-Erweiterung und das Python SDK von Azure Machine Learning v2 führen Konsistenz und eine Reihe neuer Features ein, um den produktiven Machine Learning-Lebenszyklus zu beschleunigen. In diesem Artikel finden Sie eine Übersicht über das Upgrade auf v2 mit hilfreichen Empfehlungen bei Entscheidungen zu v1, v2 oder beiden.
Voraussetzungen
- Allgemeine Kenntnisse zu Azure Machine Learning und dem Python SDK v1
- Kenntnisse über das v2-Konzept
Wann sollte v2 verwendet werden?
Sie sollten v2 verwenden, wenn Sie ein neues Machine Learning-Projekt oder einen Workflow starten. Sie sollten v2 verwenden, wenn Sie die neuen Features verwenden möchten, die in v2 angeboten werden. Sie enthält folgende Features:
- Verwaltete Rückschlüsse
- Wiederverwendbare Komponenten in Pipelines
- Verbesserte Planung von Pipelines
- Dashboard für verantwortungsvolle KI
- Registrierung von Ressourcen
Ein neues v2-Projekt kann vorhandene v1-Ressourcen wie Arbeitsbereiche und Compute sowie vorhandene Objekte wie Modelle und Umgebungen, die mit v1 erstellt wurden, wiederverwenden.
Einige Featureunterschiede in v2 sind:
- Spark-Unterstützung in Aufträgen – Dies befindet sich derzeit in der Vorschau in v2.
- Veröffentlichen von Aufträgen (Pipelines in v1) als Endpunkte. Sie können jedoch auch Pipelines ohne Veröffentlichung planen.
- Unterstützung für SQL-/Datenbankdatenspeicher.
- Möglichkeit zum Verwenden klassischer vordefinierter Komponenten im Designer mit v2.
Anschließend sollten Sie sicherstellen, dass die in v2 benötigten Features die Anforderungen Ihrer Organisation erfüllen, z. B. allgemeine Verfügbarkeit.
Wichtig
Neue Features in Azure Machine Learning sind erst in v2 verfügbar.
Welche v2-API sollte ich verwenden?
In v2 sind Schnittstellen über REST-API, CLI und Python SDK verfügbar. Die Schnittstelle, die Sie verwenden sollten, hängt vom jeweiligen Szenario und Ihren Präferenzen ab.
| API | Notizen |
|---|---|
| REST | Geringste Abhängigkeiten und kleinster Aufwand. Verwenden Sie diese Schnittstelle zum Erstellen von Anwendungen für Azure Machine Learning als Plattform – direkt in Programmiersprachen ohne verfügbares SDK oder je nach persönlicher Vorliebe. |
| Befehlszeilenschnittstelle (CLI) | Empfohlen für die Automatisierung mit CI/CD oder je nach persönlicher Vorliebe. Ermöglicht eine schnelle Iteration mit YAML-Dateien und die einfache Trennung zwischen Azure Machine Learning und ML-Modellcode. |
| Python SDK | Empfohlen für komplizierte Skripterstellung (z. B. programmgesteuerte Generierung umfangreicher Pipelineaufträge) oder je nach persönlicher Vorliebe. Ermöglicht eine schnelle Iteration mit YAML-Dateien oder alleinige Entwicklung in Python. |
Zuordnung von Python SDK v1 zu v2
Eine Vergleichscodezuordnung für SDK v1 vs v2 finden Sie in den folgenden Artikeln.
| Ressourcen und Objekte | Artikel |
|---|---|
| Arbeitsbereich | Arbeitsbereichsverwaltung in SDK v1 und SDK v2 |
| Datenspeicher | Datenspeicherverwaltung in SDK v1 und SDK v2 |
| Daten | Datenressourcen in SDK v1 und v2 |
| Compute | Computeverwaltung in SDK v1 und SDK v2 |
| Training | Ausführen eines Skripts |
| Training | Lokale Ausführungen |
| Training | Hyperparameteroptimierung |
| Training | Parallele Ausführung |
| Training | Pipelines |
| Training | AutoML |
| Modelle | Modellverwaltung in SDK v1 und SDK v2 |
| Bereitstellung | Upgrade von Bereitstellungsendpunkten auf SDK v2 |
Ressourcen und Objekte in v1 und v2
Dieser Abschnitt zeigt eine Übersicht über bestimmte Ressourcen und Objekte in Azure Machine Learning. Weitere Informationen zur Verwendung der einzelnen Entitäten in v2 finden Sie im zugehörigen Konzeptartikel.
Arbeitsbereich
Für Arbeitsbereiche muss kein Upgrade auf v2 durchgeführt werden. Sie können denselben Arbeitsbereich verwenden, unabhängig davon, ob v1 oder v2 verwendet wird.
Wenn Sie Arbeitsbereiche mithilfe von Automation erstellen, sollten Sie in Erwägung ziehen, für den Code zum Erstellen eines Arbeitsbereichs ein Upgrade auf v2 durchzuführen. Normalerweise werden Azure-Ressourcen über Azure Resource Manager (und Bicep) oder ähnliche Ressourcenbereitstellungstools verwaltet. Alternativ können Sie die Dateien von CLI (v2) und YAML verwenden.
Einen Vergleich von SDK v1- und v2-Code finden Sie unter Arbeitsbereichsverwaltung in SDK v1 und SDK v2.
Wichtig
Wenn Ihr Arbeitsbereich einen privaten Endpunkt verwendet, wird für den Arbeitsbereich automatisch das Flag v1_legacy_mode aktiviert, um die Verwendung von v2-APIs zu verhindern. Weitere Informationen finden Sie in der Vorgehensweise zum Konfigurieren der Netzwerkisolation für v2.
Verbindung (Arbeitsbereichverbindung in v1)
Arbeitsbereichverbindungen von v1 werden im Arbeitsbereich beibehalten und sind für v2 vollständig verfügbar.
Einen Vergleich von SDK v1- und v2-Code finden Sie unter Arbeitsbereichsverwaltung in SDK v1 und SDK v2.
Datenspeicher
Datenspeichertypen für Objektspeicher, die mit v1 erstellt wurden, sind uneingeschränkt für die Verwendung in v2 verfügbar. Datenbankdatenspeicher werden nicht unterstützt. Der empfohlene Migrationspfad ist ein Export in Objektspeicher (normalerweise Azure Blob).
Einen Vergleich von SDK v1- und v2-Code finden Sie unter Datenspeicherverwaltung in SDK v1 und SDK v2.
Daten (Datasets in v1)
Datasets wurden in Datenobjekte umbenannt. Abwärtskompatibilität wird bereitgestellt, d. h. Sie können V1-Datasets in V2 verwenden. Wenn Sie ein V1-Dataset in einem V2-Auftrag verwenden, werden Sie feststellen, dass diese automatisch wie folgt zu V2-Typen zugeordnet werden:
- V1 FileDataset = V2 Folder (
uri_folder) - V1 TabularDataset = V2 Table (
mltable)
Beachten Sie, dass keineAufwärtskompatibilität gegeben ist, d. h. Sie können keine V2-Datenobjekte in V1 verwenden.
In diesem Artikel erfahren Sie mehr über den Umgang mit Daten in v2 – Lesen und Schreiben von Daten in einem Auftrag
Einen Vergleich des SDK v1- und v2-Codes finden Sie unter Datenobjekte in SDK v1 und v2.
Compute
Computeressourcen des Typs AmlCompute und ComputeInstance sind uneingeschränkt für die Verwendung in v2 verfügbar.
Einen Vergleich von SDK v1- und v2-Code finden Sie unter Computeverwaltung in SDK v1 und SDK v2.
Aufträge (Experimente, Ausführungen, Pipelines in v1)
In v2 wurden „Experimente“, „Ausführungen“ und „Pipelines“ in Aufträge konsolidiert. Ein Auftrag verfügt über einen Typ. Die meisten Aufträge sind command-Aufträge, die einen Befehl ausführen, z. B. python main.py. Was in einem Auftrag ausgeführt wird, ist unabhängig von der jeweiligen Programmiersprache, sodass Sie bash-Skripts ausführen, python-Interpreter aufrufen, eine Reihe von curl-Befehlen oder beliebige andere Aktionen ausführen können. Ein weiterer allgemeiner Auftragstyp ist pipeline. Dieser definiert untergeordnete Aufträge, die Eingabe-/Ausgabebeziehungen haben können und einen gerichteten azyklischen Graphen bilden.
Einen Vergleich von SDK v1- und v2-Code finden Sie unter
- Ausführen eines Skripts
- Lokale Ausführungen
- Hyperparameteroptimierung
- Parallele Ausführung
- Pipelines
- AutoML
Designer
Sie können den Designer verwenden, um Pipelines mithilfe Ihrer eigenen benutzerdefinierten v2-Komponenten und der neuen vordefinierten Komponenten aus der Registrierung zu erstellen. In dieser Situation können Sie v1- oder v2-Datenobjekte in Ihrer Pipeline verwenden.
Sie können weiterhin den Designer verwenden, um Pipelines mithilfe klassischer vordefinierter Komponenten und v1-Datasettypen (tabellarisch, Datei) zu erstellen. Sie können keine klassischen vordefinierten Komponenten aus dem Designer mit v2-Datenobjekten verwenden.
Sie können keine Pipeline erstellen, die sowohl vordefinierte klassische Designerkomponenten als auch benutzerdefinierte v2-Komponenten verwendet.
Modell
Modelle, die von v1 erstellt wurden, können in v2 verwendet werden.
Einen Vergleich von SDK v1- und v2-Code finden Sie unter Modellverwaltung in SDK v1 und SDK v2.
Endpunkt und Bereitstellung (Endpunkt oder Webdienst in v1)
Mit SDK/CLI v1 können Sie Modelle in ACI oder AKS als Webdienste bereitstellen. Ihre bestehenden v1-Modellbereitstellungen und Webdienste funktionieren weiterhin wie bisher, aber die Verwendung von SDK/CLI v1 zur Bereitstellung von Modellen auf ACI oder AKS als Webdienste wird jetzt als Legacy betrachtet. Für neue Modellimplementierungen wird ein Upgrade zu v2 empfohlen. In v2 sind verwaltete Endpunkte und Kubernetes-Endpunkte verfügbar. Die folgende Tabelle enthält eine Übersicht über unsere Empfehlungen:
| Endpunkttyp in v2 | Upgrade von | Notizen |
|---|---|---|
| Lokal | ACI | Lokaler Schnelltest der Modellimplementierung; nicht für die Produktion. |
| Verwalteter Onlineendpunkt | ACI, AKS | Unternehmensweite, verwaltete Modellimplementierungsinfrastruktur mit Reaktion nahezu in Echtzeit und massiver Skalierung für die Produktion. |
| Verwalteter Batchendpunkt | ParallelRunStep in einer Pipeline für die Batchbewertung | Unternehmensweite, verwaltete Modellimplementierungsinfrastruktur mit massiv-paralleler Batchverarbeitung für die Produktion. |
| Azure Kubernetes Service (AKS) | ACI, AKS | Verwaltung eigener AKS-Cluster für die Modellimplementierung, um hohe Flexibilität und eine präzise Kontrolle der Kosten für IT-Aufwände zu ermöglichen. |
| Kubernetes in Azure Arc | – | Verwaltung eigener Kubernetes-Cluster in anderen Clouds oder lokal, um hohe Flexibilität und eine präzise Kontrolle der Kosten für IT-Aufwände zu ermöglichen. |
Einen Vergleich von SDK v1- und v2-Code finden Sie unter Upgrade von Bereitstellungsendpunkten auf SDK v2. Informationen zu den Migrationsschritten von Ihren bestehenden ACI-Webdiensten zu verwalteten Onlineendpunkten finden Sie in unserem Artikel in der Anleitung zum Upgrade und im Blog.
Environment
Umgebungen, die von v1 erstellt wurden, können in v2 verwendet werden. In v2 weisen Umgebungen neue Features wie die Erstellung in einem lokalen Docker-Kontext auf.
Verwaltung geheimer Schlüssel
Die Verwaltung von Key Vault-Geheimnissen unterscheidet sich in V2 erheblich von der in V1. Die SDK-Methoden „set_secret“ und „get_secret“ aus V1 sind in V2 nicht verfügbar. Stattdessen sollten Sie den direkten Zugriff über die Clientbibliotheken von Key Vault verwenden. Beim Zugriff auf geheime Schlüssel aus einem Schulungsskript können Sie entweder die verwaltete Identität des Computes oder Ihrer Identität verwenden.
Ausführliche Informationen zu Key Vault finden Sie unter Verwenden von Geheimnissen als Anmeldeinformationen für die Authentifizierung in Azure Machine Learning-Trainingsaufträgen.
Szenarien im Machine Learning-Lebenszyklus
Es gibt einige Szenarien, die in allen Machine Learning-Lebenszyklen mit Azure Machine Learning vorkommen. Wir werden uns einige davon ansehen und allgemeine Empfehlungen für das Upgrade zu v2 geben.
Azure-Einrichtung
Azure empfiehlt Azure Resource Manager-Vorlagen (zur Vereinfachung häufig über Bicep), um Ressourcen zu erstellen. Auch für die Erstellung von Azure Machine Learning-Ressourcen ist dies eine sinnvolle Vorgehensweise.
Wenn Ihr Team nur Azure Machine Learning verwendet, sollten Sie erwägen, den Arbeitsbereich und alle anderen Ressourcen stattdessen über YAML-Dateien und die CLI bereitzustellen.
Erstellen von Modellprototypen
Zum Erstellen von Modellprototypen wird v2 empfohlen. Sie sollten erwägen, die CLI für eine interaktive Verwendung von Azure Machine Learning, für den Modelltrainingscode jedoch Python oder eine andere Programmiersprache zu verwenden. Alternativ dazu können Sie einen durchgängigen Ansatz mit Python, bei dem nur das Azure Machine Learning SDK verwendet wird, oder einen gemischten Ansatz mit dem Azure Machine Learning Python SDK und YAML-Dateien nutzen.
Training des Produktionsmodells
Für das Training des Produktionsmodells wird v2 empfohlen. Aufträge konsolidieren die Terminologie und ermöglichen eine Konsistenz, die den Übergang zwischen Typen (z. B. von command zu sweep) erleichtert und GitOps-Prozesse zum Serialisieren von Aufträgen in YAML-Dateien vereinfacht.
Bei v2 sollten Sie Machine Learning-Code vom Code der Steuerungsebene trennen. Diese Trennung ermöglicht eine einfachere Iteration und einen einfacheren Übergang zwischen einer lokalen Umgebung und der Cloud. Wir empfehlen außerdem, MLflow für die Nachverfolgung und Modellprotokollierung zu verwenden. Ausführliche Informationen finden Sie im Artikel zum MLflow-Konzept.
Implementierung des Produktionsmodells
Für die Implementierung des Produktionsmodells wird v2 empfohlen. Verwaltete Endpunkte reduzieren den IT-Aufwand und ermöglichen eine performante Lösung für die Implementierung und Bewertung von Modellen sowohl für Onlineszenarien (nahezu in Echtzeit) als auch für (massiv-parallele) Batchszenarien.
Kubernetes-Bereitstellungen werden in v2 über AKS oder Azure Arc unterstützt, sodass Azure Cloud-Bereitstellungen und lokale Bereitstellungen ermöglicht werden, die von Ihrer Organisation verwaltet werden.
Machine Learning Operations (MLOps)
Ein MLOps-Workflow umfasst in der Regel Continuous Integration und Continuous Delivery (CI/CD) über ein externes Tool. Normalerweise wird eine CLI in CI/CD verwendet, Sie können aber auch Python aufrufen oder direkt REST verwenden.
Der Lösungsbeschleuniger für MLOps mit v2 wird unter https://github.com/Azure/mlops-v2 entwickelt und kann als Referenz oder für die Einrichtung und Automatisierung des Machine Learning-Lebenszyklus verwendet werden.
Ein Hinweis zu GitOps mit v2
Ein wichtiges Paradigma für v2 ist die Serialisierung von Machine Learning-Entitäten als YAML-Dateien für die Quellcodeverwaltung mit git, sodass bessere GitOps-Ansätze als mit v1 ermöglicht werden. Sie können beispielsweise Richtlinien erzwingen, damit nur ein Dienstprinzipal, der in CI/CD-Pipelines verwendet wird, einige oder alle Entitäten erstellen, aktualisieren oder löschen kann, und sichergestellt wird, dass Änderungen einen geregelten Prozess durchlaufen, z. B. Pull Requests mit erforderlichen Prüfern. Da die Dateien in der Quellcodeverwaltung YAML-Dateien sind, können Unterschiede einfach festgestellt und Änderungen im Laufe der Zeit einfach nachverfolgt werden. Sie und Ihr Team sollten beim Upgrade zu v2 in Erwägung ziehen, zu diesem Paradigma zu wechseln.
Über az ml <entity> show --output yaml können Sie mit der CLI eine YAML-Darstellung einer beliebigen Entität erhalten. Die Ausgabe umfasst systemgenerierte Eigenschaften, die ignoriert oder gelöscht werden können.
Soll ich bestehenden v1-Code auf v2 aktualisieren
Sie können Ihre bestehenden v1-Ressourcen in Ihren v2-Workflows wiederverwenden. So kann beispielsweise ein in v1 erstelltes Modell verwendet werden, um verwaltete Rückschlüsse in v2 durchzuführen.
Wenn Sie optional bestimmte Teile Ihres vorhandenen v1-Codes auf v2 aktualisieren möchten, lesen Sie die in diesem Dokument angegebenen Vergleichslinks.
Kann ich v1 und v2 zusammen verwenden?
v1 und v2 können in einem Arbeitsbereich gleichzeitig vorhanden sein. Sie können Ihre vorhandenen Ressourcen in Ihren v2-Workflows wiederverwenden. So kann beispielsweise ein in v1 erstelltes Modell verwendet werden, um verwaltete Rückschlüsse in v2 durchzuführen. Ressourcen wie Arbeitsbereich, Computeressourcen und Datenspeicher können mit Ausnahmen in v1 und v2 verwendet werden. Ein Benutzer kann das v1-Python-SDK aufrufen, um die Beschreibung eines Arbeitsbereichs zu ändern, und diese dann mit der v2-CLI-Erweiterung wieder ändern. Aufträge (Experimente/Ausführungen/Pipelines in v1) können vom v1- oder v2-Python-SDK aus an den gleichen Arbeitsbereich übermittelt werden. Ein Arbeitsbereich kann sowohl v1- als auch v2-Modellimplementierungsendpunkte aufweisen.
Gemeinsame Verwendung von v1- und v2-Code
Wir raten davon ab, die SDKs v1 und v2 zusammen in demselben Code zu verwenden. Es ist technisch möglich, v1 und v2 im selben Code zu verwenden, da sie unterschiedliche Azure-Namespaces verwenden. Allerdings gibt es in diesen Namespaces viele Klassen mit demselben Namen (z. B. Arbeitsbereich, Modell), was zu Verwirrung führen und die Lesbarkeit und Fehlersuche im Code erschweren kann.
Wichtig
Wenn Ihr Arbeitsbereich einen privaten Endpunkt verwendet, wird für den Arbeitsbereich automatisch das Flag v1_legacy_mode aktiviert, um die Verwendung von v2-APIs zu verhindern. Weitere Informationen finden Sie in der Vorgehensweise zum Konfigurieren der Netzwerkisolation mit v2.