gerenciar o atendimento ao modelo endpoint
Este artigo descreve como gerenciar o endpoint de modelo de serviço usando a UI de serviço e REST API. Consulte Serving endpoint na referência REST API .
Para criar um endpoint de modelo de serviço, use uma das seguintes opções:
Obter o status do modelo endpoint
Você pode verificar o status de um endpoint usando a interface de usuário de serviço ou programaticamente usando a API REST, o Databricks Workspace Client ou o MLflow Deployments SDK.
Os status do endpoint podem ser Ready, Ready (Update failed), Not ready (Updating), Not ready (Update failed) ou Not ready (Stopped). Prontidão refere-se à possibilidade ou não de um endpoint ser consultado. Falha na atualização indica que a última alteração no endpoint não foi bem-sucedida. Parado significa que o endpoint foi parado.
- UI
- REST API
- Databricks Workspace Client
- MLflow Deployments SDK
O indicador de estado endpoint de serviço na parte superior da página de detalhes de um endpoint:
GET /api/2.0/serving-endpoints/{name}
No exemplo de resposta a seguir, o campo state.ready é "READY", o que significa que o endpoint está pronto para receber tráfego. O campo state.update_state é NOT_UPDATING e pending_config não é mais retornado porque a atualização foi concluída com sucesso.
{
"name": "unity-model-endpoint",
"creator": "customer@example.com",
"creation_timestamp": 1666829055000,
"last_updated_timestamp": 1666829055000,
"state": {
"ready": "READY",
"update_state": "NOT_UPDATING"
},
"config": {
"served_entities": [
{
"name": "my-ads-model",
"entity_name": "myCatalog.mySchema.my-ads-model",
"entity_version": "1",
"workload_size": "Small",
"scale_to_zero_enabled": false,
"state": {
"deployment": "DEPLOYMENT_READY",
"deployment_state_message": ""
},
"creator": "customer@example.com",
"creation_timestamp": 1666829055000
}
],
"traffic_config": {
"routes": [
{
"served_model_name": "my-ads-model",
"traffic_percentage": 100
}
]
},
"config_version": 1
},
"id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"permission_level": "CAN_MANAGE"
}
from databricks.sdk import WorkspaceClient
w = WorkspaceClient()
endpoint = w.serving_endpoints.get(name="my-endpoint")
print(f"Endpoint state: {endpoint.state.ready}")
print(f"Update state: {endpoint.state.config_update}")
from mlflow.deployments import get_deploy_client
client = get_deploy_client("databricks")
endpoint = client.get_endpoint(endpoint="my-endpoint")
print(f"Endpoint state: {endpoint['state']}")
print(f"Endpoint config: {endpoint['config']}")
Parar de servir o modelo endpoint
Você pode interromper temporariamente um endpoint de modelo de operação e iniciá-lo mais tarde. Quando um endpoint é interrompido:
- O recurso provisionamento para isso está encerrado.
- O endpoint não pode atender consultas até que seja reiniciado.
- Somente endpoints que atendem modelos personalizados e não têm atualizações em andamento podem ser interrompidos.
- Pontos finais interrompidos não contam para a cota de recurso.
- Consultas enviadas a um endpoint parado retornam um erro 400.
Parar um endpoint
- UI
- REST API
Clique em Parar no canto superior direito.
POST /api/2.0/serving-endpoints/{name}/config:stop
começar um endpoint
Iniciar um endpoint cria uma nova versão de configuração com as mesmas propriedades da configuração interrompida existente.
Quando você estiver pronto para iniciar um modelo de serviço parado endpoint:
- UI
- REST API
Clique em começar no canto superior direito.
POST /api/2.0/serving-endpoints/{name}/config:start
Excluir um modelo de serviço endpoint
A exclusão de um endpoint desabilita o uso e exclui todos os dados associados ao endpoint. Não é possível desfazer a exclusão.
- UI
- REST API
- MLflow Deployments SDK
Clique no menu de kebab na parte superior e selecione Excluir.
DELETE /api/2.0/serving-endpoints/{name}
from mlflow.deployments import get_deploy_client
client = get_deploy_client("databricks")
client.delete_endpoint(endpoint="chat")
Depurar um endpointde modelo de atividade
Dois tipos de logs estão disponíveis para ajudar a depurar problemas com o endpoint:
- logsde construção do contêiner do servidor de modelo : gerados durante a inicialização endpoint quando o contêiner está sendo criado. Esses logs capturam a fase de configuração, incluindo downloads do modelo, instalação de dependências e configuração do ambiente de execução. Use esses logs para depurar por que um endpoint falhou ao iniciar ou travou durante a implantação.
- logsdo servidor de modelo : gerados durante o tempo de execução quando o endpoint está ativamente fornecendo previsões. Esses logs capturam solicitações de entrada, execução de inferência de modelo, erros de tempo de execução e logs em nível de aplicativo do código do seu modelo. Use esses logs para depurar problemas com previsões ou investigar falhas de consulta.
Ambos os tipos log também podem ser acessados na interface do endpoint na tab de logs .
Obter logs de construção de contêineres
Para a construção logs de um modelo servido, o senhor pode usar a seguinte solicitação. Para obter mais informações, consulte o guia de depuração para manutenção do modelo.
GET /api/2.0/serving-endpoints/{name}/served-models/{served-model-name}/build-logs
{
"config_version": 1 // optional
}
Obter logs do servidor modelo
Para os logs do servidor de modelos de um modelo de serviço, o senhor pode usar a seguinte solicitação:
GET /api/2.0/serving-endpoints/{name}/served-models/{served-model-name}/logs
{
"config_version": 1 // optional
}
gerenciar permissões em um endpointde modelo de operação
O senhor deve ter pelo menos a permissão CAN MANAGE em um endpoint de serviço para modificar as permissões. Para obter mais informações sobre os níveis de permissão, consulte Serving endpoint ACLs.
Obter a lista de permissões no endpoint de serviço.
- UI
- Databricks CLI
Clique no botão Permissões no canto superior direito da interface do usuário.
databricks permissions get serving-endpoints <endpoint-id>
Conceda ao usuário jsmith@example.com a permissão CAN QUERY no endpoint de atendimento.
databricks permissions update serving-endpoints <endpoint-id> --json '{
"access_control_list": [
{
"user_name": "jsmith@example.com",
"permission_level": "CAN_QUERY"
}
]
}'
O senhor também pode modificar as permissões do endpoint de atendimento usando a API de permissões.
Adicionar uma política orçamentária serverless para um modelo de serviço endpoint
Visualização
Esse recurso está em Public Preview e não está disponível para o endpoint de atendimento que atende a modelos externos.
As políticas de orçamento sem servidor permitem que sua organização aplique tags personalizadas no uso do serverless para atribuição de faturamento granular. Se o seu workspace usa políticas de orçamento serverless para atribuir o uso do serverless, o senhor pode adicionar uma política de orçamento serverless ao seu endpoint servindo modelo. Consulte Uso de atributos com as políticas de orçamento do serverless.
endpoint Durante a criação do modelo endpoint, o senhor pode selecionar a política de orçamento do serverless no menu Budget policy (Política de orçamento ) na Serving UI. Se tiver uma política de orçamento serverless atribuída a você, todos os pontos de extremidade que criar serão atribuídos a essa política de orçamento serverless, mesmo que você não selecione uma política no menu Política de orçamento .
Se o senhor tiver permissões MANAGE para um endpoint existente, poderá editar e adicionar uma política de orçamento serverless a esse endpoint na página de detalhes do ponto de extremidade na interface do usuário.
Se o senhor tiver recebido uma política de orçamento serverless, os endpoints existentes não serão automaticamente marcados com a política. O senhor deve atualizar manualmente o endpoint existente se quiser anexar uma política de orçamento serverless a ele.
Obtenha um esquema servindo modelo endpoint
Visualização
O suporte para atender a esquemas de consulta de endpoint está em Public Preview. Essa funcionalidade está disponível nas regiões do modelo servindo.
Um esquema de consulta endpoint é uma descrição formal do serviço endpoint usando a especificação padrão da OpenAPI no formato JSON. Ele contém informações sobre o endpoint, incluindo o caminho do endpoint, detalhes para consultar o endpoint, como o formato do corpo da solicitação e da resposta, e o tipo de dados de cada campo. Essas informações podem ser úteis em cenários de reprodutibilidade ou quando o senhor precisar de informações sobre o endpoint, mas não for o criador ou proprietário original do endpoint.
Para obter o esquema servindo modelo endpoint, o modelo servido deve ter um registro de assinatura de modelo e o endpoint deve estar em um estado READY.
Os exemplos a seguir demonstram como obter programaticamente o esquema servindo modelo endpoint usando o REST API.
O esquema retornado pela API está no formato de um objeto JSON que segue a especificação OpenAPI.
ACCESS_TOKEN="<endpoint-token>"
ENDPOINT_NAME="<endpoint name>"
curl "https://example.databricks.com/api/2.0/serving-endpoints/$ENDPOINT_NAME/openapi" -H "Authorization: Bearer $ACCESS_TOKEN" -H "Content-Type: application/json"
Detalhes da resposta do esquema
A resposta é uma especificação OpenAPI no formato JSON, normalmente incluindo campos como openapi, info, servers e paths. Como a resposta do esquema é um objeto JSON, o senhor pode analisá-la usando linguagens de programação comuns e gerar código de cliente a partir da especificação usando ferramentas de terceiros.
Você também pode visualizar a especificação OpenAPI usando ferramentas de terceiros, como o Swagger Editor.
Os principais campos da resposta incluem:
- O campo
info.titlemostra o nome do endpoint de atendimento. - O campo
serverssempre contém um objeto, normalmente o campourl, que é a url base do endpoint. - O objeto
pathsna resposta contém todos os caminhos suportados para um endpoint. A chave no objeto é o URL do caminho. Cadapathpode suportar vários formatos de entradas. Essas entradas estão listadas no campooneOf.
A seguir, um exemplo de resposta de esquema de endpoint:
{
"openapi": "3.1.0",
"info": {
"title": "example-endpoint",
"version": "2"
},
"servers": [{ "url": "https://example.databricks.com/serving-endpoints/example-endpoint" }],
"paths": {
"/served-models/vanilla_simple_model-2/invocations": {
"post": {
"requestBody": {
"content": {
"application/json": {
"schema": {
"oneOf": [
{
"type": "object",
"properties": {
"dataframe_split": {
"type": "object",
"properties": {
"columns": {
"description": "required fields: int_col",
"type": "array",
"items": {
"type": "string",
"enum": ["int_col", "float_col", "string_col"]
}
},
"data": {
"type": "array",
"items": {
"type": "array",
"prefixItems": [
{
"type": "integer",
"format": "int64"
},
{
"type": "number",
"format": "double"
},
{
"type": "string"
}
]
}
}
}
},
"params": {
"type": "object",
"properties": {
"sentiment": {
"type": "number",
"format": "double",
"default": "0.5"
}
}
}
},
"examples": [
{
"columns": ["int_col", "float_col", "string_col"],
"data": [
[3, 10.4, "abc"],
[2, 20.4, "xyz"]
]
}
]
},
{
"type": "object",
"properties": {
"dataframe_records": {
"type": "array",
"items": {
"required": ["int_col", "float_col", "string_col"],
"type": "object",
"properties": {
"int_col": {
"type": "integer",
"format": "int64"
},
"float_col": {
"type": "number",
"format": "double"
},
"string_col": {
"type": "string"
},
"becx_col": {
"type": "object",
"format": "unknown"
}
}
}
},
"params": {
"type": "object",
"properties": {
"sentiment": {
"type": "number",
"format": "double",
"default": "0.5"
}
}
}
}
}
]
}
}
}
},
"responses": {
"200": {
"description": "Successful operation",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"predictions": {
"type": "array",
"items": {
"type": "number",
"format": "double"
}
}
}
}
}
}
}
}
}
}
}
}