Behandeln von Problemen bei der Remotemodellimplementierung

Hier erfahren Sie, wie Sie allgemeine Fehler beim Bereitstellen eines Modells in Azure Container Instances (ACI) und Azure Kubernetes Service (AKS) mithilfe von Azure Machine Learning beheben, lösen oder umgehen.

Hinweis

Wenn Sie ein Modell in Azure Kubernetes Service (AKS) bereitstellen, empfehlen wir Ihnen, Azure Monitor für diesen Cluster zu aktivieren. Dadurch können Sie die Gesamtintegrität des Clusters sowie die Ressourcennutzung besser nachvollziehen. Folgende Ressourcen sind unter Umständen ebenfalls hilfreich:

Wenn Sie versuchen, ein Modell in einem fehlerhaften oder überladenen Cluster bereitzustellen, ist davon auszugehen, dass Probleme auftreten. Sollten Sie Hilfe bei der Behandlung von AKS-Clusterproblemen benötigen, wenden Sie sich an den Support.

Voraussetzungen

Schritte für die Docker-Bereitstellung von Machine Learning-Modellen

Wenn Sie ein Modell für nicht lokales Compute in Azure Machine Learning bereitstellen, passiert Folgendes:

  1. Das Dockerfile, das Sie in Ihrer Rückschlusskonfiguration (InferenceConfig) in Ihrem Umgebungsobjekt (Environments) angegeben haben, wird zusammen mit dem Inhalt Ihres Quellverzeichnisses an die Cloud gesendet.
  2. Wenn ein zuvor erstelltes Image nicht in Ihrer Containerregistrierung verfügbar ist, wird ein neues Docker-Image in der Cloud erstellt und in der standardmäßigen Containerregistrierung Ihres Arbeitsbereichs gespeichert.
  3. Das Docker-Image aus Ihrer Containerregistrierung wird in Ihr Computeziel heruntergeladen.
  4. Der Standardblobspeicher Ihres Arbeitsbereichs wird in Ihr Computeziel eingebunden, sodass Sie auf registrierte Modelle zugreifen können.
  5. Ihr Webserver wird initialisiert. Hierzu wird die Funktion init() Ihres Eingabeskripts ausgeführt.
  6. Wenn bei Ihrem bereitgestellten Modell eine Anforderung eingeht, wird diese durch die Funktion run() verarbeitet.

Der Hauptunterschied bei der Verwendung einer lokalen Bereitstellung besteht darin, dass das Containerimage auf Ihrem lokalen Computer erstellt wird. Daher muss bei einer lokalen Bereitstellung Docker installiert sein.

Wenn Sie mit diesen grundlegenden Schritten vertraut sind, können Sie besser nachvollziehen, wo Fehler auftreten.

Abrufen von Bereitstellungsprotokollen

Das Abrufen Ihrer Bereitstellungsprotokolle ist der erste Schritt beim Debuggen von Fehlern. Führen Sie zunächst die hier beschriebenen Anweisungen aus, um eine Verbindung mit Ihrem Arbeitsbereich herzustellen.

GILT FÜR:Azure CLI-ML-Erweiterung v1

Gehen Sie wie folgt vor, um die Protokolle aus einem bereitgestellten Webdienst abzurufen:

az ml service get-logs --verbose --workspace-name <my workspace name> --name <service name>

Lokales Debuggen

Wenn bei der Bereitstellung eines Modells für ACI oder AKS Probleme auftreten, versuchen Sie, es als lokalen Webdienst bereitzustellen. Das Verwenden eines lokalen Webdiensts erleichtert die Problembehandlung. Informationen zur lokalen Problembehandlung bei einer Bereitstellung finden Sie im Artikel zur lokalen Problembehandlung.

HTTP-Rückschlussserver von Azure Machine Learning

Mit dem lokalen Rückschlussserver können Sie Ihr Eingabeskript (score.py) schnell debuggen. Falls das zugrunde liegende Bewertungsskript einen Fehler enthält, kann der Server das Modell nicht initialisieren oder bereitstellen. Stattdessen wird eine Ausnahme ausgelöst und der Ort angegeben, an dem die Probleme aufgetreten sind. Weitere Informationen zum HTTP-Rückschlussserver von Azure Machine Learning

  1. Installieren Sie das azureml-inference-server-http-Paket aus dem pypi-Feed:

    python -m pip install azureml-inference-server-http
    
  2. Starten Sie den Server, und legen Sie score.py als Einstiegsskript fest:

    azmlinfsrv --entry_script score.py
    
  3. Senden Sie eine Bewertungsanforderung mithilfe von curl an den Server:

    curl -p 127.0.0.1:5001/score
    

Hinweis

Informieren Sie sich über häufig gestellte Fragen zum Azure Machine Learning-Rückschluss-HTTP-Server.

Container kann nicht geplant werden

Beim Bereitstellen eines Diensts für ein Azure Kubernetes Service-Computeziel versucht Azure Machine Learning, den Dienst mit der angeforderten Menge von Ressourcen zu planen. Wenn nach 5 Minuten keine Knoten mit der entsprechenden Menge von verfügbaren Ressourcen im Cluster vorhanden sind, schlägt die Bereitstellung fehl. Die Fehlermeldung ist Couldn't Schedule because the kubernetes cluster didn't have available resources after trying for 00:05:00. Sie können diesen Fehler beheben, indem Sie entweder weitere Knoten hinzufügen, die SKU Ihrer Knoten oder die Ressourcenanforderungen für Ihren Dienst ändern.

Die Fehlermeldung gibt normalerweise an, von welcher Ressource Sie mehr benötigen – wenn Sie beispielsweise eine Fehlermeldung sehen, die 0/3 nodes are available: 3 Insufficient nvidia.com/gpu darauf hinweist, dass der Dienst GPUs benötigt und es drei Knoten im Cluster gibt, die keine verfügbaren GPUs haben. Dies könnte behoben werden, indem Sie weitere Knoten hinzufügen, wenn Sie eine GPU-SKU verwenden, zu einer GPU-fähigen SKU wechseln, wenn Sie dies nicht tun, oder Ihre Umgebung so ändern, dass keine GPUs erforderlich sind.

Fehler beim Starten des Diensts

Nach der erfolgreichen Erstellung des Images versucht das System, mithilfe Ihrer Bereitstellungskonfiguration einen Container zu starten. Als Teil des Container-Startprozesses wird die init()-Funktion in Ihrem Bereitstellungsskript vom System aufgerufen. Wenn in der init()-Funktion nicht abgefangene Ausnahmen auftreten, ist in der Fehlermeldung möglicherweise ein CrashLoopBackOff-Fehler zu finden.

Nutzen Sie die Informationen im Artikel Untersuchen des Docker-Protokolls.

Fehler beim Starten des Containers „azureml-fe-aci“

Beim Bereitstellen eines Diensts in einem Computeziel von Azure Container Instances versucht Azure Machine Learning, einen Front-End-Container mit dem Namen azureml-fe-aci für die Rückschlussanforderung zu erstellen. Wenn azureml-fe-aci abstürzt, können Sie Protokolle anzeigen, indem Sie az container logs --name MyContainerGroup --resource-group MyResourceGroup --subscription MySubscription --container-name azureml-fe-aci ausführen. Sie können die Fehlermeldung in den Protokollen befolgen, um die Korrektur vorzunehmen.

Der häufigste Fehler für azureml-fe-aci ist, dass das bereitgestellte SSL-Zertifikat oder der bereitgestellte Schlüssel ungültig ist.

Fehler bei der Funktion: get_model_path()

Oftmals wird in der init()-Funktion im Bewertungsskript die Funktion Model.get_model_path() aufgerufen, um eine Modelldatei oder einen Ordner mit Modelldateien im Container zu finden. Wenn die Modelldatei oder der Ordner nicht gefunden werden kann, schlägt die Funktion fehl. Die einfachste Möglichkeit zum Debuggen dieses Fehlers besteht darin, den unten dargestellten Python-Code in der Containershell auszuführen:

GILT FÜR:Python SDK azureml v1

from azureml.core.model import Model
import logging
logging.basicConfig(level=logging.DEBUG)
print(Model.get_model_path(model_name='my-best-model'))

Dieses Beispiel gibt den lokalen Pfad (relativ zu /var/azureml-app) in dem Container aus, in dem Ihr Scoring-Skript die Modelldatei oder den Ordner erwartet. Dann können Sie überprüfen, ob sich die Datei oder der Ordner tatsächlich dort befindet, wo sie/er erwartet wird.

Das Festlegen der Protokollierungsstufe auf DEBUG kann dazu führen, dass zusätzliche Informationen protokolliert werden, was bei der Identifizierung des Fehlers nützlich sein kann.

Fehler bei der Funktion: run(input_data)

Wenn der Dienst erfolgreich bereitgestellt wurde, aber beim Veröffentlichen von Daten am Bewertungsendpunkt abstürzt, können Sie Ihrer run(input_data)-Funktion eine Anweisung zum Abfangen von Fehlern hinzufügen, damit sie stattdessen eine detaillierte Fehlermeldung zurückgibt. Beispiel:

def run(input_data):
    try:
        data = json.loads(input_data)['data']
        data = np.array(data)
        result = model.predict(data)
        return json.dumps({"result": result.tolist()})
    except Exception as e:
        result = str(e)
        # return error message back to the client
        return json.dumps({"error": result})

Hinweis: Die Rückgabe von Fehlermeldungen aus dem Aufruf run(input_data) sollte nur zu Debugzwecken erfolgen. Aus Sicherheitsgründen sollten Sie in einer Produktionsumgebung keine Fehlermeldungen auf diese Weise zurückgeben.

HTTP-Statuscode 502

Der Statuscode 502 gibt an, dass der Dienst eine Ausnahme ausgelöst hat oder in der run()-Methode der Datei „score.py“ abgestürzt ist. Verwenden Sie die Informationen in diesem Artikel, um die Datei zu debuggen.

HTTP-Statuscode 503

Azure Kubernetes Service-Bereitstellungen unterstützen die automatische Skalierung, wodurch Replikate hinzugefügt werden können, um zusätzliche Last zu unterstützen. Die Autoskalierung wurde für die Behandlung gradueller Änderungen der Auslastung konzipiert. Wenn Sie große Spitzen bei den Anforderungen pro Sekunde erhalten, erhalten Clients möglicherweise den HTTP-Statuscode 503. Obwohl das Autoscaling schnell reagiert, benötigt AKS viel Zeit, um weitere Container zu erstellen.

Skalierungsentscheidungen werden auf der Grundlage der Auslastung der aktuellen Containerreplikate getroffen. Zur Ermittlung der aktuellen Auslastung wird die Anzahl ausgelasteter Replikate (Replikate, die eine Anforderung verarbeiten) durch die Gesamtanzahl aktueller Replikate geteilt. Übersteigt dieser Wert autoscale_target_utilization, werden weitere Replikate erstellt. Wenn es niedriger ist, werden Replikate reduziert. Entscheidungen zum Hinzufügen von Replikaten sind eifrig und schnell (ungefähr 1 Sekunde). Die Entscheidung, Replikate zu entfernen, erfolgt zurückhaltend (etwa 1 Minute). Der Auslastungsgrad der Autoskalierung ist standardmäßig auf 70 % festgelegt, was bedeutet, dass der Dienst Spitzen bei den Anforderungen pro Sekunde (RPS) von bis zu 30 % verarbeiten kann.

Es gibt zwei Möglichkeiten, die beim Verhindern des Statuscodes 503 helfen können:

Tipp

Diese beiden Ansätze können einzeln oder in Kombination verwendet werden.

  • Ändern Sie den Auslastungsgrad für die Erstellung neuer Replikate durch die automatische Skalierung. Sie können den Auslastungsgrad anpassen, indem Sie einen niedrigeren Wert für autoscale_target_utilization festlegen.

    Wichtig

    Durch diese Änderung werden Replikate nicht schneller erstellt. Stattdessen werden sie mit einem niedrigeren Schwellenwert für die Auslastung erstellt. Anstatt abzuwarten, bis der Dienst zu 70 % ausgelastet ist, werden Replikate schon bei 30 % Auslastung erstellt, wenn Sie den Wert in 30 % ändern.

    Wenn der Webdienst bereits die aktuelle maximale Anzahl von Replikaten verwendet und immer noch 503-Statuscodes angezeigt werden, erhöhen Sie den autoscale_max_replicas Wert, um die maximale Anzahl von Replikaten zu erhöhen.

  • Ändern Sie die Mindestanzahl der Replikate. Indem Sie die Mindestanzahl der Replikate erhöhen, wird ein größerer Pool für die Verarbeitung eingehender Spitzen bereitgestellt.

    Legen Sie einen höheren Wert für autoscale_min_replicas fest, um die Mindestanzahl der Replikate zu erhöhen. Sie können die erforderliche Anzahl von Replikaten berechnen, indem Sie den folgenden Code verwenden und die Werte durch die Werten Ihres Projekts ersetzen:

    from math import ceil
    # target requests per second
    targetRps = 20
    # time to process the request (in seconds)
    reqTime = 10
    # Maximum requests per container
    maxReqPerContainer = 1
    # target_utilization. 70% in this example
    targetUtilization = .7
    
    concurrentRequests = targetRps * reqTime / targetUtilization
    
    # Number of container replicas
    replicas = ceil(concurrentRequests / maxReqPerContainer)
    

    Hinweis

    Wenn Anforderungsspitzen eingehen, die die neue Mindestanzahl von Replikaten überschreiten, erhalten Sie möglicherweise wieder den Statuscode 503. Wenn sich der Datenverkehr Ihres Diensts beispielsweise erhöht, müssen Sie die Mindestanzahl von Replikaten möglicherweise erhöhen.

Weitere Informationen zum Festlegen von autoscale_target_utilization, autoscale_max_replicas und autoscale_min_replicas finden Sie in der Modulreferenz zu AksWebservice.

HTTP-Statuscode 504

Der Statuscode 504 gibt an, dass für die Anforderung ein Timeout aufgetreten ist. Das Standardtimeout beträgt 1 Minute.

Sie können das Timeout erhöhen oder versuchen, den Dienst zu beschleunigen, indem Sie unnötige Aufrufe in „score.py“ entfernen. Wenn diese Aktionen das Problem nicht beheben, verwenden Sie die Informationen in diesem Artikel, um die Datei score.py zu debuggen. Der Code kann sich in einem nicht reaktionsfähigen Zustand oder in einer Endlosschleife befinden.

Andere Fehlermeldungen

Führen Sie diese Aktionen für die folgenden Fehler aus:

Fehler Lösung
409 Konfliktfehler Wenn ein Vorgang bereits ausgeführt wird, antwortet jeder neue Vorgang für denselben Webdienst mit einem 409-Konfliktfehler. Wenn beispielsweise ein Webdienstvorgang erstellt oder aktualisiert wird und Sie einen neuen Löschvorgang auslösen, wird ein Fehler ausgelöst.
Fehler bei der Imageerstellung beim Bereitstellen des Webdiensts. Fügen Sie „pynacl==1.2.1“ als pip-Anhängigkeit zur Conda-Datei für die Imagekonfiguration hinzu.
['DaskOnBatch:context_managers.DaskOnBatch', 'setup.py']' died with <Signals.SIGKILL: 9> Ändern Sie die SKU für virtuelle Computer in Ihrer Bereitstellung in eine Variante mit mehr Arbeitsspeicher.
FPGA-Fehler Um Modelle auf FPGAs bereitzustellen, müssen Sie zuerst ein FPGA-Kontingent anfordern und dessen Genehmigung abwarten. Füllen Sie das Formular zur Kontingentanforderung aus, um Zugriff anzufordern: https://aka.ms/aml-real-time-ai

Erweitertes Debuggen

Sie müssen den in der Modellimplementierung enthaltenen Python-Code ggf. interaktiv debuggen. Dies ist beispielsweise der Fall, wenn das Einstiegsskript fehlschlägt und der Grund nicht durch zusätzliche Protokollierung ermittelt werden kann. Mit Visual Studio Code und debugpy können Sie an den Code anfügen, der im Docker-Container ausgeführt wird.

Weitere Informationen finden Sie im Leitfaden „Interaktives Debuggen in VS Code“.

Benutzerforum zur Modellimplementierung

Nächste Schritte

Weitere Informationen zur Bereitstellung finden Sie hier: