Expressdistributioner för modell som betjänar slutpunkter

Den här sidan beskriver hur du använder expressdistributioner på din modell som betjänar slutpunkter. Express-driftsättningar minskar driftsättningstiderna och ser till att miljön för modellservering är densamma som miljön för modellträning.

Note

Expressdistributioner kallades tidigare serverlösa optimerade distributioner.

Vad är expressdistributioner?

Express-distributioner paketerar och mellanlagrar modellartefakter i serverlösa notebook-miljöer vid modellregistrering. Detta påskyndar slutpunktsdistributionen och håller tränings- och serveringsmiljöerna konsekventa.

I icke-expressdistributioner paketeras modellartefakter och miljöer i containrar vid distributionstillfället, så serveringsmiljön kanske inte matchar den som används under modellträningen.

Standard- och expressdistributioner

I följande tabell jämförs en standarddistribution och en expressdistribution.

Aspect Standardinstallation Expressdistribution
När miljön skapas En containeravbildning skapas vid distributionstillfället. Artefakter och miljön paketeras när du registrerar modellen.
Tränings- och serveringsmiljö Serveringsmiljön kanske inte matchar träningsmiljön. Serveringsmiljön är identisk med notebook-miljön som du registrerade från.
Distributionshastighet Långsammare. Distributionen väntar på en containeravbildningsversion. Snabbare. Distributionen hoppar över containeravbildningsversionen.
Registreringshastighet Standard. Lägger till sekunder till en minut för paketering, beroende på modell- och miljöstorlek.
Händelselogg för distribution Visar händelser för skapande av containeravbildningar. Visar inte händelser för skapande av containerbilder.

Express-distributioner flyttar det engångsarbete som paketeringen innebär till modellregistreringen, vilket innebär att ett register_model-anrop tar från några sekunder upp till en minut längre, beroende på modellens och miljöns storlek. I gengäld går driftsättningen betydligt snabbare: den hoppar helt över att bygga containeravbildningen. Det bygget är också en vanlig källa till driftsättningsfel (beroendelösning, fel vid bygge av avbildningar), så genom att hoppa över det undviker man en hel kategori problem. Händelseloggen för distribution för en Express-modell innehåller inga containerbygghändelser.

Requirements

Expressdistributionsslutpunkter har samma krav som en modell som betjänar slutpunkten. Se kraven.

Dessutom:

  • Modellen måste vara en anpassad modell
  • Modellen måste loggas och registreras i en Serverless Notebook med version 3 eller senare
  • Modellen måste loggas och registreras med mlflow>=3.12 och databricks-sdk>=0.102.0
  • Modellen måste vara registrerad i Unity Catalog. Den betjänande beräkningen måste matcha den beräkning som modellen registrerades från. Du kan registrera från en vanlig serverlös notebook för att köras på CPU, eller från serverlös GPU-beräkning för att köras på GPU.
  • Modellens maximala miljöstorlek är 200 GB

Note

Information om hur du hanterar en anpassad LLM på GPU-beräkning med hjälp av expressdistributioner finns i Hantera anpassade LLM:er med anpassad modellservering.

Driftsätt en omrankare på en GPU

Den här genomgången driftsätter BAAI/bge-reranker-base, en korsencoder-baserad omrankare som bedömer hur väl ett dokument besvarar en sökfråga. Den konfigurerar miljön, loggar och registrerar modellen med snabbpaketering, driftsätter slutpunkten och skickar frågor till den.

GPU-distributioner misslyckas ofta på grund av beroendeversionskonflikter, till exempel torch och CUDA. Expressdistributioner löser detta på två sätt:

  • Den fasta, publicerade uppsättningen bibliotek som är förinstallerade i varje serverlös GPU-miljöversion finns under exakt samma tjänst som i notebook-filen – samma miljöversion, samma versioner. Dessa bibliotek packas inte om.
  • Eventuella extra beroenden som du installerar i notebook-sessionen (till exempel med %pip install) paketeras under registreringen och återställs under serveringen.

Sammantaget innebär detta att en modell som körs i din notebook fortsätter att fungera när den driftsätts.

Steg 1: Konfigurera en serverlös GPU-notebook

Skapa en anteckningsbok i serverlös GPU-beräkning med en A10-GPU, och välj miljöversion 5, AI-miljön. AI-miljön innehåller PyTorch och vanliga maskininlärningsbibliotek (torch, transformersoch andra). De exakta fästa versionerna finns i Serverlös GPU-miljö version 5 (förhandsversion).

Installera de paket som expressdistributionen kräver:

# Express deployment requires recent MLflow and Databricks SDK versions.
%pip install "mlflow>=3.12" "databricks-sdk>=0.102.0"
# Install the libraries your model needs. transformers is preinstalled in the
# v5 AI environment; install it explicitly because this model depends on it.
%pip install transformers
%restart_python

Du kan också deklarera beroenden via en serverless-miljö, men att installera i anteckningsboken är det enklaste sättet. Utveckla mot miljöns låsta versioner så att notebook-miljön matchar driftsmiljön.

Eftersom den här modellen hanteras på GPU måste du logga och registrera den från en serverlös GPU-körning. Om du av misstag loggar modellen från en serverlös CPU-beräkningsmiljö paketeras modellen med beroenden för CPU, och GPU-slutpunkten för modellservering kan inte starta. Lägg till följande kontroll för att avbryta direkt om anteckningsboken inte körs med GPU-körning:

import os

# This model is intended to be served on GPU, so we must log and register from a Serverless GPU runtime.
if not os.environ.get("DATABRICKS_ACCELERATOR"):
    raise RuntimeError(
        "This model MUST be logged+registered from a serverless GPU runtime, otherwise the correct dependencies will not be packaged for serving."
    )

Note

Den här kontrollen behövs bara eftersom omrankaren körs på en GPU. En CPU-modell behöver den inte.

Steg 2: Logga modellen med MLflow

Ladda rerankern som en text-classification pipeline och logga den med det inbyggda mlflow.transformers formatet. Den inbyggda varianten identifierar automatiskt modellens pip-beroenden och körs på GPU. Du behöver inte ange pip_requirements, en taskeller en startpunkt.

import mlflow
from transformers import pipeline

# BAAI/bge-reranker-base is a cross-encoder reranker: it scores how well a document answers a query.
pipe = pipeline("text-classification", model="BAAI/bge-reranker-base")

model_info = mlflow.transformers.log_model(
    transformers_model=pipe,
    name="bge_reranker",
    input_example={
        "text": "What is Databricks?",
        "text_pair": "Databricks is a data and AI company.",
    },
)

Important

Registrera inte modellen med registered_model_name argumentet log_model. Den parametern accepterar inte env_pack, så det resulterar i en modell som inte är av typen Express. Om du vill aktivera expressdistribution registrerar du dig i ett separat steg med register_model (steg 3), som accepterar env_pack.

Steg 3: Registrera modellen i Unity Catalog med expresspaketering

Registrera modellen till Unity Catalog och ange parametern env_pack för att aktivera expressdistribution. Detta paketerar modellartefakterna och de beroenden som du lade till i notebooksessionen vid registreringen, så att modellen vid servering kan återanvända dem utöver miljöversionens förinstallerade bibliotek.

import mlflow
from mlflow.utils.env_pack import EnvPackConfig

mlflow.set_registry_uri("databricks-uc")

model_version = mlflow.register_model(
    model_uri=model_info.model_uri,
    name="main.default.bge_reranker",
    env_pack=EnvPackConfig(name="databricks_model_serving"),
)

Du kan använda kortformen env_pack="databricks_model_serving" i stället för EnvPackConfig(name="databricks_model_serving"). För arbetsytor utan internetåtkomst eller med anpassade bibliotek anger du install_dependencies=False (se Parameternenv_pack).

Registrering kräver databricks-sdk>=0.102.0. Tidigare versioner kan överskrida tidsgränsen vid uppladdning av stora modellartefakter.

Steg 4: Skapa en serving endpoint

Distribuera den registrerade modellen med Azure Databricks SDK. Det här distributionssteget är detsamma som för alla anpassade modeller – endast registreringssteget (steg 3) skiljer sig åt för express.

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.serving import (
    EndpointCoreConfigInput,
    ServedEntityInput,
    ServingModelWorkloadType,
)

ENDPOINT_NAME = "bge-reranker-endpoint"

w = WorkspaceClient()
w.serving_endpoints.create_and_wait(
    name=ENDPOINT_NAME,
    config=EndpointCoreConfigInput(
        name=ENDPOINT_NAME,
        served_entities=[
            ServedEntityInput(
                name="bge-reranker",
                entity_name=model_version.name,
                entity_version=model_version.version,
                workload_type=ServingModelWorkloadType.GPU_SMALL,
                workload_size="Small",
                scale_to_zero_enabled=False,
            )
        ],
    ),
)

create_and_wait blockerar tills ändpunkten är redo. GPU_SMALL räcker för den här omrankningen. Eftersom servering återanvänder samma miljöversion och återställer de beroenden som du lade till i notebook-filen körs den serverade modellen mot samma biblioteksversioner som du utvecklade mot, oavsett GPU-typ.

När slutpunkten distribueras öppnar du fliken Händelser för slutpunkten i användargränssnittet för servering. Eftersom det här är en expressdriftsättning visar händelseloggen inte händelser för skapande av containeravbildningar (vid en standarddriftsättning visas Container image creation initiated följt av Container image creation finished successfully). När slutpunkten är klar visas statusen Klar.

Steg 5: Gör en förfrågan till ändpunkten

En cross-encoder poängsätter en fråga i förhållande till ett dokument, så skicka fälten text och text_pair. Fråga programmatiskt med Databricks SDK eller curl.

Databricks SDK

w.serving_endpoints.query(
    name=ENDPOINT_NAME,
    dataframe_records=[
        {"text": "What is Databricks?", "text_pair": "Databricks is a data and AI company."},
    ],
)

curl

curl -X POST \
  -u "token:$DATABRICKS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"dataframe_records":[{"text":"What is Databricks?","text_pair":"Databricks is a data and AI company."}]}' \
  https://<workspace-url>/serving-endpoints/bge-reranker-endpoint/invocations

Slutpunkten returnerar en relevanspoäng för varje frågedokumentpar. högre poäng indikerar en bättre matchning. Använd dessa poäng för att ändra rangordning av kandidatdokument.

Exempelanteckningsbok

Importera följande notebook för att köra den här genomgången från början till slut.

Express omrankare startanteckningsbok

Hämta anteckningsbok

Parametern env_pack

Snabbstarten ovan visar en expressdistribution för en GPU-modell. Expressdistributioner fungerar också för CPU-modeller. I varje fall aktiverar du expressdistribution genom att skicka env_pack till register_model:

import mlflow
from mlflow.utils.env_pack import EnvPackConfig

mlflow.register_model(
    model_info.model_uri,
    model_name,
    env_pack=EnvPackConfig(name="databricks_model_serving"),
)

env_pack paketerar och mellanlagrar modellartefakterna och de beroenden som du lade till i notebook-sessionen när registreringen sker, vilket är anledningen till att registreringen tar längre tid än ett anrop utan env_pack.

EnvPackConfig accepterar en install_dependencies parameter (True som standard). När Trueinstalleras modellens beroenden i den aktuella miljön för att bekräfta att miljön är giltig.

Note

Registreringen kan misslyckas på arbetsytor utan internetåtkomst, eller när modellen är beroende av anpassade bibliotek, om install_dependencies är True. I dessa fall ställer du in install_dependencies till False.

Du kan ersätta strängen "databricks_model_serving" med EnvPackConfig(...) som en förkortning. Det motsvarar EnvPackConfig(name="databricks_model_serving", install_dependencies=True).

  • Last updated on