Mettre à niveau vers v2
La version 2 des API REST d’Azure Machine Learning, de l’extension Azure CLI et du SDK Python introduisent de la cohérence et un ensemble de nouvelles fonctionnalités pour accélérer le cycle de vie du Machine Learning de production. Cet article fournit une présentation de la mise à niveau vers la version 2 avec des recommandations pour vous aider à choisir v2, v1 ou les deux.
Prérequis
- Connaissance générale d’Azure Machine Learning et du kit SDK Python v1.
- Comprendre ce qu’est la version 2.
Ai-je intérêt à utiliser la version 2 ?
Vous avez tout intérêt à utiliser la version 2 si vous commencez un nouveau projet ou flux de travail d’apprentissage automatique. Vous devriez utiliser la version v2 si vous souhaitez bénéficier des nouvelles fonctionnalités de celle-ci. Cette API offre les fonctionnalités suivantes :
- Inférence managée
- Composants réutilisables dans les pipelines
- Planification améliorée des pipelines
- Tableau de bord de l’IA responsable
- Registre des ressources
Un nouveau projet v2 peut réutiliser des ressources v1 existantes, telles que des espaces de travail et des ressources de calcul et de ressources existantes telles que des modèles et des environnements créés à l’aide de v1.
Voici quelques lacunes de fonctionnalités dans la version v2 :
- Prise en charge Spark dans les travaux : il est actuellement en préversion dans v2.
- Publication des travaux (pipelines dans la version 1) en tant que points de terminaison. Vous pouvez toutefois planifier des pipelines sans publication.
- Prise en charge des magasins de données de base de données/SQL.
- Possibilité d’utiliser des composants prédéfinis classiques dans le concepteur avec la version v2.
Vous devez ensuite vérifier que les fonctionnalités dont vous avez besoin dans la version 2 répondent aux besoins de votre organisation, comme le fait d’être en disponibilité générale.
Important
Les nouvelles fonctionnalités d’Azure Machine Learning ne seront lancées que dans la version 2.
Quelle API de version 2 dois-je utiliser ?
Dans la version 2, plusieurs interfaces sont disponibles via l’API REST, l’interface CLI et le kit SDK Python. L’interface que vous devez utiliser dépend de votre scénario et de vos préférences.
| API | Notes |
|---|---|
| REST | Peu de dépendances et de surcharges. Utilisé pour créer des applications sur Azure Machine Learning en tant que plateforme, directement dans les langages de programmation sans SDK fourni ou par préférence personnelle. |
| Interface de ligne de commande | Recommandé pour l’automatisation avec CI/CD ou préférence personnelle. Permet une itération rapide avec des fichiers YAML et une séparation simple entre le code Azure Machine Learning et le code du modèle ML. |
| Kit de développement logiciel (SDK) Python | Recommandé pour les scripts complexes (par exemple, ceux qui génèrent par programmation des travaux de pipeline volumineux) ou préférence personnelle. Permet une itération rapide avec des fichiers YAML ou un développement uniquement en Python. |
Mappage du Kit de développement logiciel (SDK) Python v1 à v2
Consultez chacun des articles suivants pour obtenir un mappage de code de comparaison pour sdk v1 et v2.
| Ressources et composants | Article |
|---|---|
| Espace de travail | gestion de l’espace de travail dans sdk v1 et SDK v2 |
| Magasins de données | gestion des magasins de données dans le kit SDK v1 et sdk v2 |
| Données | ressources de donnéesdans le Kit de développement logiciel (SDK) v1 et v2 |
| Compute | gestion du calcul dans le kit SDK v1 et le SDK v2 |
| Formation | Exécuter un script |
| Formation | Exécutions locales |
| Formation | Optimisation des hyperparamètres |
| Formation | Exécution parallèle |
| Formation | Pipelines |
| Formation | AutoML |
| Modèles | Gestion des modèles dans sdk v1 et SDK v2 |
| Déploiement | Mettre à niveau des points de terminaison de déploiement vers le kit sdk v2 |
Ressources et composants dans v1 et v2
Cette section fournit une vue d’ensemble des ressources et ressources spécifiques d’Azure Machine Learning. Consultez l’article présentant le concept de chaque entité pour savoir comment les utiliser dans la version 2.
Espace de travail
Vous n’avez pas besoin d’effectuer la mise à niveau des espaces de travail vers la version 2. Vous pouvez utiliser le même espace de travail, que vous utilisiez la version 1 ou la version 2.
Si vous créez des espaces de travail à l’aide de l’automatisation, envisagez de mettre à niveau le code de création d’un espace de travail vers la version 2. En règle générale, les ressources Azure sont gérées via Azure Resource Manager (et Bicep) ou des outils de provisionnement de ressources similaires. Vous pouvez également utiliser l’interface CLI (v2) et des fichiers YAML.
Pour une comparaison de code des kits de développement logiciel (SDK) v1 et v2, consultez Gestion de l’espace de travail dans les kits de développement logiciel (SDK) v1 et v2.
Important
Si votre espace de travail utilise un point de terminaison privé, l’indicateur v1_legacy_mode est automatiquement activé, ce qui empêche l’utilisation des API de version 2. Pour plus d’informations, consulter Configurer l’isolation réseau avec la version 2.
Connexion (connexion d’espace de travail dans la version 1)
Les connexions d’espace de travail de la version 1 sont préservées dans l’espace de travail et entièrement disponibles avec la version 2.
Pour une comparaison de code des kits de développement logiciel (SDK) v1 et v2, consultez Gestion de l’espace de travail dans les kits de développement logiciel (SDK) v1 et v2.
Magasin de données
Les types de magasins de données de stockage d’objets créés avec la version 1 sont entièrement disponibles pour une utilisation dans la version 2. Les magasins de données de base de données ne sont pas pris en charge ; le chemin de migration recommandé est une exportation vers le stockage d’objets (généralement Blob Azure).
Pour une comparaison de code des kits de développement logiciel (SDK) v1 et v2, consultez Gestion du magasin de données dans les kits de développement logiciel (SDK) v1 et v2.
Données (jeux de données dans la version 1)
Les jeux de données sont renommés éléments de données. La compatibilité descendante est fournie, ce qui signifie que vous pouvez utiliser des jeux de données de la version v1 dans la version v2. Lorsque vous utilisez un jeu de données de version v1 dans un travail de version v2, vous remarquerez qu’ils sont automatiquement mappés à des types V2 comme suit :
- V1 FileDataset = V2 Folder (
uri_folder) - V1 TabularDataset = V2 Table (
mltable)
Il convient de noter que la compatibilité ascendante n’étant pas fournie, vous ne pouvez pas utiliser des ressources de données de version v2 dans la version v1.
L’article suivant fournit plus détails sur la gestion des données dans la version v2 : Lire et écrire des données dans un travail
Pour une comparaison de code des kits de développement logiciel (SDK) v1 et v2, consultez Ressources de données dans les kits de développement logiciel (SDK) v1 et v2.
Compute
Le calcul de type AmlCompute et ComputeInstance est entièrement disponible pour une utilisation dans la version 2.
Pour une comparaison de code des kits de développement logiciel (SDK) v1 et v2, consultez Gestion du calcul dans les kits de développement logiciel (SDK) v1 et v2.
Travaux (expériences, exécutions, pipelines dans la version 1)
Dans la version 2, les « expériences », les « exécutions » et les « pipelines » sont regroupés dans des travaux. Un travail possède un type. La plupart d’entre eux sont des travaux command qui exécutent une commande, comme python main.py. Ce qui s’exécute dans un travail est indépendant du langage de programmation. Vous pouvez donc exécuter des scripts bash, appeler des interpréteurs python, exécuter un ensemble de commandes curl ou toute autre chose. Tout aussi courant est le type de travail pipeline. Il définit les travaux enfants qui peuvent avoir des relations d’entrée/sortie, formant un graphe orienté acyclique (DAG).
Pour une comparaison de code des kits de développement logiciel (SDK) v1 et v2, consultez
- Exécuter un script
- Exécutions locales
- Optimisation des hyperparamètres
- Exécution parallèle
- Pipelines
- AutoML
Concepteur
Vous pouvez utiliser le concepteur pour générer des pipelines à l’aide de vos propres composants personnalisés v2 et de nouveaux composants prédéfinis à partir du Registre. Dans ce cas, vous pouvez utiliser des ressources de données v1 ou v2 dans votre pipeline.
Vous pouvez continuer à utiliser le concepteur pour générer des pipelines à l’aide de composants prédéfinis classiques et de types de jeux de données v1 (tabulaire, fichier). Vous ne pouvez pas utiliser de composants prédéfinis classiques de concepteur existants avec une ressource de données v2.
Vous ne pouvez pas créer un pipeline à l’aide de composants prédéfinis classiques existants et de composants personnalisés v2.
Modèle
Les modèles créés à partir de la version 1 peuvent être utilisés dans la version 2.
Pour une comparaison de code des kits de développement logiciel (SDK) v1 et v2, consultez Gestion des modèles dans les kits de développement logiciel (SDK) v1 et v2.
Point de terminaison et déploiement (point de terminaison et service web dans la version 1)
Avec SDK/CLI v1, vous pouvez déployer des modèles sur ACI ou AKS en tant que services web. Vos modèles de déploiement et services web v1 existants continuent de fonctionner tels quels, mais l’utilisation du SDK/de la CLI v1 pour déployer des modèles sur ACI ou AKS en tant que services web est désormais considérée comme héritée. Pour les nouveaux déploiements de modèle, nous vous recommandons d’effectuer une mise à niveau vers la version 2. Dans la version 2, nous offrons des points de terminaison managés ou points de terminaison Kubernetes. Le tableau ci-après guide nos recommandations :
| Type de point de terminaison dans la version 2 | Mise à niveau à partir de | Notes |
|---|---|---|
| Local | ACI | Test rapide du déploiement de modèle en local ; non destiné à la production. |
| Point de terminaison en ligne managé | ACI, AKS | Infrastructure de déploiement de modèle managée de niveau entreprise avec des réponses en quasi-temps réel et une mise à l’échelle massive pour la production. |
| Point de terminaison de traitement managé | ParallelRunStep dans un pipeline pour le scoring par lots | Infrastructure de modèle de déploiement managé de niveau entreprise avec un traitement par lots massivement parallèle pour la production. |
| Azure Kubernetes Service (AKS) | ACI, AKS | Gère vos propres clusters AKS pour le déploiement de modèle, ce qui offre de la flexibilité et un contrôle granulaire aux dépens de la surcharge informatique. |
| Kubernetes avec Azure Arc | N/A | Gère vos propres clusters Kubernetes dans d’autres clouds ou localement, ce qui offre de la flexibilité et un contrôle granulaire aux dépens de la surcharge informatique. |
Pour une comparaison de code des kits de développement logiciel (SDK) v1 et v2, consultez Mettre à niveau les points de terminaison de déploiement vers le Kit de développement logiciel (SDK) v2. Pour connaître les étapes de la mise à niveau de vos services web ACI existants vers des points de terminaison en ligne gérés, consultez notre guide de mise à niveau et notre blog.
Environnement
Les environnements créés à partir de la version 1 peuvent être utilisés dans la version 2. Dans la version 2, les environnements présentent de nouvelles fonctionnalités comme la création à partir d’un contexte Docker local.
Gestion des secrets
La gestion des secrets du Key Vault diffère considérablement entre les versions v2 et v1. Les méthodes du Kit de développement logiciel (SDK) v1 set_secret et get_secret ne sont pas disponibles dans la version v2. Au lieu de cela, un accès direct à l’aide de bibliothèques de client Key Vault devrait être utilisé.
Pour plus de détails sur Key Vault, consultez Utiliser des secrets d’authentification dans des travaux d’apprentissage Azure Machine Learning.
Scénarios dans le cycle de vie du Machine Learning
Certains scénarios sont communs dans le cycle de vie du Machine Learning avec Azure Machine Learning. Nous en examinerons plusieurs et vous fournirons des recommandations générales pour la mise à niveau vers la version 2.
Configuration Azure
Azure recommande l’utilisation de modèles Azure Resource Manager (souvent via Bicep pour la facilité d’utilisation) pour créer des ressources. Il en va de même pour la création de ressources Azure Machine Learning.
Si votre équipe utilise uniquement Azure Machine Learning, vous pouvez envisager de provisionner l’espace de travail et toute autre ressource via des fichiers YAML et l’interface CLI.
Modèles de prototypage
Nous vous recommandons la version 2 pour les modèles de prototypage. Vous pouvez envisager d’utiliser l’interface CLI pour une utilisation interactive d’Azure Machine Learning, alors que votre code d’entraînement de modèle est Python ou tout autre langage de programmation. Vous pouvez aussi adopter une approche de pile complète avec Python en utilisant seulement le kit SDK Azure Machine Learning ou une approche mixte avec le kit SDK Python Azure Machine Learning et des fichiers YAML.
Entraînement de modèle de production
Nous vous recommandons la version 2 pour l’entraînement de modèle de production. Les travaux regroupent la terminologie et offrent un ensemble de cohérence qui permet facilite la transition entre les types (par exemple, de command à sweep) et un processus adaptés à GitOps pour sérialiser les travaux dans des fichiers YAML.
Avec la version 2, vous devez séparer votre code de machine learning du code du plan de contrôle. Cette séparation facilite l’itération et la transition entre l’environnement local et le cloud. Nous vous recommandons également d’utiliser MLflow pour le suivi et la journalisation du modèle. Pour plus d’informations, consultez l’article sur le concept de MLflow.
Modèle de déploiement de production
Nous vous recommandons la version 2 pour le modèle de déploiement de production. Les points de terminaison managés soustraient la surcharge informatique et offrent une solution performante pour le déploiement et le scoring de modèles, à la fois pour les scénarios en ligne (en quasi-temps réel) et par lots (massivement parallèles).
Les déploiements Kubernetes sont pris en charge dans la version 2 via AKS ou Azure Arc, ce qui autorise des déploiements cloud Azure et locaux gérés par votre organisation.
Opérations de Machine Learning (MLOps)
Dans le cadre d’un workflow MLOps, l’intégration continue et la livraison continue passent généralement par un outil externe. Si une interface CLI est généralement employée dans les workflows CI/CD, vous pouvez aussi appeler Python ou utiliser directement REST.
L’accélérateur de solution pour MLOps avec la version 2 est en cours de développement sur https://github.com/Azure/mlops-v2 et peut être utilisé comme référence ou adopté pour la configuration et l’automatisation du cycle de vie du machine learning.
Note concernant GitOps avec la version 2
Un paradigme clé avec la version 2 est de sérialiser les entités de machine learning sous forme de fichiers YAML pour le contrôle de code source avec git, ce qui autorise de meilleures approches GitOps qu’avec la version 1. Par exemple, vous pouvez appliquer la stratégie selon laquelle seul un principal de service utilisé dans les pipelines CI/CD peut créer/mettre à jour/supprimer tout ou partie des entités, ce qui garantit que les modifications passent par un processus régi, comme les demandes de tirage avec les réviseurs requis. Sachant que les fichiers dans le contrôle de code source sont des fichiers YAML, il est facile de les comparer et d’en suivre les modifications au fil du temps. Vous et votre équipe pouvez envisager d’adopter ce paradigme au moment d’effectuer la mise à niveau vers la version 2.
Vous pouvez obtenir une représentation YAML de n’importe quelle entité avec l’interface CLI via az ml <entity> show --output yaml. Notez que cette sortie comportera des propriétés générées par le système, qui peuvent être ignorées ou supprimées.
Dois-je mettre à niveau le code v1 existant vers v2
Vous pouvez réutiliser vos ressources v1 existantes dans vos flux de travail v2. Par exemple, un modèle créé dans la version v1 peut être utilisé pour effectuer l’inférence managée dans la version v2.
Si vous souhaitez mettre à niveau des parties spécifiques de votre code v1 existant vers v2, reportez-vous aux liens de comparaison fournis dans ce document.
Puis-je utiliser la version 1 et la version 2 ensemble ?
Les versions v1 et v2 peuvent coexister dans un espace de travail. Vous pouvez réutiliser vos ressources existantes dans vos flux de travail v2. Par exemple, un modèle créé dans la version v1 peut être utilisé pour effectuer l’inférence managée dans la version v2. Les ressources telles que l’espace de travail, le calcul et le magasin de données fonctionnent dans la version1 et la version 2, avec des exceptions. Un utilisateur peut appeler le kit SDK Python v1 pour modifier la description d’un espace de travail et utiliser par la suite l’extension CLI v2 pour la modifier à nouveau. Les travaux (expériences/exécutions/pipelines dans la version 1) peuvent être envoyés au même espace de travail aussi bien à partir de la version 1 du kit SDK Python que de la version 2. Un espace de travail peut contenir à la fois des points de terminaison de déploiement de modèle de la version 1 et de la version 2.
Utilisation des codes v1 et v2 ensemble
Nous vous déconseillons d’utiliser les kits de développement logiciel (SDK) v1 et v2 ensemble dans le même code. Il est techniquement possible d’utiliser les versions v1 et v2 dans le même code, car elles utilisent des espaces de noms Azure différents. Toutefois, il existe de nombreuses classes portant le même nom dans ces espaces de noms (comme l’espace de travail, le modèle), ce qui peut entraîner une confusion et compliquer la lisibilité et le débogage du code.
Important
Si votre espace de travail utilise un point de terminaison privé, l’indicateur v1_legacy_mode est automatiquement activé, ce qui empêche l’utilisation des API de version 2. Pour plus d’informations, consulter Configurer l’isolation réseau avec la version 2.