Benutzerdefinierte LLMs mit benutzerdefinierter Modellbereitstellung bereitstellen

Diese Seite zeigt, wie man ein eigenes LLM auf einem Model Serving GPU-Endpunkt bereitstellt. Jedes Modell, das in vLLM läuft, wird zu einem Produktionsendpunkt mit einer OpenAI-kompatiblen API. So funktioniert es:

• Du betreibst den Inferenzserver, zum Beispiel vLLM, und wählst dessen Version und Einstellungen aus.
• Du testest den Server in einem serverlosen GPU-Notebook . Ein falsches Flag oder ein Out-of-Memory-Fehler erscheint innerhalb von Sekunden statt nach einer Bereitstellung.
• Du stellst denselben Befehl und dieselbe Umgebung, die du gebaut hast und von der du weißt, dass sie funktionieren, an einem Produktionsendpunkt bereit.

Quickstart

Importiere das folgende Notebook in deinen Arbeitsbereich und klicke in AI Runtime auf Alle ausführen mit einer A10-GPU. In etwa 15 Minuten hast du einen Qwen3.5-4B-Endpunkt, der OpenAI-kompatible Chat-Anfragen beantwortet.

Qwen3.5-4B mit vLLM bereitstellen

Notebook abrufen

Wann benutzerdefinierte LLM-Bereitstellungen verwendet werden sollten

Verwenden Sie in den folgenden Fällen die benutzerdefinierte LLM-Bereitstellung:

• Du hast ein LLM auf AI Runtime feinabgestimmt und möchtest es bereitstellen. Siehe den Abschnitt unten für ein Beispiel.
• Man möchte ein offenes Modell bereitstellen, das von Foundation Model APIs (FMAPI) nicht unterstützt wird, wie ein neues LLM, ein Sprach-zu-Text-Modell oder ein Embedding-Modell.
• Du möchtest die Laufzeit oder Architektur eines LLMs ändern und brauchst Kontrolle über Laufzeit und Umgebung.

Verwenden Sie in den folgenden Fällen nicht die Bereitstellung benutzerdefinierter LLMs:

• FMAPI liefert das Modell, das Sie brauchen, unverändert. FMAPI ist einfacher zu bedienen und hoch optimiert.
• Das Modell passt nicht auf eine einzige GPU mit etwa 80 GB Speicher. Zum Beispiel passen Qwen3.8-27B und gpt-oss-120b, aber Kimi K3 und GLM 5.3 nicht.
• Du brauchst Frontier-Level-Durchsatz oder Preis pro Token ohne Tuning. Die Leistung entspricht der Leistung von Open-Source-vLLM auf derselben GPU.

Requirements

Das Bereitstellen von benutzerdefinierten LLMs hat folgende Anforderungen:

• Dein Arbeitsbereich muss über serverless GPU Compute verfügen.
• Du musst das Modell von einem serverlosen GPU-Notebook aus loggen. Ein Modell, das aus einer CPU-Umgebung gespeichert wurde, enthält CPU-Abhängigkeiten, und der GPU-Endpunkt startet nicht.
• Du musst die Berechtigung haben, Modelle in einem Unity-Katalog-Schema zu erstellen.
• Sie müssen das Modell bei env_pack="databricks_model_serving"registrieren. Custom LLM-Serving basiert auf Express-Deployments, die die Umgebung des Notebooks mit dem Modell paketieren.
• Du musst MLflow 3.12 oder höher und databricks-sdk 0.102.0 oder höher verwenden. Die KI-v6-Umgebung umfasst beides.

Starter-Notebooks

Jedes Notizbuch bringt ein Modell von Hugging Face zu einem Endpunkt für Abfragen, wie dem Quickstart. Führe eines unverändert aus oder beginne mit einem, um dein eigenes Modell bereitzustellen.

AI v6 und Standard v6 sind KI-Laufzeitumgebungen. AI v6 wird mit vLLM, PyTorch, Transformers und anderen gängigen Machine-Learning-Paketen vorinstalliert und einsatzbereit geliefert. Siehe die AI-v6-Paketliste. Ein Standard-v6-Notebook installiert vLLM selbst, also wählst du die Version aus. Verwende ein Standard-v6-Notebook, wenn dein Modell ein neueres vLLM oder Transformers benötigt als AI v6, wie bei Muse Glimmer.

Stelle dein eigenes Modell bereit

Um ein anderes Modell bereitzustellen, wähle das Starternotebook mit derselben Aufgabe und die GPU, die dein Modell benötigt. Ändern Sie MODEL_REPO_ID und die Flaggen in vllm_command, dann führen Sie das Notebook aus. Jedes Notebook führt folgende Schritte durch:

1. Laden Sie die Modellgewichte von Hugging Face herunter oder holen Sie sie aus einem Trainings-Checkpoint.
2. Starte vLLM im Notizbuch und frage es ab.
3. Protokolliere das Modell mit dem vLLM-Befehl als Einstiegspunkt und registriere es als Express Deployment im Unity-Katalog.
4. Erstellen Sie einen Serving-Endpunkt, der denselben Befehl startet.
5. Fragen Sie den Endpunkt mit dem OpenAI-Client, dem Databricks SDK oder SQL ai_query ab.

Im folgenden Beispiel enthält das metadata des Modells die Aufgabe und den Einstiegspunkt:

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

Ein fein abgestimmtes Modell bereitstellen

Feinjustiere ein Modell in AI Runtime und stelle es aus demselben Notebook bereit. Ein Beispiel finden Sie unter Überwachtes Fine-Tuning (vollständig) und Bereitstellung von Qwen3.5-0.8B. Das Tutorial feinjustiert Qwen3.5-0.8B auf einem einzelnen H100, vergleicht Antworten vor und nach dem Training und stellt das feinabgestimmte Modell bereit.

Unterstützte Aufgaben

task in den Metadaten des Modells legt die API fest, die der Endpunkt bereitstellt. Dein Server muss die OpenAI-kompatible API für diese Aufgabe bereitstellen. Andere Aufgaben wie llm/v1/completions, werden nicht unterstützt. Die folgende Tabelle listet die unterstützten Aufgaben auf.

Wähle eine GPU

Azure Databricks empfiehlt, auf derselben GPU zu entwickeln, auf der das Modell bereitgestellt wird, daher sind die Einstellungen, die man testet, die Einstellungen, die man selbst bereitstellt. Die folgende Tabelle listet die GPUs für benutzerdefinierte LLM-Bereitstellung auf.

Häufig auftretende Probleme

Die folgenden Probleme sind die häufigsten beim Wechsel eines Notebooks:

• Der Download schlägt fehl in /Workspace, das keine Dateien im Multi-GB-Bereich akzeptiert. Lade die Gewichte auf die lokale Festplatte herunter, wie es die Starter-Notebooks tun.
• Der lokale Server startet nicht. Serverless-GPU-Notebooks erlauben nur die Ports von 3000 bis 3999, also teste auf einem davon. Nur der Entrypoint verwendet Port 8080, und ansonsten muss er mit dem Befehl übereinstimmen, den Sie getestet haben.
• Der Endpunkt kann die Gewichte nicht finden. Der Entrypoint läuft im Artefaktordner des Modells und --model muss also den von dir geloggten Ordner mit den Gewichten benennen.
• Ein Embedding-Modell liefert keine Embeddings. Starte vLLM mit --runner pooling.
• Die Registrierung schlägt beim Hochladen von model_version.tar oder model_environment.tar mit TimeoutError('Timed out after 0:05:00') fehl. Upgrade auf databricks-sdk 0.102.0 oder höher und registriere das Modell erneut.

Erstellen eines Endpunkts

Erstellen Sie den Endpunkt aus der Serving UI oder mit dem Databricks SDK, wie es die Starter-Notebooks tun. workload_type wählt die GPU aus, und workload_size (Small, Medium, , oder Large) legt die Anzahl der Repliken fest.

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

Auf Null skalieren und Kapazität

Derzeit skalieren benutzerdefinierte LLM-Endpunkte nicht automatisch, also dimensioniere workload_size für deinen Spitzenverkehr.

Bei der Skalierung auf null stoppt ein inaktiver Endpunkt alle Replikate. Die nächste Anfrage wartet ein bis mehrere Minuten, während vLLM das Modell erneut lädt und alle Repliken starten. Azure Databricks empfiehlt, Scale-to-Zero für Produktionsverkehr auszuschalten.

Endpunkt abfragen

Ein einsatzbereiter Chat-Endpoint erscheint im AI Playground. Die folgenden Beispiele fragen einen Endpunkt mit dem Databricks SDK, dem OpenAI-Client und REST ab.

Databricks SDK

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

OpenAI-Client

from openai import 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"}])
client.embeddings.create(model="<endpoint-name>", input=["The quick brown fox jumps over the lazy dog."])
with open("speech.flac", "rb") as audio:
    client.audio.transcriptions.create(model="<endpoint-name>", file=audio)

REST: Chat

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

REST: Einbettungen

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

Einige Einbettungsmodelle erwarten ein Präfix auf jeder Eingabe, wie search_query: oder search_document:. Überprüfe die Model Card.

Überwachen Sie Ihren Endpunkt

Der Logs-Tab des Endpunkts zeigt die Server-stdout und stderr-Logs live. Die Logs-API liefert die gleiche Ausgabe.

Azure Databricks leitet die Metriken Ihres vLLM-Servers weiter und zeigt sie auf dem Metrics-Tab des Endpunkts dar:

• Latenz: Zeit bis zum ersten Token, Zeit pro Ausgabetoken, Anfragelatenz und Warteschlangenzeit.
• Auslastung: Anfragen laufen und warten.
• KV-Cache: Nutzung und Trefferrate.
• Durchsatz: Prompt- und Generierungstoken pro Sekunde.

Die Exportmetrics-API liefert dieselben Metriken im Prometheus-Format, sodass man sie in Prometheus oder Datadog scrapen kann.

Mit aktivierter Telemetrie speichert Azure Databricks außerdem die Serverprotokolle und die vLLM Prometheus-Metriken in Unity-Catalog-Tabellen, sodass man sie über längere Zeiträume abfragen kann. Weitere Informationen finden Sie unter Persist custom model serving data to Unity Catalog.

Pricing

Du zahlst pro GPU-Instanzstunde, genauso wie bei anderen GPU-Custom-Model-Serving. Siehe Model Serving-Preisgestaltung.

Einschränkungen und regionale Verfügbarkeit

Du loggst ein benutzerdefiniertes LLM aus AI Runtime, sodass die Bereitstellung von benutzerdefinierten LLMs in denselben Regionen wie serverlose GPU-Rechenleistungen verfügbar ist. Das sind US-Regionen auf AWS und Azure. GCP wird nicht unterstützt.

Die folgenden Funktionen kommen bald:

• LoRA-Adapter.
• Regionsübergreifende Bereitstellung.
• Logging von Modellen außerhalb von AI Runtime, zum Beispiel von Databricks Runtime oder CPU-Serverless.

Die folgenden Features werden nicht unterstützt:

• KV-cache-bewusstes Routing.
• Routenoptimierung.