Points de terminaison et déploiements en ligne pour l’inférence en temps réel
S’APPLIQUE À :Extension Azure CLI v2 (actuelle)Kit de développement logiciel (SDK) Python azure-ai-ml v2 (version actuelle)
Azure Machine Learning vous permet d’effectuer une inférence en temps réel sur des données à l’aide de modèles déployés sur des points de terminaison en ligne. L’inférence est le processus qui consiste à appliquer de nouvelles données d’entrée à un modèle Machine Learning pour générer des sorties. Bien que ces sorties soient généralement appelées « prédictions », l’inférence peut être utilisée pour générer des sorties pour d’autres tâches d’apprentissage automatique, telles que la classification et le clustering.
Points de terminaison en ligne
Les points de terminaison en ligne déploient des modèles sur un serveur web pouvant retourner des prédictions sous le protocole HTTP. Utilisez les points de terminaison en ligne pour rendre les modèles opérationnels pour l’inférence en temps réel dans les requêtes synchrones à faible latence. Nous vous recommandons de les utiliser dans les cas suivants :
- Vous avez des exigences de faible latence
- Votre modèle peut répondre à la requête dans un laps de temps relativement court
- Les entrées de votre modèle correspondent à la charge utile HTTP de la requête
- Vous devez effectuer un scale-up au niveau du nombre de requêtes
Pour définir un point de terminaison, vous devez spécifier :
- Nom du point de terminaison : Ce nom doit être unique dans la région Azure. Pour plus d’informations sur les règles de nommage, consultez limites de point de terminaison.
- mode d’authentification: vous pouvez choisir parmi le mode d’authentification par clé, le mode d’authentification par jeton Azure Machine Learning ou l’authentification basée sur les jetons Microsoft Entra (préversion) pour le point de terminaison. Pour plus d’informations sur l’authentification, consultez S’authentifier auprès d’un point de terminaison en ligne.
Azure Machine Learning offre la commodité d’utiliser points de terminaison en ligne gérés pour déployer vos modèles Machine Learning de manière clé en main. Il s’agit de la méthode recommandée pour utiliser des points de terminaison en ligne dans Azure Machine Learning. 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. Ces points de terminaison se chargent aussi de servir, mettre à l’échelle, sécuriser et superviser vos modèles, ce qui vous évite la surcharge liée à la configuration et à la gestion de l’infrastructure sous-jacente. Pour savoir comment définir un point de terminaison en ligne managé, consultez Définir le point de terminaison.
Pourquoi choisir des points de terminaison en ligne managés plutôt qu’ACI ou AKS(v1) ?
L’utilisation de points de terminaison en ligne managés est la méthode recommandée pour utiliser des points de terminaison en ligne dans Azure Machine Learning. Le tableau suivant met en évidence les attributs clés des points de terminaison en ligne managés par rapport aux solutions SDK/CLI Azure Machine Learning v1 (ACI et AKS(v1)).
Attributs | Points de terminaison en ligne managés (v2) | ACI ou AKS(v1) |
---|---|---|
Sécurité/isolation de réseau | Contrôle entrant/sortant facile avec bascule rapide | Réseau virtuel non pris en charge ou nécessite une configuration manuelle complexe |
Service géré | - Provisionnement/mise à l’échelle du calcul complètement managé - Configuration réseau pour la prévention de l’exfiltration de données - Mise à niveau du système d’exploitation hôte, déploiement contrôlé des mises à jour sur place |
- La mise à l’échelle est limitée dans v1 - La configuration ou la mise à niveau du réseau doit être gérée par l’utilisateur |
Concept de point de terminaison/déploiement | La distinction entre point de terminaison et déploiement permet d’avoir des scénarios complexes tels que le déploiement sécurisé de modèles | Aucun concept de point de terminaison |
Diagnostics et surveillance | - Débogage de point de terminaison local possible avec Docker et Visual Studio Code - Analyse avancée des métriques et des journaux avec graphique/requête pour comparer les déploiements - Détails des coûts jusqu’au niveau du déploiement |
Pas de débogage local facile |
Évolutivité | Mise à l’échelle automatique, élastique et illimitée | - ACI n’est pas évolutif - AKS (v1) prend uniquement en charge la mise à l’échelle dans le cluster et nécessite une configuration de la scalabilité |
Préparation pour l’entreprise | Liaison privée, clés gérées par le client, Microsoft Entra ID, gestion des quotas, intégration de facturation, contrat de niveau de service | Non pris en charge |
Fonctionnalités ML avancées | - Collecte de données de modèle - Supervision des modèles - Modèle champion-challenger, déploiement sécurisé, mise en miroir du trafic - Extensibilité de l’IA responsable |
Non pris en charge |
Sinon, si vous préférez utiliser Kubernetes pour déployer vos modèles et servir des points de terminaison, et que vous êtes à l’aise avec la gestion des exigences d’infrastructure, vous pouvez utiliser des points de terminaison en ligne Kubernetes. Ces points de terminaison vous permettent de déployer des modèles et de servir des points de terminaison en ligne sur votre cluster Kubernetes entièrement configuré et managé où vous voulez, avec des processeurs CPU ou GPU.
Pourquoi choisir des points de terminaison en ligne managés plutôt qu’AKS(v2) ?
Les points de terminaison en ligne managés peuvent vous aider à simplifier votre processus de déploiement et offrent les avantages suivants par rapport aux points de terminaison en ligne Kubernetes :
Infrastructure managée
- Provisionne automatiquement le calcul et héberge le modèle (vous devez simplement spécifier les paramètres de type de machine virtuelle et de mise à l’échelle)
- Applique automatiquement les mises à jour et patchs à l’image du système d’exploitation hôte sous-jacent
- Procède automatiquement à une récupération de nœud en cas de défaillance du système
Supervision et journaux
- Supervisez la disponibilité, les performances et le SLA du modèle à l’aide de l’intégration native à Azure Monitor.
- Déboguez les déploiements à l’aide des journaux et de l’intégration native à Azure Log Analytics.
Voir les coûts
- Les points de terminaison en ligne managés vous permettent de superviser le coût au niveau du point de terminaison et du déploiement
Notes
Les points de terminaison en ligne managés sont basés sur le calcul Azure Machine Learning. Lorsque vous utilisez un point de terminaison en ligne managé, vous payez les frais de calcul et de mise en réseau. Il n’y a aucun frais supplémentaire. Pour plus d’informations sur la tarification, consultez la calculatrice de prix Azure.
Si vous utilisez un réseau virtuel Azure Machine Learning pour sécuriser le trafic sortant qui vient du point de terminaison en ligne managé, vous êtes facturé pour la liaison privée Azure et les règles de trafic sortant FQDN utilisées par le réseau virtuel managé. Pour plus d’informations, consultez Tarification des réseaux virtuels managés.
Points de terminaison en ligne managés ou points de terminaison en ligne Kubernetes
Le tableau suivant met en évidence les principales différences entre les points de terminaison en ligne managés et les points de terminaison en ligne Kubernetes.
Points de terminaison en ligne managés | Points de terminaison en ligne Kubernetes (AKS(v2)) | |
---|---|---|
Utilisateurs concernés | Utilisateurs qui souhaitent un déploiement de modèle managé et une expérience MLOps améliorée | Utilisateurs qui préfèrent Kubernetes et peuvent autogérer les exigences d’infrastructure |
Approvisionnement de nœuds | Approvisionnement, mise à jour, suppression du calcul managé | Responsabilité de l’utilisateur |
Maintenance de nœuds | Mises à jour d’images managées d’un système d’exploitation hôte et renforcement de la sécurité | Responsabilité de l’utilisateur |
Dimensionnement du cluster (mise à l’échelle) | Mise à l’échelle automatique et manuelle managée, prise en charge de l’approvisionnement de nœuds supplémentaires | Mise à l’échelle automatique et manuelle, prise en charge de la mise à l’échelle du nombre de réplicas dans les limites fixes du cluster |
Type de capacité de calcul | Géré par le service | Clusters Kubernetes managés par les clients (Kubernetes) |
Identité gérée | Pris en charge | Prise en charge |
Réseau virtuel (VNet) | Pris en charge via l’isolation réseau managée | Responsabilité de l’utilisateur |
Surveillance et journalisation prêtes à l’emploi | Azure Monitor et Log Analytics optimisés (inclut des métriques clés et des tables de journaux pour les points de terminaison et les déploiements) | Responsabilité de l’utilisateur |
Journalisation avec Application Insights (héritée) | Prise en charge | Prise en charge |
Visualisation des coûts | Détaillé au niveau du point de terminaison/du déploiement | Au niveau du cluster |
Coût appliqué à | Machines virtuelles affectées aux déploiements | Machines virtuelles affectées au cluster |
Trafic en miroir | Pris en charge | Non pris en charge |
Déploiement sans code | Pris en charge (modèles MLflow et Triton) | Pris en charge (modèles MLflow et Triton) |
Déploiements en ligne
Un déploiement est un ensemble de ressources et de calculs nécessaires pour héberger le modèle qui effectue l’inférence réelle. Un seul point de terminaison peut contenir plusieurs déploiements avec différentes configurations. Cette configuration permet de dissocier l’interface présentée par le point de terminaison des détails d’implémentation présents dans le déploiement. Un point de terminaison en ligne a un mécanisme de routage qui peut diriger les requêtes vers des déploiements spécifiques dans le point de terminaison.
Le diagramme suivant montre un point de terminaison en ligne qui a deux déploiements : bleu et vert. Le déploiement bleu utilise des machines virtuelles avec une référence de processeur et exécute la version 1 d’un modèle. Le déploiement vert utilise des machines virtuelles avec une référence SKU GPU et exécute la version 2 du modèle. Le point de terminaison est configuré pour acheminer 90 % du trafic entrant vers le déploiement bleu, tandis que le déploiement vert reçoit les 10 % restants.
Pour déployer un modèle, vous devez disposer des éléments suivants :
- Fichiers de modèle (ou le nom et la version d’un modèle déjà inscrit dans votre espace de travail).
- Un script de scoring, c’est-à-dire du code qui exécute le modèle sur une demande d’entrée donnée. Le script de scoring reçoit les données envoyées à un service web déployé et les passe au modèle. Le script exécute ensuite le modèle et retourne sa réponse au client. Le script de scoring est spécifique à votre modèle. Il doit comprendre les données que le modèle attend en tant qu’entrée et retourne en tant que sortie.
- Environnement dans lequel votre modèle s’exécute. L’environnement peut être une image Docker avec des dépendances Conda ou un Dockerfile.
- Paramètres pour spécifier le type d’instance et capacité de mise à l’échelle.
Attributs clés d’un déploiement
Le tableau suivant décrit les attributs clés d’un déploiement :
Attribut | Description |
---|---|
Nom | Le nom du déploiement. |
Nom du point de terminaison | Nom du point de terminaison sous lequel créer le déploiement. |
Model1 | Modèle à utiliser pour le déploiement. Cette valeur peut être une référence à un modèle versionné existant dans l’espace de travail ou une spécification de modèle inline. Pour plus d’informations sur le suivi et la spécification du chemin d’accès à votre modèle, consultez Identifier le chemin d’accès au modèle par rapport à AZUREML_MODEL_DIR . |
Chemin du code | Le chemin d’accès du répertoire dans l’environnement de développement local qui contient tout le code source Python pour le scoring du modèle. Vous pouvez utiliser des répertoires et des packages imbriqués. |
Script de scoring | Le chemin relatif du fichier de scoring dans le répertoire de code source. Ce code Python doit avoir une fonction init() et une fonction run() . La fonction init() sera appelée une fois le modèle créé ou mis à jour (vous pouvez l’utiliser pour mettre en cache le modèle dans la mémoire, par exemple). La fonction run() est appelée à chaque appel du point de terminaison pour effectuer la notation et la prédiction réelles. |
Environnement1 | L’environnement pour héberger le modèle et le code. Cette valeur peut être une référence à un environnement versionné existant dans l’espace de travail ou une spécification d’environnement inline. Remarque : Microsoft corrige régulièrement les images de base pour les vulnérabilités de sécurité connues. Vous devez redéployer votre point de terminaison pour utiliser l’image corrigée. Si vous fournissez votre propre image, vous êtes chargé de la mettre à jour. Pour plus d’informations, consultez Mise à jour corrective des images. |
Type d’instance | Taille de machine virtuelle à utiliser pour le déploiement. Pour obtenir la liste des tailles prises en charge, consultez la liste des références SKU des points de terminaison en ligne managés. |
Nombre d’instances | Nombre d’instances à utiliser pour le déploiement. Basez la valeur sur la charge de travail que vous attendez. Pour une haute disponibilité, nous vous recommandons de définir la valeur sur au moins 3 . Nous réservons 20 % en plus pour effectuer des mises à niveau. Pour plus d’informations, consultez allocation de quota du nombre de machines virtuelles pour les déploiements. |
1 Quelques points à noter sur le modèle et l’environnement :
- Le modèle et l’image conteneur (tels que définis dans Environnement) peuvent être référencés à nouveau à tout moment par le déploiement lorsque les instances derrière le déploiement passent par des correctifs de sécurité et/ou d’autres opérations de récupération. Si vous utilisez un modèle inscrit ou une image conteneur dans Azure Container Registry pour le déploiement et supprimez le modèle ou l’image conteneur, les déploiements qui s’appuient sur ces ressources peuvent échouer lorsque la réimagerie se produit. Si vous supprimez le modèle ou l’image conteneur, vérifiez que les déploiements dépendants sont recréé ou mis à jour avec un autre modèle ou image conteneur.
- Le registre de conteneurs auquel l’environnement fait référence ne peut être privé que si l’identité du point de terminaison a l’autorisation d’y accéder via l’authentification Microsoft Entra et Azure RBAC. Pour la même raison, les registres Docker privés autres que Azure Container Registry ne sont pas pris en charge.
Pour savoir comment déployer des points de terminaison en ligne à l’aide de l’interface CLI, du SDK, du studio et du modèle ARM, consultez Déployer un modèle ML avec un point de terminaison en ligne.
Identifier le chemin d’accès du modèle par rapport à AZUREML_MODEL_DIR
Lors du déploiement de votre modèle sur Azure Machine Learning, vous devez spécifier l’emplacement du modèle que vous souhaitez déployer dans le cadre de votre configuration de déploiement. Dans Azure Machine Learning, utilisez la variable d’environnement AZUREML_MODEL_DIR
pour suivre le chemin d’accès à votre modèle. En identifiant le chemin d’accès du modèle par rapport à AZUREML_MODEL_DIR
, vous pouvez déployer un ou plusieurs modèles stockés localement sur votre ordinateur ou déployer un modèle inscrit dans votre espace de travail Azure Machine Learning.
À titre d’illustration, nous faisons référence à la structure de dossiers locale suivante pour les deux premiers cas où vous déployez un modèle unique ou plusieurs modèles stockés localement :
Utiliser un modèle local unique dans un déploiement
Pour utiliser un modèle unique qui se trouve sur votre ordinateur local dans un déploiement, spécifiez le path
au model
dans votre fichier YAML de déploiement. Voici un exemple de fichier YAML de déploiement avec le chemin d’accès /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
Une fois votre déploiement créé, la variable d’environnement AZUREML_MODEL_DIR
pointe vers l’emplacement de stockage Azure où votre modèle est stocké. Par exemple, /var/azureml-app/azureml-models/81b3c48bbf62360c7edbbe9b280b9025/1
contient le modèle sample_m1.pkl
.
Dans votre script de scoring (score.py
), vous pouvez charger votre modèle (ici, sample_m1.pkl
) dans la fonction init()
:
def init():
model_path = os.path.join(str(os.getenv("AZUREML_MODEL_DIR")), "sample_m1.pkl")
model = joblib.load(model_path)
Utiliser plusieurs modèles locaux dans un déploiement
Même si Azure CLI, le Kit de développement logiciel (SDK) Python et d’autres outils clients ne vous laissent spécifier qu’un seul modèle par déploiement dans la définition du déploiement, vous pouvez toujours utiliser plusieurs modèles dans un déploiement en inscrivant un dossier de modèles contenant tous les modèles en tant que fichiers ou sous-répertoires.
Dans l’exemple de structure de dossiers précédent, notez la présence de plusieurs modèles dans le dossier models
. Dans votre fichier YAML de déploiement, vous pouvez spécifier le chemin d’accès au dossier models
comme suit :
$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
Une fois votre déploiement créé, la variable d’environnement AZUREML_MODEL_DIR
pointe vers l’emplacement de stockage Azure où vos modèles sont stockés. Par exemple, /var/azureml-app/azureml-models/81b3c48bbf62360c7edbbe9b280b9025/1
contient les modèles et la structure de fichiers.
Pour cet exemple, le contenu du dossier AZUREML_MODEL_DIR
se présente comme suit :
Dans votre script de scoring (score.py
), vous pouvez charger vos modèles dans la fonction init()
. Le code suivant charge le modèle sample_m1.pkl
:
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)
Pour obtenir un exemple de déploiement de plusieurs modèles dans un même déploiement, consultez Déployer plusieurs modèles dans un même déploiement (exemple CLI) et Déployer plusieurs modèles dans un même déploiement (exemple SDK).
Conseil
Si vous avez plus de 1 500 fichiers à inscrire, envisagez de compresser les fichiers ou sous-répertoires au format .tar.gz lors de l’inscription des modèles. Pour consommer les modèles, vous pouvez décompresser les fichiers ou sous-répertoires dans la fonction init()
du script de scoring. Sinon, quand vous inscrivez les modèles, définissez la propriété azureml.unpack
sur True
pour décompresser automatiquement les fichiers ou sous-répertoires. Dans les deux cas, la décompression se produit une fois dans l’étape d’initialisation.
Utiliser des modèles inscrits dans votre espace de travail Azure Machine Learning dans un déploiement
Pour utiliser un ou plusieurs modèles inscrits dans votre espace de travail Azure Machine Learning, spécifiez dans votre déploiement le nom du ou des modèles inscrits dans votre fichier YAML de déploiement. Par exemple, la configuration YAML de déploiement suivante spécifie azureml:local-multimodel:3
comme nom de model
inscrit :
$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
Pour cet exemple, considérez que local-multimodel:3
contient les artefacts de modèle suivants, que vous pouvez voir sous l’onglet Modèles dans Azure Machine Learning studio :
Une fois votre déploiement créé, la variable d’environnement AZUREML_MODEL_DIR
pointe vers l’emplacement de stockage Azure où vos modèles sont stockés. Par exemple, /var/azureml-app/azureml-models/local-multimodel/3
contient les modèles et la structure de fichiers. AZUREML_MODEL_DIR
pointe vers le dossier contenant la racine des artefacts de modèle.
Dans cet exemple, le contenu du dossier AZUREML_MODEL_DIR
se présente comme suit :
Dans votre script de scoring (score.py
), vous pouvez charger vos modèles dans la fonction init()
. Par exemple, chargez le modèle 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)
Allocation de quota du nombre de machines virtuelles pour le déploiement
Azure Machine Learning réserve 20 % de vos ressources de calcul pour les points de terminaison en ligne managés afin d’exécuter des mises à niveau sur certaines références SKU de machine virtuelle. Si vous demandez un nombre donné d’instances pour ces références SKU de machines virtuelles dans un déploiement, vous devez disposer d’un quota de ceil(1.2 * number of instances requested for deployment) * number of cores for the VM SKU
pour éviter d’obtenir une erreur. Par exemple, si vous demandez 10 instances d’une machine virtuelle Standard_DS3_v2 (qui comprend quatre cœurs) dans un déploiement, vous devez disposer d’un quota de 48 cœurs (12 instances * 4 cores
) disponibles. Ce quota supplémentaire est réservé aux opérations initiées par le système, telles que les mises à niveau du système d’exploitation et la récupération de machine virtuelle, et elle n’entraîne pas de coûts, sauf si ces opérations s’exécutent.
Certaines références SKU de machine virtuelle sont exemptées d’une réservation de quota supplémentaire. Pour afficher la liste complète, consultez la liste des références SKU de points de terminaison en ligne managés.
Pour afficher votre utilisation et demander des augmentations de quota, consultez Afficher votre utilisation et vos quotas dans le Portail Azure. Pour afficher votre coût d’exécution d’un point de terminaison en ligne managé, consultez Afficher les coûts d’un point de terminaison en ligne managé.
Azure Machine Learning fournit un pool de quotas partagé à partir duquel tous les utilisateurs peuvent accéder au quota pour effectuer des tests pendant une période limitée. Lorsque vous utilisez le studio pour déployer des modèles Llama (à partir du catalogue de modèles) vers un point de terminaison en ligne managé, Azure Machine Learning vous permet d’accéder à ce quota partagé pendant une courte période.
Toutefois, pour déployer un modèle Llama-2-70b ou Llama-2-70b-chat vous devez disposer d’un abonnement Accord Entreprise avant de pouvoir déployer à l’aide du quota partagé. Pour plus d’informations sur l’utilisation du quota partagé pour le déploiement de points de terminaison en ligne, consultez le Guide pratique pour déployer des modèles de base à l’aide du studio.
Pour plus d’informations sur les quotas et les limites des ressources dans Azure Machine Learning, consultez Gérer et augmenter les quotas et les limites des ressources avec Azure Machine Learning.
Déploiement pour les codeurs et les non-codeurs
Azure Machine Learning prend en charge le déploiement de modèles sur des points de terminaison en ligne pour les codeurs et les non-codeurs, en fournissant des options pour les déploiements no-code, les déploiements low-code et les déploiements BYOC (Bring Your Own Container).
- Le déploiement no-code fournit une inférence prête à l’emploi pour les frameworks courants (par exemple, scikit-learn, TensorFlow, PyTorch et ONNX) via MLflow et Triton.
- Déploiement à faible code vous permet de fournir un code minimal, ainsi que votre modèle Machine Learning pour le déploiement.
- Le déploiement BYOC vous permet d’apporter virtuellement tous les conteneurs pour exécuter votre point de terminaison en ligne. Vous pouvez utiliser toutes les fonctionnalités de la plateforme Azure Machine Learning, telles que la mise à l’échelle automatique, GitOps, le débogage et le déploiement sécurisé pour gérer vos pipelines MLOps.
Le tableau suivant met en évidence les principaux aspects des options de déploiement en ligne :
Sans code | Faible quantité de code | BYOC | |
---|---|---|---|
Résumé | Utilise l’inférence prête à l’emploi des frameworks connus, tels que scikit-learn, TensorFlow, PyTorch et ONNX, via MLflow et Triton. Pour plus d’informations, consultez Déployer des modèles MLflow sur des points de terminaison en ligne. | Utilise les images organisées sécurisées et publiées des frameworks connus, avec des mises à jour toutes les deux semaines pour corriger les vulnérabilités. Vous fournissez un script de scoring et/ou des dépendances Python. Pour plus d’informations, consultez Environnements organisés Azure Machine Learning. | Vous fournissez votre pile complète via la prise en charge d’Azure Machine Learning des images personnalisées. Pour plus d’informations, consultez Utiliser un conteneur personnalisé pour déployer un modèle sur un point de terminaison en ligne. |
Image de base personnalisée | Non, l’environnement organisé fournit cela pour faciliter le déploiement. | Oui et non, vous pouvez utiliser une image organisée ou votre image personnalisée. | Oui, apportez un emplacement d’image conteneur accessible, par exemple, docker.io, Azure Container Registry (ACR) ou Microsoft Container Registry (MCR), ou un dockerfile que vous pouvez créer/pousser avec ACR pour votre conteneur. |
Dépendances personnalisées | Non, l’environnement organisé fournit cela pour faciliter le déploiement. | Oui, apportez l’environnement Azure Machine Learning dans lequel le modèle s’exécute, soit une image Docker avec des dépendances Conda, soit un dockerfile. | Oui, cela est compris dans l’image conteneur. |
Code personnalisé | Non, le script de scoring est généré automatiquement pour faciliter le déploiement. | Oui, apportez votre script de scoring. | Oui, cela est compris dans l’image conteneur. |
Remarque
Les exécutions AutoML créent automatiquement un script de scoring et des dépendances pour les utilisateurs, ce qui vous permet de déployer un modèle AutoML sans créer de code supplémentaire (pour un déploiement no-code) ou de modifier les scripts générés automatiquement en fonction de vos besoins métier (pour un déploiement low-code). Pour savoir comment déployer avec des modèles AutoML, consultez Déployer un modèle AutoML avec un point de terminaison en ligne.
Débogage de points de terminaison en ligne
Nous vous recommandons vivement que vous testez votre point de terminaison localement pour valider et déboguer votre code et votre configuration avant de déployer sur Azure. L’interface Azure CLI et le SDK Python prennent en charge les points de terminaison et les déploiements locaux, contrairement à Azure Machine Learning studio et au modèle ARM.
Azure Machine Learning offre différents moyens de déboguer des points de terminaison en ligne localement et à l’aide des journaux de conteneur.
- Débogage local avec un serveur HTTP d’inférence Azure Machine Learning
- Débogage local avec un point de terminaison local
- Débogage local avec un point de terminaison local et Visual Studio Code
- Débogage avec des journaux de conteneur
Débogage local avec un serveur HTTP d’inférence Azure Machine Learning
Vous pouvez déboguer votre script de scoring localement à l’aide du serveur HTTP d’inférence Azure Machine Learning. Le serveur HTTP est un package Python qui expose votre fonction de scoring en tant que point de terminaison HTTP, et enveloppe le code et les dépendances du serveur Flask dans un même package. Il est inclus dans les images conteneur Docker prédéfinies pour l’inférence qui sont utilisées lors du déploiement d’un modèle avec Azure Machine Learning. En utilisant le package seul, vous pouvez déployer le modèle localement pour la production, et vous pouvez aussi valider facilement votre script de scoring (entrée) dans un environnement de développement local. En cas de problème avec le script de scoring, le serveur retourne une erreur et l’emplacement où l’erreur s’est produite. Vous pouvez également utiliser Visual Studio Code pour déboguer avec le serveur HTTP d’inférence Azure Machine Learning.
Conseil
Vous pouvez utiliser le package Python du serveur HTTP d’inférence Azure Machine Learning pour déboguer votre script de scoring localement sansdu moteur Docker. Le débogage avec le serveur d’inférence vous aide à déboguer le script de scoring avant le déploiement sur des points de terminaison locaux afin de pouvoir déboguer sans être affecté par les configurations de conteneur de déploiement.
Pour en savoir plus sur le débogage avec le serveur HTTP, consultez Débogage du script de scoring avec le serveur HTTP d’inférence Azure Machine Learning.
Débogage local avec un point de terminaison local
Pour le débogage local, vous avez besoin d’un déploiement local, c’est-à-dire d’un modèle déployé dans un environnement Docker local. Vous pouvez utiliser ce déploiement local pour le test et le débogage avant le déploiement dans le cloud. Pour déployer localement, vous devez installer et exécuter Docker Engine. Azure Machine Learning crée ensuite une image Docker locale qui reproduit l’image Azure Machine Learning. Azure Machine Learning génère et exécute les déploiements pour vous localement et met l’image en cache pour des itérations rapides.
Conseil
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 des outils côté client comme Docker Desktop pour déboguer les événements dans le conteneur.
Les étapes d’un débogage local sont généralement les suivantes :
- Vérifier si le déploiement local a réussi
- Appeler le point de terminaison local pour l’inférence
- Rechercher dans les journaux la sortie de l’opération d’appel
Remarque
Les points de terminaison locaux présentent les limitations suivantes :
- Ils ne prennent pas en charge les règles de trafic, l’authentification et les paramètres de sonde.
- Ils ne prennent en charge qu’un seul déploiement par point de terminaison.
- Ils prennent uniquement en charge les fichiers de modèle local et l’environnement avec un fichier conda local. Si vous souhaitez tester des modèles inscrits, commencez par les télécharger à l’aide de l’interface CLI ou du SDK, puis utilisez
path
dans la définition de déploiement pour faire référence au dossier parent. Si vous souhaitez tester des environnements inscrits, vérifiez le contexte de l’environnement dans Azure Machine Learning Studio et préparez un fichier conda local à utiliser.
Pour en savoir plus sur le débogage local, consultez Déployer et déboguer localement à l’aide d’un point de terminaison local.
Débogage local avec un point de terminaison local et Visual Studio Code (préversion)
Important
Cette fonctionnalité est actuellement disponible en préversion publique. Cette préversion est fournie sans contrat de niveau de service et n’est pas recommandée pour les charges de travail de production. Certaines fonctionnalités peuvent être limitées ou non prises en charge.
Pour plus d’informations, consultez Conditions d’Utilisation Supplémentaires relatives aux Évaluations Microsoft Azure.
Comme pour le débogage local, vous devez d’abord installer et exécuter Docker Engine, puis déployer un modèle dans l’environnement Docker local. Une fois que vous avez un déploiement local, les points de terminaison locaux Azure Machine Learning utilisent les conteneurs de développement Docker et Visual Studio Code (conteneurs de développement) pour créer et configurer un environnement de débogage local. Avec les conteneurs de développement, vous pouvez tirer parti des fonctionnalités de Visual Studio Code, telles que le débogage interactif, au sein d’un conteneur Docker.
Pour en savoir plus sur le débogage interactif de points de terminaison en ligne dans VS Code, consultez Déboguer des points de terminaison en ligne localement dans Visual Studio Code.
Débogage avec les journaux de conteneur
Pour un déploiement, vous ne pouvez pas accéder directement à la machine virtuelle sur laquelle le modèle est déployé. Toutefois, vous pouvez obtenir les journaux de certains des conteneurs qui s’exécutent sur la machine virtuelle. Il existe deux types de conteneurs à partir lesquels vous pouvez obtenir les journaux :
- Serveur d’inférence : Les journaux incluent le journal de console (à partir du serveur d’inférence) qui contient la sortie des fonctions d’affichage/de journalisation de votre script de scoring (code
score.py
). - Initialiseur de stockage : Les journaux contiennent des informations indiquant si le code et les données de modèle ont été correctement téléchargés dans le conteneur. Le conteneur s’exécute avant que le conteneur du serveur d’inférence ne commence à s’exécuter.
Pour en savoir plus sur le débogage avec les journaux de conteneur, consultez Obtenir les journaux de conteneur.
Routage et mise en miroir du trafic vers les déploiements en ligne
Rappelez-vous qu’un seul point de terminaison en ligne peut avoir plusieurs déploiements. À mesure que le point de terminaison reçoit le trafic entrant (ou les requêtes), il peut router des pourcentages de trafic vers chaque déploiement, comme utilisé dans la stratégie de déploiement bleu/vert natif. Il peut aussi mettre en miroir (ou copier) le trafic d’un déploiement vers un autre, également appelé mise en miroir ou mise en mémoire fantôme du trafic.
Routage du trafic pour le déploiement bleu/vert
Le déploiement bleu/vert est une stratégie de déploiement qui vous permet de déployer un nouveau déploiement (le déploiement vert) sur un petit sous-ensemble d’utilisateurs ou de requêtes avant de le déployer complètement. Le point de terminaison peut implémenter un équilibrage de charge pour allouer certains pourcentages du trafic à chaque déploiement, avec une allocation totale entre tous les déploiements qui atteint 100 %.
Conseil
Une requête peut contourner l’équilibrage de charge du trafic configuré en incluant un en-tête HTTP de azureml-model-deployment
. Définissez la valeur d’en-tête sur le nom du déploiement auquel vous souhaitez que la requête soit acheminée.
L’image suivante montre les paramètres dans Azure Machine Learning studio pour l’allocation du trafic entre un déploiement bleu et vert.
Cette allocation de trafic route le trafic, comme illustré dans l’image suivante, avec 10 % du trafic vers le déploiement vert et 90 % du trafic vers le déploiement bleu.
Mise en miroir du trafic vers les déploiements en ligne
Le point de terminaison peut également mettre en miroir (ou copier) le trafic d’un déploiement vers un autre. La mise en miroir du trafic (également appelée test fantôme) est utile lorsque vous souhaitez tester un nouveau déploiement avec le trafic de production sans affecter les résultats que les clients reçoivent des déploiements existants. Par exemple, lors de l’implémentation d’un déploiement bleu/vert où 100 % du trafic est routé vers le déploiement bleu et 10 % est mis en miroir vers le déploiement vert, les résultats du trafic mis en miroir vers le déploiement vert ne sont pas retournés aux clients, mais les métriques et les journaux sont enregistrés.
Pour savoir comment utiliser la mise en miroir du trafic, consultez Déploiement sécurisé pour les points de terminaison en ligne.
Autres fonctionnalités des points de terminaison en ligne dans Azure Machine Learning
Authentification et chiffrement
- Authentification : clés et jetons Azure Machine Learning
- Identité managée : affectée par l’utilisateur et par le système
- SSL par défaut pour l’appel de point de terminaison
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 gérés prennent en charge la mise à l’échelle automatique via l’intégration à la fonctionnalité de mise à l’échelle automatique d’Azure Monitor. Vous pouvez configurer la mise à l’échelle basée sur les métriques (par exemple utilisation du processeur > 70 %), la mise à l’échelle basée sur la planification (par exemple les règles de mise à l’échelle pour les heures de pointe) ou une combinaison des deux.
Pour savoir comment configurer la mise à l’échelle automatique, consultez Guide pratique pour mettre à l’échelle automatiquement des points de terminaison en ligne.
Isolation de réseau gérée
Quand vous déployez un modèle Machine Learning sur un point de terminaison en ligne managé, vous pouvez sécuriser les communications avec ce point de terminaison en ligne au moyen de points de terminaison privés.
Vous pouvez configurer la sécurité pour les demandes de scoring entrantes et les communications sortantes avec l’espace de travail et d’autres services séparément. Les communications entrantes utilisent le point de terminaison privé de l’espace de travail Azure Machine Learning. Les communications sortantes utilisent des points de terminaison privés créés pour le réseau virtuel managé de l’espace de travail.
Pour plus d’informations, consultez Isolement réseau avec des points de terminaison en ligne managés.
Surveillance des déploiements et des points de terminaison en ligne
La surveillance des points de terminaison Azure Machine Learning est possible via l’intégration d’Azure Monitor. Cette intégration vous permet d’afficher les métriques dans des graphiques, de configurer des alertes, d’interroger à partir de tables de journal, d’utiliser Application Insights pour analyser les événements des conteneurs utilisateur, etc.
Métriques : Utilisez Azure Monitor pour suivre diverses métriques de point de terminaison, telles que la latence des requêtes, et pour explorer jusqu’au niveau du déploiement ou de l’état. Vous pouvez également suivre les métriques au niveau du déploiement, telles que l’utilisation du CPU/GPU, et descendre jusqu’au niveau de l’instance. Azure Monitor vous permet de suivre ces métriques dans des graphiques et de configurer des tableaux de bord et des alertes pour une analyse plus approfondie.
Journaux : Envoyez des métriques à l’espace de travail Log Analytics, où vous pouvez interroger les journaux à l’aide de la syntaxe de requête Kusto. Vous pouvez également envoyer des métriques au compte de stockage et/ou à Event Hubs pour un traitement plus approfondi. Vous pouvez aussi utiliser des tables de journal dédiées pour les événements liés aux points de terminaison en ligne, le trafic et les journaux de conteneur. Une requête Kusto permet une analyse complexe qui joint plusieurs tables.
Application Insights : Les environnements organisés incluent l’intégration d’Application Insights, que vous pouvez activer/désactiver lorsque vous créez un déploiement en ligne. Les métriques et journaux intégrés sont envoyés à Application Insights, dont vous pouvez utiliser les fonctionnalités intégrées, telles que Métriques en direct, Recherche de transactions, Échecs et Performances, pour une analyse plus approfondie.
Pour plus d’informations sur la surveillance, consultez Surveiller les points de terminaison en ligne.
Injection de secrets dans les déploiements en ligne (préversion)
L’injection de secrets dans le contexte d’un déploiement en ligne est un processus de récupération de secrets (tels que des clés API) à partir de magasins de secrets et leur injection dans votre conteneur utilisateur qui s’exécute dans un déploiement en ligne. Les secrets seront ensuite accessibles par le biais de variables d’environnement, ce qui leur permet d’être consommés par le serveur d’inférence qui exécute votre script de scoring ou par la pile d’inférence que vous apportez avec une approche de déploiement BYOC (apportez votre propre conteneur).
Il existe deux manières d’injecter des secrets. Vous pouvez injecter des secrets vous-même, à l’aide d’identités managées ou utiliser la fonctionnalité d’injection de secrets. Pour en savoir plus sur les façons d’injecter des secrets, consultez Injection de secrets dans les points de terminaison en ligne (préversion).
Étapes suivantes
- Comment déployer des points de terminaison en ligne managés avec Azure CLI et le SDK Python
- Comment déployer des points de terminaison de lots managés avec Azure CLI et le SDK Python
- Utiliser l’isolement réseau avec les points de terminaison en ligne managés
- Déployer des modèles avec REST
- Guide pratique pour superviser des points de terminaison en ligne managés
- Comment afficher les coûts des points de terminaison en ligne managés
- Gérer et augmenter les quotas pour les ressources avec Azure Machine Learning
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de l’année 2024, nous abandonnerons progressivement le mécanisme de retour d’information GitHub Issues pour le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez :Soumettre et afficher des commentaires pour