Implantar um modelo em um endpoint

Antes de receber previsões on-line de um modelo treinado, é necessário implantar o modelo em um endpoint. Para isso, use o console do Google Cloud, a CLI do Google Cloud ou a API Vertex AI.

Este documento descreve o processo de implantação de modelos em endpoints.

O que acontece quando você implanta um modelo

A implantação de um modelo associa recursos físicos ao modelo para que ele possa exibir previsões on-line com baixa latência.

É possível implantar vários modelos em um endpoint ou o mesmo modelo em vários endpoints. Para mais informações, consulte Motivos para implantar mais de um modelo no mesmo endpoint.

Preparar a implantação de um modelo em um endpoint

Durante a implantação do modelo, você toma as seguintes decisões importantes sobre como executar a previsão on-line:

Recurso criado Configuração especificada na criação de recursos
Endpoint Local onde executar predições
Modelo Contêiner a ser usado (ModelContainerSpec)
DeployedModel Recursos de computação para usar na previsão on-line

Depois que o modelo for implantado no endpoint, essas configurações de implantação não poderão ser alteradas. Para fazer isso, é necessário reimplantar o modelo.

A primeira etapa do processo de implantação é decidir qual tipo de endpoint usar. Para mais informações, consulte Escolher um tipo de endpoint.

Em seguida, verifique se o modelo está visível no Vertex AI Model Registry. Isso é necessário para que o modelo possa ser implantado. Para saber mais sobre o Model Registry, incluindo como importar artefatos de modelo ou criá-los diretamente no Model Registry, consulte Introdução ao Vertex AI Model Registry.

A próxima decisão a ser tomada é quais recursos de computação usar para fornecer o modelo. O tipo de treinamento (AutoML ou personalizado) e dados (AutoML) do modelo determinam os tipos de recursos físicos disponíveis nele. Após a implantação do modelo, é possível mutate alguns desses recursos sem criar uma nova implantação.

O recurso de endpoint fornece o endpoint de serviço (URL) que você usa para solicitar a previsão. Exemplo:

   https://us-central1-aiplatform.googleapis.com/v1/projects/{project}/locations/{location}/endpoints/{endpoint}:predict

Implantar um modelo em um endpoint

É possível implantar um modelo em um endpoint usando o console do Google Cloud ou usando a CLI gcloud ou a API Vertex AI.

Implantar um modelo em um endpoint público usando o console do Google Cloud

No console do Google Cloud, é possível implantar um modelo em um endpoint público dedicado ou compartilhado ou criar um novo endpoint durante o processo de implantação. Para mais detalhes, consulte Implantar um modelo usando o console do Google Cloud.

Implantar um modelo em um endpoint público usando a CLI gcloud ou a API Vertex AI

Ao implantar um modelo usando a CLI gcloud ou a API Vertex AI, primeiro é necessário criar um endpoint dedicado ou compartilhado e, em seguida, implantar o modelo nele. Veja mais detalhes em:

  1. Criar um endpoint público dedicado ou compartilhado
  2. Implantar um modelo usando a CLI gcloud ou a API Vertex AI

Implantar um modelo em um endpoint do Private Service Connect

Para mais detalhes, consulte Usar endpoints do Private Service Connect para previsão on-line.

Usar uma implantação gradual para atualizar um modelo implantado

É possível usar uma implantação contínua para substituir um modelo implantado por uma nova versão do mesmo modelo. O novo modelo reutiliza os recursos de computação do modelo anterior. Para mais detalhes, consulte Usar uma implantação gradual para substituir um modelo implantado.

Cancelar a implantação de um modelo e excluir o endpoint

É possível remover a implantação de um modelo e excluir o endpoint. Para mais detalhes, consulte Cancelar a implantação de um modelo e excluir o endpoint.

Motivos para implantar mais de um modelo no mesmo endpoint

A implantação de dois modelos no mesmo endpoint permite substituir gradualmente um modelo por outro. Por exemplo, suponha que você esteja usando um modelo e encontre uma maneira de aumentar a precisão dele com novos dados de treinamento. No entanto, não convém atualizar o aplicativo para apontar para um novo URL de endpoint e você não quer criar alterações repentinas no aplicativo. Você pode adicionar o novo modelo ao mesmo endpoint, exibindo uma pequena porcentagem do tráfego e aumentar gradualmente a divisão de tráfego do novo modelo até que ele exiba 100% do tráfego.

Como os recursos são associados ao modelo em vez do endpoint, é possível implantar modelos de tipos diferentes no mesmo endpoint. No entanto, a prática recomendada é implantar modelos de um tipo específico, como um AutoML tabular ou treinamento personalizado, em um endpoint. Essa configuração é mais fácil de gerenciar.

Motivos para implantar um modelo em mais de um endpoint

Pode ser útil implantar os modelos com diferentes recursos para diferentes ambientes de aplicativos, como testes e produção. Você também pode querer oferecer suporte a diferentes SLOs para suas solicitações de previsão. Talvez um dos seus aplicativos tenha necessidades de desempenho muito mais altas do que outros. Nesse caso, é possível implantar esse modelo em um endpoint de desempenho superior com mais recursos de máquina. Para otimizar os custos, também é possível implantar o modelo em um endpoint de desempenho inferior com menos recursos da máquina.

Comportamento de escalonamento

Ao implantar um modelo para previsão on-line como um DeployedModel, é possível configurar nós de previsão para serem escalonados automaticamente. Para isso, defina dedicatedResources.maxReplicaCount com um valor maior que dedicatedResources.minReplicaCount.

Ao configurar um DeployedModel, você precisa definir dedicatedResources.minReplicaCount como pelo menos 1. Em outras palavras, não é possível configurar o DeployedModel para escalonar para 0 nós de previsão quando ele não é usado.

Por padrão, a operação de implantação só é considerada bem-sucedida se o número de nós de previsão atingir dedicatedResources.minReplicaCount antes do valor do tempo limite da solicitação de implantação. Caso contrário, a implantação é marcada como com falha e os recursos subjacentes são liberados.

Implantação e mutação parcialmente bem-sucedidas

É possível modificar o comportamento de implantação padrão definindo dedicatedResources.requiredReplicaCount como um valor menor que dedicatedResources.minReplicaCount. Nesse caso, quando o número de nós de previsão chega a dedicatedResources.requiredReplicaCount, a operação de implantação é marcada como concluída, mesmo que ainda não esteja. A implantação continua até que dedicatedResources.minReplicaCount seja alcançado. Se dedicatedResources.minReplicaCount não for alcançado antes do tempo de solicitação de implantação, a operação ainda terá sucesso, mas uma mensagem de erro para as réplicas com falha será retornada em DeployedModel.status.message.

A cota para disponibilização de modelo personalizado é calculada com base no uso em tempo real dos recursos de computação do modelo implantado. Se a soma de maxReplicaCount para todas as implantações no projeto for maior do que a cota, algumas implantações podem não ser escalonadas automaticamente devido ao esgotamento da cota.

Os endpoints são escalonados verticalmente por máquina, mas a cota é calculada por CPU ou GPU. Por exemplo, se o modelo for implantado no tipo de máquina a2-highgpu-2g, cada réplica ativa contará como 24 CPUs e 2 GPUs na cota do projeto. Para mais informações, consulte Cota e limites.

Os nós de previsão para previsão em lote não são escalonados automaticamente. A Vertex AI usa BatchDedicatedResources.startingReplicaCount e ignora BatchDedicatedResources.maxReplicaCount.

Utilização e configuração de valor desejado

Por padrão, se você implantar um modelo sem recursos de GPU dedicados, a Vertex AI fará o escalonamento vertical ou horizontal automático do número de réplicas para que o uso da CPU corresponda ao valor desejado padrão de 60%.

Por padrão, se você implantar um modelo com recursos de GPU dedicados (se machineSpec.accelerator_count for maior que 0), a Vertex AI vai escalonar automaticamente o número de réplicas para que o uso da CPU ou GPU, o que for maior, corresponda ao valor desejado padrão de 60%. Portanto, se a capacidade de processamento estiver causando alto uso da GPU, mas não alto uso da CPU, a Vertex AI será escalonada verticalmente, e a utilização da CPU será muito baixa, o que vai ficar visível no monitoramento. Por outro lado, se o contêiner personalizado estiver subutilizando a GPU, mas tiver um processo não relacionado que aumente a utilização da CPU para mais de 60%, a Vertex AI vai ser escalonada verticalmente, mesmo que isso não seja necessário para atingir as metas de QPS e latência.

É possível substituir o valor desejado e a métrica de limite padrão especificando autoscalingMetricSpecs. Se a implantação for configurada para escalonar com base apenas no uso da CPU, ela não será escalonada verticalmente mesmo que o uso da GPU seja alto.

Gerenciar o uso de recursos

É possível monitorar seu endpoint para rastrear métricas como o uso da CPU e do acelerador, o número de solicitações, a latência e o número atual e pretendido de réplicas. Essas informações podem ajudar você a entender o uso de recursos e o comportamento de escalonamento do endpoint.

Lembre-se de que cada réplica executa apenas um contêiner. Isso significa que, se um contêiner de previsão não puder usar totalmente o recurso de computação selecionado, como um código de linha de execução única para uma máquina com vários núcleos ou um modelo personalizado que chame outro serviço como parte da previsão, talvez seus nós não sejam escalonados verticalmente.

Por exemplo, se você estiver usando o FastAPI ou qualquer servidor de modelo com um número configurável de workers ou linhas de execução, poderá haver muitos casos em que ter um só worker aumentará a utilização de recursos, o melhorando a capacidade do serviço de escalonar automaticamente o número de réplicas.

Geralmente, recomendamos começar com um só worker ou linha de execução por núcleo. Se você perceber que a utilização da CPU está baixa, especialmente sob carga alta, ou se o modelo não estiver escalonando verticalmente porque a utilização da CPU está baixa, aumente o número de workers. Por outro lado, se você perceber que a utilização está muito alta e suas latências aumentam mais do que o esperado sob carga, tente usar menos workers. Se você já estiver usando apenas um worker, tente usar um tipo de máquina menor.

Comportamento de escalonamento e atraso

A Vertex AI ajusta o número de réplicas a cada 15 segundos usando dados da janela anterior de 5 minutos. Para cada ciclo de 15 segundos, o sistema mede a utilização do servidor e gera um número pretendido de réplicas com base na seguinte fórmula:

target # of replicas = Ceil(current # of replicas * (current utilization / target utilization))

Por exemplo, se você tem duas réplicas que estão sendo usadas em 100%, o valor desejado é 4:

4 = Ceil(3.33) = Ceil(2 * (100% / 60%))

Outro exemplo: se você tiver 10 réplicas e a utilização cair para 1%, o valor desejado é 1:

1 = Ceil(.167) = Ceil(10 * (1% / 60%))

No final de cada ciclo de 15 segundos, o sistema ajusta o número de réplicas para corresponder ao maior valor desejado da janela de cinco minutos anterior. Como o maior valor desejado é escolhido, seu endpoint não vai reduzir a escala vertical se houver um pico de utilização durante essa janela de cinco minutos, mesmo que a utilização geral seja muito baixa. Por outro lado, se o sistema precisar ser escalonado verticalmente, ele fará isso em até 15 segundos, já que o valor de destino mais alto é escolhido em vez da média.

Lembre-se de que, mesmo depois que a Vertex AI ajusta o número de réplicas, leva tempo para iniciar ou desativar as réplicas. Portanto, haverá um atraso maior até o endpoint se ajustar ao tráfego. Os principais fatores que contribuem para esse tempo incluem:

  • O tempo para provisionar e iniciar as VMs do Compute Engine
  • O tempo para fazer o download do contêiner do registro
  • O tempo para carregar o modelo do armazenamento

A melhor maneira de entender o comportamento de escalonamento real do seu modelo é executar um teste de carga e otimizar as características importantes para o modelo e o caso de uso. Se o escalonador automático não estiver sendo rápido o suficiente para escalonar verticalmente o aplicativo, provisione min_replicas suficientes para lidar com o tráfego de referência esperado.

Atualizar a configuração de escalonamento

Se você tiver especificado DedicatedResources ou AutomaticResources ao implantar o modelo, poderá atualizar a configuração de escalonamento sem reimplantar o modelo chamando mutateDeployedModel.

Por exemplo, a solicitação a seguir atualiza max_replica, autoscaling_metric_specs e desativa o registro de contêiner.

{
  "deployedModel": {
    "id": "2464520679043629056",
    "dedicatedResources": {
      "maxReplicaCount": 9,
      "autoscalingMetricSpecs": [
        {
          "metricName": "aiplatform.googleapis.com/prediction/online/cpu/utilization",
          "target": 50
        }
      ]
    },
    "disableContainerLogging": true
  },
  "update_mask": {
    "paths": [
      "dedicated_resources.max_replica_count",
      "dedicated_resources.autoscaling_metric_specs",
      "disable_container_logging"
    ]
  }
}

Observações sobre o uso:

  • Não é possível mudar o tipo de máquina ou alternar de DedicatedResources para AutomaticResources ou vice-versa. Os únicos campos de configuração de escalonamento que podem ser alterados são: min_replica, max_replica, required_replica e AutoscalingMetricSpec (somente DedicatedResources).
  • É necessário listar todos os campos que você precisa atualizar em updateMask. Os campos não listados são ignorados.
  • O DeployedModel precisa estar no estado DEPLOYED. Pode haver no máximo uma operação mutate ativa por modelo implantado.
  • O mutateDeployedModel também permite ativar ou desativar a geração de registros de contêineres. Para mais informações, consulte Geração de registros de previsão on-line.

A seguir