Déployer des modèles personnalisés

Article
11/06/2024

Cet article décrit la prise en charge du déploiement d’un modèle personnalisé à l’aide du service de modèles Mosaic AI. Il fournit également des détails sur les options de journalisation des modèles et les types de calcul pris en charge, sur la manière de packager les dépendances de modèle pour le service, ainsi que sur la création et la mise à l’échelle des points de terminaison.

Que sont les modèles personnalisés ?

Model Serving peut déployer n’importe quel modèle Python en tant qu’API de niveau production. Databricks fait référence à des modèles tels que les modèles personnalisés. Ces modèles de ML peuvent être entraînés à l’aide de bibliothèques ML standard telles que scikit-learn, XGBoost, PyTorch et les transformateurs HuggingFace, et peuvent inclure n'importe quel code Python.

Pour déployer un modèle personnalisé :

Consignez le modèle ou le code au format MLflow, à l’aide de versions intégrées MLflow natives ou pyfunc.
Une fois le modèle enregistré, inscrivez-le dans Unity Catalog (recommandé) ou dans le registre de l’espace de travail.
À partir de là, vous pouvez créer un point de terminaison de service de modèle pour déployer et interroger votre modèle.
1. Consultez Créer des points de terminaison pour des modèles personnalisés
2. Consultez Points de terminaison de service de requête pour les modèles personnalisés.

Pour obtenir un tutoriel complet sur la façon de servir des modèles personnalisés sur Databricks, consultez Tutoriel sur la mise en service de modèles.

Databricks prend également en charge le service des modèles d’IA générative pour les applications d'IA générative. Consultez les API des modèles de fondation et les modèles externes pour connaître les modèles pris en charge et les offres de calcul disponibles.

Important

Si vous vous reposez sur Anaconda, consultez l’avis de conditions d’utilisation du service pour plus d’informations.

Journaliser des modèles de ML

Il existe différentes méthodes de journalisation de votre modèle de ML pour la mise en service de modèle. La liste suivante récapitule les méthodes et exemples pris en charge.

L’autologging Cette méthode est automatiquement activée lors de l’utilisation de Databricks Runtime pour ML.

import mlflow
from sklearn.ensemble import RandomForestRegressor
from sklearn.datasets import load_iris

iris = load_iris()
model = RandomForestRegressor()
model.fit(iris.data, iris.target)

Journal à l’aide de saveurs intégrées de MLflow. Vous pouvez utiliser cette méthode si vous souhaitez enregistrer manuellement le modèle pour un contrôle plus détaillé.

import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.datasets import load_iris

iris = load_iris()
model = RandomForestClassifier()
model.fit(iris.data, iris.target)

with mlflow.start_run():
    mlflow.sklearn.log_model(model, "random_forest_classifier")

Journalisation personnalisée avec pyfunc. Vous pouvez utiliser cette méthode pour déployer des modèles de code Python arbitraires ou déployer du code supplémentaire en même temps que votre modèle.

  import mlflow
  import mlflow.pyfunc

  class Model(mlflow.pyfunc.PythonModel):
      def predict(self, context, model_input):
          return model_input * 2

  with mlflow.start_run():
      mlflow.pyfunc.log_model("custom_model", python_model=Model())

Télécharger à partir de HuggingFace. Vous pouvez télécharger un modèle directement depuis Hugging Face et enregistrer ce modèle pour le servir. Pour obtenir des exemples, consultez les exemples Notebook.

Exemples de signature et d’entrée

L’ajout d’une signature et d’un exemple d’entrée à MLflow est recommandé. Les signatures sont nécessaires pour la journalisation des modèles dans Unity Catalog.

Voici un exemple de signature :

from mlflow.models.signature import infer_signature

signature = infer_signature(training_data, model.predict(training_data))
mlflow.sklearn.log_model(model, "model", signature=signature)

Voici un exemple d’entrée :


input_example = {"feature1": 0.5, "feature2": 3}
mlflow.sklearn.log_model(model, "model", input_example=input_example)

Type de capacité de calcul

Le Service de modèles Mosaic AI fournit une variété d’options CPU et GPU pour le déploiement de votre modèle. Lors du déploiement avec un GPU, il est essentiel de s’assurer que votre code est configuré afin que les prédictions soient exécutées sur le GPU à l’aide des méthodes fournies par votre infrastructure. MLflow effectue cette opération automatiquement pour les modèles enregistrés avec les saveurs PyTorch ou Transformers.

Type de charge de travail	Instance GPU	mémoire
`CPU`		4 Go par concurrence
`GPU_SMALL`	1xT4	16 Go
`GPU_LARGE`	1xA100	80Go
`GPU_LARGE_2`	2xA100	160Go

Conteneur de déploiement et dépendances

Pendant le déploiement, un conteneur de niveau production est généré et déployé en tant que point de terminaison. Ce conteneur inclut des bibliothèques capturées ou spécifiées automatiquement dans le modèle MLflow.

Le conteneur de service de modèle ne contient pas de dépendances préinstallées, ce qui peut entraîner des erreurs de dépendance si toutes les dépendances requises ne sont pas inclues dans le modèle. Lorsque vous rencontrez des problèmes de modèles de déploiement, Databricks vous recommande de tester le modèle localement.

Dépendances des packages et du code

Vous pouvez ajouter des bibliothèques personnalisées ou privées à votre déploiement. Consultez Utiliser des bibliothèques personnalisées Python un service de modèle.

Pour les modèles de saveur native MLflow, les dépendances de package nécessaires sont automatiquement capturées.

Pour les modèles pyfunc personnalisés, les dépendances peuvent être ajoutées explicitement.

Vous pouvez ajouter des dépendances de package à l’aide des éléments suivants :

Paramètre pip_requirements :

mlflow.sklearn.log_model(model, "sklearn-model", pip_requirements = ["scikit-learn", "numpy"])

Paramètre conda_env :


conda_env = {
    'channels': ['defaults'],
    'dependencies': [
        'python=3.7.0',
        'scikit-learn=0.21.3'
    ],
    'name': 'mlflow-env'
}

mlflow.sklearn.log_model(model, "sklearn-model", conda_env = conda_env)

Pour inclure des exigences supplémentaires au-delà de ce qui est capturé automatiquement, utilisez extra_pip_requirements.
```
mlflow.sklearn.log_model(model, "sklearn-model", extra_pip_requirements = ["sklearn_req"])
```

Si vous avez des dépendances de code, celles-ci peuvent être spécifiées à l’aide de code_path.

  mlflow.sklearn.log_model(model, "sklearn-model", code_path=["path/to/helper_functions.py"],)

Validation de dépendances

Avant de déployer un modèle MLflow personnalisé, il est avantageux de vérifier que le modèle peut être pris en charge. MLflow offre une API permettant de valider l’artefact de modèle qui simule l’environnement de déploiement et permet d’effectuer des tests des dépendances modifiées.

Il existe deux API de validation préalables au déploiement : l’API MLflow Python et l’interface CLI MLflow.

Vous pouvez spécifier les éléments suivants en utilisant l’une de ces API.

L’model_uri du modèle qui est déployé vers la mise en service de modèles.
Celui-ci peut avoir l'une des valeurs suivantes :
- Les input_data au format attendu pour l’appel mlflow.pyfunc.PyFuncModel.predict() du modèle.
- Le input_path qui définit un fichier contenant des données d’entrée chargées et utilisées pour l’appel à predict.
Le content_type au format csv ou json.
Un output_path facultatif pour écrire les prédictions dans un fichier. Si vous omettez ce paramètre, les prédictions sont imprimées dans stdout.
Un gestionnaire d’environnement, env_manager, utilisé afin de générer l’environnement pour la mise en service :
- Par défaut, il s’agit de virtualenv. Recommandé pour la validation de la mise en service.
- local est disponible, mais il est éventuellement sujet à erreurs pour la validation de la mise en service. Généralement utilisé uniquement pour un débogage rapide.
Pour décider d’installer la version actuelle de MLflow qui est dans votre environnement avec l’environnement virtuel en utilisant install_mlflow. Le paramètre a la valeur False par défaut.
Pour décider de mettre à jour et de tester différentes versions de dépendances de packages afin de résoudre des problèmes ou d’effectuer des débogages. Vous pouvez spécifier cet élément, car une liste de dépendances de chaîne effectue une action de remplacement ou d’ajout en tirant parti de l’argument de remplacement, pip_requirements_override.

Par exemple :

import mlflow

run_id = "..."
model_uri = f"runs:/{run_id}/model"

mlflow.models.predict(
  model_uri=model_uri,
  input_data={"col1": 34.2, "col2": 11.2, "col3": "green"},
  content_type="json",
  env_manager="virtualenv",
  install_mlflow=False,
  pip_requirements_override=["pillow==10.3.0", "scipy==1.13.0"],
)

Mises à jour des dépendances

S’il existe des problèmes liés aux dépendances spécifiées avec un modèle enregistré, vous pouvez mettre à jour les exigences en utilisant l’interface CLI MLflow ou de mlflow.models.model.update_model_requirements() dans l’API MLflow Python sans devoir enregistrer un modèle.

L’exemple suivant présente comment mettre à jour les pip_requirements.txt d’un modèle enregistré sur place.

Vous pouvez mettre à jour des définitions existantes avec des versions de package spécifiées ou ajouter des exigences inexistantes dans le fichier pip_requirements.txt. Ce fichier se trouve au sein de l’artefact de modèle MLflow dans l’emplacement model_uri spécifié.

from mlflow.models.model import update_model_requirements

update_model_requirements(
  model_uri=model_uri,
  operation="add",
  requirement_list=["pillow==10.2.0", "scipy==1.12.0"],
)

Attentes et limitations

Les sections suivantes décrivent les attentes et limitations connues pour le service des modèles personnalisés en utilisant Model Serving.

Attentes en matière de création et de mise à jour des points de terminaison

Remarque

Les informations contenues dans cette section ne s’appliquent pas aux points de terminaison qui servent des modèles de base ou des modèles externes.

Le déploiement d’une version de modèle nouvellement inscrite implique l’empaquetage du modèle et de son environnement de modèle et l’approvisionnement du point de terminaison du modèle lui-même. Ce processus peut prendre environ 10 minutes.

Azure Databricks effectue une mise à jour sans temps d’arrêt des points de terminaison en conservant la configuration de point de terminaison existante jusqu’à ce que le nouveau soit prêt. Cela réduit le risque d’interruption pour les points de terminaison en cours d’utilisation.

Si le calcul du modèle prend plus de 120 secondes, les requêtes expirent. Si vous pensez que votre calcul de modèle prendra plus de 120 secondes, contactez votre équipe de compte Azure Databricks.

Databricks effectue occasionnellement des opérations de maintenance et de mise à jour du système sans temps d’arrêt sur des points de terminaison de service de modèles existants. Pendant la maintenance, Databricks recharge les modèles et marque un point de terminaison comme ayant échoué si un modèle ne parvient pas à se recharger. Assurez-vous que vos modèles personnalisés sont robustes et qu’ils peuvent se recharger à tout moment.

Attentes de mise à l’échelle des points de terminaison

Remarque

Les informations contenues dans cette section ne s’appliquent pas aux points de terminaison qui servent des modèles de base ou des modèles externes.

Les points de terminaison de service sont automatiquement mis à l’échelle en fonction du trafic et de la capacité des unités d’accès concurrentiel approvisionnées.

Accès concurrentiel approvisionné : nombre maximal de demandes parallèles que le système peut gérer. Estimez la concurrence requise à l’aide de la formule : concurrence approvisionnée = requêtes par seconde (RPS) * temps d’exécution du modèle.
Comportement de mise à l’échelle : les points de terminaison effectuent un scale-up presque immédiatement avec une augmentation du trafic et un scale-down toutes les cinq minutes pour correspondre au trafic réduit.
Mise à l’échelle à zéro : les points de terminaison peuvent être réduits à zéro après 30 minutes d’inactivité. La première requête après la mise à l’échelle à zéro subit un « démarrage à froid », ce qui entraîne une latence plus élevée. Pour les applications sensibles à la latence, envisagez de gérer efficacement cette fonctionnalité.

Limitations de la charge de travail GPU

Voici les limitations relatives aux points de terminaison de service avec des charges de travail GPU :

La création d'images de conteneur pour le service GPU prend plus de temps que la création d'images pour le service CPU en raison de la taille du modèle et des exigences d'installation accrues pour les modèles servis sur GPU.
Lors du déploiement de très grands modèles, le processus de déploiement peut expirer si la création du conteneur et le modèle de déploiement dépassent une durée de 60 minutes. Si cela se produit, le lancement d’une nouvelle tentative du processus devrait permettre de déployer le modèle avec succès.
La mise à l'échelle automatique pour le service GPU prend plus de temps que pour le service CPU.
La capacité GPU n’est pas garantie lors d’une mise à l’échelle vers zéro. Les points de terminaison GPU peuvent s’attendre à une latence élevée supplémentaire pour la première requête après la mise à l’échelle vers zéro.
La fonctionnalité n’est pas disponible en langage northcentralus.

Mise à jour des licences Anaconda

L’avis suivant concerne les clients qui s’appuient sur Anaconda.

Important

Anaconda Inc. a mis à jour ses conditions d’utilisation du service pour les canaux anaconda.org. Les nouvelles conditions d’utilisation du service peuvent vous imposer d’avoir une licence commerciale pour utiliser une distribution et des packages Anaconda. Pour plus d’informations, consultez le Forum aux questions sur l’édition commerciale d’Anaconda. Votre utilisation des canaux Anaconda est régie par leurs conditions d’utilisation du service.

Les modèles MLflow enregistrés avant la version 1.18 (Databricks Runtime 8.3 ML ou version antérieure) étaient enregistrés par défaut avec le canal conda defaults (https://repo.anaconda.com/pkgs/) en tant que dépendance. En raison de cette modification de licence, Databricks a arrêté l’utilisation du canal defaults pour les modèles enregistrés à l’aide de MLflow v1.18 et versions ultérieures. Le canal par défaut journalisé est maintenant conda-forge, qui pointe vers https://conda-forge.org/, géré par la communauté.

Si vous avez enregistré un modèle avant MLflow v1.18 sans exclure le canal defaults de l’environnement conda pour le modèle, ce modèle peut avoir une dépendance sur le canal defaults que vous n’avez peut-être pas prévue. Pour vérifier manuellement si un modèle a cette dépendance, vous pouvez examiner la valeur channel dans le fichier conda.yaml empaqueté avec le modèle journalisé. Par exemple, les modèles conda.yaml avec une dépendance de canal defaults peuvent ressembler à ceci :

channels:
- defaults
dependencies:
- python=3.8.8
- pip
- pip:
    - mlflow
    - scikit-learn==0.23.2
    - cloudpickle==1.6.0
      name: mlflow-env

Étant donné que Databricks ne peut pas déterminer si votre utilisation du référentiel Anaconda pour interagir avec vos modèles est autorisée dans votre relation avec Anaconda, Databricks n’oblige pas ses clients à apporter des modifications. Si votre utilisation du référentiel Anaconda.com par le biais de l’utilisation de Databricks est autorisée selon les conditions d’Anaconda, vous n’avez pas besoin d’effectuer d’action.

Si vous souhaitez modifier le canal utilisé dans l’environnement d’un modèle, vous pouvez réinscrire le modèle dans le registre de modèles avec un nouveau conda.yaml. Pour ce faire, spécifiez le canal dans le paramètre conda_env de log_model().

Pour plus d’informations sur l’API log_model(), consultez la documentation MLflow pour la version de modèle que vous utilisez, par exemple, log_model pour scikit-learn.

Pour plus d’informations sur les fichiers conda.yaml, consultez la documentation MLflow.

Partage via