Partage via

Déboguer des scripts de scoring à l’aide du serveur HTTP d’inférence Azure Machine Learning

Le serveur HTTP d’inférence Azure Machine Learning est un package Python qui expose votre fonction de scoring en tant que point de terminaison HTTP et encapsule le code et les dépendances du serveur Flask dans un même package. Le serveur d’inférence est inclus dans les images Docker prédéfinies pour l’inférence utilisée lorsque vous déployez un modèle dans Azure Machine Learning. Lorsque vous utilisez le package seul, vous pouvez déployer le modèle localement pour la production. Vous pouvez également valider facilement votre script de notation (entrée) dans un environnement de développement local. En cas de problème avec le script de scoring, le serveur d’inférence retourne une erreur et l’emplacement de l’erreur.

Vous pouvez également utiliser le serveur d’inférence pour créer des portes de validation dans un pipeline d’intégration et de déploiement continus. Par exemple, vous pouvez démarrer le serveur d’inférence avec le script candidat et exécuter la suite de tests sur le point de terminaison local.

Cet article prend en charge les développeurs qui souhaitent utiliser le serveur d’inférence pour déboguer localement. Dans cet article, vous voyez comment utiliser le serveur d’inférence avec des points de terminaison en ligne.

Prérequis

  • Python 3.8 ou version ultérieure
  • Anaconda

Le serveur d’inférence s’exécute sur les systèmes d’exploitation Windows et Linux.

Explorer les options de débogage local pour les points de terminaison en ligne

En débogueant les points de terminaison localement avant de déployer sur le cloud, vous pouvez intercepter les erreurs dans votre code et votre configuration au début. Pour déboguer des points de terminaison localement, vous avez plusieurs options, notamment :

Le tableau suivant fournit une vue d’ensemble de la prise en charge que chaque option offre pour différents scénarios de débogage :

Scénario Serveur d’inférence Point de terminaison local
Mettre à jour l’environnement Python local, sans regénération de l’image Docker Oui Non
Mettre à jour le script de scoring Oui Oui
Mettre à jour les configurations de déploiement (déploiement, environnement, code, modèle) Non Oui
Intégrer le débogueur Microsoft Visual Studio Code (VS Code) Oui Oui

Cet article explique comment utiliser le serveur d’inférence.

Lorsque vous exécutez le serveur d’inférence localement, vous pouvez vous concentrer sur le débogage de votre script de scoring sans préoccupation pour les configurations de conteneur de déploiement.

Déboguer votre script de scoring localement

Pour déboguer votre script de scoring localement, vous avez plusieurs options pour tester le comportement du serveur d’inférence :

  • Utilisez un script de notation factice.
  • Utilisez VS Code pour déboguer avec le package azureml-inference-server-http .
  • Exécutez un script de scoring réel, un fichier de modèle et un fichier d’environnement à partir du dépôt d’exemples.

Les sections suivantes fournissent des informations sur chaque option.

Utiliser un script de scoring factice pour tester le comportement du serveur d’inférence

  1. Créez un répertoire nommé server_quickstart pour contenir vos fichiers :

    mkdir server_quickstart
cd server_quickstart

  2. Pour éviter les conflits de package, créez un environnement virtuel, par myenvexemple, et activez-le :

    python -m virtualenv myenv

    Remarque

    Sous Linux, exécutez la commande source myenv/bin/activate pour activer l’environnement virtuel.

    Après avoir testé le serveur d’inférence, vous pouvez exécuter la deactivate commande pour désactiver l’environnement virtuel Python.

  3. Installez le azureml-inference-server-http package à partir du flux Python Package Index (PyPI) :

    python -m pip install azureml-inference-server-http

  4. Créez votre script d’entrée. L’exemple suivant crée un script d’entrée de base et l’enregistre dans un fichier nommé score.py :

    echo -e 'import time\ndef init(): \n\ttime.sleep(1) \n\ndef run(input_data): \n\treturn {"message":"Hello, World!"}' > score.py

  5. Utilisez la azmlinfsrv commande pour démarrer le serveur d’inférence et définir le fichier score.py comme script d’entrée :

    azmlinfsrv --entry_script score.py

    Remarque

    Le serveur d’inférence est hébergé sur 0.0.0.0, ce qui signifie qu’il écoute toutes les adresses IP de la machine d’hébergement.

  6. Utilisez l’utilitaire curl pour envoyer une demande de scoring au serveur d’inférence :

    curl -p 127.0.0.1:5001/score

    Le serveur d’inférence publie la réponse suivante :

    {"message": "Hello, World!"}

  7. Lorsque vous avez terminé le test, sélectionnez Ctrl+C pour arrêter le serveur d’inférence.

Vous pouvez modifier le fichier de script de scoring score.py. Vous pouvez ensuite tester vos modifications à l’aide de la azmlinfsrv --entry_script score.py commande pour réexécuter le serveur d’inférence.

Intégrer à VS Code

Dans VS Code, vous pouvez utiliser l’extension Python pour le débogage avec le package azureml-inference-server-http . VS Code offre deux modes de débogage : lancer et attacher.

Avant d’utiliser l’un ou l’autre mode, installez le azureml-inference-server-http package en exécutant la commande suivante :

python -m pip install azureml-inference-server-http

Remarque

Pour éviter les conflits de package, installez le serveur d’inférence dans un environnement virtuel. Vous pouvez utiliser la pip install virtualenv commande pour activer les environnements virtuels pour votre configuration.

Mode de lancement

Pour le mode de lancement, procédez comme suit pour configurer le fichier de configuration launch.json VS Code et démarrer le serveur d’inférence dans VS Code :

  1. Démarrez VS Code et ouvrez le dossier qui contient le script score.py.

  2. Pour cet espace de travail dans VS Code, ajoutez la configuration suivante au fichier launch.json :

    {
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug score.py",
            "type": "debugpy",
            "request": "launch",
            "module": "azureml_inference_server_http.amlserver",
            "args": [
                "--entry_script",
                "score.py"
            ]
        }
    ]
  }

  3. Démarrez la session de débogage dans VS Code en sélectionnant Exécuter>le débogage ou en sélectionnant F5.

Mode Attacher

Pour le mode d’attachement, procédez comme suit pour utiliser VS Code avec l’extension Python pour l’attacher au processus du serveur d’inférence :

Remarque

Pour Linux, installez d’abord le gdbpackage en exécutantsudo apt-get install -y gdb la commande.

  1. Démarrez VS Code et ouvrez le dossier qui contient le script score.py.

  2. Pour cet espace de travail dans VS Code, ajoutez la configuration suivante au fichier launch.json :

    {
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Attach using Process ID",
            "type": "debugpy",
            "request": "attach",
            "processId": "${command:pickProcess}",
            "justMyCode": true
        }
    ]
  }

  3. Dans une fenêtre de commande, démarrez le serveur d’inférence en exécutant la azmlinfsrv --entry_script score.py commande.

  4. Procédez comme suit pour démarrer la session de débogage dans VS Code :

    1. Sélectionnez Démarrer>le débogage, ou sélectionnez F5.

    2. Dans la fenêtre de commande, recherchez dans les journaux du serveur d'inférence pour localiser l'ID de l'instance de processus azmlinfsrv :

      Capture d’écran d’une fenêtre de commande montrant les journaux d’activité du serveur d’inférence. Dans une instruction de journal, l’ID de processus de la commande azmlinfsrv est mis en surbrillance.

      Veillez à localiser l’ID du azmlinfsrv processus, et non le gunicorn processus.

    3. Dans le débogueur VS Code, entrez l’ID du azmlinfsrv processus.

      Si vous ne voyez pas le sélecteur de processus VS Code, entrez manuellement l’ID de processus dans le processId champ du fichier launch.json de l’espace de travail.

Pour les modes de lancement et d’attachement, vous pouvez définir des points d’arrêt et déboguer le script étape par étape.

Utiliser un exemple de bout en bout

La procédure suivante exécute le serveur d’inférence localement avec des exemples de fichiers à partir du référentiel d’exemples Azure Machine Learning. Les exemples de fichiers incluent un script de scoring, un fichier de modèle et un fichier d’environnement. Pour plus d’exemples sur l’utilisation de ces fichiers d’exemple, voir Déployer et évaluer un modèle d’apprentissage automatique à l’aide d’un point de terminaison en ligne.

  1. Clonez l’exemple de référentiel et accédez au dossier qui contient les exemples de fichiers appropriés :

    git clone --depth 1 https://github.com/Azure/azureml-examples
cd azureml-examples/cli/endpoints/online/model-1/

  2. Utilisez conda pour créer et activer un environnement virtuel :

    Dans cet exemple, le package azureml-inference-server-http est automatiquement installé. Le package est inclus en tant que bibliothèque dépendante du azureml-defaults package, qui est répertoriée dans le fichier conda.yaml.

    # Create the environment from the YAML file.
conda env create --name model-env -f ./environment/conda.yaml
# Activate the new environment.
conda activate model-env

  3. Passez en revue le script de scoring, onlinescoring/score.py :

    import os
import logging
import json
import numpy
import joblib


def init():
    """
    This function is called when the container is initialized/started, typically after create/update of the deployment.
    You can write the logic here to perform init operations like caching the model in memory
    """
    global model
    # AZUREML_MODEL_DIR is an environment variable created during deployment.
    # It is the path to the model folder (./azureml-models/$MODEL_NAME/$VERSION)
    # Please provide your model's folder name if there is one
    model_path = os.path.join(
        os.getenv("AZUREML_MODEL_DIR"), "model/sklearn_regression_model.pkl"
    )
    # deserialize the model file back into a sklearn model
    model = joblib.load(model_path)
    logging.info("Init complete")


def run(raw_data):
    """
    This function is called for every invocation of the endpoint to perform the actual scoring/prediction.
    In the example we extract the data from the json input and call the scikit-learn model's predict()
    method and return the result back
    """
    logging.info("model 1: request received")
    data = json.loads(raw_data)["data"]
    data = numpy.array(data)
    result = model.predict(data)
    logging.info("Request processed")
    return result.tolist()

  4. Exécutez le serveur d’inférence en spécifiant le script de scoring et le chemin d’accès au dossier du modèle.

    Pendant le déploiement, la AZUREML_MODEL_DIR variable est définie pour stocker le chemin d’accès au dossier du modèle. Vous spécifiez cette valeur dans le model_dir paramètre. Lorsque le script de scoring s’exécute, il récupère la valeur de la AZUREML_MODEL_DIR variable.

    Dans ce cas, utilisez le répertoire actuel, ./ comme valeur de model_dir, car le script de scoring spécifie le sous-répertoire comme model/sklearn_regression_model.pkl.

    azmlinfsrv --entry_script ./onlinescoring/score.py --model_dir ./

    Lorsque le serveur d’inférence démarre et appelle correctement le script de scoring, l’exemple de journal de démarrage s’ouvre. Sinon, le journal affiche les messages d’erreur.

  5. Testez le script de scoring avec des exemples de données en procédant comme suit :

    1. Ouvrez une autre fenêtre de commande et accédez au même répertoire de travail dans lequel vous avez exécuté la azmlinfsrv commande.

    2. Utilisez l’utilitaire suivant curl pour envoyer un exemple de requête au serveur d’inférence et recevoir un résultat de scoring :

      curl --request POST "127.0.0.1:5001/score" --header "Content-Type:application/json" --data @sample-request.json

      Lorsqu’il n’y a aucun problème dans votre script de scoring, le script retourne le résultat du scoring. Si des problèmes se produisent, vous pouvez mettre à jour le script de scoring, puis redémarrer le serveur d’inférence pour tester le script mis à jour.

Examiner les itinéraires du serveur d’inférence

Le serveur d’inférence écoute sur le port 5001 par défaut aux itinéraires suivants :

Nom Itinéraire
Sonde Liveness 127.0.0.1:5001/
Score 127.0.0.1:5001/score
OpenAPI (swagger) 127.0.0.1:5001/swagger.json

Examiner les paramètres du serveur d’inférence

Le serveur d’inférence accepte les paramètres suivants :

Paramètre Obligatoire Par défaut Descriptif
entry_script Vrai S/O Identifie le chemin relatif ou absolu vers le script de notation
model_dir Faux S/O Identifie le chemin relatif ou absolu vers le répertoire qui contient le modèle utilisé pour l’inférence
port Faux 5001 Spécifie le port de service du serveur d’inférence
worker_count Faux 1 Fournit le nombre de threads de travail pour traiter les requêtes simultanées
appinsights_instrumentation_key Faux S/O Fournit la clé d'instrumentation pour l'instance d'Application Insights où les journaux sont publiés
access_control_allow_origins Faux S/O Active le partage de ressources inter-origines (CORS) pour les origines spécifiées, où plusieurs origines sont séparées par une virgule (,, par exemple, microsoft.com, bing.com

Explorer le traitement des demandes du serveur d’inférence

Les étapes suivantes montrent comment le serveur d’inférence, azmlinfsrvgère les requêtes entrantes :

  1. Un wrapper CLI Python se trouve autour de la pile réseau du serveur d’inférence et est utilisé pour démarrer le serveur d’inférence.

  2. Un client envoie une demande au serveur d’inférence.

  3. Le serveur d’inférence envoie la requête via le serveur WSGI (Web Server Gateway Interface), qui distribue la requête à l’une des applications de travail Flask suivantes :

  4. L’application worker Flask gère la requête, ce qui inclut le chargement du script d’entrée et toutes les dépendances.

  5. Votre script d’entrée reçoit la requête. Le script d’entrée effectue un appel d’inférence au modèle chargé et retourne une réponse.

Diagramme montrant comment le serveur d’inférence démarre et comment une requête passe à une application de travail Flask, puis au code utilisateur.

Explorer les journaux du serveur d’inférence

Il existe deux façons d’obtenir des données de journal pour le test du serveur d’inférence :

  • Exécutez le package azureml-inference-server-http localement et affichez la sortie du journal.
  • Utilisez des points de terminaison en ligne et affichez les journaux de conteneur. Le journal du serveur d’inférence est nommé serveur HTTP d’inférence Azure Machine Learning <version>.

Remarque

Le format de journalisation a changé depuis la version 0.8.0. Si votre journal utilise un style différent de celui prévu, mettez à jour le package azureml-inference-server-http avec la dernière version.

Afficher les journaux de démarrage

Lorsque le serveur d’inférence démarre, les journaux affichent les paramètres initiaux du serveur suivants :

Azure ML Inferencing HTTP server <version>


Server Settings
---------------
Entry Script Name: <entry-script>
Model Directory: <model-directory>
Config File: <configuration-file>
Worker Count: <worker-count>
Worker Timeout (seconds): None
Server Port: <port>
Health Port: <port>
Application Insights Enabled: false
Application Insights Key: <Application-Insights-instrumentation-key>
Inferencing HTTP server version: azmlinfsrv/<version>
CORS for the specified origins: <access-control-allow-origins>
Create dedicated endpoint for health: <health-check-endpoint>


Server Routes
---------------
Liveness Probe: GET   127.0.0.1:<port>/
Score:          POST  127.0.0.1:<port>/score

<logs>

Par exemple, lorsque vous exécutez le serveur d’inférence en suivant les étapes de l’exemple de bout en bout, les journaux contiennent les informations suivantes :

Azure ML Inferencing HTTP server v1.2.2


Server Settings
---------------
Entry Script Name: /home/user-name/azureml-examples/cli/endpoints/online/model-1/onlinescoring/score.py
Model Directory: ./
Config File: None
Worker Count: 1
Worker Timeout (seconds): None
Server Port: 5001
Health Port: 5001
Application Insights Enabled: false
Application Insights Key: None
Inferencing HTTP server version: azmlinfsrv/1.2.2
CORS for the specified origins: None
Create dedicated endpoint for health: None

Server Routes
---------------
Liveness Probe: GET   127.0.0.1:5001/
Score:          POST  127.0.0.1:5001/score

2022-12-24 07:37:53,318 I [32726] gunicorn.error - Starting gunicorn 20.1.0
2022-12-24 07:37:53,319 I [32726] gunicorn.error - Listening at: http://0.0.0.0:5001 (32726)
2022-12-24 07:37:53,319 I [32726] gunicorn.error - Using worker: sync
2022-12-24 07:37:53,322 I [32756] gunicorn.error - Booting worker with pid: 32756
Initializing logger
2022-12-24 07:37:53,779 I [32756] azmlinfsrv - Starting up app insights client
2022-12-24 07:37:54,518 I [32756] azmlinfsrv.user_script - Found user script at /home/user-name/azureml-examples/cli/endpoints/online/model-1/onlinescoring/score.py
2022-12-24 07:37:54,518 I [32756] azmlinfsrv.user_script - run() is not decorated. Server will invoke it with the input in JSON string.
2022-12-24 07:37:54,518 I [32756] azmlinfsrv.user_script - Invoking user's init function
2022-12-24 07:37:55,974 I [32756] azmlinfsrv.user_script - Users's init has completed successfully
2022-12-24 07:37:55,976 I [32756] azmlinfsrv.swagger - Swaggers are prepared for the following versions: [2, 3, 3.1].
2022-12-24 07:37:55,976 I [32756] azmlinfsrv - Scoring timeout is set to 3600000
2022-12-24 07:37:55,976 I [32756] azmlinfsrv - Worker with pid 32756 ready for serving traffic

Comprendre le format des données du journal

Tous les journaux du serveur d’inférence, à l’exception du script du lanceur, présentent des données au format suivant :

<UTC-time> <level> [<process-ID>] <logger-name> - <message>

Chaque entrée se compose des composants suivants :

  • <UTC-time> : L'heure à laquelle l'entrée est saisie dans le journal
  • <level> : Le premier caractère du niveau de journalisation de l’entrée, tel que E pour ERREUR, I pour INFO, etc.
  • <process-ID>: ID du processus associé à l’entrée
  • <logger-name>: nom de la ressource associée à l’entrée de journal
  • <message> : Le contenu du message de journal

Il existe six niveaux de journalisation dans Python. Chaque niveau a une valeur numérique affectée en fonction de sa gravité :

Niveau de journalisation Valeur numérique
CRITIQUE 50
ERREUR 40
AVERTISSEMENT 30
INFO 20
DEBUG 10
NOTSET 0

Résoudre les problèmes liés au serveur d’inférence

Les sections suivantes fournissent des conseils de dépannage de base pour le serveur d’inférence. Pour résoudre les problèmes de points de terminaison en ligne, consultez Résoudre les problèmes de déploiement et de scoring de points de terminaison en ligne.

Vérifier les packages installés

Pour résoudre les problèmes liés aux packages installés, effectuez les étapes suivantes :

  1. Collectez des informations sur les packages et les versions installés pour votre environnement Python.

  2. Dans votre fichier d’environnement, vérifiez la version du azureml-inference-server-http package Python spécifié. Dans les journaux de démarrage du serveur HTTP d’inférence Azure Machine Learning, vérifiez la version du serveur d’inférence qui s’affiche. Vérifiez que les deux versions correspondent.

    Dans certains cas, le programme de résolution de dépendance pip installe des versions de package inattendues. Vous devrez peut-être exécuter pip pour corriger les packages et les versions installés.

  3. Si vous spécifiez Flask ou ses dépendances dans votre environnement, supprimez ces éléments.

    • Les packages dépendants incluent flask, jinja2, itsdangerous, werkzeug, markupsafe et click.
    • Le flask package est répertorié en tant que dépendance dans le package du serveur d’inférence. La meilleure approche consiste à autoriser le serveur d’inférence à installer le package flask.
    • Lorsque le serveur d’inférence est configuré pour prendre en charge les nouvelles versions de Flask, le serveur d’inférence reçoit automatiquement les mises à jour du package dès qu’ils deviennent disponibles.

Vérifier la version du serveur d’inférence

Le package de serveur azureml-inference-server-http est publié sur PyPI. La page PyPI répertorie le journal des modifications et toutes les versions du package.

Si vous utilisez une version anticipée du package, mettez à jour votre configuration vers la dernière version. Le tableau suivant récapitule les versions stables, les problèmes courants et les ajustements recommandés :

Version du package Descriptif Problème Résolution
0.4.x Incluse dans les images d’entraînement datées du 20220601 ou antérieures et avec les versions 0.1.34 à 1.43 du package azureml-defaults. La dernière version stable est 0.4.13. Pour les versions de serveur antérieures à la version 0.4.11, vous pouvez rencontrer des problèmes de dépendance Flask, tels que can't import name Markup from jinja2. Effectuez une mise à niveau vers la version 0.4.13 ou 1.4.x, la dernière version, si possible.
0.6.x Préinstallée dans les images d’inférence datant de 20220516 et antérieures. La dernière version stable est 0.6.1. S/O S/O
0.7 x Prend en charge Flask 2. La dernière version stable est 0.7.7. S/O S/O
0.8.x Utilise un format de journal mis à jour. Met fin à la prise en charge de Python 3.6. S/O S/O
1.0.x Met fin à la prise en charge de Python 3.7. S/O S/O
1.1.x Migre vers pydantic 2.0. S/O S/O
1.2.x Ajoute la prise en charge de Python 3.11. Mise à jour gunicorn vers la version 22.0.0. Mises à jour werkzeug vers la version 3.0.3 et les versions ultérieures. S/O S/O
1.3.x Ajoute la prise en charge de Python 3.12. certifi Mises à niveau vers la version 2024.7.4. flask-cors Mise à niveau vers la version 5.0.0. Met à niveau les packages gunicorn et pydantic. S/O S/O
1.4.x waitress Mise à niveau vers la version 3.0.1. Met fin à la prise en charge de Python 3.8. Supprime la couche de compatibilité qui empêche la mise à niveau flask 2.0 de rompre le code objet de la requête. Si vous dépendez de la couche de compatibilité, votre code objet de requête peut ne pas fonctionner. Migrez votre script de score vers Flask 2.

Vérifier les dépendances de package

Les packages dépendants les plus pertinents pour le package de serveur azureml-inference-server-http sont les suivants :

  • flask
  • opencensus-ext-azure
  • inference-schema

Si vous spécifiez le azureml-defaults package dans votre environnement Python, le azureml-inference-server-http package est un package dépendant. La dépendance est installée automatiquement.

Conseil

Si vous utilisez le Kit de développement logiciel (SDK) Azure Machine Learning pour Python v1 et que vous ne spécifiez pas explicitement le azureml-defaults package dans votre environnement Python, le SDK peut ajouter automatiquement le package. Toutefois, la version du package est verrouillée par rapport à la version du Kit de développement logiciel (SDK). Par exemple, si la version du Kit de développement logiciel (SDK) est 1.38.0, l’entrée azureml-defaults==1.38.0 est ajoutée aux exigences pip de l’environnement.

TypeError lors du démarrage du serveur d’inférence

Vous pouvez rencontrer les éléments suivants TypeError au démarrage du serveur d’inférence :

TypeError: register() takes 3 positional arguments but 4 were given

  File "/var/azureml-server/aml_blueprint.py", line 251, in register

    super(AMLBlueprint, self).register(app, options, first_registration)

TypeError: register() takes 3 positional arguments but 4 were given

Cette erreur se produit lorsque Flask 2 est installé dans votre environnement Python, mais que votre version de package azureml-inference-server-http ne prend pas en charge Flask 2. La prise en charge de Flask 2 est disponible dans le azureml-inference-server-http package 0.7.0 et les versions ultérieures, ainsi que dans le azureml-defaults package 1.44 et les versions ultérieures.

  • Si vous n’utilisez pas le package Flask 2 dans une image Docker Azure Machine Learning, utilisez la dernière version du package azureml-inference-server-http ou azureml-defaults.

  • Si vous utilisez le package Flask 2 dans une image Docker Azure Machine Learning, vérifiez que la version de build de l’image est July 2022 ou ultérieure.

    Vous trouverez la version de l’image dans les journaux du conteneur. Par exemple, voir les déclarations de journal suivantes :

    2022-08-22T17:05:02,147738763+00:00 | gunicorn/run | AzureML Container Runtime Information
2022-08-22T17:05:02,161963207+00:00 | gunicorn/run | ###############################################
2022-08-22T17:05:02,168970479+00:00 | gunicorn/run | 
2022-08-22T17:05:02,174364834+00:00 | gunicorn/run | 
2022-08-22T17:05:02,187280665+00:00 | gunicorn/run | AzureML image information: openmpi4.1.0-ubuntu20.04, Materialization Build:20220708.v2
2022-08-22T17:05:02,188930082+00:00 | gunicorn/run | 
2022-08-22T17:05:02,190557998+00:00 | gunicorn/run |

    La date de génération de l’image apparaît après la notation Materialization Build. Dans l’exemple précédent, la version de l’image est 20220708, ou le 8 juillet 2022. Dans cet exemple, l’image est compatible avec Flask 2.

    Si vous ne voyez pas de message similaire dans le journal de votre conteneur, votre image est obsolète et doit être mise à jour. Si vous utilisez une image CUDA (Compute Unified Device Architecture) et que vous ne trouvez pas d’image plus récente, vérifiez le dépôt AzureML-Containers pour voir si votre image est déconseillée. Vous trouverez des remplacements désignés pour les images déconseillées.

    Si vous utilisez le serveur d’inférence avec un point de terminaison en ligne, vous pouvez trouver les journaux dans Azure Machine Learning studio. Dans la page de votre point de terminaison, sélectionnez l’onglet Journaux .

Si vous déployez avec le Kit de développement logiciel (SDK) v1 et que vous ne spécifiez pas explicitement d’image dans votre configuration de déploiement, le serveur d’inférence applique le openmpi4.1.0-ubuntu20.04 package avec une version qui correspond à votre ensemble d’outils sdk local. Toutefois, la version installée n’est peut-être pas la dernière version disponible de l’image.

Pour le SDK version 1.43, le serveur d’inférence installe la version du openmpi4.1.0-ubuntu20.04:20220616 package par défaut, mais cette version de package n’est pas compatible avec le SDK 1.43. Veillez à utiliser la dernière version du kit SDK pour votre déploiement.

Si vous ne pouvez pas mettre à jour l’image, vous pouvez éviter temporairement le problème en épinglant l’entrée azureml-defaults==1.43 ou azureml-inference-server-http~=0.4.13 dans votre fichier d’environnement. Ces entrées dirigent le serveur d’inférence pour installer l’ancienne version avec flask 1.0.x.

ImportError ou ModuleNotFoundError au démarrage du serveur d’inférence

Vous pouvez rencontrer un ImportError ou ModuleNotFoundError sur des modules spécifiques, tels que opencensus, , jinja2markupsafeou click, pendant le démarrage du serveur d’inférence. L’exemple suivant montre le message d’erreur :

ImportError: cannot import name 'Markup' from 'jinja2'

Les erreurs d’importation et de module se produisent lorsque vous utilisez la version 0.4.10 ou les versions antérieures du serveur d’inférence qui n’épinglent pas la dépendance Flask à une version compatible. Pour éviter le problème, installez une version ultérieure du serveur d’inférence.

Contenu connexe