Aller au contenu principal
Dernière mise à jour le

Log model dependencies

Dans cet article, vous apprendrez comment enregistrer un modèle et ses dépendances en tant qu'artefacts de modèle, afin qu'ils soient disponibles dans votre environnement pour les tâches de production telles que la mise à disposition de modèles.

Enregistrer les dépendances de modèle de package Python​

MLflow offre une prise en charge native pour certaines bibliothèques ML Python, où MLflow peut Log de manière fiable les dépendances pour les modèles qui utilisent ces bibliothèques. Voir saveurs de modèles intégrées.

Par exemple, MLflow prend en charge scikit-learn dans le module mlflow.sklearn et la commande mlflow.sklearn.log_model Enregistre la version sklearn. Il en va de même pour le log automatique avec ces bibliothèques ML. Consultez le repository GitHub MLflow pour des exemples supplémentaires.

remarque

Pour activer la journalisation des traces pour les charges de travail d’IA générative, MLflow prend en charge l’ autologging OpenAI.

Pour les bibliothèques ML qui peuvent être installées avec pip install PACKAGE_NAME==VERSION, mais qui n'ont pas de variantes de modèle MLflow intégrées, vous pouvez journaliser ces packages en utilisant mlflow.pyfunc.log_model méthode. Assurez-vous de 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 packagées sous forme de fichiers Python egg ou Python wheel.
  • Packages publics sur PyPI et packages hébergés en privé sur votre propre serveur PyPI.

Avec mlflow.pyfunc.log_model, MLflow tente de déduire automatiquement les dépendances. MLflow déduit les dépendances à l'aide de mlflow.models.infer_pip_requirements, et les Logs dans un fichier requirements.txt en tant qu'artefact de modèle.

Dans les anciennes versions, MLflow n'identifie parfois pas toutes les exigences Python automatiquement, surtout si la bibliothèque n'est pas un modèle intégré. Dans ces cas, vous pouvez spécifier des dépendances supplémentaires avec le parameter extra_pip_requirements dans la commande log_model. Voir un exemple d'utilisation du parameter extra_pip_requirements.

important

Vous pouvez également remplacer l’ensemble des exigences avec les paramètres conda_env et pip_requirements, mais cela est généralement déconseillé, car cela annule les dépendances que MLflow détecte automatiquement. Voir un exemple d'utilisation du pip_requirements paramètre pour outrepasser les exigences.

Journalisation de modèle personnalisée​

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

  • Écrivez un modèle Python personnalisé. Ceci vous permet de créer une sous-classe de mlflow.pyfunc.PythonModel pour personnaliser l'initialisation et la prédiction. Cette approche fonctionne bien pour la personnalisation de modèles uniquement Python.

  • Écrire une saveur personnalisée. Dans ce scénario, vous pouvez personnaliser la journalisation plus que le type générique pyfunc, mais cela nécessite plus d'efforts d'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 l'enregistrement d'un modèle, vous pouvez indiquer à MLflow que le modèle peut trouver ces dépendances à un chemin spécifié en utilisant le parameter code_paths (ou code_path dans MLflow 2.x) dans mlflow.pyfunc.log_model. MLflow stocke tous les fichiers ou répertoires passés à l'aide de code_paths ou code_path comme artefacts avec le modèle dans un répertoire de code. Lors du chargement du modèle, MLflow ajoute ces fichiers ou répertoires au chemin Python. Cette route fonctionne également avec des fichiers Python wheel personnalisés, qui peuvent être inclus dans le modèle à l'aide de code_paths ou code_path, tout comme les fichiers .py.

Python
mlflow.pyfunc.log_model(
   name=name,
   code_paths=[filename.py],
   data_path=data_path,
   conda_env=conda_env,
)

Enregistrer les dépendances directes et transitives​

Avec MLflow 3, vous pouvez choisir d'enregistrer les dépendances directes et transitives en définissant la variable d'environnement MLFLOW_LOCK_MODEL_DEPENDENCIES.

Python
import os
os.environ["MLFLOW_LOCK_MODEL_DEPENDENCIES"] = "true"

# Now when you log your model, MLflow captures
# both direct and transitive dependencies

mlflow.sklearn.log_model(
    model,
    "my_model",
)

Journaliser les dépendances de modèle de package non-Python​

MLflow ne détecte pas automatiquement les dépendances non Python, telles que les packages Java, les packages R et les packages natifs (tels que les packages Linux). Pour ces packages, vous devez enregistrer des données supplémentaires.

  • Liste des dépendances : Databricks recommande d'enregistrer un artefact avec le modèle spécifiant ces dépendances non Python. Il peut s'agir d'un simple fichier .txt ou .json. 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 vous assurer que les packages sont disponibles dans votre environnement de déploiement. Pour les packages dans un emplacement central tel que Maven Central ou votre propre repository, assurez-vous que l'emplacement est disponible au moment de la notation ou du service. Pour les packages privés non hébergés ailleurs, vous pouvez enregistrer les packages avec le modèle en tant qu'artefacts.

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

Lorsque vous déployez un modèle à partir de MLflow Tracking Server ou de Model Registry, vous devez vous assurer que l’environnement de déploiement dispose des dépendances appropriées installées. Le chemin le plus simple peut dépendre de votre mode de déploiement : batch/streaming ou service en ligne, 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 que vous avez utilisée pendant l'entraînement, car le Databricks Runtime dans lequel vous avez créé votre modèle dispose de diverses bibliothèques déjà installées. MLflow dans Databricks enregistre automatiquement cette version du runtime dans le fichier de métadonnées MLmodel dans un champ databricks_runtime, tel que databricks_runtime: 10.2.x-cpu-ml-scala2.12.

Service en ligne : Model Serving​

Databricks propose Model Serving, où vos Modèle de machine learning MLflow sont exposés en tant qu'Endpoint 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 Python wheel lors de l'enregistrement du modèle en utilisant code_paths (ou code_path dans MLflow 2.x), MLflow charge ces dépendances pour vous automatiquement.

important

Les runtimes Databricks Runtime ML incluent mlflow-skinny default plutôt que le package mlflow complet. Lorsque vous enregistrez un modèle pyfunc sur l'un de ces runtimes sans spécifier pip_requirements, MLflow capture mlflow-skinny dans le conda.yaml du modèle, et Model Serving ne peut pas créer l'image conteneur car il nécessite mlflow. Spécifiez mlflow==<version> dans pip_requirements lorsque vous log le modèle. Pour plus de détails, voir Déployer du code Python avec Model Serving.

Pour ces scénarios de service de modèle, consultez ce qui suit :

Service en ligne : systèmes tiers ou conteneurs Docker​

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

Databricks recommande ce qui suit pour le service tiers qui gère automatiquement les dépendances Python. Cependant, pour les dépendances non Python, le conteneur doit être modifié pour les inclure.

Jobs batch et streaming​

Le scoring batch et streaming doit être exécuté en tant que Lakeflow Jobs. Un Notebook Job suffit souvent, et la façon la plus simple de préparer le code est d'utiliser le Model Registry Databricks pour générer un Notebook de notation.

Ce qui suit décrit le processus et les étapes à suivre pour s'assurer que les dépendances sont installées et appliquées en conséquence :

  1. start votre cluster de scoring avec la même version de Databricks Runtime utilisée pendant l'entraînement. Lisez le champ databricks_runtime du fichier de métadonnées MLmodel, et start un cluster avec cette version d'exécution.

    • 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 Jobs et l’ API Clusters.

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

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

  3. Votre Job de scoring installe les dépendances Python dans l'environnement d'exécution du Job. Dans Databricks, le Model Registry vous permet de générer un notebook pour l'inférence qui le fait pour vous.

    • Lorsque vous utilisez le Databricks Model Registry pour générer un notebook de scoring, le notebook contient du code pour installer les dépendances Python dans le fichier requirements.txt du modèle. Pour votre Job Notebook pour la notation batch ou streaming, ce code initialise votre environnement Notebook, de sorte que les dépendances du modèle soient installées et prêtes pour votre modèle.

  4. MLflow gère tout code Python personnalisé inclus dans code_paths (ou code_path dans MLflow 2.x) dans log_model. Ce code est ajouté au chemin d'accès Python lorsque la méthode predict() du modèle est appelée. Vous pouvez également le faire manuellement en :

remarque

Si vous avez spécifié des fichiers .py ou des fichiers Python wheel lors de l'enregistrement du modèle à l'aide de code_paths ou code_path, MLflow charge automatiquement ces dépendances pour vous.

Sur cette page