Instructions pour déployer des modèles MLflow

Article
02/05/2024

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

Dans cet article, découvrez le déploiement de modèles MLflow sur Azure Machine Learning pour bénéficier d’une inférence en temps réel et par lots. Découvrez également les différents outils que vous pouvez utiliser pour gérer le déploiement.

Déploiement de modèles MLflow par rapport aux modèles personnalisés

Contrairement au modèle de déploiement personnalisé dans Azure Machine Learning, lorsque vous déployez des modèles MLflow sur Azure Machine Learning, vous n’avez pas besoin de fournir un script de scoring ou un environnement pour le déploiement. Azure Machine Learning génère automatiquement à la place le script de scoring et l’environnement pour vous. 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 Python

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 peuvent varier en fonction de votre type de déploiement.

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

conda.yaml

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

Avertissement

MLflow détecte automatiquement des packages lors de l’enregistrement d’un modèle et épingle les versions de package dans les dépendances conda du modèle. Toutefois, il est possible que cette détection de package automatique ne reflète pas toujours vos intentions ou besoins. Dans de tels cas, envisagez alors d’enregistrer des modèles avec une définition de dépendances conda personnalisée.

Implications de l’utilisation de 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 par lots ou en ligne, Azure Machine Learning fait appliquer le respect du nombre et des types d’entrées de données avec la signature. Si les données entrées ne peuvent pas être analysées comme prévu, l’appel du modèle échoue.

Vous pouvez inspecter la signature d’un modèle MLflow en ouvrant le fichier MLmodel associé au modèle. Pour plus d’informations sur le fonctionnement des signatures dans MLflow, consultez Signatures dans MLflow.

Le fichier suivant montre le fichier MLmodel associé à un modèle MLflow.

mlModel

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 sont facultatives dans des modèles MLflow, mais elles sont vivement recommandées, car elles offrent un moyen pratique pour détecter des problèmes de compatibilité des données de manière précoce. 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.

Modèles déployés dans Azure Machine Learning par rapport aux modèles déployés dans le serveur intégré MLflow

MLflow inclut des outils de déploiement intégrés que les développeurs de modèles peuvent utiliser pour tester des 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 -m my_model ou l’interface CLI MLflow mlflow models predict.

Inférence avec des lots par rapport aux points de terminaison en ligne

Azure Machine Learning prend en charge le déploiement de modèles sur des points de terminaison en ligne et de lot. 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 sont semblables au serveur intégré MLflow du fait qu’ils offrent un moyen évolutif, synchrone et léger d’exécuter des modèles pour l’inférence.

D’autre part, les points de terminaison par lots, en revanche, permettent d’exécuter une inférence asynchrone sur des processus d’inférence durables qui peuvent être mis à l’échelle pour de grandes quantités de données. Le serveur MLflow ne dispose pas de cette capacité pour le moment, même si l’utilisation de travaux Spark permet d’obtenir une capacité similaire. 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.

Les sections qui suivent portent davantage sur des modèles MLflow déployés sur des points de terminaison en ligne Azure Machine Learning.

Formats d’entrée

Type d’entrée	Serveur intégré MLflow	Points 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	✓	Utiliser les points de terminaison de lot¹
Format d’entrée de tenseur sous forme de listes sérialisées avec JSON (tenseurs) et dictionnaire de listes (tenseurs nommés)	✓	✓
Entrée du tenseur mise en forme comme dans l’API TF Serving	✓

¹ Envisagez d’utiliser l’inférence par lots pour traiter des fichiers. Pour obtenir plus d’informations, consultez Déployer des modèles MLflow sur des points de terminaison de lot.

Structure d’entrée

Quel que soit le type d’entrée utilisé, Azure Machine Learning exige que vous fournissiez des entrées dans une charge utile JSON au sein d’une clé de dictionnaire input_data. Étant donné que cette clé n’est pas nécessaire lors de l’utilisation de la commande mlflow models serve pour servir des modèles, vous ne pouvez pas utiliser des charges utiles de manière interchangeable pour des points de terminaison en ligne Azure Machine Learning et le serveur intégré MLflow.

Important

Avertissement concernant MLflow 2.0 : notez que la structure de la charge utile a changé dans MLflow 2.0.

Cette section présente différents exemples de charge utile et les différences entre un serveur déployé dans le serveur intégré MLflow et le serveur d’inférence Azure Machine Learning.

Exemple de charge utile pour un DataFrame Pandas sérialisé avec JSON dans l’orientation de fractionnement

Azure Machine Learning
Serveur intégré MLflow

{
    "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]
        ]
    }
}

{
    "dataframe_split": {
        "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]
        ]
    }
}

Cette charge utile correspond au serveur MLflow 2.0.

Exemple de charge utile pour une entrée de tenseur

Azure Machine Learning
Serveur intégré MLflow

{
    "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]
    ]
}

{
    "inputs": [
          [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]
    ]
}

Exemple de charge utile pour une entrée nommée-tenseur

Azure Machine Learning
Serveur intégré MLflow

{
    "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]
        ]
    }
}

{
    "inputs": {
        "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]
        ]
    }
}

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.

Personnaliser l’inférence dans le cadre du déploiement de modèles MLflow

Il est possible que vous ayez l’habitude de créer des scripts de scoring pour personnaliser le mode d’exécution de l’inférence pour vos modèles personnalisés. Toutefois, dans le cadre du déploiement de modèles MLflow sur Azure Machine Learning, la décision quant au mode d’exécution de l’inférence est prise par le créateur du modèle (la personne qui a généré le modèle), et non par l’ingénieur DevOps (la personne qui tente de le déployer). Chaque infrastructure de modèle peut appliquer automatiquement des routines d’inférence spécifiques.

À tout moment, si vous devez modifier la façon d’exécuter l’inférence d’un modèle MLflow, vous pouvez effectuer l’une des deux opérations :

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

Lorsque vous journalisez un modèle en tirant parti de mlflow.autolog ou de mlflow.<flavor>.log_model, la saveur utilisée pour le modèle détermine comment l’inférence doit être exécutée et le type de résultat retourné par le modèle. MLflow n’applique aucun comportement spécifique pour la façon dont la fonction predict() génère des résultats.

Toutefois, dans certains cas, il est possible que vous vouliez effectuer un traitement antérieur ou postérieur avant et après l’exécution de votre modèle. Dans d’autres cas, il est possible que vous souhaitez changer ce qui est retourné (par exemple, des probabilités par opposition à des 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 connus pour implémenter des pipelines et sont parfois conseillés pour des considérations en termes de performances. Une autre solution consiste à personnaliser la façon dont votre modèle effectue l’inférence en utilisant une saveur de modèle personnalisée.

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 en fournir un, le cas échéant. Vous pouvez utiliser le script de scoring pour personnaliser la façon dont l’inférence est exécutée pour des modèles MLflow. Pour obtenir plus d’informations sur la personnalisation de l’inférence, consultez Personnalisation des modèles de déploiement MLflow (points de terminaison en ligne) et Personnalisation des modèles de déploiement MLflow (points de terminaison de lot).

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 offre de nombreuses façons de déployer des modèles MLflow sur des points de terminaison en ligne et de lot. Vous pouvez déployer des modèles en tirant parti des outils suivants :

Kit de développement logiciel (SDK) MLflow
Interface CLI Azure Machine Learning
SDK Azure Machine Learning pour Python
Azure Machine Learning Studio

Chaque workflow dispose de différentes fonctionnalités, en particulier concernant le type de calcul qu’il peut cibler. Le tableau suivant répertorie les différentes capacités.

Scénario	Kit de développement logiciel (SDK) MLflow	CLI/SDK Azure Machine Learning	Azure Machine Learning Studio
Déploiement sur des points de terminaison en ligne managés	Consultez l’exemple¹	Consultez l’exemple¹	Consultez l’exemple¹
Déploiement sur des points de terminaison en ligne managés (avec un script de scoring)	Non pris en charge³	Consultez l’exemple	Consultez l’exemple
Déploiement sur des points de terminaison de lot	Non pris en charge³	Consultez l’exemple	Consultez l’exemple
Déploiement sur des points de terminaison de lot (avec un script de scoring)	Non pris en charge³	Consultez l’exemple	Consultez l’exemple
Déploiement sur des services web (ACI/AKS)	Prise en charge héritée²	Non pris en charge²	Non pris en charge²
Déploiement sur des services web (ACI/AKS - avec un script de scoring)	Non pris en charge³	Prise en charge héritée²	Prise en charge héritée²

¹ 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).

² Nous vous recommandons de passer à des points de terminaison en ligne managés.

³ MLflow (OSS) n’a aucun concept de script de scoring et ne prend actuellement pas en charge l’exécution par lots.

Quel outil de déploiement utiliser ?

Utilisez le Kit de développement logiciel (SDK) MLflow si deux de ces conditions s’appliquent :
- Vous connaissez MLflow ou vous utilisez une plateforme qui prend en charge MLflow de manière native (comme Azure Databricks).
- Vous souhaitez continuer à utiliser le même ensemble de méthodes à partir de MLflow.
Utilisez l’interface Azure Machine Learning CLI v2 si une de ces conditions s’applique :
- Vous connaissez l’interface Azure Machine Learning CLI v2.
- Vous voulez automatiser les déploiements en utilisant des pipelines d’automatisation.
- Vous voulez conserver une configuration de déploiement dans un référentiel Git.
Utilisez le déploiement d’interface utilisateur Azure Machine Learning studio si vous voulez déployer rapidement et tester des modèles entraînés avec MLflow.