Servir des LLM personnalisés avec la mise en service de modèle personnalisé

Important

Cette fonctionnalité est en version bêta. Les administrateurs d’espace de travail peuvent contrôler l’accès à cette fonctionnalité à partir de la page Aperçus . Consultez Gérer les préversions d’Azure Databricks.

Cette page vous montre comment déployer des modèles de langage volumineux personnalisés sur le service de modèle à l’aide d’un moteur vLLM . Utilisez ce flux de travail pour déployer des modèles affinés, des variantes PEFT, des modèles multimodaux et d’autres modèles de base qui ne sont pas disponibles dans les API de modèles de base (FMAPI). Le bloc-notes de démarrage à la fin de cette page contient tout le code exécutable pour les étapes suivantes.

Quand utiliser le service LLM personnalisé

Azure Databricks recommande un service LLM personnalisé lorsque vous avez l’un des cas d’usage suivants :

  • Modèles entièrement affinés avec des poids personnalisés, que vous avez entraînés sur Azure Databricks.
  • Modèles provenant de Hugging Face qui ne sont pas disponibles dans FMAPI.
  • Recettes PEFT personnalisées que FMAPI ne prend pas en charge.
  • Modèles spécialisés en dehors du catalogue FMAPI, tels que MedGemma.
  • Modèles multimodaux (vision-langage) tels que Qwen/Qwen2.5-VL-3B-Instruct.
  • Incorporation de modèles qui ne sont pas disponibles dans FMAPI, tels que nomic-ai/nomic-embed-text-v2-moe.
  • Tout modèle qui s’adapte à un 1 xH100 (80 Go de mémoire GPU).

Requirements

  • Le service LLM personnalisé est en version bêta. Les administrateurs d’espace de travail peuvent activer ou désactiver cette fonctionnalité à partir de la page Aperçus . Consultez Gérer les préversions d’Azure Databricks.

  • Calcul GPU serverless. Un GPU A10 est l’environnement de développement recommandé pour les modèles plus petits, H100 pour les modèles plus volumineux.

  • MLflow 3.12 ou version ultérieure et databricks-sdk>=0.102.0. Les broches mlflow==3.12.0 de notebook de démarrage et une version compatible du SDK. Si vous générez votre propre environnement, faites correspondre ces versions. Les versions antérieures du Kit de développement logiciel (SDK) peuvent expirer lors du chargement des artefacts de modèle lors de l’inscription. Consultez les délais de chargement de l’artefact pendant l’inscription.

Étape 1 : Configurer votre environnement

Créez un notebook utilisant un calcul GPU serverless avec un GPU A10. Installez vLLM et ses dépendances. Le notebook de démarrage épingle une version testée de vLLM.

Vous pouvez également spécifier des dépendances via un environnement serverless au lieu d’utiliser %pip install.

Important

Définissez votre répertoire de travail vers le disque dur local (par exemple, à l’aide de tempfile.mkdtemp()). Le système de fichiers /Workspace ne prend pas en charge les fichiers volumineux tels que les pondérations de modèle.

Étape 2 : Télécharger votre modèle

Téléchargez les pondérations du modèle depuis Hugging Face avec snapshot_download. Le notebook de démarrage utilise Qwen/Qwen3-4B comme exemple, mais vous pouvez remplacer n’importe quel modèle qui correspond au budget de mémoire de votre GPU sélectionné, y compris les éléments suivants :

  • Modèles multimodaux tels que Qwen/Qwen2.5-VL-3B-Instruct pour les cas d’usage du langage de vision.
  • Modèles plus grands qui tiennent sur 1xH100, comme openai/gpt-oss-120b.

Sélectionnez un GPU en fonction des besoins en mémoire et en performances de votre modèle.

Unité de traitement graphique (GPU) Mémoire GPU workload_type
T4 16 Go GPU_SMALL
A100 80 Go GPU_LARGE

Étape 3 : Tester le modèle localement avec vLLM

Avant de déployer, testez le modèle directement dans votre notebook GPU serverless en lançant un serveur vLLM local. Les tests locaux vous permettent de vérifier le modèle, d’expérimenter les paramètres vLLM et de résoudre les problèmes avant de créer un point de terminaison de service.

Éléments clés à connaître :

  • Le calcul GPU serverless autorise uniquement les ports 3000 à 3999 pour les tests locaux. Sélectionnez un port dans cette plage ; le notebook de démarrage utilise 3080.
  • Le serveur vLLM expose une API compatible OpenAI à l’adresse /invocations.
  • Vous pouvez tester les demandes régulières et de diffusion en continu.
  • Paramétrez des paramètres tels que --dtype, --max-model-lenet --gpu-memory-utilization pour votre modèle.
  • Ajoutez --enforce-eager pour un démarrage plus rapide, au coût de certaines performances d’inférence.
  • Pour les modèles plus volumineux, utilisez une variante GPU serverless H100 pour les tests locaux.

Lorsque vous êtes satisfait de la configuration, arrêtez le serveur local avant de continuer.

Étape 4 : Consigner le modèle avec un point d’entrée personnalisé

Cette étape connecte votre configuration locale au service de modèles et présente les exigences de configuration suivantes :

  • Le task doit être "llm/v1/chat" (modèles de conversation, y compris multimodaux) ou "llm/v1/embeddings" (modèles d’embeddings). Consultez les tâches prises en charge.
  • Le point d’entrée doit s’ouvrir sur le port 8080, le port attendu par Model Serving.
  • La commande entrypoint doit mettre en miroir ce que vous avez testé à l’étape 3, avec le port 8080 au lieu de votre port local.
  • Le point d’entrée démarre à partir du dossier artefacts du modèle MLflow. Les chemins d’accès aux modèles sont donc relatifs à ce dossier.

Pour un modèle de conversation :

metadata = {
    "task": "llm/v1/chat",
    "entrypoint": (
        "python -u -m vllm.entrypoints.openai.api_server "
        "--model qwen3 --served-model-name qwen "
        "--host 0.0.0.0 --port 8080 "
        "--dtype float16 --max-model-len 16384 "
        "--gpu-memory-utilization 0.85"
    ),
}

Pour un modèle d’incorporation, définissez task"llm/v1/embeddings" et démarrez votre serveur en mode incorporation. Avec la version vLLM utilisée ici, c’est-à-dire --runner pooling (anciennes versions vLLM utilisent --task embed) :

metadata = {
    "task": "llm/v1/embeddings",
    "entrypoint": (
        "python -u -m vllm.entrypoints.openai.api_server "
        "--model nomic-embed --served-model-name nomic-embed "
        "--runner pooling "
        "--host 0.0.0.0 --port 8080 "
        "--gpu-memory-utilization 0.85"
    ),
}

Tâches prises en charge

task Type de modèle Surface de requête
llm/v1/chat Modèles de chat, y compris multimodaux (vision-langage) chat.completions
llm/v1/embeddings Incorporation de modèles embeddings

La task déclaration doit correspondre à ce que votre point d’entrée sert réellement : le point d’entrée doit exposer l’API compatible OpenAI pour cette tâche sur le port 8080. Les exemples ci-dessus utilisent vLLM, mais tout serveur qui répond à ce contrat fonctionne. D’autres types de tâches, tels que llm/v1/completions, ne sont pas pris en charge.

Étape 5 : Inscrire le modèle dans le catalogue Unity

Enregistrez le modèle dans Unity Catalog à l’aide de mlflow.register_model. Le service LLM personnalisé est basé sur des déploiements express. L’inscription utilise donc le env_pack="databricks_model_serving" paramètre et nécessite mlflow>=3.12 et databricks-sdk>=0.102.0.

Par exemple, ajoutez ce qui suit à votre bloc-notes :


model_version = mlflow.register_model(model_info.model_uri, UC_MODEL_NAME, env_pack="databricks_model_serving")

Étape 6 : Créer un point de terminaison de service

Créer le point de terminaison à partir de l’interface utilisateur ou par programmation avec le KIT de développement logiciel (SDK) Azure Databricks. Les décisions clés sont le type de calcul, la taille de la charge de travail et le comportement de mise à l’échelle à zéro.

Sélectionnez un workload_type en fonction de votre modèle et de votre cloud :

workload_type Unité de traitement graphique (GPU) Remarques
GPU_SMALL 1x T4 (16 Go) Option la plus petite.
GPU_LARGE 1x A100 (80 Go) Recommandé pour les charges de travail LLM volumineuses.

workload_size(Small ou MediumLarge) contrôle le nombre de réplicas provisionnés derrière le point de terminaison. Utiliser Small pour les charges de travail de développement et de faible trafic.

L’exemple suivant montre une configuration classique :

ServedEntityInput(
    entity_name="main.<catalog>.<model_name>",
    entity_version="<version>",
    workload_type=ServingModelWorkloadType.GPU_MEDIUM,
    workload_size="Small",
    scale_to_zero_enabled=True,
)

Mise à l’échelle à zéro et planification des capacités

Le service LLM personnalisé en version bêta provisionne un nombre fixe de réplicas derrière votre point de terminaison. La mise à l’échelle automatique entre plusieurs réplicas n’est pas encore prise en charge, vous devez donc dimensionner workload_type et workload_size pour votre pic de trafic. Le point de terminaison met en file d’attente les requêtes qui dépassent la capacité des réplicas provisionnés.

Définissez scale_to_zero_enabled=True pour permettre au point de terminaison de passer à zéro réplica lorsqu’il est inactif. Les démarrages à froid sont lents : le chargement des poids du modèle et le démarrage de vLLM prennent généralement une à plusieurs minutes.

Pour les charges de travail sensibles à la latence ou critiques en production, définissez scale_to_zero_enabled=False et dimensionnez workload_size pour votre pic de trafic en amont.

Avertissement

La capacité de montée en puissance n’est pas garantie. Chaque fois qu’Azure Databricks a besoin d’allouer un nouveau GPU pour votre point de terminaison, lors de sa création, lors d’une workload_size augmentation ou lorsqu’un point de terminaison sort de l’état zéro, la requête peut cesser de répondre si le fournisseur de services cloud ne dispose d’aucune capacité GPU dans votre région. Cela s’applique à tous les types GPU. Databricks atténue ce problème grâce à des pools préchauffés et à la pré-réservation, qui maintiennent une capacité GPU disponible et prête à l’emploi.

Étape 7 : Envoyer une requête à votre point de terminaison

Une fois que le point de terminaison est prêt, il apparaît automatiquement dans le terrain de jeu IA à partir de la page du point de terminaison. Vous pouvez également l’interroger par programmation à l’aide du Kit de développement logiciel (SDK) Databricks, du Kit de développement logiciel (SDK) OpenAI ou de curl.

Modèles de conversation (llm/v1/chat) :

Kit de développement logiciel (SDK) Databricks

w.serving_endpoints.query(
    name="<endpoint-name>",
    messages=[ChatMessage(role=ChatMessageRole.USER, content="Hello")],
)

Kit de développement logiciel (SDK) OpenAI

client = OpenAI(
    api_key=DATABRICKS_TOKEN,
    base_url=f"{DATABRICKS_HOST}/serving-endpoints",
)
client.chat.completions.create(
    model="<endpoint-name>",
    messages=[{"role": "user", "content": "Hello"}],
)

curl

curl -X POST \
  -u "token:$DATABRICKS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"Hello"}]}' \
  https://<workspace-url>/serving-endpoints/<endpoint-name>/invocations

Incorporation de modèles (llm/v1/embeddings) :

Kit de développement logiciel (SDK) OpenAI

client = OpenAI(
    api_key=DATABRICKS_TOKEN,
    base_url=f"{DATABRICKS_HOST}/serving-endpoints",
)
client.embeddings.create(
    model="<endpoint-name>",
    input=["The quick brown fox jumps over the lazy dog."],
)

curl

curl -X POST \
  -u "token:$DATABRICKS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"input":["The quick brown fox jumps over the lazy dog."]}' \
  https://<workspace-url>/serving-endpoints/<endpoint-name>/invocations

Certains modèles d’incorporation attendent un préfixe spécifique à une tâche sur chaque entrée (par exemple, nomic-embed-text-v2-moe utilise search_query: et search_document:). Vérifiez la carte de votre modèle pour connaître ses conventions d’entrée.

Surveiller votre point de terminaison

Le service LLM personnalisé utilise la même infrastructure d’observabilité que les points de terminaison de service de modèle personnalisé standard, mais avec quelques extras spécifiques à vLLM décrits dans les sections suivantes.

Logs en temps réel

L’onglet Journaux de la page du point de terminaison dans l’interface utilisateur Serving affiche stdout et stderr de votre processus vLLM en temps réel. Vous pouvez également accéder à cette sortie via l’API logs.

Journaux et métriques persistants

Lorsque la télémétrie est activée, les journaux et les métriques sont stockés de manière persistante dans des tables Delta d’Unity Catalog pour une conservation à long terme, les requêtes SQL et la conformité. Consultez Conserver un modèle personnalisé servant des données dans le catalogue Unity pour obtenir des instructions d’installation complètes, des exigences et des schémas de table.

Pour un service LLM personnalisé spécifiquement :

  • Journaux : stdout et stderr du processus vLLM sont automatiquement capturés. Aucun code de journalisation côté application n’est requis.
  • Métrique : Azure Databricks collecte automatiquement les métriques depuis le point de terminaison Prometheus /metrics du serveur vLLM et les stocke avec les journaux. Par défaut, vous disposez de la latence par requête, du débit, du nombre de jetons, de la profondeur de file d’attente et du taux d’utilisation du cache KV.

Interroger les données de télémétrie

Dans la version bêta, il n’existe aucune interface utilisateur pour visualiser les journaux ou les métriques. Interrogez les données persistantes directement dans le catalogue Unity à l’aide de SQL ou d’un notebook. Consultez les schémas de métriques et de journaux documentés dans Conserver les données personnalisées de service de modèle dans Unity Catalog.

Le notebook suivant montre comment analyser et visualiser les métriques vLLM persistantes :

Notebooks de métriques de service LLM personnalisé

Obtenir un ordinateur portable

Exemple de bloc-notes

Développer et tester le modèle dans un notebook GPU sans serveur, puis consigner et déployer la même configuration en tant que point de terminaison d’inférence. Le notebook suivant contient le workflow complet pouvant être exécuté présenté dans ce guide.

Bloc-notes de démarrage LLM personnalisé

Obtenir un ordinateur portable

Limitations

Les limitations suivantes s’appliquent pendant la version bêta.

  • Aucune mise à l’échelle automatique entre les réplicas. La mise à l’échelle jusqu’à zéro est prise en charge.
  • Seules les tâches de chat (llm/v1/chat, y compris multimodal) et d’embeddings (llm/v1/embeddings) sont prises en charge. Consultez les tâches prises en charge.
  • Aucune optimisation des itinéraires.
  • Aucune interface utilisateur pour visualiser les journaux ou les métriques. Interroger les données de télémétrie directement dans le catalogue Unity.

Contactez votre équipe de compte Azure Databricks pour obtenir des commentaires ou des questions.

Le chargement de l’artefact expire pendant l’inscription

Lorsque vous inscrivez le modèle avec env_pack, Azure Databricks charge les pondérations et l’environnement du modèle empaqueté en tant qu’artefacts (model_version.tar et model_environment.tar). Avec databricks-sdk les versions antérieures à 0.102.0, le chargement d’artefacts LLM volumineux peut expirer après cinq minutes et échouer l’inscription avec une erreur comme suit :

MlflowException: The following failures occurred while uploading one or more artifacts to
/Models/<catalog>/<schema>/<model>/<version>: {
  '.../model_environment.tar': "TimeoutError('Timed out after 0:05:00')",
  '.../model_version.tar': "TimeoutError('Timed out after 0:05:00')"
}

Pour résoudre ce problème, mettez à niveau vers databricks-sdk>=0.102.0, puis réenregistrez le modèle :

%pip install databricks-sdk>=0.102.0
  • Last updated on