Partager via


Déployer et évaluer un modèle de Machine Learning à l’aide d’un point de terminaison en ligne

S’APPLIQUE À :Extension Azure CLI v2 (actuelle)Kit de développement logiciel (SDK) Python azure-ai-ml v2 (version actuelle)

Dans cet article, vous allez apprendre à déployer votre modèle sur un point de terminaison en ligne pour une utilisation en temps réel de l’inférence. Vous commencez par déployer un modèle sur votre ordinateur local pour déboguer les erreurs. Ensuite, vous déployez et testez le modèle dans Azure, affichez les journaux de déploiement et surveillez le contrat de niveau de service (SLA). À la fin de cet article, vous disposez d’un point de terminaison HTTPS/REST évolutif que vous pouvez utiliser pour l’inférence en temps réel.

Les points de terminaison en ligne sont des points de terminaison utilisés pour l’inférence en temps réel. Il existe deux types de points de terminaison en ligne : les points de terminaison en ligne managés et les points de terminaison en ligne Kubernetes. Pour plus d’informations sur les différences, consultez Points de terminaison en ligne managés et points de terminaison en ligne Kubernetes.

Les points de terminaison en ligne managés vous aident à déployer vos modèles Machine Learning en un tournemain. Les points de terminaison en ligne managés fonctionnent avec des ordinateurs de processeur et GPU puissants dans Azure de manière évolutive et entièrement gérée. Les points de terminaison en ligne gérés s’occupent de servir, de mettre à l’échelle, de sécuriser et de surveiller vos modèles. Cette assistance vous libère de la surcharge liée à la configuration et à la gestion de l’infrastructure sous-jacente.

L’exemple principal de cet article utilise des points de terminaison en ligne managés pour le déploiement. Pour utiliser Kubernetes à la place, consultez les notes dans ce document qui sont incluses avec la discussion sur les points de terminaison en ligne managés.

Prérequis

S’APPLIQUE À :Extension ml Azure CLI v2 (actuelle)

  • Azure CLI et l’extension ml d’Azure CLI, installées et configurées. Pour plus d’informations, consultez Installer et configurer l’interface CLI (v2).

  • Un interpréteur de commandes Bash ou un interpréteur de commandes compatible, par exemple, un interpréteur de commandes sur un système Linux ou un sous-système Windows pour Linux. Les exemples Azure CLI de cet article supposent que vous utilisez ce type d’interpréteur de commandes.

  • Un espace de travail Azure Machine Learning. Pour obtenir des instructions sur la création d’un espace de travail, consultez Configurer.

  • Le contrôle d’accès en fonction du rôle Azure (Azure RBAC) est utilisé pour accorder l’accès aux opérations dans Azure Machine Learning. Pour effectuer les étapes décrites dans cet article, votre compte d’utilisateur doit être affecté au rôle Propriétaire ou Contributeur pour l’espace de travail Azure Machine Learning, ou un rôle personnalisé doit autoriser Microsoft.MachineLearningServices/workspaces/onlineEndpoints/*. Si vous utilisez Azure Machine Learning Studio pour créer et gérer des points de terminaison ou des déploiements en ligne, vous avez besoin de l’autorisation Microsoft.Resources/deployments/write supplémentaire du propriétaire du groupe de ressources. Pour plus d’informations, consultez Gérer l’accès aux espaces de travail Azure Machine Learning.

  • (Facultatif) Pour déployer localement, vous devez installer Moteur Docker sur votre ordinateur local. Nous recommandons vivement cette option, ce qui facilite le débogage des problèmes.

  • Vérifiez que vous disposez d’un quota de machine virtuelle suffisant alloué pour le déploiement. Azure Machine Learning réserve 20% de vos ressources de calcul pour effectuer des mises à niveau sur certaines versions de machine virtuelle. Par exemple, si vous demandez 10 instances dans un déploiement, vous devez disposer d’un quota de 12 pour chaque nombre de cœurs pour la version de la machine virtuelle. L’échec du compte des ressources de calcul supplémentaires entraîne une erreur. Certaines versions de machine virtuelle sont exemptées de la réservation de quota supplémentaire. Pour plus d’informations sur l’allocation de quota, consultez Allocation de quota de machines virtuelles pour le déploiement.

  • Vous pouvez également utiliser le quota à partir du pool de quotas partagés Azure Machine Learning pendant une durée limitée. Azure Machine Learning fournit un pool de quotas partagé auquel les utilisateurs de diverses régions peuvent accéder pour effectuer des tests pendant une durée limitée, en fonction de la disponibilité. Lorsque vous utilisez le studio pour déployer des modèles Llama-2, Phi, Nemotron, Mistral, Dolly et Deci-DeciLM à partir du catalogue de modèles vers un point de terminaison en ligne managé, Azure Machine Learning vous permet d’accéder à son pool de quotas partagés pendant une courte période afin de pouvoir effectuer des tests. Pour plus d’informations sur le pool de quotas partagés, consultez quota partagé Azure Machine Learning.

Préparer votre système

Définir des variables d’environnement

Si vous n’avez pas encore défini les paramètres par défaut pour l’interface CLI Azure, enregistrez vos paramètres par défaut. Pour éviter de transmettre plusieurs fois les valeurs de votre abonnement, de votre espace de travail et de votre groupe de ressources, exécutez le code suivant :

az account set --subscription <subscription ID>
az configure --defaults workspace=<Azure Machine Learning workspace name> group=<resource group>

Cloner le référentiel d’exemples

Pour suivre cet article, commencez par cloner le référentiel azureml-examples, puis passez au répertoire azureml-examples/cli du référentiel :

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

Utilisez --depth 1 pour cloner uniquement le dernier commit dans le référentiel, ce qui réduit le temps nécessaire à l'opération.

Les commandes de ce didacticiel se trouvent dans les fichiers deploy-local-endpoint.sh et deploy-managed-online-endpoint.sh dans le répertoire cli . Les fichiers de configuration YAML se trouvent dans le sous-répertoire endpoints/online/managed/sample/.

Notes

Les fichiers de configuration YAML pour les points de terminaison en ligne Kubernetes se trouvent dans les points de terminaison/online/kubernetes/ sous-répertoire.

Définir le point de terminaison

Pour définir un point de terminaison en ligne, spécifiez le nom du point de terminaison et le mode d’authentification. Pour plus d’informations sur les points de terminaison en ligne managés, consultez points de terminaison en ligne.

Définir un nom d’un point de terminaison

Pour définir le nom de votre point de terminaison, exécutez la commande suivante. Remplacez <YOUR_ENDPOINT_NAME> par un nom unique dans la région Azure. Pour obtenir plus d’informations sur les règles d’affectation de noms, consultez Limites de point de terminaison.

export ENDPOINT_NAME="<YOUR_ENDPOINT_NAME>"

Configurer le point de terminaison

L’extrait de code suivant montre le fichier endpoints/online/managed/sample/endpoint.yml :

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineEndpoint.schema.json
name: my-endpoint
auth_mode: key

La référence pour le format YAML du point de terminaison est décrite dans le tableau suivant. Pour savoir comment spécifier ces attributs, consultez la référence YAML du point de terminaison en ligne. Pour plus d’informations sur les limites liées aux points de terminaison managés, consultez les points de terminaison en ligne Azure Machine Learning et les points de terminaison par lots.

Clé Descriptif
$schema (Facultatif) Schéma YAML. Pour voir toutes les options disponibles dans le fichier YAML, vous pouvez consulter le schéma dans l’extrait de code précédent avec un navigateur.
name Nom du point de terminaison.
auth_mode Utilisez key pour l’authentification basée sur les clés.
Utilisez aml_token pour l’authentification Azure Machine Learning basée sur les jetons.
Utilisez aad_token pour l’authentification basée sur le jeton Microsoft Entra (préversion).
Pour plus d’informations sur l’authentification, consultez Authentifier les clients pour les points de terminaison en ligne.

Définir le déploiement

Un déploiement est un ensemble de ressources nécessaires pour héberger le modèle qui effectue l’inférence réelle. Pour cet exemple, vous déployez un modèle qui effectue une scikit-learn régression et utilisez un script de scoring score.py pour exécuter le modèle sur une demande d’entrée spécifique.

Pour en savoir plus sur les attributs clés d’un déploiement, consultez déploiements en ligne.

Configurer un déploiement

Votre configuration de déploiement utilise l’emplacement du modèle que vous souhaitez déployer.

L’extrait de code suivant montre le fichier endpoints/online/managed/sample/blue-deployment.yml avec toutes les entrées nécessaires pour configurer un déploiement :

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

Le fichier blue-deployment.yml spécifie les attributs de déploiement suivants :

  • model: spécifie les propriétés du modèle inline à l’aide du path paramètre (où charger des fichiers à partir de). L’interface CLI charge automatiquement les fichiers de modèle et inscrit le modèle avec un nom généré automatiquement.
  • environment: utilise des définitions inline qui incluent l’emplacement à partir duquel charger des fichiers. L’interface CLI charge automatiquement le fichier conda.yaml et inscrit l’environnement. Plus tard, pour générer l’environnement, le déploiement utilise le image paramètre pour l’image de base. Dans cet exemple, il est mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest. Les conda_file dépendances sont installées sur l’image de base.
  • code_configuration: charge les fichiers locaux, tels que la source Python pour le modèle de scoring, à partir de l’environnement de développement pendant le déploiement.

Pour plus d’informations sur le schéma YAML, consultez le document Référence YAML sur les points de terminaison en ligne.

Notes

Pour utiliser des points de terminaison Kubernetes au lieu de points de terminaison en ligne gérés comme cible de calcul :

  1. Créez et attachez votre cluster Kubernetes comme cible de calcul à votre espace de travail Azure Machine Learning avec Azure Machine Learning Studio.
  2. Utilisez le YAML du point de terminaison pour cibler Kubernetes au lieu du YAML du point de terminaison géré. Vous devez modifier le YAML pour modifier la valeur de compute en nom de votre cible de calcul inscrite. Vous pouvez utiliser ce deployment.yaml qui a d’autres propriétés qui s’appliquent à un déploiement Kubernetes.

Toutes les commandes utilisées dans cet article pour les points de terminaison en ligne managés s’appliquent également aux points de terminaison Kubernetes, à l’exception des fonctionnalités suivantes qui ne s’appliquent pas aux points de terminaison Kubernetes :

Comprendre le script de scoring

Le format du script de scoring pour les points de terminaison en ligne est le même que celui utilisé dans la version précédente de l’interface CLI et dans le SDK Python.

Le script de scoring spécifié dans code_configuration.scoring_script doit avoir une fonction init() et une fonction run().

Cet exemple utilise le fichier score.py à partir du dépôt que vous avez cloné ou téléchargé précédemment :

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()

La fonction init() est appelée lorsque le conteneur est initialisé ou démarré. Cette initialisation se produit généralement peu après la création ou la mise à jour du déploiement. La fonction init est l’endroit où écrire une logique pour les opérations d’initialisation globales, telles que la mise en cache du modèle en mémoire (comme indiqué dans ce fichier score.py).

La run() fonction est appelée chaque fois que le point de terminaison est appelé. Il effectue les véritables évaluations et prédictions. Dans ce fichier score.py, la fonction run() extrait les données d’une entrée JSON, appelle la méthode predict() du modèle scikit-learn, puis retourne le résultat de prédiction.

Déployer et déboguer localement à l’aide d’un point de terminaison local

Nous vous recommandons vivement de tester votre point de terminaison localement pour valider et déboguer votre code et votre configuration avant de déployer sur Azure. Azure CLI et le Kit de développement logiciel (SDK) Python prennent en charge les points de terminaison et les déploiements locaux, mais pas les modèles Azure Machine Learning Studio et ARM.

Pour effectuer un déploiement local, le moteur Docker doit être installé et en cours d’exécution. Le moteur Docker démarre généralement au démarrage de l’ordinateur. Si ce n’est pas le cas, vous pouvez dépanner le Moteur Docker.

Vous pouvez utiliser le package Python du serveur HTTP d’inférence Azure Machine Learning pour déboguer votre script de scoring localement sans le moteur Docker. Le débogage avec le serveur d’inférence vous permet de déboguer le script de scoring avant de déployer sur des points de terminaison locaux afin de pouvoir déboguer sans être affecté par les configurations de conteneur de déploiement.

Pour plus d’informations sur le débogage des points de terminaison en ligne localement avant de déployer sur Azure, consultez débogage de point de terminaison en ligne.

Déployer le modèle localement

Tout d’abord, créez un point de terminaison. Si vous le souhaitez, pour un point de terminaison local, vous pouvez ignorer cette étape. Vous pouvez créer le déploiement directement (étape suivante), ce qui crée à son tour les métadonnées requises. Le déploiement de modèles localement est utile à des fins de développement et de test.

az ml online-endpoint create --local -n $ENDPOINT_NAME -f endpoints/online/managed/sample/endpoint.yml

À présent, créez un déploiement nommé blue sous le point de terminaison.

az ml online-deployment create --local -n blue --endpoint $ENDPOINT_NAME -f endpoints/online/managed/sample/blue-deployment.yml

L’indicateur --local oriente l’interface CLI pour déployer le point de terminaison dans l’environnement Docker.

Conseil

Utilisez Visual Studio Code pour tester et déboguer vos points de terminaison localement. Pour plus d’informations, consultez Déboguer des points de terminaison en ligne localement dans Visual Studio Code.

Vérifier que le déploiement local a réussi

Vérifiez l’état du déploiement pour déterminer si le modèle a été déployé sans erreur :

az ml online-endpoint show -n $ENDPOINT_NAME --local

Le résultat doit ressembler au JSON suivant. Le provisioning_state paramètre est Succeeded.

{
  "auth_mode": "key",
  "location": "local",
  "name": "docs-endpoint",
  "properties": {},
  "provisioning_state": "Succeeded",
  "scoring_uri": "http://localhost:49158/score",
  "tags": {},
  "traffic": {}
}

Le tableau suivant contient les valeurs possibles de provisioning_state :

Valeur Descriptif
Creating La ressource est en cours de création.
Updating La ressource est en cours de mise à jour.
Deleting La ressource est en cours de suppression.
Succeeded L’opération de création ou de mise à jour a réussi.
Failed Échec de l’opération de création, de mise à jour ou de suppression.

Appeler le point de terminaison local pour effectuer la notation des données avec votre modèle

Appelez le point de terminaison pour noter le modèle à l’aide de la commande invoke et en passant des paramètres de requête stockés dans un fichier JSON :

az ml online-endpoint invoke --local --name $ENDPOINT_NAME --request-file endpoints/online/model-1/sample-request.json

Si vous souhaitez utiliser un client REST (par exemple, une boucle), vous devez disposer de l’URI de notation. Pour récupérer l’URI de notation, exécutez az ml online-endpoint show --local -n $ENDPOINT_NAME. Dans les données retournées, recherchez l’attribut scoring_uri.

Rechercher dans les journaux la sortie de l’opération d’appel

Dans l’exemple fichier score.py, la méthode run() journalise une sortie dans la console.

Vous pouvez afficher cette sortie en utilisant la commande get-logs :

az ml online-deployment get-logs --local -n blue --endpoint $ENDPOINT_NAME

Déployer votre point de terminaison en ligne dans Azure

Ensuite, déployez votre point de terminaison en ligne dans Azure. Comme meilleure pratique pour la production, nous vous recommandons d’inscrire le modèle et l’environnement que vous utilisez dans votre déploiement.

Inscrire votre modèle et votre environnement

Nous vous recommandons d’inscrire votre modèle et votre environnement avant le déploiement sur Azure afin de pouvoir spécifier leurs noms et versions inscrits pendant le déploiement. Après avoir inscrit vos ressources, vous pouvez les réutiliser sans avoir à les charger chaque fois que vous créez des déploiements. Cette pratique augmente la reproductibilité et la traçabilité.

Contrairement au déploiement vers Azure, le déploiement local ne prend pas en charge l’utilisation de modèles et d’environnements inscrits. Au lieu de cela, le déploiement local utilise des fichiers de modèle local et utilise des environnements avec des fichiers locaux uniquement.

Pour le déploiement sur Azure, vous pouvez utiliser des ressources locales ou inscrites (modèles et environnements). Dans cette section de l’article, le déploiement sur Azure utilise des ressources inscrites, mais vous avez la possibilité d’utiliser des ressources locales à la place. Pour obtenir un exemple de configuration de déploiement qui charge les fichiers locaux à utiliser pour le déploiement local, consultez Configurer un déploiement.

Pour inscrire le modèle et l’environnement, utilisez le formulaire model: azureml:my-model:1 ou environment: azureml:my-env:1.

Pour l'inscription, vous pouvez extraire les définitions YAML de model et environment vers des fichiers YAML distincts dans le dossier endpoints/online/managed/sample, et utiliser les commandes az ml model create et az ml environment create. Pour en savoir plus sur ces commandes, exécutez az ml model create -h et az ml environment create -h.

  1. Créez une définition YAML pour le modèle. Nommez le fichier model.yml :

    $schema: https://azuremlschemas.azureedge.net/latest/model.schema.json
    name: my-model
    path: ../../model-1/model/
    
  2. Inscrivez le modèle :

    az ml model create -n my-model -v 1 -f endpoints/online/managed/sample/model.yml
    
  3. Créez une définition YAML pour l’environnement. Nommez le fichier environment.yml :

    $schema: https://azuremlschemas.azureedge.net/latest/environment.schema.json
    name: my-env
    image: mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest
    conda_file: ../../model-1/environment/conda.yaml
    
  4. Inscrivez l’environnement :

    az ml environment create -n my-env -v 1 -f endpoints/online/managed/sample/environment.yml
    

Pour plus d’informations sur l’inscription de votre modèle en tant que ressource, consultez Inscrire un modèle à l’aide de l’interface de ligne de commande Azure ou du Kit de développement logiciel (SDK) Python. Pour plus d’informations sur la création d’un environnement, consultez Créer un environnement personnalisé.

Important

Lorsque vous définissez un environnement personnalisé pour votre déploiement, vérifiez que le azureml-inference-server-http package est inclus dans le fichier conda. Ce package est essentiel pour que le serveur d’inférence fonctionne correctement. Si vous ne connaissez pas la création de votre propre environnement personnalisé, utilisez l’un de nos environnements organisés tels que minimal-py-inference (pour les modèles personnalisés qui n’utilisent mlflowpas) ou mlflow-py-inference (pour les modèles qui utilisent mlflow). Vous trouverez ces environnements organisés sous l’onglet Environnements de votre instance d’Azure Machine Learning Studio.

Configurer un déploiement qui utilise des ressources inscrites

Votre configuration de déploiement utilise le modèle inscrit que vous souhaitez déployer et votre environnement inscrit.

Utilisez les ressources inscrites (modèle et environnement) dans votre définition de déploiement. L’extrait de code suivant montre le fichier endpoints/online/managed/sample/blue-deployment-with-registered-assets.yml, avec toutes les entrées requises pour configurer un déploiement :

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json
name: blue
endpoint_name: my-endpoint
model: azureml:my-model:1
code_configuration:
  code: ../../model-1/onlinescoring/
  scoring_script: score.py
environment: azureml:my-env:1
instance_type: Standard_DS3_v2
instance_count: 1

Utilisation de différents types d’images et d’instances de processeur et GPU

Vous pouvez spécifier les types et images d’instance processeur ou GPU dans votre définition de déploiement pour le déploiement local et le déploiement sur Azure.

Votre définition de déploiement dans le fichier blue-deployment-with-registered-assets.yml a utilisé une instance de type Standard_DS3_v2 usage général et l’image mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latestDocker non GPU. Pour le calcul GPU, choisissez une version de type de calcul GPU et une image Docker GPU.

Pour connaître les types d’instances à usage général et GPU pris en charge, consultez la liste des références SKU des points de terminaison en ligne managés. Pour obtenir la liste des images de base de processeur et GPU d’Azure ML, consultez Images de base Azure Machine Learning.

Notes

Pour utiliser Kubernetes au lieu de points de terminaison managés comme cible de calcul, consultez Présentation de la cible de calcul Kubernetes.

Ensuite, déployez votre point de terminaison en ligne dans Azure.

Déployer sur Azure

  1. Créez le point de terminaison dans le cloud Azure :

    az ml online-endpoint create --name $ENDPOINT_NAME -f endpoints/online/managed/sample/endpoint.yml
    
  2. Créez le déploiement nommé blue au niveau du point de terminaison :

    az ml online-deployment create --name blue --endpoint $ENDPOINT_NAME -f endpoints/online/managed/sample/blue-deployment-with-registered-assets.yml --all-traffic
    

    La création du déploiement peut prendre jusqu’à 15 minutes, selon que l’environnement ou l’image sous-jacent est créé pour la première fois. Les déploiements suivants qui utilisent le même environnement sont traités plus rapidement.

    Si vous préférez ne pas bloquer votre console CLI, vous pouvez ajouter l’indicateur --no-wait à la commande. Toutefois, cette option arrête l’affichage interactif de l’état du déploiement.

    L’indicateur --all-traffic dans le code az ml online-deployment create utilisé pour créer le déploiement alloue 100 % du trafic de point de terminaison au déploiement bleu nouvellement créé. L’utilisation de cet indicateur est utile à des fins de développement et de test, mais pour la production, vous pouvez router le trafic vers le nouveau déploiement via une commande explicite. Par exemple, utilisez az ml online-endpoint update -n $ENDPOINT_NAME --traffic "blue=100".

Pour déboguer des erreurs dans votre déploiement, consultez Résolution des problèmes de déploiements de points de terminaison en ligne.

Vérifier l’état du point de terminaison en ligne

  1. Utilisez la commande show pour afficher des informations dans le provisioning_state pour le point de terminaison et le déploiement :

    az ml online-endpoint show -n $ENDPOINT_NAME
    
  2. Répertoriez tous les points de terminaison de l’espace de travail dans un format de tableau à l’aide de la commande list :

    az ml online-endpoint list --output table
    

Vérifier l’état du déploiement en ligne

Vérifiez les journaux pour voir si le modèle a été déployé sans erreur.

Pour voir la sortie de journal d’un conteneur, utilisez la commande CLI suivante :

az ml online-deployment get-logs --name blue --endpoint $ENDPOINT_NAME

Par défaut, les journaux sont extraits du conteneur du serveur d’inférence. Pour voir les journaux du conteneur de l’initialiseur de stockage, ajoutez l’indicateur --container storage-initializer. Pour plus d’informations sur les journaux de déploiement, consultez Obtenir des journaux de conteneur.

Appeler le point de terminaison pour effectuer la notation des données avec votre modèle

  1. Utilisez la commande invoke ou un client REST de votre choix pour appeler le point de terminaison et noter certaines données :

    az ml online-endpoint invoke --name $ENDPOINT_NAME --request-file endpoints/online/model-1/sample-request.json
    
  2. Obtenez la clé utilisée pour l’authentification auprès du point de terminaison :

    Vous pouvez contrôler quels principaux de sécurité Microsoft Entra peuvent obtenir la clé d’authentification en leur attribuant un rôle personnalisé qui autorise Microsoft.MachineLearningServices/workspaces/onlineEndpoints/token/action et Microsoft.MachineLearningServices/workspaces/onlineEndpoints/listkeys/action. Pour plus d’informations sur la gestion de l’autorisation sur les espaces de travail, consultez Gérer l’accès à un espace de travail Azure Machine Learning.

    ENDPOINT_KEY=$(az ml online-endpoint get-credentials -n $ENDPOINT_NAME -o tsv --query primaryKey)
    
  3. Utilisez curl pour noter les données.

    SCORING_URI=$(az ml online-endpoint show -n $ENDPOINT_NAME -o tsv --query scoring_uri)
    
    curl --request POST "$SCORING_URI" --header "Authorization: Bearer $ENDPOINT_KEY" --header 'Content-Type: application/json' --data @endpoints/online/model-1/sample-request.json
    

    Notez que vous utilisez show et get-credentials commandes pour obtenir les informations d’identification d’authentification. Notez également que vous utilisez l’indicateur --query pour filtrer uniquement les attributs nécessaires. Pour en savoir plus sur l’indicateur de --query, consultez requête de sortie de commande Azure CLI.

  4. Pour visualiser les journaux d’appel, exécutez get-logs de nouveau.

(Facultatif) Mettre à jour le déploiement

Si vous souhaitez mettre à jour le code, le modèle ou l’environnement, mettez à jour le fichier YAML. Exécutez ensuite la commande az ml online-endpoint update.

Si vous mettez à jour le nombre d’instances (pour mettre à l’échelle votre déploiement) ainsi que d’autres paramètres de modèle (tels que le code, le modèle ou l’environnement) dans une seule update commande, l’opération de mise à l’échelle est effectuée en premier. Les autres mises à jour sont appliquées ensuite. Il est conseillé d’effectuer ces opérations séparément dans un environnement de production.

Pour comprendre comment update fonctionne :

  1. Ouvrez le fichier online/model-1/onlinescoring/score.py.

  2. Modifiez la dernière ligne de la fonction init() : après logging.info("Init complete"), ajoutez logging.info("Updated successfully").

  3. Enregistrez le fichier .

  4. Exécutez cette commande :

    az ml online-deployment update -n blue --endpoint $ENDPOINT_NAME -f endpoints/online/managed/sample/blue-deployment-with-registered-assets.yml
    

    La mise à jour à l’aide de YAML est déclarative. Autrement dit, les modifications apportées au YAML sont reflétées dans les ressources Resource Manager sous-jacentes (points de terminaison et déploiements). Une approche déclarative facilite les GitOps : Toutes les modifications apportées aux points de terminaison et déploiements passent (même instance_count) par le fichier YAML.

    Vous pouvez utiliser des paramètres de mise à jour génériques, tels que le paramètre --set, avec la commande CLI update pour remplacer les attributs dans votre YAML ou pour définir des attributs spécifiques sans les passer dans le fichier YAML. L’utilisation de --set pour les attributs uniques est particulièrement importante dans les scénarios de développement et de test. Par exemple, pour effectuer un scale-up de la valeur instance_count pour le premier déploiement, vous pouvez utiliser l’indicateur --set instance_count=2. Toutefois, étant donné que le code YAML n’est pas mis à jour, cette technique ne facilite pas les GitOps.

    La spécification du fichier YAML n’est pas obligatoire. Par exemple, si vous souhaitez tester différents paramètres d’accès concurrentiel pour un déploiement spécifique, vous pouvez essayer quelque chose comme az ml online-deployment update -n blue -e my-endpoint --set request_settings.max_concurrent_requests_per_instance=4 environment_variables.WORKER_COUNT=4. Cette approche conserve toutes les configurations existantes, mais met à jour uniquement les paramètres spécifiés.

  5. Étant donné que vous avez modifié la init() fonction, qui s’exécute lorsque le point de terminaison est créé ou mis à jour, le message Updated successfully apparaît dans les journaux. Récupérez les journaux en exécutant :

    az ml online-deployment get-logs --name blue --endpoint $ENDPOINT_NAME
    

La commande update fonctionne également avec les déploiements locaux. Utilisez la même commande az ml online-deployment update avec l’indicateur --local.

Notes

La mise à jour du déploiement dans cette section est un exemple de mise à jour propagée sur place.

  • Pour un point de terminaison en ligne managé, le déploiement est mis à jour vers la nouvelle configuration avec 20 % des nœuds à la fois. Autrement dit, si le déploiement a 10 nœuds, 2 nœuds à la fois sont mis à jour.
  • Pour un point de terminaison en ligne Kubernetes, le système crée de manière itérative une nouvelle instance de déploiement avec la nouvelle configuration et supprime l’ancienne.
  • Pour l’utilisation de la production, envisagez un déploiement bleu-vert, qui offre une alternative plus sûre pour la mise à jour d’un service web.

(Facultatif) Configurer la mise à l’échelle automatique

La mise à l’échelle automatique exécute automatiquement la quantité appropriée de ressources pour gérer la charge sur votre application. Les points de terminaison en ligne managés prennent en charge la mise à l’échelle automatique via l’intégration à la fonctionnalité de mise à l’échelle automatique Azure Monitor. Pour configurer la mise à l’échelle automatique, consultez Mise à l’échelle automatique de points de terminaison en ligne.

(Facultatif) Surveiller le contrat SLA à l’aide d’Azure Monitor

Pour afficher les métriques et définir des alertes en fonction de votre contrat SLA, suivez les étapes décrites dans Surveiller les points de terminaison en ligne.

(Facultatif) Intégrer à Log Analytics

La get-logs commande de l’interface CLI ou de la get_logs méthode du Kit de développement logiciel (SDK) fournit uniquement les dernières centaines de lignes de journaux d’activité d’une instance sélectionnée automatiquement. Toutefois, Log Analytics offre un moyen de stocker et d’analyser durablement les journaux. Pour plus d’informations sur l’utilisation de la journalisation, consultez Utiliser les journaux d’activité.

Supprimez le point de terminaison et le déploiement

Utilisez la commande suivante pour supprimer le point de terminaison et tous ses déploiements sous-jacents :

az ml online-endpoint delete --name $ENDPOINT_NAME --yes --no-wait