Distribuzioni rapide per i modelli che servono gli endpoint

Questa pagina descrive come utilizzare i deployment rapidi sui tuoi endpoint di model serving. Le distribuzioni rapide diminuiscono i tempi di distribuzione e mantengono l'ambiente di gestione del modello allo stesso modo dell'ambiente di training del modello.

Annotazioni

Le distribuzioni Rapide sono state precedentemente chiamate distribuzioni ottimizzate senza server.

Cosa sono le distribuzioni rapide?

Pacchetti di distribuzioni rapide e artefatti del modello di staging in ambienti notebook serverless durante la registrazione del modello. Ciò accelera la distribuzione degli endpoint e mantiene coerenti gli ambienti di training e serving.

Nelle distribuzioni non rapide, gli artefatti e gli ambienti del modello vengono inseriti in contenitori in fase di distribuzione, pertanto l'ambiente di gestione potrebbe non corrispondere a quello usato durante il training del modello.

Distribuzioni standard e rapide

La tabella seguente confronta una distribuzione standard e una distribuzione rapida.

Aspect Distribuzione standard Distribuzione rapida
Quando l'ambiente viene creato Un'immagine container viene creata al momento della distribuzione. Gli artefatti e l'ambiente vengono inseriti in un pacchetto quando si registra il modello.
Ambiente di training e gestione L'ambiente di gestione potrebbe non corrispondere all'ambiente di training. L'ambiente di serving è identico all'ambiente notebook da cui è stata effettuata la registrazione.
Velocità di distribuzione Più lento. La distribuzione è in attesa della creazione di un'immagine del container. Più velocemente. La distribuzione ignora la compilazione dell'immagine del contenitore.
Velocità di registrazione Standard. Richiede da alcuni secondi a un minuto per creare il pacchetto, a seconda delle dimensioni del modello e dell'ambiente.
Registro degli eventi di distribuzione Mostra gli eventi di creazione di immagini del contenitore. Non mostra gli eventi di creazione dell'immagine del contenitore.

Le distribuzioni rapide spostano il lavoro di creazione di pacchetti monouso nella registrazione del modello, che aggiunge secondi a un minuto a una register_model chiamata, a seconda delle dimensioni del modello e dell'ambiente. In cambio, la distribuzione è notevolmente più veloce: ignora completamente la compilazione dell'immagine del contenitore. Questa build è anche una causa comune di errori di distribuzione (risoluzione delle dipendenze, errori di build delle immagini), quindi saltarla elimina un'intera classe di problemi. Il registro eventi di distribuzione per un modello express non contiene eventi di compilazione del contenitore.

Requirements

Gli endpoint di distribuzione rapida hanno gli stessi requisiti di un endpoint di gestione del modello. Vedere Requisiti.

In aggiunta:

  • Il modello deve essere un modello personalizzato
  • Il modello deve essere tracciato e registrato in un Serverless Notebook con versione 3 o successiva
  • Il modello deve essere registrato nei log e registrato con mlflow>=3.12 e databricks-sdk>=0.102.0
  • Il modello deve essere registrato in Unity Catalog. La gestione delle risorse di calcolo deve corrispondere al calcolo da cui è stato registrato il modello. È possibile eseguire la registrazione da un normale notebook serverless da usare sulla CPU o dal calcolo GPU serverless da usare nella GPU.
  • La dimensione massima dell'ambiente del modello è 200 GB

Annotazioni

Per gestire un LLM personalizzato in un ambiente di calcolo GPU tramite distribuzioni rapide, vedere Gestire gli LLM personalizzati con la gestione del modello personalizzata.

Distribuisci un reranker su GPU

Questa procedura dettagliata distribuisce BAAI/bge-reranker-base, un reranker tra codificatori che assegna un punteggio alla frequenza con cui un documento risponde a una query. Configura l'ambiente, registra i log e il modello con Express Packaging, distribuisce l'endpoint e lo interroga.

Le distribuzioni GPU spesso hanno esito negativo a causa di conflitti di versione delle dipendenze, torch ad esempio e CUDA. Le distribuzioni rapide consentono di risolvere questo problema in due modi:

  • Il set fisso e pubblicato di librerie preinstallate in ogni versione dell'ambiente GPU serverless è presente durante la gestione esattamente come nel notebook, ovvero la stessa versione dell'ambiente, le stesse versioni. Queste librerie non vengono reimpacchettate.
  • Tutte le dipendenze aggiuntive installate nella sessione del notebook , ad esempio con %pip install, vengono incluse durante la registrazione e ripristinate durante la gestione.

Questo significa che un modello eseguito nel notebook continua a funzionare quando viene servito.

Passaggio 1: Configurare un notebook GPU serverless

Crea un notebook in serverless GPU compute con una GPU A10 e seleziona versione 5 dell'ambiente, ambiente IA. L'ambiente di intelligenza artificiale include PyTorch e librerie comuni di Machine Learning (torch, transformerse altri). Per le versioni bloccate esatte, vedi Ambiente GPU serverless versione 5 (Anteprima).

Installare i pacchetti necessari per la distribuzione rapida:

# 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

È anche possibile dichiarare le dipendenze tramite un ambiente serverless, ma l'installazione nel notebook è il percorso più semplice. Sviluppare utilizzando le versioni bloccate dell'ambiente in modo che l'ambiente del notebook corrisponda all'ambiente di serving.

Poiché questo modello viene eseguito su GPU, devi registrarlo nei log e registrarlo da un ambiente di runtime serverless con GPU. Se si esegue la registrazione dal calcolo della CPU serverless per errore, il modello viene creato in un pacchetto con dipendenze della CPU e l'endpoint di gestione della GPU non viene avviato. Aggiungere il controllo seguente per fallire immediatamente se il notebook non è in esecuzione su un runtime GPU:

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

Annotazioni

Questo controllo è necessario solo perché il reranker viene servito nella GPU. Un modello di CPU non ne ha bisogno.

Passaggio 2: Registrare il modello con MLflow

Carica il reranker come una pipeline text-classification e registralo con il formato nativo mlflow.transformers. Il flavor nativo rileva automaticamente le dipendenze di pip del modello e viene eseguito su GPU. Non è necessario impostare pip_requirements, task o un punto di ingresso.

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

Importante

Non registrare il modello con l'argomento registered_model_name di log_model. L'argomento non accetta env_pack, quindi registra un modello non express. Per abilitare la distribuzione rapida, eseguire la registrazione in un passaggio separato con register_model (passaggio 3), che accetta env_pack.

Passaggio 3: Registrare il modello in Unity Catalog con la creazione rapida dei pacchetti

Registrare il modello in Unity Catalog e impostare il parametro per abilitare la env_pack distribuzione rapida. Questo crea un pacchetto con gli artefatti del modello e le dipendenze che hai aggiunto alla sessione del notebook durante la registrazione, in modo che il servizio di serving le riutilizzi oltre alle librerie preinstallate nella versione dell'ambiente.

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

È possibile usare la stringa abbreviata env_pack="databricks_model_serving" al posto di EnvPackConfig(name="databricks_model_serving"). Per le aree di lavoro senza accesso a Internet o con librerie personalizzate, impostare install_dependencies=False (vedere Il env_pack parametro ).

La registrazione richiede databricks-sdk>=0.102.0. Le versioni precedenti possono andare in timeout durante il caricamento di artefatti del modello di grandi dimensioni.

Passaggio 4: Creare un endpoint di gestione

Distribuire il modello registrato con Azure Databricks SDK. Questo passaggio di distribuzione è identico a quello di qualsiasi modello personalizzato. Solo il passaggio di registrazione (passaggio 3) è diverso per 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 blocca fino a quando l'endpoint non è pronto. GPU_SMALL è sufficiente per questo reranker. Poiché serve riutilizza la stessa versione dell'ambiente e ripristina le dipendenze aggiunte nel notebook, il modello servito viene eseguito sulle stesse versioni della libreria sviluppate, indipendentemente dal tipo di GPU.

Durante la distribuzione dell'endpoint, aprire la scheda Eventi dell'endpoint nell'interfaccia utente di gestione. Poiché si tratta di una distribuzione rapida, il registro eventi non mostra gli eventi di creazione dell'immagine del contenitore (viene visualizzata Container image creation initiated una distribuzione standard seguita da Container image creation finished successfully). Al termine dell'endpoint, il relativo stato è Pronto.

Passaggio 5: Eseguire una query sull'endpoint

Un cross-encoder attribuisce un punteggio a una query rispetto a un documento, quindi invia i campi text e text_pair. Interroga tramite codice con l'SDK di Databricks o 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

L'endpoint restituisce un punteggio di pertinenza per ogni coppia di documenti di query; punteggi più alti indicano una corrispondenza migliore. Usa questi punteggi per riordinare i documenti candidati.

Notebook di esempio

Importa il notebook seguente per eseguire questa guida dall'inizio alla fine.

Notebook di avvio per reranker Express

Ottieni il notebook

Parametro env_pack

La guida rapida qui sopra mostra una distribuzione rapida per un modello GPU. Le distribuzioni rapide funzionano anche per i modelli di CPU. In ogni caso, si abilita la distribuzione rapida passando env_pack a 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 impacchetta e prepara gli artefatti del modello e le dipendenze che hai aggiunto alla sessione del notebook al momento della registrazione, per questo la registrazione richiede più tempo rispetto a una chiamata senza env_pack.

EnvPackConfig accetta un install_dependencies parametro (True per impostazione predefinita). Quando True, le dipendenze del modello vengono installate nell'ambiente corrente per verificare che l'ambiente sia valido.

Annotazioni

La registrazione può avere esito negativo nelle aree di lavoro senza accesso a Internet o quando il modello dipende da librerie personalizzate, se install_dependencies è True. In questi casi, impostare install_dependencies su False.

È possibile sostituire la stringa "databricks_model_serving" come EnvPackConfig(...) abbreviata. Equivale a EnvPackConfig(name="databricks_model_serving", install_dependencies=True).

  • Last updated on