Instructions pour déployer des modèles MLflow

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

Dans cet article, découvrez le déploiement de modèles MLflow sur Azure Machine Learning pour l’inférence en temps réel et par lots ainsi que les différents outils qui permettent de gérer les déploiements.

Déploiement sans code

Quand vous déployez des modèles MLflow sur Azure Machine Learning, contrairement au déploiement de modèles personnalisés, vous n’avez pas à fournir de script de scoring ni d’environnement. Azure Machine Learning génère automatiquement le script de scoring et l’environnement à votre place. Cette fonctionnalité est appelée déploiement sans code.

Pour un déploiement sans code, Azure Machine Learning effectue ce qui suit :

  • Vérifie que toutes les dépendances de package indiquées dans le modèle MLflow sont satisfaites.
  • Fournit une image de base MLflow ou un environnement organisé qui contient les éléments suivants :
    • Packages requis pour qu’Azure Machine Learning effectue l’inférence, y compris mlflow-skinny.
    • Script de scoring pour effectuer l’inférence.

Conseil

Espaces de travail sans accès au réseau public : avant de pouvoir déployer des modèles MLflow sur des points de terminaison en ligne sans connectivité de sortie, vous devez empaqueter les modèles (préversion). En utilisant l’empaquetage de modèles, vous pouvez éviter la nécessité d’une connexion Internet, qu’Azure Machine Learning nécessiterait pour installer dynamiquement les packages Python nécessaires pour les modèles MLflow.

Packages et dépendances

Azure Machine Learning génère automatiquement les environnements pour exécuter l’inférence sur des modèles MLflow. Pour générer les environnements, Azure Machine Learning lit les dépendances conda spécifiées dans le modèle MLflow et ajoute les packages requis pour exécuter le serveur d’inférence. Ces packages supplémentaires varient en fonction du type de déploiement.

L’exemple de fichier conda.yaml suivant montre les dépendances Conda spécifiées dans un modèle MLflow.

channels:
- conda-forge
dependencies:
- python=3.10.11
- pip<=23.1.2
- pip:
  - mlflow==2.7.1
  - cloudpickle==1.6.0
  - dataclasses==0.6
  - lz4==4.0.0
  - numpy==1.23.5
  - packaging==23.0
  - psutil==5.9.0
  - pyyaml==6.0
  - scikit-learn==1.1.2
  - scipy==1.10.1
  - uuid==1.30
name: mlflow-env

Important

MLflow détecte automatiquement les packages quand il journalise un modèle, et épingle les versions de package dans les dépendances Conda du modèle. Cette détection automatique de package ne reflète peut-être pas vos intentions ou vos besoins. Vous pouvez également journaliser des modèles avec une signature, un environnement ou des exemples personnalisés.

Modèles avec signatures

Les modèles MLflow peuvent inclure une signature qui indique les entrées attendues et leurs types. Quand de tels modèles sont déployés sur des points de terminaison en ligne ou par lots, Azure Machine Learning vérifie que le nombre et les types d’entrées de données sont conformes à la signature. Si les données d’entrée ne peuvent pas être analysées comme prévu, l’appel du modèle échoue.

Vous pouvez inspecter une signature de modèle MLflow en ouvrant le fichier MLmodel. Pour plus d’informations sur le fonctionnement des signatures dans MLflow, consultez Signatures dans MLflow.

L’exemple de fichier MLmodel suivant met en évidence signature.

artifact_path: model
flavors:
  python_function:
    env:
      conda: conda.yaml
      virtualenv: python_env.yaml
    loader_module: mlflow.sklearn
    model_path: model.pkl
    predict_fn: predict
    python_version: 3.10.11
  sklearn:
    code: null
    pickled_model: model.pkl
    serialization_format: cloudpickle
    sklearn_version: 1.1.2
mlflow_version: 2.7.1
model_uuid: 3f725f3264314c02808dd99d5e5b2781
run_id: 70f15bab-cf98-48f1-a2ea-9ad2108c28cd
signature:
  inputs: '[{"name": "age", "type": "double"}, {"name": "sex", "type": "double"},
    {"name": "bmi", "type": "double"}, {"name": "bp", "type": "double"}, {"name":
    "s1", "type": "double"}, {"name": "s2", "type": "double"}, {"name": "s3", "type":
    "double"}, {"name": "s4", "type": "double"}, {"name": "s5", "type": "double"},
    {"name": "s6", "type": "double"}]'
  outputs: '[{"type": "double"}]'

Conseil

Les signatures dans les modèles MLflow sont recommandées, car elles constituent un moyen pratique de détecter les problèmes de compatibilité des données. Pour obtenir plus d’informations sur la façon d’enregistrer des modèles avec des signatures, consultez Journalisation des modèles avec une signature, un environnement ou des exemples personnalisés.

Déploiement sur le serveur intégré MLflow et déploiement sur le serveur d’inférence Azure Machine Learning

Les développeurs de modèles peuvent utiliser les outils de déploiement intégrés MLflow pour tester les modèles localement. Par exemple, vous pouvez exécuter une instance locale d’un modèle inscrit dans le registre du serveur MLflow en utilisant mlflow models serve, ou mlflow models predict via MLflow CLI. Pour obtenir plus d’informations sur les outils de déploiement intégrés MLflow, consultez Outils de déploiement intégrés dans la documentation MLflow.

Azure Machine Learning prend également en charge le déploiement de modèles sur les points de terminaison en ligne et par lots. Ces points de terminaison exécutent des technologies d’inférence différentes qui peuvent avoir des fonctionnalités distinctes.

  • Les points de terminaison en ligne Azure Machine Learning, à l’image du serveur intégré MLflow, fournissent un moyen évolutif, synchrone et léger d’exécuter des modèles pour l’inférence.

  • Les points de terminaison de traitement par lots Azure Machine Learning peuvent exécuter une inférence asynchrone sur des processus d’inférence durables, qui peuvent être mis à l’échelle sur de grandes quantités de données. Le serveur MLflow ne dispose pas de cette fonctionnalité. Toutefois, vous pouvez obtenir une fonctionnalité similaire à l’aide des travaux Spark. Pour obtenir plus d’informations sur les points de terminaison par lots et les modèles MLflow, consultez Utiliser des modèles MLflow dans les déploiements par lots.

Formats d’entrée

Le tableau suivant présente les types d’entrées pris en charge par le serveur intégré MLflow par rapport aux points de terminaison en ligne Azure Machine Learning.

Type d’entrée Serveur intégré MLflow Point de terminaison en ligne Azure Machine Learning
DataFrames pandas sérialisés avec JSON dans l’orientation du fractionnement
DataFrames pandas sérialisés avec JSON dans l’orientation des enregistrements Déprécié
DataFrames pandas sérialisés au format CSV Utilise l’inférence par lots. Pour obtenir plus d’informations, consultez Déployer des modèles MLflow sur des points de terminaison de lot.
Entrée TensorFlow sous forme de listes sérialisées JSON (tenseurs) et de dictionnaire de listes (tenseurs nommés)
Entrée TensorFlow via l’API de mise à disposition de TensorFlow

Les sections suivantes se concentrent sur les modèles MLflow déployés sur les points de terminaison en ligne Azure Machine Learning.

Structure d’entrée

Quel que soit le type d’entrée, Azure Machine Learning vous impose de fournir les entrées dans une charge utile JSON au sein de la clé de dictionnaire input_data. Dans la mesure où cette clé n’est pas obligatoire quand vous utilisez la commande mlflow models serve pour mettre à disposition des modèles, vous ne pouvez pas utiliser les charges utiles de manière interchangeable pour les points de terminaison en ligne Azure Machine Learning et le serveur intégré MLflow.

Important

La structure de la charge utile a changé dans MLflow 2.0.

Les exemples de charge utile suivants montrent les différences entre un modèle déployé sur le serveur intégré MLflow et le serveur d’inférence Azure Machine Learning.

DataFrames Pandas sérialisés au format JSON en orientation fractionnée

{
    "input_data": {
        "columns": [
            "age", "sex", "trestbps", "chol", "fbs", "restecg", "thalach", "exang", "oldpeak", "slope", "ca", "thal"
        ],
        "index": [1],
        "data": [
            [1, 1, 145, 233, 1, 2, 150, 0, 2.3, 3, 0, 2]
        ]
    }
}

Entrée Tensor

{
    "input_data": [
          [1, 1, 0, 233, 1, 2, 150, 0, 2.3, 3, 0, 2],
          [1, 1, 0, 233, 1, 2, 150, 0, 2.3, 3, 0, 2]
          [1, 1, 0, 233, 1, 2, 150, 0, 2.3, 3, 0, 2],
          [1, 1, 145, 233, 1, 2, 150, 0, 2.3, 3, 0, 2]
    ]
}

Entrée utilisant des tenseurs nommés

{
    "input_data": {
        "tokens": [
          [0, 655, 85, 5, 23, 84, 23, 52, 856, 5, 23, 1]
        ],
        "mask": [
          [0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0]
        ]
    }
}

Personnalisation de l’inférence pour les modèles MLflow

Les scripts de scoring personnalisent la façon d’exécuter l’inférence pour les modèles personnalisés. Toutefois, pour le déploiement de modèles MLflow, la décision relative à l’exécution de l’inférence est prise par Model Builder plutôt que par l’ingénieur de déploiement. Chaque infrastructure de modèle peut appliquer automatiquement des routines d’inférence spécifiques.

Si vous devez changer la façon dont l’inférence est exécutée pour un modèle MLflow, vous pouvez effectuer l’une des actions suivantes :

  • Modifiez la façon dont vous enregistrez votre modèle dans la routine d’apprentissage.
  • Personnalisez l’inférence avec un script de scoring au moment du déploiement.

Modifier la façon dont votre modèle est journalisé pendant l’entraînement

Quand vous journalisez un modèle en utilisant mlflow.autolog ou mlflow.<flavor>.log_model, la saveur utilisée pour le modèle détermine le mode d’exécution de l’inférence ainsi que les résultats à retourner. MLflow n’applique aucun comportement spécifique pour la façon dont la fonction predict() génère des résultats.

Dans certains cas, vous pouvez être amené à effectuer un prétraitement ou un post-traitement avant et après l’exécution de votre modèle. Vous pouvez également changer ce qui est retourné, par exemple des probabilités à la place de classes. Une solution consiste à implémenter des pipelines Machine Learning qui passent des entrées aux sorties directement.

Par exemple, sklearn.pipeline.Pipeline ou pyspark.ml.Pipeline sont des moyens populaires d’implémenter des pipelines, et sont parfois recommandés pour des raisons de performance. Vous pouvez également personnaliser la façon dont votre modèle effectue l’inférence en journalisant des modèles personnalisés.

Personnaliser l’inférence avec un script de scoring

Bien que les modèles MLflow ne nécessitent pas de script de scoring, vous pouvez toujours en fournir un afin de personnaliser l’exécution de l’inférence pour les modèles MLflow, le cas échéant. Pour plus d’informations sur la personnalisation de l’inférence, consultez Personnaliser les déploiements de modèles MLflow pour les points de terminaison en ligne, ou Personnaliser le modèle de déploiement avec le script de scoring pour les points de terminaison de traitement par lots.

Important

Si vous choisissez de spécifier un script de scoring pour un modèle de déploiement MLflow, vous devez également fournir un environnement pour le déploiement.

Outils de déploiement

Azure Machine Learning propose les outils suivants pour déployer des modèles MLflow sur des points de terminaison en ligne et par lots :

Chaque outil a des fonctionnalités différentes, en particulier pour le type de calcul qu’il peut cibler. Le tableau suivant montre la prise en charge de différents scénarios de déploiement MLflow.

Scénario Kit de développement logiciel (SDK) MLflow Azure Machine Learning CLI/SDK ou studio
Déployer sur des points de terminaison en ligne gérés1 Pris en charge. Consultez Lancement progressif de modèles MLflow sur des points de terminaison en ligne Pris en charge. Consultez Déployer des modèles MLflow sur des points de terminaison en ligne
Déployer sur des points de terminaison en ligne gérés avec un script de scoring Non pris en charge3 Pris en charge. Consultez Personnaliser les déploiements de modèles MLflow
Déploiement sur des points de terminaison de lot Non pris en charge3 Pris en charge. Consultez Utiliser des modèles MLflow dans les déploiements par lots
Déployer sur des points de terminaison de traitement par lots avec un script de scoring Non pris en charge3 Pris en charge. Consultez Personnaliser le modèle de déploiement avec le script de scoring
Déployer sur des services web tels qu’Azure Container Instances ou AKS (Azure Kubernetes Service) Prise en charge héritée2 Non pris en charge2
Déployer sur des services web tels que Container Instances ou AKS avec un script de scoring Non pris en charge3 Prise en charge héritée2

1 Le déploiement vers des points de terminaison en ligne qui se trouvent dans des espaces de travail avec liaison privée activée vous oblige à empaqueter les modèles avant le déploiement (préversion).

2 Passez aux points de terminaison en ligne gérés si possible.

3 MLflow open source n’a pas de concept de script de scoring, et ne prend pas en charge l’exécution par lots.

Choisir un outil de déploiement

Utilisez le kit SDK MLflow si :

  • Vous connaissez bien MLflow, vous souhaitez continuer à utiliser les mêmes méthodes, et
  • Vous utilisez une plateforme telle qu’Azure Databricks, qui prend en charge MLflow de manière native.

Utilisez Azure Machine Learning CLI v2 ou le kit SDK pour Python si :

  • Vous les connaissez bien, ou
  • Vous souhaitez automatiser le déploiement avec des pipelines, ou
  • Vous souhaitez conserver la configuration de déploiement dans un dépôt Git.

Utilisez l’IU d’Azure Machine Learning studio si vous souhaitez déployer et tester rapidement des modèles formés avec MLflow.