Aangepaste LLM's leveren met aangepaste modelbediening

Important

Deze functie bevindt zich in de bètaversie. Werkruimtebeheerders kunnen de toegang tot deze functie beheren vanaf de pagina Previews . Zie Azure Databricks previews beheren.

Op deze pagina ziet u hoe u aangepaste modellen voor grote talen (LLM's) implementeert in Model Serving met behulp van een vLLM-engine . Gebruik deze werkstroom om nauwkeurig afgestemde modellen, PEFT-varianten, multimodale modellen en andere basismodellen te leveren die niet beschikbaar zijn in Foundation Model API's (FMAPI). Het startersnotitieblok aan het einde van deze pagina bevat alle uitvoerbare code voor de volgende stappen.

Wanneer gebruikt u aangepaste LLM-server

Azure Databricks raadt aangepaste LLM-server aan wanneer u een van de volgende gebruiksscenario's hebt:

  • Volledig fijnafgestelde modellen met aangepaste gewichten die u hebt getraind in Azure Databricks.
  • Modellen van Hugging Face die niet beschikbaar zijn in FMAPI.
  • Aangepaste PEFT-recepten die FMAPI niet ondersteunt.
  • Gespecialiseerde modellen buiten de FMAPI-catalogus, zoals MedGemma.
  • Multimodale (vision-language) modellen zoals Qwen/Qwen2.5-VL-3B-Instruct.
  • Modellen insluiten die niet beschikbaar zijn in FMAPI, zoals nomic-ai/nomic-embed-text-v2-moe.
  • Elk model dat past op een 1xH100 (80 GB GPU-geheugen).

Requirements

Stap 1: Uw omgeving instellen

Maak een notebook op serverloze GPU-rekenkracht met een A10 GPU. Installeer vLLM en de bijbehorende afhankelijkheden. Het startnotebook legt een geteste vLLM-versie vast.

U kunt ook afhankelijkheden opgeven via een serverloze omgeving in plaats van te gebruiken %pip install.

Important

Stel uw werkmap in op de lokale harde schijf (bijvoorbeeld met behulp van tempfile.mkdtemp()). Het /Workspace bestandssysteem biedt geen ondersteuning voor grote bestanden, zoals modelgewichten.

Stap 2: Uw model downloaden

Download de modelgewichten van Hugging Face met snapshot_download. Het startersnotitieblok gebruikt Qwen/Qwen3-4B als voorbeeld, maar u kunt elk model vervangen dat past bij het geheugenbudget van uw geselecteerde GPU, waaronder de volgende:

  • Multimodale modellen zoals Qwen/Qwen2.5-VL-3B-Instruct voor gebruikssituaties met beeld en taal.
  • Grotere modellen die op een 1xH100 passen, zoals openai/gpt-oss-120b.

Selecteer een GPU op basis van de geheugen- en prestatiebehoeften van uw model.

Graphics Processing Unit (GPU) GPU-geheugen workload_type
T4 16 GB GPU_SMALL
A100 80 GB GPU_LARGE

Stap 3: Het model lokaal testen met vLLM

Voordat u het model implementeert, test u het model rechtstreeks in uw serverloze GPU-notebook door een lokale vLLM-server te starten. Met lokaal testen kunt u het model verifiëren, experimenteren met vLLM-parameters en problemen oplossen voordat u een service-eindpunt maakt.

Belangrijke dingen die u moet weten:

  • Serverloze GPU-rekenkracht staat alleen poorten 3000-3999 toe voor lokale tests. Selecteer een poort in dat bereik; het startersnotitieblok maakt gebruik van 3080.
  • De vLLM-server maakt een openAI-compatibele API beschikbaar op /invocations.
  • U kunt zowel reguliere als streamingaanvragen testen.
  • Stem parameters zoals --dtype, --max-model-lenen --gpu-memory-utilization voor uw model af.
  • Voeg --enforce-eager toe voor sneller opstarten, ten koste van enige inferenceprestaties.
  • Gebruik voor grotere modellen een serverloze GPU-variant van H100 voor lokaal testen.

Wanneer u tevreden bent met de configuratie, stopt u de lokale server voordat u doorgaat.

Stap 4: Het model vastleggen met een aangepast invoerpunt

Deze stap verbindt uw lokale installatie met Model Serving en heeft de volgende configuratievereisten:

  • De task moet "llm/v1/chat" zijn (chatmodellen, inclusief multimodale modellen) of "llm/v1/embeddings" (embeddingmodellen). Zie Ondersteunde taken.
  • Het invoerpunt moet zijn geopend op poort 8080, de poort die Model Serving verwacht.
  • De invoerpuntopdracht moet spiegelen wat u in stap 3 hebt getest, met poort 8080 in plaats van uw lokale poort.
  • Het invoerpunt wordt gestart vanuit de map MLflow-modelartefacten, dus modelpaden zijn relatief ten opzichte van die map.

Voor een chatmodel:

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

Voor een embeddingmodel stelt u task in op "llm/v1/embeddings" en start u de server in embeddingmodus. Met de vLLM-versie die hier wordt gebruikt, is dat --runner pooling (oudere vLLM-versies gebruiken --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"
    ),
}

Ondersteunde taken

task Modeltype Zoekoppervlak
llm/v1/chat Chatmodellen, waaronder multimodale (beeld-taal)modellen chat.completions
llm/v1/embeddings Modellen insluiten embeddings

De task die u declareert, moet overeenkomen met wat uw entrypoint daadwerkelijk aanbiedt: het entrypoint moet de OpenAI-compatibele API voor die taak beschikbaar maken op poort 8080. In de bovenstaande voorbeelden wordt vLLM gebruikt, maar elke server die aan dit contract voldoet, werkt. Andere taaktypen, zoals llm/v1/completions, worden niet ondersteund.

Stap 5: het model registreren bij Unity Catalog

Registreer het model bij Unity Catalog met behulp van mlflow.register_model. Aangepaste LLM-service is gebaseerd op snelle implementaties, dus de registratie maakt gebruik van de env_pack="databricks_model_serving" parameter en vereist mlflow>=3.12 en databricks-sdk>=0.102.0.

Voeg bijvoorbeeld het volgende toe aan uw notitieblok:


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

Stap 6: Een service-eindpunt maken

Maak het eindpunt vanuit de gebruikersinterface of programmatisch met de Azure Databricks SDK. De belangrijkste beslissingen zijn het rekentype, de grootte van de workload en het scale-to-zero-gedrag.

Selecteer een workload_type op basis van uw model en cloud:

workload_type Graphics Processing Unit (GPU) Opmerkingen
GPU_SMALL 1x T4 (16 GB) Kleinste optie.
GPU_LARGE 1x A100 (80 GB) Aanbevolen voor grote LLM-workloads.

workload_size (Small, Mediumof Large) bepaalt het aantal ingerichte replica's achter het eindpunt. Gebruik Small voor ontwikkeling en workloads met weinig verkeer.

In het volgende voorbeeld ziet u een typische configuratie:

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

Schaal naar nul en capaciteitsplanning

Aangepaste LLM-service in bèta richt een vast aantal replica's achter uw eindpunt in. Automatisch opschalen naar meer dan nul replica's wordt nog niet ondersteund, dus u moet workload_type en workload_size afstemmen op uw piekverkeer. Het eindpunt plaatst aanvragen die de capaciteit van de ingerichte replica’s overschrijden in de wachtrij.

Stel scale_to_zero_enabled=True in om het eindpunt omlaag te laten schalen naar nul replica's wanneer het inactief is. Koude start is traag: het laden van modelgewichten en het starten van vLLM duurt meestal één tot enkele minuten.

Voor latentiegevoelige of productiekritische workloads stelt u scale_to_zero_enabled=False in en stemt u de grootte van workload_size vooraf af op uw piekverkeer.

Warning

Opschalingscapaciteit is niet gegarandeerd. Wanneer Azure Databricks een nieuwe GPU moet toewijzen aan uw eindpunt — bij het maken ervan, bij een toename van workload_size, of wanneer uw eindpunt vanuit nul ontwaakt — kan de aanvraag vastlopen als de cloudprovider in uw regio geen GPU-capaciteit beschikbaar heeft. Dit geldt voor alle GPU-typen. Databricks beperkt dit met warme pools en prereservatie, waardoor GPU-capaciteit beschikbaar en gereed blijft.

Stap 7: Een query uitvoeren op uw eindpunt

Nadat het eindpunt gereed is, wordt het automatisch weergegeven in de AI-speeltuin vanaf de pagina van het eindpunt. U kunt er ook programmatisch query's op uitvoeren met behulp van de Databricks SDK, de OpenAI SDK of curl.

Chatmodellen (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

Modellen insluiten (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

Sommige insluitmodellen verwachten een taakspecifiek voorvoegsel voor elke invoer (bijvoorbeeld nomic-embed-text-v2-moe gebruikt search_query: en search_document:). Controleer de kaart van uw model op de invoerconventies.

Uw eindpunt bewaken

Aangepaste LLM-service maakt gebruik van dezelfde waarneembaarheidsinfrastructuur als standaard aangepaste modellen voor eindpunten, maar met enkele vLLM-specifieke extra's die in de volgende secties worden beschreven.

Livelogboeken

Het tabblad Logboeken op de eindpuntpagina in de Serving-UI toont stdout en stderr vanuit uw vLLM-proces in realtime. U kunt deze uitvoer ook openen via de logboeken-API.

Persistente logboeken en metrische gegevens

Wanneer telemetrie is ingeschakeld, worden zowel logboeken als metrische gegevens bewaard in Unity Catalog Delta-tabellen voor langetermijnretentie, SQL-query's en naleving. Zie Persistent aangepast model dat gegevens verwerkt in Unity Catalog voor volledige installatie-instructies, vereisten en tabelschema's.

Voor een aangepaste LLM-server met name:

  • Logboeken: stdout en stderr van het vLLM-proces worden automatisch vastgelegd. Er is geen logboekregistratiecode aan de toepassingszijde vereist.
  • Metrics: Azure Databricks automatisch het Prometheus-eindpunt van de vLLM-server /metrics verwijdert en de metrische gegevens naast logboeken persistent maakt. Standaard krijgt u latentie per aanvraag, doorvoer, tokenaantallen, wachtrijdiepte en KV-cachegebruik.

Telemetriegegevens opvragen

Tijdens bèta is er geen gebruikersinterface voor het visualiseren van logboeken of metrische gegevens. Query's uitvoeren op de persistente gegevens rechtstreeks in Unity Catalog met behulp van SQL of een notebook. Zie de schema's voor metriek en logboeken zoals gedocumenteerd in Aangepaste modelservinggegevens persistent opslaan in Unity Catalog.

In het volgende notebook ziet u hoe u de persistente metrische gegevens van vLLM kunt parseren en visualiseren:

Aangepaste LLM-notebook voor metrische gegevens

Notebook krijgen

Voorbeeld van notebook

Ontwikkel en test het model in een serverloze GPU-notebook , logeer en implementeer dezelfde configuratie als een dienend eindpunt. Het volgende notebook bevat de volledige uitvoerbare werkstroom van deze handleiding.

Starternotebook voor het serveren van aangepaste LLM's

Notebook krijgen

Limitations

De volgende beperkingen gelden tijdens de bètaversie.

  • Geen automatische schaalaanpassing tussen replica's. Schaal naar nul wordt ondersteund.
  • Alleen de chattaken (llm/v1/chatinclusief multimodale) en insluitingen (llm/v1/embeddings) worden ondersteund. Zie Ondersteunde taken.
  • Geen routeoptimalisatie.
  • Er is geen gebruikersinterface voor het visualiseren van logboeken of metrische gegevens. Telemetrie direct opvragen in Unity Catalog.

Neem contact op met uw Azure Databricks-accountteam voor feedback of vragen.

Uploaden van artefacten krijgt een time-out tijdens registratie

Wanneer u het model registreert met env_pack, uploadt Azure Databricks de verpakte modelgewichten en omgeving als artefacten (model_version.tar en model_environment.tar). Met databricks-sdk versies ouder dan 0.102.0, kan het uploaden van grote LLM-artefacten na vijf minuten een time-out hebben en mislukt de registratie met een fout zoals hieronder:

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

Om dit op te lossen, upgrade naar databricks-sdk>=0.102.0 en registreer het model opnieuw:

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