Implantações expressas para endpoint de modelo de operação
Esta página descreve como usar implantações expressas em seus endpoints de serviço de modelo. Implantações expressas reduzem os tempos de implantação e mantêm o ambiente de servindo modelo igual ao ambiente de treinamento de modelo.
As implantações do Express eram anteriormente chamadas de implantações otimizadas para serverless .
O que são implantações expressas?
As implantações expressas empacotam e preparam artefatos de modelo em ambientes de notebook serverless durante o registro do modelo. Isso acelera a implantação do endpoint e mantém os ambientes de treinamento e serviço consistentes.
Em implantações não expressas, artefatos e ambientes de modelo são empacotados em contêineres no momento da implantação, portanto, o ambiente de disponibilização pode não corresponder ao usado durante o treinamento do modelo.
Implantações padrão vs expressas
A tabela a seguir compara uma implantação padrão e uma implantação expressa.
Aspecto | Implantação padrão | Implantação expressa |
|---|---|---|
Quando o ambiente é criado | Uma imagem de contêiner é criada no momento da implantação. | Os artefatos e o ambiente são empacotados quando você registra o modelo. |
Ambiente de treinamento e serviço | O ambiente de serviço pode não corresponder ao ambiente de treinamento. | O ambiente de serviço é idêntico ao ambiente de notebook do qual você fez o registro. |
Velocidade de implantação | Mais lento. A implantação aguarda uma compilação de imagem do contêiner. | Mais rápido. A implantação ignora a criação da imagem de contêiner. |
Velocidade de registro | Padrão. | Adiciona segundos a um minuto para empacotamento, dependendo do tamanho do modelo e do ambiente. |
Log de eventos de implantação | Mostra eventos de criação de imagem de contêiner. | Não mostra eventos de criação de imagem de contêiner. |
Implantações expressas transferem o trabalho de empacotamento único para o registro do modelo, o que adiciona segundos a um minuto a uma chamada register_model, dependendo do tamanho do modelo e do ambiente. Em troca, a implantação é significativamente mais rápida : ela ignora totalmente a criação da imagem de contêiner. Essa compilação também é uma fonte comum de falhas de implantação (resolução de dependências, erros de criação de imagem), portanto, ignorá-la remove uma classe inteira de problemas. O log de eventos de implantação para um modelo expresso não contém eventos de criação de contêiner.
Requisitos
Endpoints de implantação expressa têm os mesmos requisitos que um Endpoint de servindo modelo. Consulte Requisitos.
Além disso:
- O modelo deve ser um modelo personalizado
- O modelo deve ser registrado em um Notebook Serverless usando a versão 3 ou posterior.
- O modelo deve ser registrado em Logs com
mlflow>=3.12edatabricks-sdk>=0.102.0 - O modelo deve ser registrado no Unity Catalog. O compute de serviço deve corresponder ao compute do qual o modelo foi registrado. Você pode registrar a partir de um notebook serverless comum para uso na CPU, ou a partir de compute de GPU serverless para uso na GPU.
- O tamanho máximo do ambiente do modelo é 200GB
Para disponibilizar um LLM personalizado no compute de GPU usando implantações expressas, consulte Disponibilizar LLMs personalizados com o Model Serving personalizado.
Implantar um reclassificador em GPU
Este passo a passo implanta BAAI/bge-reranker-base, um reclassificador de codificador cruzado que avalia o quão bem um documento responde a uma query. Ele configura o ambiente, registra em Logs e registra o modelo com empacotamento expresso, implanta o Endpoint e o consulta.
As implantações de GPU geralmente falham devido a conflitos de versão de dependência, por exemplo, torch e CUDA. Implantações expressas resolvem isso de duas maneiras:
- O conjunto fixo e publicado de bibliotecas pré-instaladas em cada versão do ambiente de GPU serverless está presente durante o serviço exatamente como está no notebook — mesma versão do ambiente, mesmas versões. Estas bibliotecas não são reempacotadas.
- Quaisquer dependências extras instaladas na sessão do Notebook (por exemplo, com
%pip install) são empacotadas durante o registro e restauradas durante o serviço.
Juntos, isso significa que um modelo que é executado no seu notebook continua funcionando quando disponibilizado.
Passo 1: Configurar um Notebook Serverless de GPU
Crie um notebook no compute com GPU serverless com uma GPU A10 e selecione a versão 5 do ambiente, ambiente de AI . O ambiente de AI inclui PyTorch e bibliotecas de machine learning comuns (torch, transformers e outras). Para as versões pinadas exatas, consulte Serverless GPU environment version 5 (Preview).
Instale os pacotes que a implantação expressa requer:
# 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
Você também pode declarar dependências por meio de um ambiente serverless, mas instalar no notebook é o caminho mais simples. Desenvolva em relação às versões pinadas do ambiente para que o ambiente do notebook corresponda ao ambiente de disponibilização.
Como este modelo é disponibilizado em GPU, você deve registrá-lo a partir de um Runtime de GPU serverless. Se você logs de compute de CPU serverless por acidente, o modelo é empacotado com dependências de CPU e o Endpoint de disponibilização de GPU não consegue começar. Adicione a seguinte verificação para falhar rapidamente se o notebook não estiver em um Runtime de 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."
)
Essa verificação só é necessária porque o reclassificador é disponibilizado em GPU. Um modelo de CPU não precisa disso.
O passo 2: Registrar o modelo com MLflow
Carregue o reclassificador como um pipeline text-classification e registre-o com o sabor nativo mlflow.transformers. O flavor nativo captura automaticamente as dependências pip do modelo e executa em GPU. Você não precisa definir pip_requirements, um task ou um ponto de entrada.
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.",
},
)
Não registre o modelo com o argumento registered_model_name de log_model. Esse argumento não aceita env_pack, então ele registra um modelo não expresso. Para habilitar a implantação expressa, registre-se em um passo separado com register_model (Passo 3), que aceita env_pack.
Passo 3: Registrar o Modelo no Unity Catalog com Empacotamento Expresso
Registre o modelo no Unity Catalog e defina o parâmetro env_pack para habilitar a implantação expressa. Este pacote de artefatos do modelo e as dependências que você adicionou à sessão do notebook durante o registro, para que o serviço os reutilize sobre a biblioteca pré-instalada da versão do 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"),
)
Pode-se usar a abreviação de string env_pack="databricks_model_serving" em vez de EnvPackConfig(name="databricks_model_serving"). Para Workspace sem acesso à internet ou com bibliotecas personalizadas, defina install_dependencies=False (consulte O parâmetro env_pack).
O registro requer databricks-sdk>=0.102.0. Versões anteriores podem expirar ao fazer upload de grandes artefatos do modelo.
Passo 4: Criar um Endpoint de Serviço
Implante o modelo registrado com o Databricks SDK. Este passo de implantação é o mesmo que para qualquer modelo personalizado — apenas o passo de registro (Passo 3) difere para o expresso.
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 bloqueia até que o Endpoint esteja pronto. GPU_SMALL é suficiente para este reclassificador. Como a disponibilização reutiliza a mesma versão do ambiente e restaura as dependências que você adicionou no notebook, o modelo disponibilizado é executado com as mesmas versões de biblioteca em relação às quais você desenvolveu, independentemente do tipo de GPU.
Enquanto o Endpoint é implantado, abra a tab Eventos do Endpoint na UI de Serviço. Como esta é uma implantação expressa, o log de eventos não mostra eventos de criação de imagem de contêiner (uma implantação padrão mostra Container image creation initiated seguido por Container image creation finished successfully). Quando o endpoint termina, seu estado mostra Pronto .
O passo 5: Consultar o endpoint
Um codificador cruzado pontua uma query contra um documento, então envie os campos text e text_pair. Consulte programaticamente com o SDK do Databricks ou curl.
- Databricks SDK
- curl
w.serving_endpoints.query(
name=ENDPOINT_NAME,
dataframe_records=[
{"text": "What is Databricks?", "text_pair": "Databricks is a data and AI company."},
],
)
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
O Endpoint retorna uma pontuação de relevância para cada par query-documento; pontuações mais altas indicam uma melhor correspondência. Use essas pontuações para reclassificar documentos candidatos.
Exemplo de Notebook
Importe o seguinte notebook para executar este passo a passo de ponta a ponta.
Notebook inicial do reclassificador expresso
O parâmetro env_pack
O início rápido acima mostra uma implantação expressa para um modelo de GPU. Implantações expressas também funcionam para modelos de CPU. Em todos os casos, a implantação expressa é habilitada ao passar env_pack para 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 empacota e prepara os artefatos do modelo e as dependências que você adicionou à sessão do notebook no momento do registro, razão pela qual o registro leva mais tempo do que uma chamada sem env_pack.
EnvPackConfig aceita um parâmetro install_dependencies (True por default). Quando True, as dependências do modelo são instaladas no ambiente atual para confirmar se o ambiente é válido.
O registro pode falhar em workspaces sem acesso à internet, ou quando o modelo depende de bibliotecas personalizadas, se install_dependencies for True. Nesses casos, defina install_dependencies como False.
Você pode substituir a string "databricks_model_serving" por EnvPackConfig(...) como abreviação. É equivalente a EnvPackConfig(name="databricks_model_serving", install_dependencies=True).