Présentation des modèles personnalisés

Cet article décrit la prise en charge des modèles personnalisés à l’aide de Model Serving. Il fournit des détails sur les options de journalisation de modèle prises en charge et les types de compute, sur la manière d’inclure les dépendances du modèle dans le package pour la mise à disposition, et sur les attentes concernant la création et le scaling des Endpoint.

Que sont les modèles personnalisés ?

Model Serving peut déployer n’importe quel modèle Python ou code personnalisé en tant qu’API de qualité production utilisant des ressources compute CPU ou GPU. Databricks fait référence à ces modèles en tant que modèles personnalisés . Ces modèles ML peuvent être entraînés à l’aide de bibliothèques ML standard comme scikit-learn, XGBoost, PyTorch et les transformeurs HuggingFace, et peuvent inclure n’importe quel code Python.

Pour déployer un modèle personnalisé ,

Enregistrez le modèle ou le code au format MLflow, en utilisant les variantes MLflow intégrées natives ou pyfunc.
Une fois le modèle journalisé, enregistrez-le dans Unity Catalog (recommandé) ou dans le registre du Workspace.
À partir de là, vous pouvez créer un endpoint de Model Serving pour déployer et query votre modèle.
1. Consultez Créer des endpoints de service de modèle personnalisés
2. Voir Endpoint de service de query pour les modèles personnalisés.

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

Databricks prend également en charge le déploiement de modèles de fondation pour les applications d'IA générative. Consultez les APIs de modèles de fondation et les Modèles externes pour connaître les modèles et les offres de compute pris en charge.

Enregistrer des modèles ML

Il existe différentes méthodes pour enregistrer votre modèle ML pour le déploiement de modèles. La liste suivante récapitule les méthodes et exemples pris en charge.

Autologging Cette méthode est activée automatiquement lors de l'utilisation de Databricks Runtime pour le ML.

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

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

Enregistrer à l'aide des 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é.

Python
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 arbitraire ou déployer du code additionnel avec votre modèle.

Python
  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())

Signature et exemples d'entrée

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

Voici un exemple de signature :

Python
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 :

Python

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

Type de compute

Model Serving offre une variété d'options de CPU et de GPU pour le déploiement de votre modèle. Lors du déploiement avec un GPU, vous devez vous assurer que votre code est configuré de manière à ce que les prédictions s'exécutent sur le GPU, en utilisant les méthodes fournies par votre framework. MLflow le fait automatiquement pour les modèles enregistrés avec les saveurs PyTorch ou Transformers.

Les types de charge de travail CPU_MEDIUM et CPU_LARGE vous permettent d’échanger de la concurrence contre davantage de mémoire par Worker sur le même matériel CPU. Utilisez-les lorsque votre modèle a besoin de plus de mémoire que le standard CPU n’en fournit.

Type de Workload	Instance GPU	Mémoire	Notes
`CPU`		4 Go par simultanéité
`CPU_MEDIUM`		8 Go par concurrence
`CPU_LARGE`		16 Go par simultanéité
`GPU_SMALL`	1xT4	16 Go par simultanéité
`GPU_MEDIUM`	1xA10G	24 GB par concurrence
`MULTIGPU_MEDIUM`	4xA10G	96 Go par concurrence
`GPU_MEDIUM_8`	8xA10G	192 Go par simultanéité
`GPU_LARGE` (Bêta)	1xL40	48 Go par simultanéité	Uniquement disponible dans `ap-northeast-2`, `ap-northeast-1`, `us-east-1`, `us-east-2`, `us-west-2` et `eu-central-1`.

Type de Workload	Instance GPU	Mémoire	Notes
`CPU`		4 Go par simultanéité
`CPU_MEDIUM`		8 Go par concurrence
`CPU_LARGE`		16 Go par simultanéité
`GPU_SMALL`	1xT4	16 Go par simultanéité
`GPU_MEDIUM`	1xA10G	24 GB par concurrence
`MULTIGPU_MEDIUM`	4xA10G	96 Go par concurrence
`GPU_MEDIUM_8`	8xA10G	192 Go par simultanéité
`GPU_LARGE` (Bêta)	1xL40	48 Go par simultanéité	Uniquement disponible dans `ap-northeast-2`, `ap-northeast-1`, `us-east-1`, `us-east-2`, `us-west-2` et `eu-central-1`.

Conteneur de déploiement et dépendances

Pendant le déploiement, un conteneur de qualité production est construit et déployé en tant qu'endpoint. Ce conteneur inclut des bibliothèques automatiquement capturées ou spécifiées dans le modèle MLflow. L'image de base peut inclure certaines dépendances au niveau du système, mais les dépendances au niveau de l'application doivent être explicitement spécifiées dans votre modèle MLflow.

Si toutes les dépendances requises ne sont pas incluses dans le modèle, vous pourriez rencontrer des erreurs de dépendance lors du déploiement. En cas de problèmes de déploiement de modèle, Databricks vous recommande de tester le modèle localement.

Dépendances de package et de code

Des bibliothèques personnalisées ou privées peuvent être ajoutées à votre déploiement. Consultez Utiliser des bibliothèques Python personnalisées avec Model Serving.

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 explicitement ajoutées. Pour des informations détaillées sur les exigences de journalisation et les bonnes pratiques, consultez la documentation des modèles MLflow et la référence de l'API Python MLflow.

Vous pouvez ajouter des dépendances de package en utilisant :

Le paramètre pip_requirements :

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

Le paramètre conda_env :

Python

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 automatiquement capturé, utilisez extra_pip_requirements.
Python
```
mlflow.sklearn.log_model(model, "sklearn-model", extra_pip_requirements = ["sklearn_req"])
```

Si vous avez des dépendances de code, vous pouvez les spécifier en utilisant code_path.

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

Pour en savoir plus sur la validation et la mise à jour des dépendances avant le déploiement, voir Validation avant le déploiement pour Model Serving.

Attentes et limites

remarque

Les informations contenues dans cette section ne s'appliquent pas aux Endpoint qui servent des modèles de fondation ou des modèles externes.

Les sections suivantes décrivent les attentes et les limitations connues pour le service de modèles personnalisés à l'aide de Model Serving.

Attentes de création et de mise à jour de l'Endpoint

Durée du déploiement : le déploiement d'une version de modèle nouvellement enregistrée implique la mise en package du modèle et de son environnement de modèle, ainsi que le provisionnement de l'Endpoint du modèle lui-même. Ce processus peut prendre environ 10 minutes, mais peut être plus long selon la complexité, la taille et les dépendances du modèle.
Mises à jour sans temps d'arrêt : Databricks effectue une mise à jour sans temps d'arrêt des endpoints en maintenant la configuration d'endpoint existante active jusqu'à ce que la nouvelle soit prête. Cela réduit le risque d'interruption pour les Endpoint en cours d'utilisation. Pendant ce processus de mise à jour, vous êtes facturé pour les configurations d'endpoint anciennes et nouvelles jusqu'à ce que la transition soit terminée.
Expiration de la requête : Si le calcul du modèle prend plus de 597 secondes, les requêtes expireront.

important

Databricks effectue des mises à jour système et une maintenance occasionnelles sans temps d'arrêt sur les Endpoint Model Serving existants. Pendant la maintenance, Databricks recharge les modèles. Si un modèle ne parvient pas à se recharger, la mise à jour de l'endpoint est marquée comme ayant échoué et la configuration existante de l'endpoint continue de traiter les requêtes. Assurez-vous que vos modèles personnalisés sont robustes et peuvent être rechargés à tout moment.

Attentes en matière de mise à l'échelle de l'Endpoint

Les Endpoints de diffusion montent en charge automatiquement en fonction du trafic et de la capacité des unités de simultanéité provisionnées.

Simultanéité provisionnée : le nombre maximal de requêtes parallèles que le système peut gérer. Estimez la concurrence requise à l’aide de la formule : concurrence provisionnée = requêtes par seconde (QPS) * temps d’exécution du modèle (s). Pour valider votre configuration de simultanéité, consultez Tests de charge pour les Endpoint de service.
Comportement de Monter en charge : les Endpoint montent en charge presque immédiatement en cas d’augmentation du trafic et réduisent leur capacité toutes les cinq minutes pour s’adapter à la baisse du trafic. Les nœuds sont prêts à traiter le trafic une fois le modèle download et que les vérifications d’intégrité sont passées ; la taille du modèle et le temps de chargement déterminent la durée de cette opération.
Mise à l'échelle à zéro : La mise à l'échelle à zéro est une fonctionnalité facultative pour les Endpoint qui leur permet de réduire à zéro après 30 minutes d'inactivité. La première requête après la mise à l'échelle à zéro subit un « cold start », entraînant une latence plus élevée. Le passage de zéro à l'échelle prend généralement de 10 à 20 secondes, mais peut parfois prendre plusieurs minutes. Il n'y a pas de SLA sur la latence de l'évolution à partir de zéro.
Optimisation de l'itinéraire : pour les cas d'utilisation à QPS élevé et à faible latence, l' optimisation de l'itinéraire est l'option optimale et recommandée pour améliorer les performances.
Déploiements Express : Pour une vitesse de déploiement d'endpoint plus rapide, utilisez des déploiements Express.

attention

La mise à zéro ne doit pas être utilisée pour les charges de travail de production qui nécessitent une disponibilité constante ou des temps de réponse garantis. Pour les applications sensibles à la latence ou les Endpoint nécessitant une disponibilité continue, désactivez la mise à zéro.

Limitations des charges de travail GPU

Voici les limitations pour les endpoints de service avec des charges de travail GPU :

La création d'images de conteneurs 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 modèles très volumineux, le processus de déploiement peut expirer si la construction du conteneur et le déploiement du modèle dépassent 60 minutes, ou la construction du conteneur peut échouer avec l'erreur « Plus d'espace sur le périphérique » en raison de limitations de stockage. Pour les grands modèles linguistiques, utilisez plutôt les APIs de modèle de fondation.
L'autoscaling pour le service de GPU prend plus de temps que pour le service de CPU.
La capacité du GPU n'est pas garantie lors de la mise à zéro. Les Endpoint GPU peuvent s'attendre à une latence très élevée lors de la première requête après la mise à zéro.

Avis de licence Anaconda pour les modèles hérités

remarque

Cette section s'applique uniquement aux modèles journalisés avec MLflow v1.17 ou version antérieure (Databricks Runtime 8.3 ML ou version antérieure). Si vous utilisez une version plus récente, vous pouvez ignorer cette section.

L'avis suivant s'adresse aux clients qui utilisent Anaconda avec des modèles hérités.

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.

Que sont les modèles personnalisés ?​

Enregistrer des modèles ML​

Signature et exemples d'entrée​

Type de compute​

Conteneur de déploiement et dépendances​

Dépendances de package et de code​

Attentes et limites​

Attentes de création et de mise à jour de l'Endpoint​

Attentes en matière de mise à l'échelle de l'Endpoint​

Limitations des charges de travail GPU​

Avis de licence Anaconda pour les modèles hérités​

Ressources supplémentaires​