Aller au contenu principal
Dernière mise à jour le

MLflow Model Serving hérité sur Databricks

info

Aperçu

Cette fonctionnalité est en aperçu public.

important
  • Cette documentation a été retirée et pourrait ne pas être mise à jour. Les produits, services ou technologies mentionnés dans ce contenu ne sont plus pris en charge.
  • Les orientations de cet article concernent le Legacy MLflow Model Serving. Databricks vous recommande de migrer vos workflows de déploiement de modèles vers Model Serving pour un déploiement et une évolutivité améliorés des Endpoint de modèle. Pour plus d'informations, consultez Déployer des modèles à l'aide de Model Serving.

Legacy MLflow Model Serving vous permet d'héberger des modèles de machine learning à partir du Model Registry en tant qu'Endpoints REST qui sont mis à jour automatiquement en fonction de la disponibilité des versions de modèles et de leurs étapes. Il utilise un cluster à nœud unique qui s'exécute sous votre propre compte dans ce qui est maintenant appelé le plan de compute classique. Ce plan de compute comprend le réseau virtuel et ses ressources de compute associées, tels que des clusters pour notebooks et jobs, des SQL Warehouses pro et classiques, et des Endpoints de service de modèles hérités.

Lorsque vous activez Model Serving pour un modèle enregistré donné, Databricks crée automatiquement un cluster unique pour le modèle et déploie toutes les versions non archivées du modèle sur ce cluster. Databricks redémarre le cluster si une erreur se produit et arrête le cluster lorsque vous désactivez Model Serving pour le modèle. Model Serving se synchronise automatiquement avec Model Registry et déploie toutes les nouvelles versions de modèles enregistrées. Les versions de modèle déployées peuvent être interrogées avec une requête d'API REST standard. Databricks authentifie les requêtes vers le modèle en utilisant son authentification standard.

Pendant que ce service est en préversion, Databricks recommande son utilisation pour les applications à faible throughput et non critiques. Le throughput cible est de 200 qps et la disponibilité cible est de 99,5 %, bien qu'aucune garantie ne soit donnée pour l'un ou l'autre. De plus, il existe une limite de taille de charge utile de 16 Mo par requête.

Chaque version du modèle est déployée à l'aide du déploiement de modèles MLflow et s'exécute dans un environnement Conda spécifié par ses dépendances.

remarque
  • Le cluster est maintenu tant que le service est activé, même si aucune version de modèle active n'existe. Pour arrêter le cluster de service, désactivez la mise à disposition de modèles pour le modèle enregistré.
  • Le cluster est considéré comme un cluster multifonction, soumis aux Tarifs des charges de travail multifonctions.
  • Les scripts d’initialisation globaux ne sont pas exécutés sur les clusters de service de modèle.
important

Anaconda Inc. a mis à jour ses conditions d'utilisation pour les canaux de distribution anaconda.org. Selon les nouvelles conditions d'utilisation, il se peut que vous ayez besoin d'une licence commerciale si vous vous basez sur l'empaquetage et la distribution d'Anaconda. Voir la FAQ d'Anaconda Commercial Edition pour plus d'informations. Votre utilisation des canaux de distribution Anaconda est régie par leurs conditions d'utilisation.

Les modèles MLflow enregistrés avant v1.18 (Databricks Runtime 8.3 ML ou antérieur) étaient par default enregistrés avec le Canal de distribution conda defaults (https://repo.anaconda.com/pkgs/) en tant que dépendance. En raison de cette modification de licence, Databricks a cessé d'utiliser le canal de distribution defaults pour les modèles enregistrés avec MLflow v1.18 et versions ultérieures. Le Canal de distribution par default enregistré est maintenant conda-forge, qui pointe vers la https://conda-forge.org/ gérée par la Communauté.

Si vous avez enregistré un modèle avant MLflow v1.18 sans exclure le canal de distribution defaults de l'environnement conda pour le modèle, ce modèle peut avoir une dépendance vis-à-vis du canal de distribution defaults que vous n'aviez pas l'intention d'avoir. Pour confirmer manuellement si un modèle a cette dépendance, vous pouvez examiner la valeur channel dans le fichier conda.yaml qui est empaqueté avec le modèle enregistré. Par exemple, le conda.yaml d'un modèle avec une dépendance vis-à-vis du canal de distribution defaults peut ressembler à ceci :

YAML
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 repository Anaconda pour interagir avec vos modèles est autorisée dans le cadre de votre relation avec Anaconda, Databricks n'oblige pas ses clients à apporter des modifications. Si votre utilisation du repository Anaconda.com via Databricks est autorisée selon les conditions d'Anaconda, vous n'avez pas besoin d'agir.

Si vous souhaitez modifier le canal de distribution utilisé dans l’environnement d’un modèle, vous pouvez réenregistrer le modèle dans le registre des modèles avec un nouveau conda.yaml. Vous pouvez le faire en spécifiant le Canal de distribution dans le paramètre conda_env de log_model().

Pour plus d'informations sur l'API log_model(), consultez la documentation MLflow pour le type de modèle avec lequel vous travaillez, par exemple, log_model pour scikit-learn.

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

Exigences​

Déploiement de modèles à partir du Model Registry​

Le déploiement de modèles est disponible dans Databricks depuis le Model Registry.

Activer et désactiver le déploiement de modèles​

Vous activez un modèle pour le déploiement à partir de sa page de modèle enregistré.

  1. Cliquez sur l’onglet tab . Si le modèle n’est pas déjà activé pour le déploiement, le bouton Activer le déploiement apparaît.

    Bouton Activer le déploiement

  2. Cliquez sur Activer le service . L'onglet Serving s'affiche avec le Statut affiché comme « En attente ». Après quelques minutes, le Statut passe à Prêt.

Pour désactiver la mise à disposition d'un modèle, cliquez sur **Arrêter**.

Valider la mise à disposition de modèles​

Depuis l'onglet Serving , vous pouvez envoyer une requête au modèle servi et visualiser la réponse.

Activer le service

URI de version de modèle​

Chaque version de modèle déployée se voit attribuer un ou plusieurs URI uniques. Au minimum, chaque version de modèle se voit attribuer un URI construit comme suit :

<databricks-instance>/model/<registered-model-name>/<model-version>/invocations

Par exemple, pour appeler la version 1 d'un modèle enregistré sous le nom iris-classifier, utilisez cette URI :

https://<databricks-instance>/model/iris-classifier/1/invocations

Vous pouvez également appeler une version de modèle par son étape. Par exemple, si la version 1 est à l'étape Production , elle peut également être scorée à l'aide de cet URI :

https://<databricks-instance>/model/iris-classifier/Production/invocations

La liste des URI de modèles disponibles apparaît en haut de l'onglet Versions de modèle sur la page de mise en service.

Gérer les versions servies​

Toutes les versions de modèle actives (non archivées) sont déployées, et vous pouvez les interroger à l'aide des URI. Databricks déploie automatiquement les nouvelles versions de modèle lorsqu'elles sont enregistrées, et supprime automatiquement les anciennes versions lorsqu'elles sont archivées.

remarque

Toutes les versions déployées d'un modèle enregistré partagent le même cluster.

Gérer les droits d'accès aux modèles​

Les droits d'accès au modèle sont hérités du Model Registry. L'activation ou la désactivation de la fonctionnalité de déploiement nécessite l'autorisation 'Gérer' sur le modèle enregistré. Toute personne disposant de droits de lecture peut évaluer n'importe laquelle des versions déployées.

Évaluer les versions de modèle déployées​

Pour évaluer un modèle déployé, vous pouvez utiliser l’interface utilisateur ou envoyer une requête d’API REST à l’URI du modèle.

Noter via l'interface utilisateur​

C'est le moyen le plus simple et le plus rapide de tester le modèle. Vous pouvez insérer les données d'entrée du modèle au format JSON et cliquer sur Envoyer la demande . Si le modèle a été enregistré avec un exemple d'entrée (comme illustré dans le graphique ci-dessus), cliquez sur Charger l'exemple pour charger l'exemple d'entrée.

Score via une requête d'API REST​

Vous pouvez envoyer une requête de scoring via l'API REST en utilisant l'authentification standard Databricks. Les exemples ci-dessous montrent l'authentification à l'aide d'un jeton d'accès personnel avec MLflow 1.x.

remarque

En tant que bonne pratique de sécurité lorsque vous vous authentifiez avec des outils, des systèmes, des scripts et des applications automatisés, Databricks vous recommande d'utiliser des jetons OAuth.

Si vous utilisez l'authentification par jeton d'accès personnel, Databricks recommande d'utiliser des jetons d'accès personnels appartenant aux Service Principal plutôt qu'aux utilisateurs du Workspace. Pour créer des jetons pour les Service Principals, consultez Gérer les jetons pour un Service Principal.

Étant donné un MODEL_VERSION_URI tel que https://<databricks-instance>/model/iris-classifier/Production/invocations (où <databricks-instance> est le nom de votre instance Databricks) et un jeton d'API REST Databricks appelé DATABRICKS_API_TOKEN, les exemples suivants montrent comment query un modèle déployé :

Les exemples suivants reflètent le format de notation pour les modèles créés avec MLflow 1.x. Si vous préférez utiliser MLflow 2.0, vous devez mettre à jour le format de votre charge utile de requête.

Extrait pour query un modèle acceptant les entrées de dataframe.

Bash
curl -X POST -u token:$DATABRICKS_API_TOKEN $MODEL_VERSION_URI \
  -H 'Content-Type: application/json' \
  -d '[
    {
      "sepal_length": 5.1,
      "sepal_width": 3.5,
      "petal_length": 1.4,
      "petal_width": 0.2
    }
  ]'

Extrait pour interroger un modèle acceptant des entrées tensor. Les entrées tensor doivent être formatées comme décrit dans les documents de l'API de TensorFlow Serving.

Bash
curl -X POST -u token:$DATABRICKS_API_TOKEN $MODEL_VERSION_URI \
   -H 'Content-Type: application/json' \
   -d '{"inputs": [[5.1, 3.5, 1.4, 0.2]]}'

Surveiller les modèles déployés​

La page de mise en service affiche les indicateurs d'état pour le cluster de mise en service ainsi que les versions de modèles individuelles.

  • Pour inspecter l'état du cluster de service, utilisez l'onglet **Model Events tab**, qui affiche une liste de tous les événements de service pour ce modèle.
  • Pour inspecter l'état d'une seule version de modèle, cliquez sur le tab Versions du modèle et faites défiler pour afficher les Logs ou Événements de version tabs.

Serving tab

Personnaliser le cluster de service​

Pour personnaliser le cluster de service, utilisez l'onglet Paramètres du cluster de l'onglet Serving .

Paramètres du cluster

  • Pour modifier la taille de la mémoire et le nombre de cœurs d'un cluster de service, utilisez le menu déroulant **Type d'instance** pour sélectionner la configuration de cluster souhaitée. Lorsque vous cliquez sur **Enregistrer**, le cluster existant est terminé et un nouveau cluster est créé avec les paramètres spécifiés.
  • Pour ajouter une balise, saisissez le nom et la valeur dans les champs Ajouter une balise et cliquez sur Ajouter .
  • Pour modifier ou supprimer un tag existant, cliquez sur l’une des icônes de la colonne **actions** du tableau **tags**.

Intégration du magasin de fonctionnalités​

Le service de modèles hérité peut rechercher automatiquement les valeurs de fonctionnalités dans les magasins en ligne publiés.

Databricks Legacy MLflow Model Serving prend en charge la recherche automatique de fonctionnalités à partir de ces magasins en ligne :

  • Amazon DynamoDB (v0.3.8 et supérieur)
  • Amazon Aurora (compatible MySQL)
  • Amazon RDS MySQL

Erreurs connues​

ResolvePackageNotFound: pyspark=3.1.0

Cette erreur peut se produire si un modèle dépend de pyspark et est journalisé à l'aide de Databricks Runtime 8.x. Si vous voyez cette erreur, spécifiez explicitement la version pyspark lors de la journalisation du modèle, en utilisant le conda_env parameter.

Unrecognized content type parameters: format

Cette erreur peut se produire en raison du nouveau format de protocole de scoring MLflow 2,0. Si vous voyez cette erreur, vous utilisez probablement un format de requête d’évaluation obsolète. Pour résoudre l'erreur, vous pouvez effectuer l'une des actions suivantes :

  • Mettez à jour le format de votre demande de notation vers le dernier protocole.
remarque

Les exemples suivants reflètent le format de score introduit dans MLflow 2,0. Si vous préférez utiliser MLflow 1.x, vous pouvez modifier vos appels log_model() API pour inclure la dépendance de version MLflow souhaitée dans le parameter extra_pip_requirements. Cela garantit que le format de scoring approprié est utilisé.

Python
    mlflow.<flavor>.log_model(..., extra_pip_requirements=["mlflow==1.*"])

Interrogez un modèle acceptant les entrées de DataFrame pandas.

Bash
curl -X POST -u token:$DATABRICKS_API_TOKEN $MODEL_VERSION_URI \
  -H 'Content-Type: application/json' \
  -d '{
      "dataframe_records": [{"sepal_length (cm)": 5.1, "sepal_width (cm)": 3.5, "petal_length (cm)": 1.4, "petal_width": 0.2},
                            {"sepal_length (cm)": 4.2, "sepal_width (cm)": 5.0, "petal_length (cm)": 0.8, "petal_width": 0.5}]
      }'

Query un modèle acceptant des entrées tensor. Les entrées tensor doivent être formatées comme décrit dans les documents de l'API de TensorFlow Serving.

Bash
curl -X POST -u token:$DATABRICKS_API_TOKEN $MODEL_VERSION_URI \
  -H 'Content-Type: application/json' \
  -d '{"inputs": [[5.1, 3.5, 1.4, 0.2]]}'

Pour plus d’informations sur les formats de données d’entrée acceptés par le serveur (par exemple, le format orienté fractionnement pandas), consultez la documentation MLflow.

Sur cette page