Hantera anpassade LLM:er med anpassad modellservering

Viktigt!

Den här funktionen finns i Beta. Arbetsyteadministratörer kan styra åtkomsten till den här funktionen från sidan Förhandsversioner . Se Hantera förhandsversioner av Azure Databricks.

Den här sidan visar hur du distribuerar anpassade stora språkmodeller (LLM) på modellservern med hjälp av en vLLM-motor . Använd det här arbetsflödet för att hantera finjusterade modeller, PEFT-varianter, multimodala modeller och andra grundmodeller som inte är tillgängliga i FOUNDATION Model API:er (FMAPI). Startanteckningsboken i slutet av den här sidan innehåller all körbar kod för följande steg.

När du ska använda anpassad LLM-servering

Azure Databricks rekommenderar anpassad LLM-servering när du har något av följande användningsfall:

  • Helt finjusterade modeller med anpassade vikter som du har tränat på Azure Databricks.
  • Modeller från Hugging Face som inte är tillgängliga i FMAPI.
  • Anpassade PEFT-recept som FMAPI inte stöder.
  • Specialiserade modeller utanför FMAPI-katalogen, till exempel MedGemma.
  • Multimodala modeller (visionsspråk), till exempel Qwen/Qwen2.5-VL-3B-Instruct.
  • Inbäddningsmodeller som inte är tillgängliga i FMAPI, till exempel nomic-ai/nomic-embed-text-v2-moe.
  • Alla modeller som passar på en 1xH100 (80 GB GPU-minne).

Requirements

  • Anpassad LLM-servering finns i Beta. Arbetsyteadministratörer kan aktivera eller inaktivera den här funktionen från sidan Förhandsversioner . Se Hantera förhandsversioner av Azure Databricks.

  • Serverlös GPU-beräkning. En A10 GPU är den rekommenderade utvecklingsmiljön för mindre modeller, H100 för större modeller.

  • MLflow 3.12 eller högre och databricks-sdk>=0.102.0. Startanteckningsboken fästs mlflow==3.12.0 och en kompatibel SDK-version. Om du bygger en egen miljö, se till att använda samma versioner. Tidigare SDK-versioner kan få timeout när modellartefakter laddas upp vid registrering. Se Tidsgränsen för artefaktuppladdning under registreringen.

Steg 1: Konfigurera din miljö

Skapa en anteckningsbok i serverlös GPU-beräkning med en A10-GPU. Installera vLLM och dess beroenden. Startanteckningsboken fäster en testad vLLM-version.

Du kan också ange beroenden via en serverlös miljö i stället för att använda %pip install.

Viktigt!

Ange arbetskatalogen till den lokala hårddisken (till exempel med tempfile.mkdtemp()). Filsystemet /Workspace stöder inte stora filer som modellvikter.

Steg 2: Ladda ned din modell

Ladda ned modellvikter från Hugging Face med snapshot_download. Startanteckningsboken använder Qwen/Qwen3-4B som exempel, men du kan ersätta alla modeller som passar den valda GPU:ns minnesbudget, inklusive följande:

  • Multimodala modeller, till exempel Qwen/Qwen2.5-VL-3B-Instruct för användningsfall med visionsspråk.
  • Större modeller som passar på en 1xH100, till exempel openai/gpt-oss-120b.

Välj en GPU baserat på modellens minnes- och prestandabehov.

GPU (grafikprocessor) GPU-minne workload_type
T4 16 GB GPU_SMALL
A100 80 GB GPU_LARGE

Steg 3: Testa modellen lokalt med vLLM

Innan du driftsätter kan du testa modellen direkt i din serverlösa GPU-notebook genom att starta en lokal vLLM-server. Med lokal testning kan du verifiera modellen, experimentera med vLLM-parametrar och felsöka problem innan du skapar en serverdelsslutpunkt.

Viktiga saker att veta:

  • Serverlös GPU-beräkning tillåter endast portar 3000–3999 för lokal testning. Välj en port i det intervallet. startanteckningsboken använder 3080.
  • VLLM-servern exponerar ett OpenAI-kompatibelt API på /invocations.
  • Du kan testa både regelbundna och strömmande begäranden.
  • Justera parametrar som --dtype, --max-model-lenoch --gpu-memory-utilization för din modell.
  • Lägg till --enforce-eager för snabbare start, på bekostnad av viss slutsatsdragningsprestanda.
  • För större modeller använder du en H100-serverlös GPU-variant för lokal testning.

När du är nöjd med konfigurationen stoppar du den lokala servern innan du fortsätter.

Steg 4: Logga modellen med en anpassad startpunkt

Det här steget ansluter din lokala konfiguration till Modellservering och har följande konfigurationskrav:

  • Måste task vara "llm/v1/chat" (chattmodeller, inklusive multimodala) eller "llm/v1/embeddings" (inbäddningsmodeller). Se Aktiviteter som stöds.
  • Startpunkten måste öppnas på port 8080, porten som Model Serving förväntar sig.
  • Kommandot entrypoint måste spegla det du testade i steg 3 med port 8080 i stället för din lokala port.
  • Startpunkten startas från mappen MLflow-modellartefakter, så modellsökvägarna är relativa till den mappen.

För en chattmodell:

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

För en inbäddningsmodell anger du task till "llm/v1/embeddings" och startar servern i inbäddningsläge. Med den vLLM-version som används här är --runner pooling det (äldre vLLM-versioner använder --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"
    ),
}

Uppgifter som stöds

task Modelltyp Frågeyta
llm/v1/chat Chattmodeller, inklusive multimodala (visionsspråk) chat.completions
llm/v1/embeddings Inbäddningsmodeller embeddings

Det du deklarerar med task måste överensstämma med vad din entrypoint faktiskt tillhandahåller: entrypointen måste exponera ett OpenAI-kompatibelt API för den uppgiften på port 8080. Exemplen ovan använder vLLM, men alla servrar som uppfyller det här kontraktet fungerar. Andra aktivitetstyper, till exempel llm/v1/completions, stöds inte.

Steg 5: Registrera modellen i Unity Catalog

Registrera modellen i Unity Catalog med .mlflow.register_model Anpassad LLM-servering bygger på expressdistributioner, så registreringen använder parametern env_pack="databricks_model_serving" och kräver mlflow>=3.12 och databricks-sdk>=0.102.0.

Lägg till exempel till följande i anteckningsboken:


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

Steg 6: Skapa en serveringsslutpunkt

Skapa slutpunkten från användargränssnittet eller programmatiskt med Azure Databricks SDK. De viktigaste besluten är beräkningstyp, arbetsbelastningsstorlek och beteende för skalning till noll.

Välj en workload_type baserat på din modell och ditt moln:

workload_type GPU (grafikprocessor) Notes
GPU_SMALL 1 x T4 (16 GB) Minsta alternativ.
GPU_LARGE 1x A100 (80 GB) Rekommenderas för stora LLM-arbetsbelastningar.

workload_size (Small, Medium eller Large) anger antalet provisionerade repliker bakom slutpunkten. Använd Small för utveckling och arbetsbelastningar med låg trafikvolym.

I följande exempel visas en typisk konfiguration:

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

Skala till noll och kapacitetsplanering

Drift av anpassade LLM:er i betaversion tilldelar ett fast antal repliker bakom din slutpunkt. Autoskalning mellan fler än noll repliker stöds ännu inte, så du måste storleksanpassa workload_type och workload_size för din högsta trafik. Ändpunkten köar inkommande begäranden som överskrider kapaciteten hos provisionerade repliker.

Ställ in scale_to_zero_enabled=True så att slutpunkten skalar ned till noll repliker när den är inaktiv. Kallstarter är långsamma – att ladda in modellvikter och starta vLLM tar vanligtvis från en till flera minuter.

För svarstidskänsliga eller produktionskritiska arbetsbelastningar anger du scale_to_zero_enabled=False och dimensionerar workload_size utifrån din topptrafik i förväg.

Varning

Uppskalningskapaciteten är inte garanterad. När Azure Databricks behöver skaffa en ny GPU för slutpunkten – när den skapas, workload_size ökar eller när en slutpunkt vaknar från noll – kan begäran sluta svara om molnleverantören inte har någon GPU-kapacitet i din region. Detta gäller för alla GPU-typer. Databricks minimerar detta med varma pooler och förreservation, som håller GPU-kapaciteten tillgänglig och redo.

Steg 7: Fråga din slutpunkt

När slutpunkten är klar visas den automatiskt på AI Playground från slutpunktens sida. Du kan också fråga den programmässigt med Databricks SDK, OpenAI SDK eller curl.

Chattmodeller (llm/v1/chat):

Databricks SDK

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

OpenAI SDK

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

Inbäddningsmodeller (llm/v1/embeddings):

OpenAI SDK

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

Vissa inbäddningsmodeller förväntar sig ett uppgiftsspecifikt prefix för varje indata (till exempel använder nomic-embed-text-v2-moesearch_query: och search_document:). Kontrollera modellkortet för information om dess indatakonventioner.

Övervaka slutpunkten

Anpassad LLM-servering använder samma observabilityinfrastruktur som standard anpassade slutpunkter för modellservering, men med några vLLM-specifika tillägg som beskrivs i följande avsnitt.

Liveloggar

Fliken Loggar på slutpunktssidan i användargränssnittet för servering visar stdout och stderr från din vLLM-process i realtid. Du kan också öppna utdata via logg-API:et.

Bevarade loggar och mått

När telemetri är aktiverat sparas både loggar och mått i Delta-tabellerna i Unity Catalog för långsiktig kvarhållning, SQL-frågor och efterlevnad. Se Spara anpassade data för modellservering i Unity Catalog för fullständiga anvisningar om konfigurering, krav och tabellscheman.

För anpassad LLM-servering specifikt:

  • Loggar: stdout och stderr från vLLM-processen registreras automatiskt. Ingen loggningskod på programsidan krävs.
  • Metrics: Azure Databricks skrapar automatiskt vLLM-serverns Prometheus /metrics slutpunkt och bevarar måtten tillsammans med loggar. Som standard får du svarstid per begäran, dataflöde, antal token, ködjup och KV-cacheanvändning.

Fråga efter telemetridata

Under Beta finns det inget användargränssnitt för visualisering av loggar eller mått. Fråga efter beständiga data direkt i Unity Catalog med hjälp av SQL eller en notebook-fil. Se mätvärdes- och loggscheman som dokumenteras i Spara anpassade data för modellservering till Unity Catalog.

Följande notebook-fil visar hur du parsar och visualiserar de bevarade vLLM-måtten:

Notebook för anpassade mätvärden för LLM-servering

Hämta anteckningsbok

Exempelanteckningsbok

Utveckla och testa modellen i en serverlös GPU-notebook och logga sedan samma konfiguration och driftsätt den som en slutpunkt för servering. Följande notebook-fil innehåller det fullständiga körningsbara flödet från den här guiden.

Startnotebook för driftsättning av anpassad LLM

Hämta anteckningsbok

Limitations

Följande begränsningar gäller under betaversionen.

  • Ingen autoskalning mellan repliker. Skalning till noll stöds.
  • Endast chattuppgifterna (llm/v1/chatinklusive multimodala) och inbäddningar (llm/v1/embeddings) stöds. Se Aktiviteter som stöds.
  • Ingen routningsoptimering.
  • Inget användargränssnitt för visualisering av loggar eller mått. Fråga telemetri direkt i Unity Catalog.

Kontakta ditt Azure Databricks kontoteam för feedback eller frågor.

Tidsgränsen för artefaktuppladdning under registreringen

När du registrerar modellen med env_packladdar Azure Databricks upp de paketerade modellvikterna och miljön som artefakter (model_version.tar och model_environment.tar). Med versioner av databricks-sdk tidigare än 0.102.0 kan uppladdning av stora LLM-artefakter överskrida tidsgränsen efter fem minuter, och registreringen kan misslyckas med ett felmeddelande som liknar följande:

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

Åtgärda detta genom att uppgradera till databricks-sdk>=0.102.0 och registrera modellen igen:

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