Aller au contenu principal

Déploiements express pour les Endpoint de service de modèle

Cette page décrit comment utiliser les déploiements express sur vos Endpoint de service de modèle. Les déploiements express réduisent les temps de déploiement et maintiennent l'environnement de service de modèle identique à l'environnement d'entraînement de modèle.

remarque

Les déploiements Express étaient auparavant appelés déploiements optimisés Serverless.

Que sont les déploiements express ?

Les déploiements express empaquettent et mettent en scène les artefacts de modèle dans des environnements de Notebook Serverless pendant l'enregistrement du modèle. Cela accélère le déploiement d'endpoint et maintient les environnements d'entraînement et de service cohérents.

Dans les déploiements non express, les artefacts de modèle et les environnements sont empaquetés dans des conteneurs au moment du déploiement, de sorte que l'environnement de service pourrait ne pas correspondre à celui utilisé pendant l'entraînement du modèle.

Déploiements standard vs express

Le tableau suivant compare un déploiement standard et un déploiement express.

Aspect

Déploiement standard

Déploiement express

Lorsque l'environnement est créé

Une image de conteneur est créée au moment du déploiement.

Les artefacts et l'environnement sont empaquetés lorsque vous enregistrez le modèle.

Environnement d'entraînement et de service

L'environnement de service pourrait ne pas correspondre à l'environnement d'entraînement.

L'environnement de service est identique à l'environnement du Notebook à partir duquel vous vous êtes enregistré.

Vitesse de déploiement

Plus lent. Le déploiement attend une build d'image de conteneur.

Plus rapide. Le déploiement ignore la build d'image de conteneur.

Vitesse d'enregistrement

Standard.

Ajoute des secondes à une minute pour le packaging, en fonction de la taille du modèle et de l'environnement.

Journal des événements de déploiement

Affiche les événements de création d'images de conteneurs.

Ne montre pas les événements de création d'image de conteneur.

Aspect

Déploiement standard

Déploiement express

Lorsque l'environnement est créé

Une image de conteneur est créée au moment du déploiement.

Les artefacts et l'environnement sont empaquetés lorsque vous enregistrez le modèle.

Environnement d'entraînement et de service

L'environnement de service pourrait ne pas correspondre à l'environnement d'entraînement.

L'environnement de service est identique à l'environnement du Notebook à partir duquel vous vous êtes enregistré.

Vitesse de déploiement

Plus lent. Le déploiement attend une build d'image de conteneur.

Plus rapide. Le déploiement ignore la build d'image de conteneur.

Vitesse d'enregistrement

Standard.

Ajoute des secondes à une minute pour le packaging, en fonction de la taille du modèle et de l'environnement.

Journal des événements de déploiement

Affiche les événements de création d'images de conteneurs.

Ne montre pas les événements de création d'image de conteneur.

Les déploiements express transfèrent le travail de packaging unique à l'enregistrement du modèle, ce qui ajoute de quelques secondes à une minute à un appel register_model, en fonction de la taille du modèle et de l'environnement. En contrepartie, le déploiement est considérablement plus rapide : il ignore entièrement la construction de l'image de conteneur. Cette construction est également une source courante d'échecs de déploiement (résolution des dépendances, erreurs de build d'images) ; la contourner élimine toute une catégorie de problèmes. Le log des événements de déploiement pour un modèle express ne contient aucun événement de build de conteneur.

Exigences

Les Endpoint de déploiement express ont les mêmes exigences qu'un Endpoint de service de modèle. Consultez les exigences.

En outre :

  • Le modèle doit être un modèle personnalisé
  • Le modèle doit être journalisé et enregistré dans un Notebook Serverless en utilisant la version 3 ou ultérieure.
  • Le modèle doit être journalisé et enregistré avec mlflow>=3.12 et databricks-sdk>=0.102.0
  • Le modèle doit être enregistré dans Unity Catalog. Le compute de diffusion doit correspondre au compute à partir duquel le modèle a été enregistré. Vous pouvez vous inscrire à partir d'un Notebook serverless standard pour servir sur CPU, ou à partir d'un compute GPU serverless pour servir sur GPU.
  • La taille maximale de l'environnement du modèle est de 200 Go
remarque

Pour servir un LLM personnalisé sur compute GPU en utilisant des déploiements express, consultez Servir des LLM personnalisés avec un Model Serving personnalisé.

Déployer un réordonnanceur sur GPU

Ce guide déploie BAAI/bge-reranker-base, un réordonnanceur à encodeur croisé qui évalue la pertinence avec laquelle un document répond à une query. Il configure l'environnement, Logs et ajoute le modèle au registre avec un package express, déploie l'Endpoint et le query.

Les déploiements de GPU échouent souvent en raison de conflits de version de dépendance, par exemple : torch et CUDA. Les déploiements express résolvent ce problème de deux façons :

  • L'ensemble fixe et publié de bibliothèques préinstallées dans chaque version d'environnement GPU Serverless est présent lors du service exactement tel qu'il est dans le Notebook — même version d'environnement, mêmes versions. Ces bibliothèques ne sont pas remises en package.
  • Toutes les dépendances supplémentaires que vous installez dans la session du Notebook (par exemple, avec %pip install) sont packagées lors de l'enregistrement et restaurées lors du service.

Ensemble, cela signifie qu'un modèle qui s'exécute dans votre Notebook continue de fonctionner lorsqu'il est déployé.

Étape 1 : configurer un notebook GPU serverless

Créez un Notebook sur compute GPU Serverless avec un GPU A10, et sélectionnez **version 5 de l'environnement, environnement IA**. L'environnement IA comprend PyTorch et les bibliothèques courantes de machine learning (torch, transformers, et d'autres). Pour les versions épinglées exactes, consultez l'environnement GPU Serverless version 5 (préversion).

Installez les packages requis pour le déploiement express :

Python
# Express deployment requires recent MLflow and Databricks SDK versions.
%pip install "mlflow>=3.12" "databricks-sdk>=0.102.0"
# Install the libraries your model needs. transformers is preinstalled in the
# v5 AI environment; install it explicitly because this model depends on it.
%pip install transformers
%restart_python

Vous pouvez aussi déclarer les dépendances via un environnement serverless, mais l’installation dans le notebook est la solution la plus simple. Développez à partir des versions épinglées de l’environnement afin que l’environnement du notebook corresponde à l’environnement de service.

Étant donné que ce modèle est servi sur GPU, vous devez l'enregistrer à partir d'un runtime GPU Serverless. Si vous loggez accidentellement depuis un compute CPU Serverless, le modèle est package avec des dépendances CPU et l'Endpoint de service GPU ne start pas. Ajoutez la vérification suivante pour échouer rapidement si le Notebook n'est pas sur un runtime GPU :

Python
import os

# This model is intended to be served on GPU, so we must log and register from a Serverless GPU runtime.
if not os.environ.get("DATABRICKS_ACCELERATOR"):
raise RuntimeError(
"This model MUST be logged+registered from a serverless GPU runtime, otherwise the correct dependencies will not be packaged for serving."
)
remarque

Cette vérification n'est nécessaire que parce que le réorganisateur est déployé sur GPU. Un modèle de CPU n'en a pas besoin.

Étape 2 : Enregistrer le modèle avec MLflow

Chargez le réorganisateur en tant que pipeline text-classification et enregistrez-le avec la variante native mlflow.transformers. La variante native capture automatiquement les dépendances pip du modèle et s'exécute sur GPU. Vous n'avez pas besoin de définir pip_requirements, un task ou un point d'entrée.

Python
import mlflow
from transformers import pipeline

# BAAI/bge-reranker-base is a cross-encoder reranker: it scores how well a document answers a query.
pipe = pipeline("text-classification", model="BAAI/bge-reranker-base")

model_info = mlflow.transformers.log_model(
transformers_model=pipe,
name="bge_reranker",
input_example={
"text": "What is Databricks?",
"text_pair": "Databricks is a data and AI company.",
},
)
important

N'enregistrez pas le modèle avec l'argument registered_model_name de log_model. Cet argument n'accepte pas env_pack, il ajoute donc au registre un modèle non express. Pour activer le déploiement express, enregistrez dans une étape distincte avec register_model (Étape 3), qui accepte env_pack.

Étape 3 : enregistrer le modèle dans Unity Catalog avec le packaging express

Enregistrez le modèle dans Unity Catalog et définissez le parameter env_pack pour activer le déploiement express. Ceci met en package les artefacts du modèle et les dépendances que vous avez ajoutées à la session du Notebook lors de l'enregistrement, afin que le service les réutilise en plus des bibliothèques préinstallées de la version de l'environnement.

Python
import mlflow
from mlflow.utils.env_pack import EnvPackConfig

mlflow.set_registry_uri("databricks-uc")

model_version = mlflow.register_model(
model_uri=model_info.model_uri,
name="main.default.bge_reranker",
env_pack=EnvPackConfig(name="databricks_model_serving"),
)

Vous pouvez utiliser l’abréviation de chaîne env_pack="databricks_model_serving" à la place de EnvPackConfig(name="databricks_model_serving"). Pour les workspaces sans accès Internet ou avec des bibliothèques personnalisées, définissez install_dependencies=False (voir le parameter env_pack).

L'inscription requiert databricks-sdk>=0.102.0. Les versions antérieures peuvent expirer lors de l'upload d'artefacts de modèle volumineux.

Étape 4 : créer un endpoint de service

Déployez le modèle enregistré avec le SDK Databricks. Cette étape de déploiement est la même que pour n’importe quel modèle personnalisé — seule l’étape d’enregistrement (Étape 3) diffère pour express.

Python
from databricks.sdk import WorkspaceClient
from databricks.sdk.service.serving import (
EndpointCoreConfigInput,
ServedEntityInput,
ServingModelWorkloadType,
)

ENDPOINT_NAME = "bge-reranker-endpoint"

w = WorkspaceClient()
w.serving_endpoints.create_and_wait(
name=ENDPOINT_NAME,
config=EndpointCoreConfigInput(
name=ENDPOINT_NAME,
served_entities=[
ServedEntityInput(
name="bge-reranker",
entity_name=model_version.name,
entity_version=model_version.version,
workload_type=ServingModelWorkloadType.GPU_SMALL,
workload_size="Small",
scale_to_zero_enabled=False,
)
],
),
)

create_and_wait bloque jusqu'à ce que l'Endpoint soit prêt. GPU_SMALL est suffisant pour ce réordonnanceur. Étant donné que le service réutilise la même version d'environnement et restaure les dépendances que vous avez ajoutées dans le Notebook, le modèle servi s'exécute avec les mêmes versions de bibliothèque avec lesquelles vous avez développé, quel que soit le type de GPU.

Pendant le déploiement de l’endpoint, ouvrez l’onglet Events de l’endpoint dans l’interface utilisateur de service. Comme il s’agit d’un déploiement express, le log d’événements n’affiche pas les événements de création d’image de conteneur (un déploiement standard affiche Container image creation initiated suivi de Container image creation finished successfully). Lorsque l’endpoint est terminé, son état affiche Ready .

Étape 5 : Query l'Endpoint

Un cross-encoder attribue un score à une query par rapport à un document, donc envoyez les champs text et text_pair. Interrogez par programmation avec le SDK Databricks ou curl.

Python
w.serving_endpoints.query(
name=ENDPOINT_NAME,
dataframe_records=[
{"text": "What is Databricks?", "text_pair": "Databricks is a data and AI company."},
],
)

L'Endpoint renvoie un score de pertinence pour chaque paire query-document ; des scores plus élevés indiquent une meilleure correspondance. Utilisez ces scores pour réordonnancer les documents candidats.

Exemple de Notebook

Importez le Notebook suivant pour exécuter ce guide de bout en bout.

Notebook de démarrage du réorganisateur express

Le parameter env_pack

Le démarrage rapide ci-dessus montre un déploiement express pour un modèle GPU. Les déploiements express fonctionnent aussi pour les modèles CPU. Dans tous les cas, vous activez le déploiement express en passant env_pack à register_model:

Python
import mlflow
from mlflow.utils.env_pack import EnvPackConfig

mlflow.register_model(
model_info.model_uri,
model_name,
env_pack=EnvPackConfig(name="databricks_model_serving"),
)

env_pack empaquette et met en scène les artefacts de modèle et les dépendances que vous avez ajoutées à la session du Notebook au moment de l'enregistrement, c'est pourquoi l'enregistrement prend plus de temps qu'un appel sans env_pack.

EnvPackConfig accepte un parameter install_dependencies (True par default). Lorsque True, les dépendances du modèle sont installées dans l'environnement actuel pour confirmer que l'environnement est valide.

remarque

L'enregistrement peut échouer dans les Workspace sans accès à Internet, ou lorsque le modèle dépend de bibliothèques personnalisées, si install_dependencies est True. Dans ces cas, définissez install_dependencies sur False.

Vous pouvez substituer la chaîne "databricks_model_serving" par EnvPackConfig(...) comme raccourci. C'est l'équivalent de EnvPackConfig(name="databricks_model_serving", install_dependencies=True).