Enregistrer les dépendances du modèle

Dans cet article, vous apprenez à journaliser un modèle et ses dépendances en tant qu’artefacts de modèle pour qu’ils soient disponibles dans votre environnement pour les tâches de production telles que le service de modèles.

Journaliser les dépendances de modèle de package Python

MLflow dispose d’une prise en charge native de certaines bibliothèques Python ML. MLflow peut fiablement y journaliser les dépendances pour les modèles qui utilisent ces bibliothèques. Consultez les saveurs intégrées de modèles.

Par exemple, MLflow prend en charge scikit-learn dans le module mlflow.sklearn et la commande mlflow.sklearn.log_model journalise la version sklearn. Il en est de même pour la journalisation automatique avec ces bibliothèques ML. Pour d’autres exemples, consultez le référentiel github MLflow.

Pour les bibliothèques ML qui peuvent être installées avec pip install PACKAGE_NAME==VERSION, mais qui n’ont pas de saveurs intégrées de modèles MLflow, vous pouvez journaliser ces packages à l’aide de la méthode mlflow.pyfunc.log_model. Veillez à journaliser les exigences avec la version exacte de la bibliothèque, par exemple f"nltk=={nltk.__version__}" au lieu de simplement nltk.

mlflow.pyfunc.log_model prend en charge la journalisation pour :

• Bibliothèques publiques et personnalisées présentées sous forme de fichiers d’œuf Python ou de roue Python.
• Packages publics sur PyPI et packages hébergés en privé sur votre propre serveur PyPI.

MLflow tente d’inférer automatiquement les dépendances avec mlflow.pyfunc.log_model. MLflow déduit les dépendances à l’aide de mlflow.models.infer_pip_requirements et les journalise dans un fichier requirements.txt en tant qu’artefact de modèle.

Dans les versions antérieures, MLflow n’identifie pas toujours automatiquement toutes les exigences Python, en particulier si la bibliothèque n’est pas une saveur de modèle intégrée. Dans ces cas, vous pouvez spécifier des dépendances supplémentaires avec le paramètre extra_pip_requirements dans la commande log_model. Consultez un exemple d’utilisation du paramètre extra_pip_requirements.

Journalisation personnalisée de modèle

Pour les scénarios où une journalisation de modèle plus personnalisée est nécessaire, vous pouvez soit :

• Écrire un modèle Python personnalisé. Cela vous permet de sous-classer mlflow.pyfunc.PythonModel pour personnaliser l’initialisation et la prédiction. Cette approche fonctionne bien pour la personnalisation des modèles utilisant uniquement Python.
  • Pour un exemple simple, consultez l’exemple ajouter un modèle N.
  • Pour un exemple plus complexe, consultez l’exemple de modèle XGBoost personnalisé.
• Écrire une saveur personnalisée. Dans ce scénario, vous pouvez personnaliser la journalisation plus que la saveur pyfunc générique, mais cela nécessite plus de travail pour l’implémentation.

Code Python personnalisé

Vous pouvez avoir des dépendances de code Python qui ne peuvent pas être installées à l’aide de la commande %pip install, comme un ou plusieurs fichiers .py.

Lors de la journalisation d’un modèle, vous pouvez indiquer à MLflow que le modèle peut trouver ces dépendances dans un chemin spécifié à l’aide du paramètre code_path dans mlflow.pyfunc.log_model. MLflow stocke tous les fichiers ou répertoires passés en utilisant code_path en tant qu’artefacts et le modèle dans un répertoire de code. Lors du chargement du modèle, MLflow ajoute ces fichiers ou répertoires au chemin d’accès Python. Cet itinéraire fonctionne également avec des fichiers de roue Python personnalisés, qui peuvent être inclus dans le modèle à l’aide de code_path, tout comme les fichiers .py.

mlflow.pyfunc.log_model( artifact_path=artifact_path,
                         code_path=[filename.py],
                         data_path=data_path,
                         conda_env=conda_env,
                       )

Journaliser les dépendances de modèle de package autres que Python

MLflow ne récupère pas automatiquement les dépendances autres que Python, telles que les packages Java, les packages R et les packages natifs (comme les packages Linux). Pour ces packages, vous devez journaliser des données supplémentaires.

• Liste de dépendances : Databricks recommande de journaliser un artefact avec le modèle qui spécifie ces dépendances autres que Python. Il peut s’agir d’un fichier .txt ou .json simple. mlflow.pyfunc.log_model vous permet de spécifier cet artefact supplémentaire à l’aide de l’argument artifacts.
• Packages personnalisés : comme pour les dépendances Python personnalisées ci-dessus, vous devez assurer que les packages sont disponibles dans votre environnement de déploiement. Pour les packages dans un emplacement central tels que Maven Central ou votre propre référentiel, assurez-vous que l’emplacement est disponible au moment du scoring ou du service. Pour les packages privés qui ne sont pas hébergés ailleurs, vous pouvez journaliser les packages avec le modèle en tant qu’artefacts.

Déployer des modèles avec des dépendances

Lors du déploiement d’un modèle à partir du serveur de suivi MLflow ou du Registre de modèles, vous devez assurer que l’environnement de déploiement a les bonnes dépendances installées. Le chemin le plus simple peut dépendre de votre mode de déploiement : service en ligne ou par lots/diffusion en continu et des types de dépendances.

Pour tous les modes de déploiement, Databricks recommande d’exécuter l’inférence sur la même version du runtime que celle utilisée pendant l’apprentissage, car le Databricks Runtime dans lequel vous avez créé votre modèle a déjà installé différentes bibliothèques. MLflow dans Databricks enregistre automatiquement cette version du runtime dans le fichier de métadonnées MLmodel d’un champ databricks_runtime, tel que databricks_runtime: 10.2.x-cpu-ml-scala2.12.

Service en ligne : Service de modèles Mosaic AI

Databricks propose le Service de modèle dans lequel vos modèles Machine Learning MLflow sont exposés en tant que points de terminaison d’API REST évolutifs.

Pour les dépendances Python dans le fichier requirements.txt, Databricks et MLflow gèrent tout pour les dépendances PyPI publiques. De même, si vous avez spécifié des fichiers .py ou des fichiers de roue Python lors de la journalisation du modèle à l’aide de l’argument code_path, MLflow charge automatiquement ces dépendances pour vous.

Pour ces scénarios de service de modèles, consultez les rubriques suivantes :

• Utiliser des bibliothèques personnalisées Python un service de modèle
• Packager des artefacts et fichiers personnalisés pour le Service de modèle

Pour les dépendances Python dans le fichier requirements.txt, Databricks et MLflow gèrent tout pour les dépendances PyPI publiques. De même, si vous avez spécifié des fichiers .py ou des fichiers de roue Python lors de la journalisation du modèle à l’aide de l’argument code_path, MLflow charge automatiquement ces dépendances pour vous.

Service en ligne : systèmes tiers ou conteneurs Docker

Si votre scénario nécessite un service vers des solutions de service tierces ou votre propre solution Docker, vous pouvez exporter votre modèle en tant que conteneur Docker.

Databricks recommande les actions suivantes pour le service tiers qui gère automatiquement les dépendances Python. Toutefois, pour les dépendances autres que Python, le conteneur doit être modifié pour les inclure.

• Intégration Docker de MLflow pour la solution de service basée sur Docker : modèles MLflow build-docker

• Intégration MLflow d’Azure Machine Learning :

  • Déployer sur Azure Container Instances (ACI)
  • Déployer sur Azure Kubernetes Service (AKS)

Tâches de traitement par lots et par diffusion en continu

Le scoring par lots et par diffusion en continu doit être exécuté en tant que travail Databricks. Une tâche de notebook suffit la plupart du temps et le moyen le plus simple de préparer le code est d’utiliser le Registre de modèles Databricks pour générer un notebook de scoring.

L’article suivant décrit le processus et les étapes à suivre pour garantir que les dépendances sont installées et appliquées en conséquence :

1. Démarrez votre cluster de scoring avec la même version de Databricks Runtime utilisée pendant l’apprentissage. Lisez le champ databricks_runtime du fichier de métadonnées MLmodel et démarrez un cluster avec cette version du runtime.

   • Cela peut être fait manuellement dans la configuration du cluster ou automatisé avec une logique personnalisée. Pour l’automatisation, le format de version du runtime que vous lisez à partir du fichier de métadonnées dans l’API Travaux et l’API Clusters.

2. Ensuite, installez toutes les dépendances autres que Python. Pour assurer que vos dépendances autres que Python sont accessibles à votre environnement de déploiement, vous pouvez :

   • Installer manuellement les dépendances autres que Python de votre modèle sur le cluster Databricks dans le cadre de la configuration du cluster avant d’exécuter l’inférence.
   • Sinon, vous pouvez écrire une logique personnalisée dans votre déploiement de tâche de scoring pour automatiser l’installation des dépendances sur votre cluster. En supposant que vous ayez enregistré vos dépendances autres que Python en tant qu’artefacts, comme décrit dans Journaliser les dépendances de modèle de package autres que Python, cette automatisation peut installer des bibliothèques à l’aide de l’API Bibliothèques. Vous pouvez également écrire du code spécifique pour générer un script d’initialisation dans l’étendue du cluster pour installer les dépendances.

3. Votre tâche de scoring installe les dépendances Python dans l’environnement d’exécution de tâche. Dans Databricks, le Registre de modèles vous permet de générer un notebook pour l’inférence, qui le fait à votre place.

   • Lorsque vous utilisez le Registre de modèles Databricks pour générer un notebook de scoring, celui-ci contient du code pour installer les dépendances Python dans le fichier requirements.txt du modèle. Pour votre tâche de notebook pour le scoring par lots ou par diffusion en continu, ce code initialise votre environnement de notebook de sorte que les dépendances de modèle sont installées et prêtes pour votre modèle.

4. MLflow gère tout code Python personnalisé inclus dans le paramètre code_path dans log_model. Ce code est ajouté au chemin Python lorsque la méthode predict() du modèle est appelée. Vous pouvez également effectuer cette opération manuellement en procédant comme suit :

   • Appel de mlflow.pyfunc.spark_udf avec l’argument env_manager=['virtualenv'/'conda'].
   • Extraction des exigences à l’aide de mlflow.pyfunc.get_model_dependencies et les installer avec %pip install.

   Remarque

   Si vous avez spécifié des fichiers .py ou des fichiers de roue Python lors de la journalisation du modèle avec l’argument code_path, MLflow charge automatiquement ces dépendances pour vous.