Vue d’ensemble des modèles personnalisés

Cet article décrit la prise en charge des modèles personnalisés à l’aide de Mosaïque AI Model Serve. Il fournit des détails sur les options de journalisation des modèles et les types de calcul pris en charge, sur la façon d'empaqueter les dépendances de modèle pour le service, et sur les attentes concernant 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 ou code personnalisé en tant qu’API de niveau production à l’aide de ressources de calcul processeur ou GPU. Databricks fait référence à des modèles tels que des 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 des saveurs intégrées MLflow natives ou de 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 le didacticiel Sur le service de modèles.

Databricks prend également en charge la prise en charge des modèles de base pour les applications d’IA génératives, consultez les API Foundation Model et les modèles externes pour les modèles pris en charge et les offres de calcul.

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.

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)

Connectez-vous à 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é.

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 de bloc-notes.

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, vous devez vous 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
`GPU_LARGE_4`	4xA100	320 Go

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. 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 spécifiées explicitement dans votre modèle MLflow.

Si toutes les dépendances requises ne sont pas incluses dans le modèle, vous pouvez rencontrer des erreurs de dépendance pendant le déploiement. 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 Python personnalisées avec Model Service.

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

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"],)

Pour plus d’informations sur la validation et la mise à jour des dépendances avant le déploiement, consultez la validation de prédéploiement pour le service de modèle.

Attentes et limitations

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

Temps de déploiement : le déploiement d’une version de modèle nouvellement inscrite implique l’empaquetage du modèle et son environnement de modèle et l’approvisionnement du point de terminaison de modèle lui-même. Ce processus peut prendre environ 10 minutes, mais peut prendre plus de temps en fonction de la complexité, de la taille et des dépendances du modèle.
Mises à jour sans temps d’arrêt : 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. Pendant ce processus de mise à jour, vous êtes facturé pour les anciennes et nouvelles configurations de point de terminaison jusqu’à ce que la transition soit terminée.
Délai d’expiration de la demande : si le calcul du modèle prend plus de 297 secondes, les requêtes expirent.

Important

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. Si un modèle ne parvient pas à recharger, la mise à jour du point de terminaison est marquée comme ayant échoué et la configuration du point de terminaison existante continue de traiter les demandes. 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

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 provisionné : Nombre maximal de requêtes 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. Pour valider votre configuration d’accès concurrentiel, consultez Test de charge pour les points de terminaison de service.
Comportement de mise à l’échelle : Les points de terminaison augmentent presque immédiatement avec une augmentation du trafic et se réduisent toutes les cinq minutes pour correspondre à la réduction du trafic.
Mettre à l’échelle à zéro : La mise à l’échelle à zéro est une fonctionnalité facultative pour les points de terminaison 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 vers zéro subit un « démarrage à froid », ce qui entraîne une latence plus élevée. L'augmentation à partir de zéro prend généralement 10 à 20 secondes, mais peut parfois prendre plusieurs minutes. Aucun SLA n'existe pour l'échelle à partir de latence nulle.
Optimisation de l’itinéraire : Pour les cas d’utilisation à faible latence et QPS élevés, l’optimisation des itinéraires est l’option optimale et recommandée pour améliorer les performances.
Déploiements optimisés serverless : Pour accélérer la vitesse de déploiement des points de terminaison, utilisez des déploiements optimisés serverless.

Avertissement

La mise à l’échelle à zéro ne doit pas être utilisée pour les charges de travail de production qui nécessitent une durée de fonctionnement cohérente ou des temps de réponse garantis. Pour les applications ou points de terminaison sensibles à la latence nécessitant une disponibilité continue, désactivez la mise à l’échelle à zéro.

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.
Lorsqu'on déploie des modèles très volumineux, le processus de déploiement peut expirer si la génération du conteneur et le déploiement du modèle dépassent une durée de 60 minutes, ou la construction du conteneur peut échouer avec l’erreur « Pas d’espace disponible sur le périphérique » en raison de limitations de stockage. Pour les modèles de langage volumineux, utilisez plutôt les API Foundation Model .
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.

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

Remarque

Cette section s’applique uniquement aux modèles enregistré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 concerne les clients qui s’appuient sur Anaconda avec d'anciens modèles.

Important

Anaconda Inc. a mis à jour leurs conditions d’utilisation pour les canaux anaconda.org. En fonction des nouvelles conditions d’utilisation, vous pouvez exiger une licence commerciale si vous vous appuyez sur l’emballage et la distribution d’Anaconda. Pour plus d’informations, consultez la FAQ Anaconda Commercial Edition . 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/) comme 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, un modèle avec une conda.yaml dépendance de defaults canal peut 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 dépôt Anaconda.com par le biais de l’utilisation de Databricks est autorisée sous les termes 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 avec laquelle vous travaillez, par exemple , log_model pour scikit-learn.

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

Ressources supplémentaires

Rétroaction

Cette page a-t-elle été utile ?

Last updated on 2025-12-19