Share via

Onlineendpunkte und Bereitstellungen für Rückschlüsse in Echtzeit

  • Artikel

GILT FÜR:Azure CLI ML-Erweiterung v2 (aktuell)Python SDK azure-ai-ml v2 (aktuell)

Azure Machine Learning ermöglicht Ihnen die Durchführung von Echtzeitrückschlüssen für Daten mithilfe von Modellen, die auf Onlineendpunkten bereitgestellt werden. Rückschluss ist der Prozess, bei dem neue Eingabedaten auf ein Machine Learning-Modell angewandt werden, um Ausgaben zu generieren. Obwohl diese Ausgaben in der Regel als „Vorhersagen“ bezeichnet werden, können Rückschlüsse verwendet werden, um Ausgaben für andere Aufgaben zum maschinellen Lernen wie Klassifizierung und Clustering zu generieren.

Onlineendpunkte

Onlineendpunkte stellen Modelle auf einem Webserver bereit, der über das HTTP-Protokoll Vorhersagen zurückgeben kann. Verwenden Sie Onlineendpunkte, um Modelle für Echtzeitrückschlüsse in synchronen Anforderungen mit niedriger Latenz zu operationalisieren. Es wird empfohlen, sie in folgenden Fällen zu verwenden:

  • Ihre Anforderungen sind latenzarm.
  • Ihr Modell kann eine Anforderung in relativ kurzer Zeit beantworten.
  • Die Eingaben Ihres Modells passen zur HTTP-Payload der Anforderung.
  • Sie müssen die Anzahl der Anforderungen hochskalieren.

Um einen Endpunkt zu definieren, müssen Sie folgendes angeben:

  • Endpunktname: Dieser muss innerhalb der Azure-Region eindeutig sein. Weitere Informationen zu den Benennungsregeln finden Sie unter Endpunktgrenzwerte.
  • Authentifizierungsmodus: Sie können für den Endpunkt aus dem schlüsselbasierten Authentifizierungsmodus, dem tokenbasierten Azure Machine Learning-Authentifizierungsmodus oder dem tokenbasierten Microsoft Entra-Authentifizierungsmodus (Preview) wählen. Weitere Informationen zur Authentifizierung finden Sie unter Authentifizieren bei einem Onlineendpunkt.

Azure Machine Learning ermöglicht die Verwendung praktischer verwalteter Onlineendpunkte, sodass Sie Ihre Machine Learning-Modelle schlüsselfertig bereitstellen können. Dies ist die empfohlene Option für die Verwendung von Onlineendpunkten in Azure Machine Learning. Verwaltete Onlineendpunkte arbeiten mit leistungsstarken CPU- und GPU-Computern in Azure auf skalierbare, vollständig verwaltete Weise. Diese Endpunkte sorgen auch für die Bereitstellung, Skalierung, Sicherung und Überwachung Ihrer Modelle, sodass Sie sich nicht um die Einrichtung und Verwaltung der zugrunde liegenden Infrastruktur kümmern müssen. Informationen zum Definieren eines verwalteten Onlineendpunkts finden Sie unter Definieren des Endpunkts.

Was spricht für verwaltete Onlineendpunkte im Gegensatz zu ACI oder AKS(v1)?

Verwaltete Onlineendpunkte sind die empfohlene Option für die Verwendung von Onlineendpunkten in Azure Machine Learning. In der folgenden Tabelle werden die wichtigsten Attribute verwalteter Onlineendpunkte mit Azure Machine Learning-Lösungen mit SDK/CLI v1 (ACI und AKS(v1)) verglichen.

Attribute Verwaltete Onlineendpunkte (v2) ACI oder AKS(v1)
Netzwerksicherheit/-isolation Einfache Eingangs-/Ausgangssteuerung mit schneller Umschaltung Virtuelle Netzwerke werden nicht unterstützt oder erfordern komplexe manuelle Konfiguration
Verwalteter Dienst – Vollständig verwaltete Computebereitstellung/-skalierung
– Netzwerkkonfiguration zur Verhinderung von Datenexfiltration
– Hostbetriebssystemupgrade, kontrollierter Rollout von direkten Updates		 – Skalierung in v1 eingeschränkt
– Netzwerkkonfiguration oder -upgrade muss benutzerseitig verwaltet werden
Endpunkte/Bereitstellung: Konzept Trennung zwischen Endpunkt und Bereitstellung für komplexe Szenarien wie den sicheren Rollout von Modellen Kein Endpunktkonzept
Diagnose und Überwachung – Debuggen lokaler Endpunkte mit Docker und Visual Studio Code möglich
– Erweiterte Metrik- und Protokollanalyse mit Diagramm/Abfrage zum Vergleich zwischen Bereitstellungen
– Kostenaufschlüsselung bis hinunter zur Bereitstellungsebene		 Kein einfaches lokales Debuggen
Skalierbarkeit Grenzenlose, elastische und automatische Skalierung - ACI ist nicht skalierbar
– AKS (v1) unterstützt nur clusterinterne Skalierung und erfordert Skalierbarkeitskonfiguration
Unternehmensfähigkeit Privater Link, kundenseitig verwaltete Schlüssel, Microsoft Entra ID, Kontingentverwaltung, Abrechnungsintegration, SLA Nicht unterstützt
Erweiterte ML-Features – Modelldatensammlung
– Modellüberwachung
– Champion-Challenger-Modell, sicherer Rollout, Datenverkehrsspiegelung
– Erweiterbar für verantwortungsvolle KI		 Nicht unterstützt

Wenn Sie lieber Kubernetes verwenden, um Ihre Modelle bereitzustellen und Endpunkte zu verwalten, und wenn Sie sich selbst um die Infrastrukturanforderungen kümmern können, können Sie alternativ auch Kubernetes-Onlineendpunkte verwenden. Auf diesen Endpunkten können Sie Modelle bereitstellen und Onlineendpunkte an Ihrem vollständig konfigurierten und verwalteten Kubernetes-Computeziel (mit CPUs oder GPUs) verwenden.

Was spricht für verwaltete Onlineendpunkte im Gegensatz zu AKS(v2)?

Mit verwalteten Onlineendpunkte können Sie Ihren Bereitstellungsprozess optimieren und von folgenden Vorteilen profitieren, die Kubernetes-Onlineendpunkte nicht bieten:

  • Verwaltete Infrastruktur

    • Automatische Bereitstellung der Computeressourcen und Hosting des Modells (Sie müssen nur VM-Typ und Skalierungseinstellungen angeben)
    • Automatische Updates und Patches für das zugrunde liegende Host-Betriebssystem-Image
    • Automatische Wiederherstellung von Knoten nach einem Systemausfall

  • Überwachung und Protokolle

    Screenshot: Azure Monitor-Graph zur Endpunktlatenz

  • Anzeigen von Kosten

    Screenshot: Kostendiagramm für einen Endpunkt und eine Bereitstellung

    Hinweis

    Verwaltete Onlineendpunkte basieren auf Azure Machine Learning Compute. Wenn Sie einen verwalteten Onlineendpunkt verwenden, bezahlen Sie die Compute- und Netzwerkgebühren. Es fallen keine zusätzlichen Gebühren an. Weitere Informationen zu Preisen finden Sie unter Azure-Preisrechner.

    Wenn Sie ein virtuelles Azure Machine Learning-Netzwerk verwenden, um ausgehenden Datenverkehr vom verwalteten Onlineendpunkt zu schützen, werden Ihnen die vom verwalteten virtuellen Netzwerk verwendeten Ausgangsregeln für Azure Private Link und FQDN in Rechnung gestellt. Weitere Informationen finden Sie bei den Preisen für verwaltete virtuelle Netzwerke.

Verwaltete Onlineendpunkte und Kubernetes-Onlineendpunkte im Vergleich

In der folgenden Tabelle werden die wichtigsten Unterschiede zwischen verwalteten Onlineendpunkten und Kubernetes-Onlineendpunkten hervorgehoben.

Verwaltete Onlineendpunkte Kubernetes-Onlineendpunkte (AKS(v2))
Empfohlene Benutzer Benutzer, die eine Bereitstellung eines verwalteten Modells und eine verbesserte MLOps-Benutzeroberfläche benötigen Benutzer, die Kubernetes bevorzugen und Infrastrukturanforderungen selbst verwalten können
Knotenbereitstellung Verwaltete Computebereitstellung, -aktualisierung, -entfernung Benutzerverantwortung
Knotenwartung Betriebssystemabbildaktualisierungen für verwaltete Hosts und Sicherheitshärtung Benutzerverantwortung
Clusterdimensionierung (Skalierung) Verwaltete manuelle und automatische Skalierung, die die Bereitstellung zusätzlicher Knoten unterstützt Manuelle und automatische Skalierung, die die Skalierung der Replikatanzahl innerhalb fester Clustergrenzen unterstützt
Computetyp Vom Dienst verwaltet Kundenseitig verwalteter Kubernetes-Cluster (Kubernetes)
Verwaltete Identität Unterstützt Unterstützt
Virtuelles Netzwerk (VNET) Unterstützt über verwaltete Netzwerkisolation Benutzerverantwortung
Standardmäßige Überwachung und Protokollierung Azure Monitor- und Log Analytics-Unterstützung (einschließlich Schlüsselmetriken und Protokolltabellen für Endpunkte und Bereitstellungen) Benutzerverantwortung
Protokollierung mit Application Insights (Legacy) Unterstützt Unterstützt
Anzeigen von Kosten Detaillierte Informationen zu Endpunkt/Bereitstellungsebene Clusterebene
Kosten, die angewendet werden auf VMs, die den Bereitstellungen zugewiesen sind Dem Cluster zugewiesene VMs
Gespiegelter Datenverkehr Unterstützt Nicht unterstützt
Bereitstellung ohne Code Unterstützt (MLflow- und Triton-Modelle) Unterstützt (MLflow- und Triton-Modelle)

Onlinebereitstellungen

Eine Bereitstellung umfasst Ressourcen und Berechnungen, die für das Hosting des Modells erforderlich sind, das den eigentlichen Rückschluss durchführt. Ein einzelner Endpunkt kann mehrere Bereitstellungen mit unterschiedlichen Konfigurationen enthalten. Dieses Setup hilft beim Entkoppeln der Schnittstelle, die vom Endpunkt dargestellt wird, von den Implementierungsdetails der Bereitstellung. Ein Onlineendpunkt verfügt über einen Routingmechanismus, der Anforderungen an bestimmte Bereitstellungen am Endpunkt weiterleiten kann.

Das folgende Diagramm zeigt einen Onlineendpunkt mit zwei Bereitstellungen: blau und grün. Die blaue Bereitstellung verwendet VMs mit einer CPU-SKU und führt Version 1 eines Modells aus. Die grüne Bereitstellung verwendet VMs mit einer GPU-SKU und führt Version 2 des Modells aus. Der Endpunkt ist so konfiguriert, dass 90 % des eingehenden Datenverkehrs an die blaue Bereitstellung und die verbleibenden 10 % an die grüne Bereitstellung geleitet werden.

Diagramm: Endpunkt, bei dem Datenverkehr auf zwei Bereitstellungen aufgeteilt wird

Um ein Modell bereitzustellen, müssen Sie über Folgendes verfügen:

  • Modelldateien (oder Name und Version eines Modells, das bereits in Ihrem Arbeitsbereich registriert ist).
  • Ein Bewertungsskript, d. h. Code, der das Modell für eine bestimmte Eingabeanforderung ausführt. Das Bewertungsskript empfängt an einen bereitgestellten Webdienst übermittelte Daten und übergibt sie an das Modell. Anschließend führt das Skript das Modell aus und gibt dessen Antwort an den Client zurück. Das Bewertungsskript ist modellspezifisch und muss die Daten verstehen, die das Modell als Eingabe erwartet und als Ausgabe zurückgibt.
  • Eine Umgebung, in der Ihr Modell ausgeführt wird. Die Umgebung kann ein Docker-Image mit Conda-Abhängigkeiten oder ein Dockerfile sein.
  • Einstellungen zum Angeben des Instanztyps und der Skalierungskapazität.

Wichtige Attribute einer Bereitstellung

In der folgenden Tabelle sind die Schlüsselattribute dieser Bereitstellung beschrieben:

Attribut Beschreibung
Name Der Name der Bereitstellung
Endpunktname Der Name des Endpunkts, unter dem die Bereitstellung erstellt werden soll.
Modell1 Das für die Bereitstellung zu verwendende Modell. Dieser Wert kann entweder ein Verweis auf ein vorhandenes versioniertes Modell im Arbeitsbereich oder eine Inline-Modellspezifikation sein. Weitere Informationen zum Nachverfolgen und Angeben des Pfads zu Ihrem Modell finden Sie unter Identifizieren des Modellpfads in Bezug auf AZUREML_MODEL_DIR.
Codepfad Der Pfad zu dem Verzeichnis in der lokalen Entwicklungsumgebung, das den gesamten Python-Quellcode für die Bewertung des Modells enthält. Sie können geschachtelte Verzeichnisse und Pakete verwenden.
„Scoring script“ (Bewertungsskript) Der Relativer Pfad zur Bewertungsdatei im Quellcodeverzeichnis. Dieser Python-Code muss über eine init()- und eine run()-Funktion verfügen. Die Funktion init() wird aufgerufen, nachdem das Modell erstellt oder aktualisiert wurde. (Sie kann verwendet werden, um das Modell z. B. im Arbeitsspeicher zwischenzuspeichern.) Die Funktion run() wird bei jedem Aufruf des Endpunkts aufgerufen, um die tatsächliche Bewertung und Vorhersage auszuführen.
Umgebung1 Die Umgebung zum Hosten des Modells und des Codes. Dieser Wert kann entweder ein Verweis auf eine vorhandene versionierte Umgebung im Arbeitsbereich oder eine Inline-Umgebungsspezifikation sein. Hinweis: Microsoft patcht die Basisimages regelmäßig, um bekannte Sicherheitsrisiken zu beheben. Sie müssen Ihren Endpunkt erneut bereitstellen, um das gepatchte Image verwenden zu können. Wenn Sie die Images selbst bereitstellen, liegt die Aktualisierung in Ihrer Verantwortung. Weitere Informationen finden Sie unter Patchen von Images.
Instanztyp Die VM-Größe, die für die Bereitstellung verwendet werden soll. Eine Liste der unterstützten Größen finden Sie unter SKU-Liste für verwaltete Onlineendpunkte.
Anzahl von Instanzen Die Anzahl der Instanzen, die für die Bereitstellung verwendet werden sollen. Richten Sie den Wert nach der zu erwartenden Workload. Für Hochverfügbarkeit empfiehlt es sich, den Wert mindestens auf 3 festzulegen. Wir reservieren zusätzliche 20 % für die Durchführung von Upgrades. Weitere Informationen finden Sie unter VM-Kontigentzuweisungen für Bereitstellungen.

1 Einige Hinweise zu Modell und Umgebung:

  • Das Modell und das Container-Image (wie in Umgebung definiert) können jederzeit von der Bereitstellung erneut referenziert werden, wenn die Instanzen hinter der Bereitstellung Sicherheits-Patches und/oder andere Wiederherstellungsvorgänge durchlaufen. Wenn Sie ein registriertes Modell oder Container-Image in Azure Container Registry für die Bereitstellung verwenden und das Modell oder das Container-Image entfernen, können die Bereitstellungen, die sich auf diese Objekte stützen, fehlschlagen, wenn ein Reimaging stattfindet. Wenn Sie das Modell oder das Container-Image entfernt haben, stellen Sie sicher, dass die abhängigen Bereitstellungen mit einem alternativen Modell oder Container-Image neu erstellt oder aktualisiert werden.
  • Die Containerregistrierung, auf die sich die Umgebung bezieht, kann nur dann privat sein, wenn die Endpunkt-Identität die Berechtigung hat, über die Microsoft Entra-Authentifizierung und Azure RBAC darauf zuzugreifen. Aus dem gleichen Grund werden andere private Docker-Registrierungen als Azure Container Registry nicht unterstützt.

Informationen zum Bereitstellen von Onlineendpunkten über die CLI, mit dem SDK, in Studio oder mithilfe einer ARM-Vorlage finden Sie unter Bereitstellen eines ML-Modells mit einem Onlineendpunkt.

Identifizieren des Modellpfads in Bezug auf AZUREML_MODEL_DIR

Wenn Sie Ihr Modell in Azure Machine Learning bereitstellen, müssen Sie den Speicherort des Modells angeben, das Sie als Teil Ihrer Bereitstellungskonfiguration bereitstellen möchten. In Azure Machine Learning wird der Pfad zu Ihrem Modell mit der Umgebungsvariablen AZUREML_MODEL_DIR nachverfolgt. Indem Sie den Modellpfad in Bezug auf AZUREML_MODEL_DIR identifizieren, können Sie Modelle bereitstellen, die lokal auf Ihrem Computer gespeichert sind, oder ein Modell bereitstellen, das in Ihrem Azure Machine Learning-Arbeitsbereich registriert ist.

Zur Veranschaulichung verweisen wir in den ersten beiden Fällen auf die folgende lokale Ordnerstruktur. In diesen Fällen stellen Sie ein einzelnes Modell bzw. mehrere lokal gespeicherte Modelle bereit:

Screenshot einer Ordnerstruktur mit mehreren Modellen.

Verwenden eines einzelnen lokalen Modells in einer Bereitstellung

Wenn Sie ein einzelnes Modell auf Ihrem lokalen Computer in einer Bereitstellung verwenden möchten, geben Sie den Pfad (path) zum Modell (model) in Ihrer YAML-Datei für die Bereitstellung an. Hier ist ein Beispiel für die Bereitstellungs-YAML-Datei mit dem Pfad /Downloads/multi-models-sample/models/model_1/v1/sample_m1.pkl:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: 
  path: /Downloads/multi-models-sample/models/model_1/v1/sample_m1.pkl 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1

Nachdem Sie Ihre Bereitstellung erstellt haben, verweist die Umgebungsvariable AZUREML_MODEL_DIR auf den Speicherort in Azure, an dem Ihr Modell gespeichert ist. Beispielsweise enthält /var/azureml-app/azureml-models/81b3c48bbf62360c7edbbe9b280b9025/1 das Modell sample_m1.pkl.

In Ihrem Bewertungsskript (score.py) können Sie Ihr Modell (in diesem Beispiel sample_m1.pkl) in der init()-Funktion laden:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR")), "sample_m1.pkl") 
    model = joblib.load(model_path)

Verwenden mehrerer lokaler Modelle in einer Bereitstellung

Die Azure CLI, das Python SDK und andere Clienttools ermöglichen es Ihnen zwar, nur ein Modell pro Bereitstellung in der Bereitstellungsdefinition anzugeben, aber Sie können weiterhin mehrere Modelle in einer Bereitstellung verwenden, indem Sie einen Modellordner registrieren, der alle Modelle als Dateien oder Unterverzeichnisse enthält.

Sie sehen in der vorherigen Beispielordnerstruktur, dass im Ordner models mehrere Modelle vorhanden sind. In Ihrer Bereitstellungs-YAML können Sie den Pfad zum Ordner models wie folgt angeben:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: 
  path: /Downloads/multi-models-sample/models/ 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1

Nachdem Sie Ihre Bereitstellung erstellt haben, verweist die Umgebungsvariable AZUREML_MODEL_DIR auf den Speicherort in Azure, an dem Ihre Modelle gespeichert sind. Beispielsweise enthält /var/azureml-app/azureml-models/81b3c48bbf62360c7edbbe9b280b9025/1 die Modelle und die Dateistruktur.

In diesem Beispiel sieht der Inhalt des Ordners AZUREML_MODEL_DIR wie folgt aus:

Screenshot der Ordnerstruktur des Speicherorts für mehrere Modelle.

In Ihrem Bewertungsskript (score.py) können Sie Ihre Modelle in der init()-Funktion laden: Mit dem folgenden Code wird das Modell sample_m1.pkl geladen:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR")), "models","model_1","v1", "sample_m1.pkl ") 
    model = joblib.load(model_path)

Ein Beispiel für die Bereitstellung mehrerer Modelle in einer Bereitstellung finden Sie unter Bereitstellen mehrerer Modelle in einer Bereitstellung (CLI-Beispiel) und Bereitstellen mehrerer Modelle in einer Bereitstellung (SDK-Beispiel).

Tipp

Wenn Sie mehr als 1.500 Dateien registrieren müssen, komprimieren Sie beim Registrieren der Modelle die Dateien oder Unterverzeichnisse ggf. als „.tar.gz“. Um die Modelle zu nutzen, können Sie die Dateien oder Unterverzeichnisse in der Funktion init() aus dem Bewertungsskript dekomprimieren. Wenn Sie die Modelle registrieren, legen Sie alternativ die Eigenschaft azureml.unpack auf True fest, um die Dateien oder Unterverzeichnisse automatisch zu dekomprimieren. In jedem Fall erfolgt die Dekomprimierung einmal in der Initialisierungsphase.

Verwenden von Modellen, die in Ihrem Azure Machine Learning-Arbeitsbereich registriert sind, in einer Bereitstellung

Wenn Sie Modelle, die in Ihrem Azure Machine Learning-Arbeitsbereich registriert sind, in Ihrer Bereitstellung verwenden möchten, geben Sie den Namen der registrierten Modelle in Ihrer Bereitstellungs-YAML an. Die folgende Bereitstellungs-YAML-Konfiguration gibt beispielsweise den registrierten model-Namen als azureml:local-multimodel:3 an:

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json 
name: blue 
endpoint_name: my-endpoint 
model: azureml:local-multimodel:3 
code_configuration: 
  code: ../../model-1/onlinescoring/ 
  scoring_script: score.py 
environment:  
  conda_file: ../../model-1/environment/conda.yml 
  image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest 
instance_type: Standard_DS3_v2 
instance_count: 1

Beachten Sie in diesem Beispiel, dass local-multimodel:3 die folgenden Modellartefakte enthält, die auf der Registerkarte Modelle im Azure Machine Learning Studio angezeigt werden können:

Screenshot der Ordnerstruktur mit den Modellartefakten des registrierten Modells.

Nachdem Sie Ihre Bereitstellung erstellt haben, verweist die Umgebungsvariable AZUREML_MODEL_DIR auf den Speicherort in Azure, an dem Ihre Modelle gespeichert sind. Beispielsweise enthält /var/azureml-app/azureml-models/local-multimodel/3 die Modelle und die Dateistruktur. AZUREML_MODEL_DIR verweist auf den Ordner, der den Stamm der Modellartefakte enthält. Basierend auf diesem Beispiel sieht der Inhalt des Ordners AZUREML_MODEL_DIR wie folgt aus:

Screenshot der Ordnerstruktur mit mehreren Modellen.

In Ihrem Bewertungsskript (score.py) können Sie Ihre Modelle in der init()-Funktion laden: Laden Sie beispielsweise das Modell diabetes.sav:

def init(): 
    model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR"), "models", "diabetes", "1", "diabetes.sav") 
    model = joblib.load(model_path)

Kontingentzuordnung für virtuelle Computer für die Bereitstellung

Für verwaltete Onlineendpunkte reserviert Azure Machine Learning 20 % Ihrer Computeressourcen für die Durchführung von Upgrades auf einigen VM-SKUs. Wenn Sie eine bestimmte Anzahl von Instanzen für diese VM-SKUs in einer Bereitstellung anfordern, müssen Sie über ein Kontingent für ceil(1.2 * number of instances requested for deployment) * number of cores for the VM SKU verfügen, um zu verhindern, dass Sie einen Fehler erhalten. Wenn Sie in einer Bereitstellung also beispielsweise zehn Instanzen einer VM vom Typ Standard_DS3_v2 (mit vier Kernen) anfordern, muss ein Kontingent für 48 Kerne (12 instances * 4 cores) verfügbar sein. Dieses zusätzliche Kontingent ist für systemseitig initiierte Vorgänge wie Betriebssystem-Upgrades und VM-Wiederherstellungen reserviert und verursacht nur dann Kosten, wenn ein solcher Vorgang ausgeführt wird.

Es gibt bestimmte VM-SKUs, die von der zusätzlichen Kontingentreservierung ausgenommen sind. Informationen zum Anzeigen der vollständigen Liste finden Sie unter SKU-Liste verwalteter Onlineendpunkte.

Informationen zum Anzeigen Ihres Verbrauchs und zum Anfordern von Kontingenterhöhungen finden Sie unter Anzeigen Ihres Verbrauchs und Ihrer Kontingente im Azure-Portal. Informationen zum Anzeigen Ihrer Kosten für die Ausführung eines verwalteten Onlineendpunkts finden Sie unter Anzeigen der Kosten für einen verwalteten Azure Machine Learning-Onlineendpunkt.

Azure Machine Learning bietet einen Pool freigegebener Kontingente, aus dem alle Benutzer auf das Kontingent zugreifen können, um Tests für einen begrenzten Zeitraum durchzuführen. Wenn Sie das Studio verwenden, um Llama-Modelle (aus dem Modellkatalog) auf einem verwalteten Online-Endpunkt bereitzustellen, ermöglicht Azure Machine Learning Ihnen den Zugriff auf dieses freigegebene Kontingent für eine kurze Zeit.

Um ein Llama-2-70b- oder Llama-2-70b-Chat-Modell bereitzustellen, müssen Sie jedoch über ein Enterprise Agreement-Abonnement verfügen, bevor Sie mit dem freigegebenen Kontingent bereitstellen können. Weitere Informationen zur Verwendung des freigegebenen Kontingents für die Bereitstellung von Onlineendpunkten finden Sie unter Bereitstelle von Grundlagenmodellen mittels Studio.

Weitere Informationen zu Kontingenten und Grenzwerten für Ressourcen in Azure Machine Learning finden Sie unter Verwalten und Erhöhen von Kontingenten und Grenzwerten für Ressourcen mit Azure Machine Learning.

Bereitstellung für Personen mit und ohne Programmiererfahrung

Azure Machine Learning unterstützt die Modellimplementierung für Onlineendpunkte für Personen mit und ohne Programmiererfahrung mit Optionen für die No-Code-Bereitstellung, die Low-Code-Bereitstellung und die BYOC-Bereitstellung (Bring Your Own Container).

  • Die No-Code-Bereitstellung bietet sofort einsatzbereite Funktionen für Rückschlüsse für gängige Frameworks (z. B. scikit-learn, TensorFlow, PyTorch und ONNX) über MLflow und Triton.
  • Die Low-Code-Bereitstellung ermöglicht es Ihnen, Ihr ML-Modell zusammen mit einem Mindestmaß an Code bereitzustellen.
  • Mit der BYOC-Bereitstellung können Sie praktisch jeden beliebigen Container zum Ausführen Ihres Onlineendpunkts verwenden. Sie können alle Features der Azure Machine Learning-Plattform verwenden – z. B. automatische Skalierung, GitOps, Debuggen und sicheres Rollout –, um Ihre MLOps-Pipelines zu verwalten.

Die folgende Tabelle zeigt die wichtigsten Aspekte der verschiedenen Optionen für die Onlinebereitstellung:

Kein Code Low-Code-Entwicklung BYOC
Zusammenfassung Bietet sofort einsatzbereite Funktionen für Rückschlüsse für gängige Frameworks wie scikit-learn, TensorFlow, PyTorch und ONNX über MLflow und Triton. Weitere Informationen finden Sie unter Bereitstellen von MLflow-Modellen in Onlineendpunkten. Verwendet sichere, öffentliche zusammengestellte Images für beliebte Frameworks; alle zwei Wochen erfolgen Updates zum Beheben von Sicherheitsrisiken. Sie stellen das Bewertungsskript und/oder Python-Abhängigkeiten bereit. Weitere Informationen finden Sie unter Azure Machine Learning – zusammengestellte Umgebungen. Sie stellen Ihren vollständigen Stapel mithilfe der Azure Machine Learning-Unterstützung für benutzerdefinierte Images bereit. Weitere Informationen finden Sie unter Verwenden eines benutzerdefinierten Containers zum Bereitstellen eines Modells auf einen Onlineendpunkt.
Benutzerdefiniertes Basisimage Nein. Zur Vereinfachung der Bereitstellung ist dies in der zusammengestellten Umgebung enthalten. Ja und nein. Sie können entweder ein zusammengestelltes Image oder Ihr angepasstes Image verwenden. Ja. Sie stellen einen zugänglichen Containerimagespeicherort (z. B. docker.io, Azure Container Registry [ACR] oder Microsoft Container Registry [MCR]) oder ein Dockerfile bereit, das Sie mit ACR für Ihren Container erstellen/pushen können.
Benutzerdefinierte Abhängigkeiten Nein. Zur Vereinfachung der Bereitstellung ist dies in der zusammengestellten Umgebung enthalten. Ja. Sie stellen die Azure Machine Learning-Umgebung bereit, in der das Modell ausgeführt wird: entweder ein Docker-Image mit Conda-Abhängigkeiten oder ein Dockerfile. Ja. Dies ist im Containerimage enthalten.
Benutzerdefinierter Code Nein. Zur Vereinfachung der Bereitstellung werden automatisch Bewertungsskripts generiert. Ja. Sie stellen Ihr Bewertungsskript bereit. Ja. Dies ist im Containerimage enthalten.

Hinweis

AutoML-Ausführungen erstellen automatisch ein Bewertungsskript und Abhängigkeiten für Benutzer*innen. So können Sie jedes AutoML-Modell bereitstellen, ohne zusätzlichen Code schreiben zu müssen (für die No-Code-Bereitstellung), oder automatisch generierte Skripts an Ihre Geschäftsanforderungen anpassen (für die Low-Code-Bereitstellung). Informationen zu Bereitstellungen mit AutoML-Modellen finden Sie unter Bereitstellen eines AutoML-Modells mit einem Onlineendpunkt.

Debuggen von Onlineendpunkten

Wir empfehlen dringend, dass Sie Ihren Endpunkt lokal testen, indem Sie Ihren Code und Ihre Konfiguration validieren und debuggen, bevor Sie ihn in Azure bereitstellen. Die Azure CLI und das Python-SDK unterstützen lokale Endpunkte und Bereitstellungen, während Azure Machine Learning Studio und ARM-Vorlagen dies nicht tun.

Azure Machine Learning bietet verschiedene Möglichkeiten, Onlineendpunkte lokal und mithilfe von Containerprotokollen zu debuggen.

Lokales Debuggen mit einem HTTP-Rückschlussserver von Azure Machine Learning

Sie können Ihr Bewertungsskript lokal debuggen, indem Sie den HTTP-Rückschlusserver von Azure Machine Learning verwenden. Dieser HTTP-Server ist ein Python-Paket, das Ihre Bewertungsfunktion als HTTP-Endpunkt verfügbar macht und den Flask-Servercode und die Abhängigkeiten in ein einzelnes Paket packt. Er ist in den vordefinierten Docker-Images für Rückschlüsse enthalten, die beim Bereitstellen eines Modells mit Azure Machine Learning verwendet werden. Mithilfe des Pakets können Sie das Modell lokal für die Produktion bereitstellen und Ihr Bewertungsskript (Einstiegsskript) auch sehr einfach in einer lokalen Entwicklungsumgebung überprüfen. Wenn ein Problem mit dem Bewertungsskript auftritt, gibt der Server einen Fehler und den Speicherort zurück, an dem der Fehler aufgetreten ist. Sie können Visual Studio Code auch für das Debugging mit dem HTTP-Rückschlussserver von Azure Machine Learning verwenden.

Tipp

Sie können das Python-Paket von Azure Machine Learning für HTTP-Rückschlussserver verwenden, um Ihr Bewertungsskript lokal und ohne Docker-Engine zu debuggen. Das Debuggen mit dem Rückschlussserver hilft beim Debuggen des Bewertungsskripts vor der Bereitstellung auf lokalen Endpunkten, sodass Sie beim Debuggen nicht von der Konfiguration der Bereitstellungscontainer abhängig sind.

Weitere Informationen zum Debuggen mit dem HTTP-Server finden Sie unter Debuggen von Bewertungsskripts mit dem HTTP-Rückschlussserver von Azure Machine Learning.

Lokales Debuggen mit lokalem Endpunkt

Zum lokalen Debuggen benötigen Sie eine lokale Bereitstellung. d. h. ein Modell, das in einer lokalen Docker-Umgebung bereitgestellt ist. Sie können diese lokale Bereitstellung für Test- und Debugvorgänge vor der Bereitstellung in der Cloud verwenden. Für lokale Bereitstellungen muss die Docker Engine installiert sein und ausgeführt werden. Azure Machine Learning erstellt dann ein lokales Docker-Image, das das Azure Machine Learning-Image imitiert. Azure Machine Learning erstellt Bereitstellungen für Sie lokal und führt diese aus. Das Image wird zwischengespeichert, um schnelle Iterationen zu ermöglichen.

Tipp

Die Docker-Engine wird in der Regel gestartet, wenn der Computer gestartet wird. Wenn dies nicht der Fall ist, können Sie die Problembehandlung für die Docker-Engine durchführen. Sie können clientseitige Tools wie Docker Desktop verwenden, um zu debuggen, was im Container passiert.

Die Schritte für das lokale Debuggen umfassen in der Regel Folgendes:

  • Überprüfen, ob die lokale Bereitstellung erfolgreich war
  • Aufrufen des lokalen Endpunkts für Rückschlüsse
  • Überprüfen der Protokolle hinsichtlich der Ausgaben des Aufrufvorgangs

Hinweis

Lokale Endpunkte haben die folgenden Einschränkungen:

  • Sie unterstützen keine Datenverkehrsregeln, Authentifizierung oder Testeinstellungen.
  • Sie unterstützen nur eine Bereitstellung pro Endpunkt.
  • Sie unterstützen lokale Modelldateien und -umgebung nur mit lokaler Conda-Datei. Wenn Sie registrierte Modelle testen wollen, laden Sie diese zuerst mithilfe der CLI oder des SDK herunter, und verwenden Sie dann path in der Bereitstellungsdefinition, um auf den übergeordneten Ordner zu verweisen. Wenn Sie registrierte Umgebungen testen möchten, überprüfen Sie den Kontext der Umgebung in Azure Machine Learning Studio, und bereiten Sie eine lokale Conda-Datei für die Verwendung vor.

Weitere Informationen zum lokalen Debuggen finden Sie unter Lokales Bereitstellen und Debuggen mithilfe eines lokalen Endpunkts.

Lokales Debuggen mit lokalem Endpunkt und Visual Studio Code (Vorschau)

Wichtig

Dieses Feature ist zurzeit als öffentliche Preview verfügbar. Diese Vorschauversion wird ohne Vereinbarung zum Servicelevel bereitgestellt und ist nicht für Produktionsworkloads vorgesehen. Manche Features werden möglicherweise nicht unterstützt oder sind nur eingeschränkt verwendbar.

Weitere Informationen finden Sie unter Zusätzliche Nutzungsbestimmungen für Microsoft Azure-Vorschauen.

Wie beim lokalen Debuggen müssen Sie zunächst die Docker Engine installieren und ausführen und dann ein Modell in der lokalen Docker-Umgebung bereitstellen. Sobald Sie über eine lokale Bereitstellung verfügen, verwenden die lokalen Endpunkte von Azure Machine Learning Docker- und Visual Studio Code-Entwicklungscontainer (Dev-Container), um eine lokale Debuggingumgebung zu erstellen und zu konfigurieren. Mit Dev-Containern können Sie Visual Studio Code-Features wie z. B. interaktives Debugging in einem Docker-Container nutzen.

Weitere Informationen zum interaktiven Debuggen von Onlineendpunkten in VS Code finden Sie unter Lokales Debuggen von Onlineendpunkten in Visual Studio Code.

Debuggen mit Containerprotokollen

In einer Bereitstellung können Sie keinen direkten Zugriff auf die VM erhalten, auf der das Modell bereitgestellt ist. Es ist aber möglich, Protokolle aus einigen Containern abzurufen, die auf dem virtuellen Computer ausgeführt werden. Es gibt zwei Arten von Containern, aus denen Sie die Protokolle abrufen können:

  • Rückschlussserver: Protokolle enthalten das Konsolenprotokoll (vom Rückschlussserver), das die Ausgabe der Druck-/Protokollierungsfunktionen aus Ihrem Bewertungsskript (score.py-Code) enthält.
  • Speicherinitialisierer: Protokolle enthalten Informationen dazu, ob das Herunterladen der Code- und Modelldaten in den Container erfolgreich war. Der Container wird ausgeführt, bevor die Ausführung des Containers des Rückschlussservers gestartet wird.

Weitere Informationen zum Debuggen mit Containerprotokollen finden Sie unter Abrufen von Containerprotokollen.

Datenverkehrsrouting und -spiegelung in Onlinebereitstellungen

Denken Sie daran, dass ein einzelner Onlineendpunkt mehrere Bereitstellungen enthalten kann. Wenn der Endpunkt eingehenden Datenverkehr (oder Anforderungen) empfängt, kann er prozentuale Anteile dieses Datenverkehrs an jede Bereitstellung weiterleiten – wie in der nativen Blau/Grün-Bereitstellungsstrategie. Der Endpunkt kann auch Datenverkehr von einer Bereitstellung in eine andere spiegeln (kopieren). Dies wird auch als Datenverkehrsspiegelung oder Shadowing bezeichnet.

Datenverkehrsrouting für Blau/Grün-Bereitstellung

Eine Blau/Grün-Bereitstellung ist eine Strategie, mit der Sie eine neue Bereitstellung (die grüne Bereitstellung) für eine kleine Teilmenge von Benutzer*innen oder Anforderungen einführen können, bevor Sie sie in vollem Umfang einführen. Der Endpunkt kann einen Lastenausgleich implementieren, um jeder Bereitstellung einen bestimmten Prozentsatz des Datenverkehrs zuzuweisen. Dabei summiert sich die Gesamtzuweisung für alle Bereitstellungen auf 100 %.

Tipp

Eine Anforderung kann den konfigurierten Lastausgleich umgehen, indem sie einen HTTP-Header von azureml-model-deployment enthält. Setzen Sie den Wert der Kopfzeile auf den Namen der Einrichtung, an die die Anforderung weitergeleitet werden soll.

Die folgende Abbildung zeigt Einstellungen in Azure Machine Learning Studio für die Zuweisung von Datenverkehr zwischen einer blauen und einer grünen Bereitstellung.

Screenshot: Schieberegler zum Festlegen der Datenverkehrszuordnung für mehrere Bereitstellungen

Diese Datenverkehrszuweisung leitet Datenverkehr weiter, wie in der folgenden Abbildung gezeigt: 10 % des Datenverkehrs werden an die grüne Bereitstellung und 90 % des Datenverkehrs an die blaue Bereitstellung geleitet.

Diagramm: Endpunkt, bei dem Datenverkehr auf zwei Bereitstellungen aufgeteilt wird

Datenverkehrsspiegelung in Onlinebereitstellungen

Der Endpunkt kann auch Datenverkehr von einer Bereitstellung in eine andere spiegeln (kopieren). Die Datenverkehrsspiegelung (auch als Shadow Testing bezeichnet) ist nützlich, wenn Sie eine neue Bereitstellung mit Produktionsdatenverkehr testen möchten, ohne die Ergebnisse zu beeinträchtigen, die Kund*innen in vorhandenen Bereitstellungen erhalten. Wenn Sie beispielsweise eine Blau/Grün-Bereitstellung implementieren, bei der 100 % des Datenverkehrs an die blaue Bereitstellung geleitet und 10 % an die grüne Bereitstellung gespiegelt werden, werden die Ergebnisse des gespiegelten Datenverkehrs zur grünen Bereitstellung nicht an die Clients zurückgegeben, aber Metriken und Protokolle werden aufgezeichnet.

Diagramm: Endpunkt, der den Datenverkehr zu einer Bereitstellung spiegelt

Informationen zur Verwendung der Datenverkehrsspiegelung finden Sie unter Sicherer Rollout für Onlineendpunkte.

Weitere Funktionen von Onlineendpunkten in Azure Machine Learning

Authentifizierung und Verschlüsselung

  • Authentifizierung: Schlüssel- und Azure Machine Learning-Token
  • Verwaltete Identität: Benutzerseitig und systemseitig zugewiesen
  • Standardmäßiges SSL für Aufruf von Endpunkten

Automatische Skalierung

Autoscale führt automatisch die richtige Menge an Ressourcen aus, um die Last Ihrer Anwendung zu bewältigen. Verwaltete Endpunkte unterstützen Autoscaling durch die Integration mit der Funktion Azure Monitor Autoscale. Sie können metrikbasierte Skalierung (z. B. CPU-Auslastung >70 %), zeitplanbasierte Skalierung (z. B. Skalierungsregeln für Hauptgeschäftszeiten) oder eine Kombination davon konfigurieren.

Screenshot: Autoskalierung stellt abhängig von den Regeln flexibel zwischen minimalen und maximalen Instanzen bereit

Informationen zum Konfigurieren der automatischen Skalierung finden Sie unter Automatisches Skalieren von Onlineendpunkten.

Verwaltete Netzwerkisolation

Wenn Sie ein Machine Learning-Modell auf einem verwalteten Onlineendpunkt bereitstellen, können Sie die Kommunikation mit dem Onlineendpunkt durch die Verwendung privater Endpunkte absichern.

Sie können Sicherheit für eingehende Bewertungsanfragen und ausgehende Kommunikationen mit dem Arbeitsbereich und anderen Diensten separat konfigurieren. Eingehende Kommunikation verwendet den privaten Endpunkt des Azure Machine Learning-Arbeitsbereichs. Ausgehende Kommunikation verwendet private Endpunkte, die für das verwaltete virtuelle Netzwerk des Arbeitsbereichs erstellt wurden.

Weitere Informationen finden Sie unter Netzwerkisolation mit verwalteten Onlineendpunkten.

Überwachen von Onlineendpunkten und Bereitstellungen

Die Überwachung für Azure Machine Learning-Endpunkte ist per Integration in Azure Monitor möglich. Mit dieser Integration können Sie Metriken in Diagrammen anzeigen, Warnungen konfigurieren, Protokolltabellen abfragen, Application Insights zum Analysieren von Ereignissen aus Benutzercontainern verwenden und vieles mehr.

  • Metriken: Verwenden Sie Azure Monitor, um verschiedene Endpunktmetriken wie etwa die Anforderungslatenz nachzuverfolgen und einen Drilldown zur Bereitstellungs- oder Statusebene durchzuführen. Sie können auch Metriken auf Bereitstellungsebene nachverfolgen, z. B. die CPU-/GPU-Auslastung, und einen Drilldown auf Instanzebene durchführen. Mit Azure Monitor können Sie diese Metriken in Diagrammen nachverfolgen und Dashboards und Warnungen zur weiteren Analyse einrichten.

  • Protokolle: Senden Sie Metriken an den Log Analytics-Arbeitsbereich, in dem Sie Protokolle mithilfe der Kusto-Abfragesyntax abfragen können. Sie können Metriken auch zur weiteren Verarbeitung an ein Speicherkonto und/oder Event Hubs senden. Darüber hinaus können Sie dedizierte Protokolltabellen für Onlineendpunkteereignisse, Datenverkehr und Containerprotokolle verwenden. Die Kusto-Abfragesprache ermöglicht komplexe Analysen, bei denen mehrere Tabellen verknüpft werden.

  • Application Insights: Zusammengestellte Umgebungen umfassen die Integration in Application Insights, und Sie können diese aktivieren/deaktivieren, wenn Sie eine Onlinebereitstellung erstellen. Integrierte Metriken und Protokolle werden an Application Insights gesendet, und Sie können die integrierten Features wie Livemetriken, Transaktionssuche, Fehler und Leistung zur weitere Analyse verwenden.

Weitere Informationen zur Überwachung finden Sie unter Überwachen von Onlineendpunkten.

Geheimniseinschleusung in Onlinebereitstellungen (Vorschau)

Die Geheimniseinschleusung im Kontext einer Onlinebereitstellung besteht aus dem Abrufen von Geheimnissen (z. B. API-Schlüssel) aus Geheimnisspeichern und dem Einschleusen dieser in Ihren Benutzercontainer, der in einer Onlinebereitstellung ausgeführt wird. Auf Geheimnisse wird schließlich sicher über Umgebungsvariablen zugegriffen, die vom Rückschlussserver, der Ihr Bewertungsskript ausführt, oder vom Rücksschlussstapel verwendet werden, den Sie mit einem BYOC-Bereitstellungsansatz (Bring Your Own Container) zur Verfügung stellen.

Es gibt zwei Möglichkeiten für die Geheimniseinschleusung. Sie können Geheimnisse manuell mithilfe von verwalteten Identitäten einschleusen oder das Feature zur Geheimniseinschleusung verwenden. Weitere Informationen zu den Möglichkeiten der Geheimniseinschleusung finden Sie unter Geheimniseinschleusung in Onlineendpunkten (Vorschau).

Nächste Schritte