Aller au contenu principal

Servez les LLM personnalisés avec Custom Model Serving

info

Aperçu

Cette fonctionnalité est en aperçu public. Les administrateurs du workspace peuvent contrôler l’accès à cette fonctionnalité à partir de la page Previews . Consultez Gérer les aperçus Databricks.

Cette page indique comment déployer votre propre LLM sur un endpoint GPU Model Serving. N'importe quel modèle exécuté par vLLM devient un endpoint de production doté d'une API compatible avec OpenAI. Voici comment cela fonctionne :

  • Vous exécutez le serveur d'inférence, tel que vLLM, et choisissez sa version et ses paramètres.
  • Vous testez le serveur dans un notebook GPU serverless. Un indicateur erroné ou une erreur de mémoire insuffisante apparaît en quelques secondes au lieu de se manifester après un déploiement.
  • Vous déployez la même commande et le même environnement que ceux que vous avez créés et dont vous savez qu’ils fonctionnent sur un endpoint de service de production.

Démarrage rapide​

Importez le notebook suivant dans votre workspace et cliquez sur Run all sur AI Runtime avec un GPU A10. En 15 minutes environ, vous disposez d’un modèle Qwen3.5-4B endpoint qui répond aux requêtes de chat compatibles avec OpenAI.

Servir Qwen3.5-4B avec vLLM

Quand utiliser le service LLM personnalisé​

Utilisez le service de LLM personnalisé dans les cas suivants :

  • Vous avez affiné un LLM sur AI Runtime et vous souhaitez le déployer. Voir la section ci-dessous pour un exemple.
  • Vous souhaitez servir un modèle ouvert que les Foundation Model APIs (FMAPI) ne prennent pas en charge, tel qu’un nouveau LLM, un modèle de transcription de la parole en texte ou un modèle d'intégration.
  • Vous souhaitez modifier le runtime ou l'architecture d'un LLM et avez besoin de contrôler le runtime et l'environnement.

N’utilisez pas le service de LLM personnalisé dans les cas suivants :

  • FMAPI sert le modèle dont vous avez besoin, tel quel. FMAPI est plus simple à utiliser et hautement optimisée.
  • Le modèle ne tient pas sur un seul GPU doté d'environ 80 Go de mémoire. Par exemple, Qwen3.8-27B et gpt-oss-120b conviennent, mais Kimi K3 et GLM 5.3 ne conviennent pas.
  • Vous avez besoin d'un throughput ou d'un prix par jeton de niveau « frontier » sans réglage. Les performances correspondent à celles du vLLM open source sur le même GPU.

Exigences​

Custom LLM serving présente les exigences suivantes :

  • Votre workspace doit disposer d'un compute serverless GPU.
  • Vous devez enregistrer le modèle à partir d’un notebook GPU serverless. Un modèle enregistré à partir d’un environnement CPU package des dépendances CPU, et l’Endpoint GPU ne parvient pas à start.
  • Vous devez disposer des autorisations nécessaires pour créer des modèles dans un schéma Unity Catalog.
  • Vous devez enregistrer le modèle avec env_pack="databricks_model_serving". Le service de LLM personnalisé repose sur des déploiements express, qui regroupent l'environnement du notebook et le modèle dans un package.
  • Vous devez utiliser MLflow 3.12 ou une version supérieure et databricks-sdk 0.102.0 ou une version supérieure. L'environnement AI v6 comprend les deux.

Notebooks de démarrage​

Chaque notebook transmet un modèle de Hugging Face vers un endpoint interrogé, comme dans le guide de démarrage rapide. Exécutez-en un tel quel ou start par l'un d'eux pour servir votre propre modèle.

Modèle

Tâche

Environnement

Notebook GPU

Endpoint GPU

Qwen3.5-4B

Chat

AI v6 ou Standard v6

A10

A10G (AWS), A100 (Azure)

Qwen3.8-27B

Discuter avec des appels d'outils

AI v6

H100

H100 (AWS), A100 (Azure)

Gemma 4 26B-A4B

Discuter avec des appels d'outils

AI v6

H100

H100 (AWS), A100 (Azure)

Muse Glimmer 30B

Chat

Standard v6

H100

H100 (AWS), A100 (Azure)

Whisper large-v3-turbo

Transcription audio

AI v6

A10

A10G (AWS), A100 (Azure)

Qwen3-Embedding-0.6B

Intégrations

AI v6

A10

A10G (AWS), A100 (Azure)

Modèle

Tâche

Environnement

Notebook GPU

Endpoint GPU

Qwen3.5-4B

Chat

AI v6 ou Standard v6

A10

A10G (AWS), A100 (Azure)

Qwen3.8-27B

Discuter avec des appels d'outils

AI v6

H100

H100 (AWS), A100 (Azure)

Gemma 4 26B-A4B

Discuter avec des appels d'outils

AI v6

H100

H100 (AWS), A100 (Azure)

Muse Glimmer 30B

Chat

Standard v6

H100

H100 (AWS), A100 (Azure)

Whisper large-v3-turbo

Transcription audio

AI v6

A10

A10G (AWS), A100 (Azure)

Qwen3-Embedding-0.6B

Intégrations

AI v6

A10

A10G (AWS), A100 (Azure)

Les versions AI v6 et Standard v6 sont des environnements Runtime de l'IA. AI v6 est fourni avec vLLM, PyTorch, Transformers et d'autres packages de machine learning courants préinstallés et prêts à l'emploi. Consultez la liste des packages AI v6. Un notebook Standard v6 installe lui-même vLLM, vous choisissez donc sa version. Utilisez un notebook Standard v6 lorsque votre modèle nécessite une version de vLLM ou de transformers plus récente que celle incluse dans AI v6, comme avec Muse Glimmer.

Hébergez votre propre modèle​

Pour servir un autre modèle, choisissez le notebook de démarrage doté de la même tâche et du GPU requis par votre modèle. Modifiez MODEL_REPO_ID et les indicateurs dans vllm_command, puis exécutez le notebook. Chaque notebook exécute les étapes suivantes :

  1. download les poids du modèle à partir de Hugging Face ou récupérez-les à partir d’un point de contrôle d’entraînement.
  2. Start vLLM dans le Notebook et query-le.
  3. Enregistrez le modèle avec la commande vLLM comme point d’entrée, puis enregistrez-le dans Unity Catalog en tant que déploiement express.
  4. Créez un Endpoint de service, ce qui start la même commande.
  5. Query l’Endpoint avec le client OpenAI, le Databricks SDK ou SQL ai_query.

Dans l’exemple suivant, le paramètre metadata du modèle contient la tâche et le point d’entrée :

Python
import mlflow
from mlflow.pyfunc.model import ChatCompletionResponse, ChatModel

# The endpoint runs the entrypoint and never calls predict, but MLflow needs a model class to log.
class Placeholder(ChatModel):
def predict(self, context, messages, params):
return ChatCompletionResponse.from_dict({"choices": []})

model_info = mlflow.pyfunc.log_model(
name="my-model",
python_model=Placeholder(),
artifacts={"model_dir": "my-model"}, # the weights folder, which --model names
metadata={
"task": "llm/v1/chat",
"entrypoint": (
"python -u -m vllm.entrypoints.openai.api_server "
"--model my-model --served-model-name my-model "
"--host 0.0.0.0 --port 8080 --max-model-len 16384"
),
},
)
mlflow.register_model(model_info.model_uri, "<catalog>.<schema>.my_model", env_pack="databricks_model_serving")

Déployer un modèle affiné​

Affinez un modèle sur AI Runtime et effectuez son déploiement à partir du même notebook. Pour voir un exemple, consultez l'affinement supervisé (complet) et la mise en service de Qwen3.5-0.8B. Le tutoriel affine Qwen3.5-0.8B sur un seul H100, compare les réponses avant et après l'entraînement, et déploie le modèle affiné.

Tâches prises en charge​

Le paramètre task dans les métadonnées du modèle définit l’API que l’endpoint sert. Votre serveur doit exposer l’API compatible avec OpenAI pour cette tâche. D’autres tâches, telles que llm/v1/completions, ne sont pas prises en charge. Le tableau suivant liste les tâches prises en charge.

task

Type de modèle

Query avec

llm/v1/chat

Modèles de chat, y compris les modèles vision-langage

chat.completions

llm/v1/embeddings

Modèles d'intégration

embeddings

llm/v1/audio/transcriptions

Modèles de reconnaissance vocale

audio.transcriptions

llm/v1/audio/translations

Modèles de traduction de la parole vers l’anglais

audio.translations

task

Type de modèle

Query avec

llm/v1/chat

Modèles de chat, y compris les modèles vision-langage

chat.completions

llm/v1/embeddings

Modèles d'intégration

embeddings

llm/v1/audio/transcriptions

Modèles de reconnaissance vocale

audio.transcriptions

llm/v1/audio/translations

Modèles de traduction de la parole vers l’anglais

audio.translations

Choisissez un GPU​

Databricks vous recommande de développer sur le même GPU que celui sur lequel vous effectuez le service, de sorte que les paramètres que vous testez soient ceux que vous déployez. Le tableau suivant répertorie les GPU pour le service d’LLM personnalisé.

workload_type

GPU

Notes

GPU_SMALL

1x T4 (16 Go)

Petits modèles.

GPU_MEDIUM

1x A10G (24 Go)

Modèles comptant jusqu’à environ 10 milliards de paramètres. Généralement disponible.

GPU_LARGE

1x L40S (48 Go)

Modèles comptant jusqu’à environ 15B de paramètres. Disponible dans us-east-1, us-east-2, us-west-2, eu-central-1, ap-northeast-1 et ap-northeast-2.

GPU_XLARGE

1x H100 (80 Go)

Recommandé pour les grands LLM. Disponible uniquement dans us-west-2, avec une inscription auprès de l’équipe de votre compte Databricks. Ne prend pas en charge Monter en charge-to-zero.

GPU_LARGE_RTX

1x RTX PRO 6000 (96 Go)

Plus de mémoire que le H100, mais moins optimisé pour le service de LLM. Disponible dans us-west-2, us-east-1, us-east-2, ap-northeast-1 et ap-northeast-2.

workload_type

GPU

Notes

GPU_SMALL

1x T4 (16 Go)

Petits modèles.

GPU_MEDIUM

1x A10G (24 Go)

Modèles comptant jusqu’à environ 10 milliards de paramètres. Généralement disponible.

GPU_LARGE

1x L40S (48 Go)

Modèles comptant jusqu’à environ 15B de paramètres. Disponible dans us-east-1, us-east-2, us-west-2, eu-central-1, ap-northeast-1 et ap-northeast-2.

GPU_XLARGE

1x H100 (80 Go)

Recommandé pour les grands LLM. Disponible uniquement dans us-west-2, avec une inscription auprès de l’équipe de votre compte Databricks. Ne prend pas en charge Monter en charge-to-zero.

GPU_LARGE_RTX

1x RTX PRO 6000 (96 Go)

Plus de mémoire que le H100, mais moins optimisé pour le service de LLM. Disponible dans us-west-2, us-east-1, us-east-2, ap-northeast-1 et ap-northeast-2.

Problèmes courants​

Les problèmes suivants sont les plus courants lorsque vous modifiez un notebook :

  • Le download échoue dans /Workspace, qui n'accepte pas les fichiers de plusieurs Go. download les poids sur le disque local, comme le font les Notebooks de démarrage.
  • Le serveur local ne start pas. Les notebooks GPU serverless n'autorisent que les ports 3000 à 3 999 ; veuillez donc effectuer vos tests sur l'un d'entre eux. Seul le point d'entrée utilise le port 8080, et il doit par ailleurs correspondre à la commande que vous avez testée.
  • L’Endpoint ne parvient pas à trouver les pondérations. L’entrypoint s’exécute dans le dossier des artefacts du modèle, de sorte que --model doit nommer le dossier des pondérations que vous avez enregistré.
  • Un modèle d’intégration ne sert pas d’intégrations. Start vLLM avec --runner pooling.
  • L'enregistrement échoue avec TimeoutError('Timed out after 0:05:00') lors de l'upload de model_version.tar ou de model_environment.tar. Mettez à niveau vers databricks-sdk 0.102.0 ou une version ultérieure, puis enregistrez à nouveau le modèle.

Créer un endpoint​

Créez l'endpoint à partir de l'interface utilisateur de serving ou avec le SDK Databricks, comme le font les notebooks de démarrage. workload_type sélectionne le GPU et workload_size (Small, Medium ou Large) définit le nombre de répliques.

Python
ServedEntityInput(
entity_name="<catalog>.<schema>.<model>",
entity_version="<version>",
workload_type=ServingModelWorkloadType.GPU_MEDIUM,
workload_size="Small",
scale_to_zero_enabled=False,
)

Monter en charge à zéro et capacité​

Actuellement, les Endpoint LLM personnalisés ne sont pas mis à l'échelle dynamiquement ; dimensionnez donc workload_size en fonction de votre trafic de pointe.

Avec la fonction monter en charge à zéro, un Endpoint inactif arrête toutes les répliques. La requête suivante attend une à plusieurs minutes pendant que vLLM charge à nouveau le modèle et que toutes les répliques démarrent. Databricks recommande de désactiver la fonction monter en charge à zéro pour le trafic de production.

attention

La capacité de monter en charge n’est pas garantie. Chaque fois que Databricks doit acquérir un nouveau GPU pour votre endpoint, par exemple lors de la création, d’une augmentation de workload_size ou lorsqu’un endpoint sort d’un état d’inactivité, la requête peut échouer si le fournisseur cloud ne dispose d’aucune capacité GPU dans votre région. Databricks atténue ce problème grâce à des pools chauds et à la pré-réservation, qui permettent de maintenir la capacité du GPU disponible et prête.

GPU_XLARGE Les Endpoint (1xH100) ne prennent pas en charge scale_to_zero_enabled=True actuellement.

query votre endpoint​

Un endpoint de chat prêt apparaît dans l’ AI Playground. Les exemples suivants query un endpoint avec le SDK Databricks, le client OpenAI et REST.

Python
from databricks.sdk import WorkspaceClient
from databricks.sdk.service.serving import ChatMessage, ChatMessageRole

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

Certains modèles d'intégration attendent un préfixe sur chaque entrée, tel que search_query: ou search_document:. Consultez la fiche du modèle.

Surveiller votre endpoint​

L’tab Logs de l’Endpoint affiche en direct le stdout et le stderr de votre serveur. L’ API de logs renvoie le même résultat.

Databricks transfère les métriques de votre serveur vLLM et les représente graphiquement sur l’tab Metrics de l’Endpoint :

  • Latence : délai avant le premier jeton, temps par jeton de sortie, latence de requête et temps de file d'attente.
  • Charge : requêtes en cours d’exécution et en attente.
  • Cache KV : utilisation et taux de réussite.
  • Throughput : jetons de prompt et de génération par seconde.

L'API d’exportation de métriques renvoie les mêmes métriques au format Prometheus, ce qui vous permet de les récupérer dans Prometheus ou Datadog.

Lorsque la télémétrie est activée, Databricks enregistre également les logs du serveur et les métriques Prometheus de vLLM dans les tables Unity Catalog, ce qui vous permet de les query sur de plus longues périodes. Voir Persist custom model serving data to Unity Catalog.

Tarifs​

Vous payez par heure d'instance GPU, de la même manière que pour les autres services de modèles personnalisés sur GPU. Consultez Model Serving Tarifs.

Limitations et disponibilité régionale​

Vous enregistrez un LLM personnalisé à partir d'AI Runtime, de sorte que le service de LLM personnalisé est disponible dans les mêmes régions que le compute serverless GPU. Il s'agit de régions américaines sur AWS et Azure. GCP n’est pas pris en charge.

Les fonctionnalités suivantes seront bientôt disponibles :

  • Adaptateurs LoRA.
  • Service interrégional.
  • Journalisation de modèles en dehors d'AI Runtime, par exemple à partir de Databricks Runtime ou de l'environnement serverless CPU.

Les fonctionnalités suivantes ne sont pas prises en charge :

  • Routage prenant en compte le cache KV.
  • Optimisation des itinéraires.