Déployer un Endpoint de mise à disposition de modèle (Triton) optimisé pour le throughput
Bêta
Cette fonctionnalité est en bêta. Les administrateurs du workspace peuvent contrôler l’accès à cette fonctionnalité depuis la page Previews . Consultez Manage Databricks previews.
Model Serving personnalisé peut exécuter votre endpoint GPU avec le backend NVIDIA Triton Inference Server. Triton batch les requêtes entrantes avant qu’elles n’atteignent votre modèle, ce qui augmente le throughput des modèles limités par le GPU en situation de concurrence. Cette page vous montre quand Triton est utile, comment l’activer sur un endpoint de service de modèles GPU et comment vérifier qu’il est actif.
Quand utiliser Triton
Triton regroupe les requêtes simultanées en batches sur le GPU ; il est donc particulièrement utile lorsque le GPU est votre goulot d’étranglement. Les bons candidats sont les charges GPU lourdes et pouvant être traitées par lots, dans un contexte de trafic en temps réel à high concurrency, pour lesquelles les gains de throughput peuvent être substantiels :
- Inférence avec BERT et d’autres transformateurs
- Modèles d’intégration
- CLASSIFICATION D'IMAGES
- DÉTECTION D'OBJETS
Triton s'avère moins utile lorsque le GPU ne constitue pas le goulet d'étranglement, comme c'est le cas pour les petits modèles ou un modèle de vision qui décode et redimensionne les images sur le CPU. Le GPU y reste inactif en attendant le prétraitement du CPU, de sorte que le batch en amont ne fait qu'ajouter un saut. Le déplacement du prétraitement vers le GPU est ce qui permet à un tel modèle d'en tirer profit.
Le batching permet de sacrifier une petite quantité de latence par requête en échange d'un throughput plus élevé, et le gain dépend de la concurrence. Si le trafic est faible, les batchs restent réduits et le bénéfice est limité. Avant de procéder à un déploiement à large échelle, start avec un unique endpoint et mesurez à la fois le throughput et la latence dans des conditions de concurrence réalistes.
Configuration requise
Cette fonctionnalité nécessite que :
- L’aperçu est activé pour votre workspace. Un administrateur du workspace active l’aperçu depuis la page Previews . Consultez Manage Databricks previews. Rien ne fonctionne ci-dessous tant que cette opération n’est pas effectuée.
- Service de GPU. L’entité desservie doit utiliser un type de charge de travail GPU (
GPU_SMALL,GPU_MEDIUM,GPU_LARGE, etc.). Triton n'a aucun effet sur les Endpoint CPU. - Un modèle compatible avec le batch. Le modèle doit être compatible avec le batch : le nombre d’entrées correspond au nombre de sorties (N entrées produisent N sorties), et les requêtes ne présentent aucune dépendance inter-requête. Le modèle doit également traiter un batch entier en un seul appel. Dans un
pyfunc, transmettez le batch en une seule fois (par exemple,model(**batched_inputs)) au lieu d’effectuer une boucle sur les entrées une par une — une boucle par élément ne tire aucun avantage du traitement par batch. - Un modèle sur le chemin de déploiement express. Enregistrez le modèle avec
env_pack="databricks_model_serving"afin que ses poids et son environnement soient préparés en tant qu’artefacts déployables. Un modèle qui bascule vers le chemin de génération du conteneur ne peut pas utiliser le backend Triton. Enregistrez-le à partir de Serverless GPU compute v4, v5 ou v6, pour Standard comme pour AI. Voir les déploiements express pour les Endpoint de Model Serving.
Étape 1 : enregistrer votre modèle pour un déploiement express
Loggez et enregistrez le modèle avec env_pack="databricks_model_serving". Exécutez ceci à partir d’un runtime de GPU serverless. L’utilisation de logs à partir d’un runtime sans GPU crée un package des dépendances du CPU, et l’Endpoint du GPU ne parvient pas à start.
import mlflow
mlflow.set_registry_uri("databricks-uc")
with mlflow.start_run():
model_info = mlflow.pyfunc.log_model(
artifact_path="model",
python_model=MyModel(),
# An input example enables automatic tuning of batching parameters in PuPr.
input_example=example,
)
# env_pack puts the model on the express deployment path (required for Triton).
mlflow.register_model(
model_info.model_uri,
"<catalog>.<schema>.<model>",
env_pack="databricks_model_serving",
)
Étape 2 : Activer l'optimisation du throughput et créer l'endpoint
Activez le traitement par batch des requêtes lorsque vous créez l’endpoint. Cette opération sert le modèle sur Triton, et Databricks établit le profil du modèle et applique des paramètres de traitement par batch optimisés.
Le batching est disponible uniquement lorsque toutes les conditions suivantes sont remplies :
- L’entité desservie utilise un type de workload de GPU, et non de CPU.
- Le modèle mis à disposition ne dispose d’aucun point d’entrée personnalisé.
- La version du modèle est éligible au déploiement express (SOD). Voir l’étape 1.
- L'aperçu est activé pour votre Workspace. Consultez la rubrique Configuration requise.
Créer l’endpoint en tant qu’endpoint GPU normal depuis l’interface de service :
- Sur le formulaire Create serving endpoint , sélectionnez une version de modèle éligible au déploiement express et un type de workload de GPU.
- Sélectionnez Throughput optimisé . Cette case à cocher s’affiche uniquement lorsque les conditions précédentes sont remplies.
- Terminez la configuration de l'endpoint, puis sélectionnez Créer .
Pour modifier ce paramètre ultérieurement, modifiez l’endpoint, puis sélectionnez ou désélectionnez Throughput optimized . La décision d’effectuer le traitement par batch est réévaluée lors de chaque déploiement : elle active ou désactive Triton lors du déploiement suivant et ne s’applique pas rétroactivement à un déploiement déjà en cours d’exécution.
Étape 3 : lancer une query sur l’Endpoint
Envoyez un petit batch pour confirmer que l’endpoint dessert les requêtes. Adaptez la forme d’entrée attendue par votre modèle.
import numpy as np
import requests
host = "https://<workspace-host>"
endpoint = "my-detector"
batch = np.zeros((2, 3, 224, 224), dtype=np.float32) # example input shape
resp = requests.post(
f"{host}/serving-endpoints/{endpoint}/invocations",
headers={
"Authorization": f"Bearer {DATABRICKS_TOKEN}",
"Content-Type": "application/json",
},
json={"inputs": batch.tolist()},
)
resp.raise_for_status()
predictions = np.array(resp.json()["predictions"])
Étape 4 : Confirmer que Triton est actif
Un statut READY à lui seul ne prouve pas que le backend Triton est attaché. Il n’existe actuellement aucun champ d’API dédié ni aucun badge d’interface utilisateur pour cela, et un endpoint READY a exactement la même apparence dans les deux cas. Confirmez avec l’une des options suivantes :
- Logs de service. Consultez les logs de service de l’Endpoint pour repérer les lignes de Startup de Triton (la bannière de Triton Inference Server et les messages de chargement du modèle). Leur présence signifie que le backend est associé. Voici un exemple de log :
[ts/g7zw9] I0911 22:42:18.894428 1 cuda_memory_manager.cc:107] "CUDA memory pool is created on device 0 with size 67108864"
[ts/g7zw9] I0911 22:42:18.916439 1 model_lifecycle.cc:473] "loading: model:1"
[ts/g7zw9] I0911 22:42:23.775240 1 python_be.cc:2289] "TRITONBACKEND_ModelInstanceInitialize: model_0_0 (GPU device 0)"
[ts/g7zw9] I0911 22:43:22.356197 1 model_lifecycle.cc:849] "successfully loaded 'model'"
[ts/g7zw9] I0911 22:43:22.357208 1 server.cc:681]
[ts/g7zw9] +-------+---------+--------+
[ts/g7zw9] | Model | Version | Status |
[ts/g7zw9] +-------+---------+--------+
[ts/g7zw9] | model | 1 | READY |
[ts/g7zw9] +-------+---------+--------+
[ts/g7zw9] I0911 22:43:22.387088 1 grpc_server.cc:2562] "Started GRPCInferenceService at 127.0.0.1:8001"
[ts/g7zw9] I0911 22:43:22.387651 1 http_server.cc:4809] "Started HTTPService at 127.0.0.1:8002"
[ts/g7zw9] I0911 22:43:22.430569 1 http_server.cc:358] "Started Metrics Service at 0.0.0.0:8003"
- Contactez l'équipe de votre compte Databricks pour confirmer le backend associé à votre endpoint. Si ce n'est pas le cas, ils pourront vous en indiquer la raison. Les causes courantes sont présentées dans Dépannage.
Effectuez ensuite un benchmark dans des conditions de simultanéité réalistes. Le gain de throughput de Triton se manifeste sous charge, et le batch ajoute une certaine latence par requête ; mesurez donc les deux avant le déploiement.
(Optionnel) Ajuster le batching
Les paramètres par default de mise en batch sont ajustables par déploiement. Pour les ajuster pour votre Endpoint, veuillez contacter l'équipe de votre compte Databricks.
Dépannage
Problème | Causes et corrections |
|---|---|
| L’optimisation du throughput n’est pas activée, ou l’aperçu est désactivé. Confirmez que la prévisualisation est activée et que Throughput optimized est activé (étape 2), puis redéployez. |
Le déploiement a basculé en l’absence de backend Triton | Le modèle ne se trouve pas sur le chemin de déploiement express. Réenregistrez avec |
Aucun gain de throughput par rapport à un endpoint sans Triton | Le modèle n’est pas limité par le GPU (GPU inactif ou prétraitement limité par le CPU). C’est normal ; pour les modèles de vision, déplacez le décodage et le redimensionnement des images sur le GPU. |
Triton plante sur les entrées volumineuses |
|
L'endpoint effectue un surprovisionnement pour atteindre la simultanéité maximale en cas de trafic stable. | L’autoscaling est actuellement agressif et peut provisionner la simultanéité maximale dès le début. Contactez l’équipe de votre compte Databricks pour régler l’autoscaling de manière plus prudente. |
Contactez l’équipe de votre compte Databricks pour tout retour ou question.