Implemente um modelo num ponto final

Antes de poder obter inferências online a partir de um modelo preparado, tem de implementar o modelo num ponto final. Isto pode ser feito através da Google Cloud consola, da Google Cloud CLI ou da API Vertex AI.

Este documento descreve o processo de implementação de modelos em pontos finais.

O que acontece quando implementa um modelo

A implementação de um modelo associa recursos físicos ao modelo para que possa publicar inferências online com baixa latência.

Pode implementar vários modelos num ponto final ou implementar o mesmo modelo em vários pontos finais. Para mais informações, consulte o artigo Motivos para implementar mais do que um modelo no mesmo ponto final.

Prepare-se para implementar um modelo num ponto final

Durante a implementação do modelo, toma as seguintes decisões importantes sobre como executar a inferência online:

Recurso criado Definição especificada na criação do recurso
Ponto final Localização na qual executar inferências
Modelo Contentor a usar (ModelContainerSpec)
DeployedModel Recursos de computação a usar para a inferência online

Após a implementação do modelo no ponto final, não é possível alterar estas definições de implementação. Para as alterar, tem de voltar a implementar o modelo.

O primeiro passo no processo de implementação é decidir que tipo de ponto final usar. Para mais informações, consulte o artigo Escolha um tipo de ponto final.

Em seguida, certifique-se de que o modelo está visível no Registo de modelos do Vertex AI. Isto é necessário para que o modelo seja implementável. Para obter informações sobre o Registo de modelos, incluindo como importar artefactos de modelos ou criá-los diretamente no Registo de modelos, consulte o artigo Introdução ao Registo de modelos do Vertex AI.

A próxima decisão a tomar é que recursos de computação usar para publicar o modelo. O tipo de preparação do modelo (AutoML ou personalizado) e o tipo de dados (AutoML) determinam os tipos de recursos físicos disponíveis para o modelo. Após a implementação do modelo, pode mutate alguns desses recursos sem criar uma nova implementação.

O recurso de ponto final fornece o ponto final de serviço (URL) que usa para pedir a inferência. Por exemplo:

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

Implemente um modelo num ponto final

Pode implementar um modelo num ponto final através da Google Cloud consola ou através da CLI gcloud ou da API Vertex AI.

Implemente um modelo num ponto final público através da Google Cloud consola

Na Google Cloud consola, pode implementar um modelo num ponto final público dedicado ou partilhado existente, ou pode criar um novo ponto final durante o processo de implementação. Para ver detalhes, consulte o artigo Implemente um modelo através da Google Cloud consola.

Implemente um modelo num ponto final público através da CLI gcloud ou da API Vertex AI

Quando implementa um modelo através da CLI gcloud ou da API Vertex AI, tem de criar primeiro um ponto final dedicado ou partilhado e, em seguida, implementar o modelo no mesmo. Para obter mais detalhes, consulte as secções:

  1. Crie um ponto final público dedicado ou partilhado
  2. Implemente um modelo através da CLI gcloud ou da API Vertex AI

Implemente um modelo num ponto final do Private Service Connect

Para ver detalhes, consulte o artigo Use pontos finais do Private Service Connect para inferência online.

Use uma implementação progressiva para atualizar um modelo implementado

Pode usar uma implementação contínua para substituir um modelo implementado por uma nova versão do mesmo modelo. O novo modelo reutiliza os recursos de computação do modelo anterior. Para ver detalhes, consulte o artigo Use uma implementação contínua para substituir um modelo implementado.

Anule a implementação de um modelo e elimine o ponto final

Pode anular a implementação de um modelo e eliminar o ponto final. Para ver detalhes, consulte o artigo Anule a implementação de um modelo e elimine o ponto final.

Motivos para implementar mais do que um modelo no mesmo ponto final

A implementação de dois modelos no mesmo ponto final permite-lhe substituir gradualmente um modelo pelo outro. Por exemplo, suponha que está a usar um modelo e encontra uma forma de aumentar a precisão desse modelo com novos dados de preparação. No entanto, não quer atualizar a sua aplicação para apontar para um novo URL do ponto final e não quer criar alterações súbitas na sua aplicação. Pode adicionar o novo modelo ao mesmo ponto final, publicando uma pequena percentagem do tráfego e aumentando gradualmente a divisão do tráfego para o novo modelo até estar a publicar 100% do tráfego.

Uma vez que os recursos estão associados ao modelo e não ao ponto final, pode implementar modelos de diferentes tipos no mesmo ponto final. No entanto, a prática recomendada é implementar modelos de um tipo específico (por exemplo, AutoML tabular ou com formação personalizada) num ponto final. Esta configuração é mais fácil de gerir.

Motivos para implementar um modelo em mais do que um ponto final

Pode querer implementar os seus modelos com recursos diferentes para diferentes ambientes de aplicação, como testes e produção. Também pode querer suportar diferentes SLOs para os seus pedidos de inferência. Talvez uma das suas aplicações tenha necessidades de desempenho muito superiores às das outras. Neste caso, pode implementar esse modelo num ponto final de maior desempenho com mais recursos de aprendizagem automática. Para otimizar os custos, também pode implementar o modelo num ponto final de desempenho inferior com menos recursos de aprendizagem automática.

Comportamento de dimensionamento

Quando implementa um modelo para inferência online como um DeployedModel, pode configurar os nós de inferência para serem dimensionados automaticamente. Para tal, defina dedicatedResources.maxReplicaCount para um valor superior a dedicatedResources.minReplicaCount.

Quando configura um DeployedModel, tem de definir dedicatedResources.minReplicaCount como, pelo menos, 1. Por outras palavras, não pode configurar o DeployedModel para ser dimensionado para 0 nós de inferência quando não está a ser usado.

Por predefinição, a operação de implementação só é considerada bem-sucedida se o número de nós de inferência atingir dedicatedResources.minReplicaCount antes do valor de tempo limite do pedido de implementação. Caso contrário, a implementação é marcada como falhada e os recursos subjacentes são libertados.

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

Pode modificar o comportamento de implementação predefinido definindo dedicatedResources.requiredReplicaCount para um valor inferior a dedicatedResources.minReplicaCount. Neste caso, quando o número de nós de inferência atinge dedicatedResources.requiredReplicaCount, a operação de implementação é marcada como bem-sucedida, embora ainda não esteja concluída. A implementação continua até atingir dedicatedResources.minReplicaCount. Se dedicatedResources.minReplicaCount não for alcançado antes da hora do pedido de implementação, a operação continua a ser bem-sucedida, mas é devolvida uma mensagem de erro para as réplicas com falhas em DeployedModel.status.message.

A quota para a publicação de modelos personalizados é calculada com base na utilização em tempo real do modelo implementado de recursos de computação. Se a soma de maxReplicaCount para todas as implementações no seu projeto for superior à quota do projeto, algumas implementações podem não ser dimensionadas automaticamente devido ao esgotamento da quota.

Os pontos finais são dimensionados para cima e para baixo por máquina, mas a quota é calculada por CPU ou GPU. Por exemplo, se o seu modelo for implementado no tipo de máquina, cada réplica ativa conta como 24 CPUs e 2 GPUs em relação à quota do seu projeto.a2-highgpu-2g Para mais informações, consulte o artigo Quota e limites.

Os nós de inferência para inferência em lote não são dimensionados automaticamente. O Vertex AI usa BatchDedicatedResources.startingReplicaCount e ignora BatchDedicatedResources.maxReplicaCount.

Utilização e configuração do alvo

Por predefinição, se implementar um modelo sem recursos de GPU dedicados, o Vertex AI dimensiona automaticamente o número de réplicas para cima ou para baixo, de modo que a utilização da CPU corresponda ao valor alvo predefinido de 60%.

Por predefinição, se implementar um modelo com recursos de GPU dedicados (se machineSpec.accelerator_count for superior a 0), o Vertex AI dimensiona automaticamente o número de réplicas para cima ou para baixo, de modo que a utilização da CPU ou da GPU, consoante o que for mais elevado, corresponda ao valor alvo predefinido de 60%. Por conseguinte, se a taxa de transferência de inferência estiver a causar uma utilização elevada da GPU, mas não uma utilização elevada da CPU, o Vertex AI é dimensionado verticalmente, e a utilização da CPU é muito baixa, o que é visível na monitorização. Por outro lado, se o seu contentor personalizado estiver a usar a GPU de forma insuficiente, mas tiver um processo não relacionado que aumente a utilização da CPU para mais de 60%, o Vertex AI é dimensionado, mesmo que isso não seja necessário para atingir os objetivos de QPS e latência.

Pode substituir a métrica e o objetivo do limite predefinidos especificando autoscalingMetricSpecs. Tenha em atenção que, se a sua implementação estiver configurada para ser dimensionada apenas com base na utilização da CPU, não vai ser dimensionada, mesmo que a utilização da GPU seja elevada.

Faça a gestão da utilização de recursos

Pode monitorizar o seu ponto final para acompanhar métricas como a utilização da CPU e do acelerador, o número de pedidos, a latência e o número atual e de destino de réplicas. Estas informações podem ajudar a compreender a utilização de recursos e o comportamento de escalabilidade do seu ponto final.

Tenha em atenção que cada réplica executa apenas um único contentor. Isto significa que, se um contentor de inferência não conseguir usar totalmente o recurso de computação selecionado, como código de thread único para uma máquina com vários núcleos ou um modelo personalizado que chama outro serviço como parte da inferência, os seus nós podem não ser dimensionados.

Por exemplo, se estiver a usar o FastAPI ou qualquer servidor de modelos que tenha um número configurável de trabalhadores ou threads, existem muitos casos em que ter mais do que um trabalhador pode aumentar a utilização de recursos, o que melhora a capacidade de o serviço dimensionar automaticamente o número de réplicas.

Geralmente, recomendamos que comece com um trabalhador ou um segmento por núcleo. Se notar que a utilização da CPU é baixa, especialmente sob carga elevada, ou que o seu modelo não está a ser dimensionado porque a utilização da CPU é baixa, aumente o número de trabalhadores. Por outro lado, se notar que a utilização é demasiado elevada e as latências aumentam mais do que o esperado sob carga, experimente usar menos trabalhadores. Se já estiver a usar apenas um único trabalhador, experimente usar um tipo de máquina mais pequeno.

Comportamento de dimensionamento e atraso

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

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

Por exemplo, se tiver 2 réplicas a serem usadas a 100%, o alvo é 4:

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

Outro exemplo: se tiver 10 réplicas e a utilização descer para 1%, o alvo é 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 valor alvo mais elevado da janela de 5 minutos anterior. Tenha em atenção que, uma vez que é escolhido o valor alvo mais elevado, o seu ponto final não é reduzido se houver um pico de utilização durante esse período de 5 minutos, mesmo que a utilização geral seja muito baixa. Por outro lado, se o sistema precisar de ser dimensionado, fá-lo-á no prazo de 15 segundos, uma vez que é escolhido o valor alvo mais elevado em vez da média.

Tenha em atenção que, mesmo depois de o Vertex AI ajustar o número de réplicas, é necessário tempo para iniciar ou desativar as réplicas. Assim, existe um atraso adicional antes de o ponto final se poder ajustar ao tráfego. Os principais fatores que contribuem para este tempo incluem o seguinte:

  • O tempo para aprovisionar e iniciar as VMs do Compute Engine
  • O tempo para transferir o contentor do registo
  • O tempo para carregar o modelo a partir do armazenamento

A melhor forma de compreender o comportamento de escalabilidade do seu modelo no mundo real é executar um teste de carga e otimizar as caraterísticas importantes para o seu modelo e o seu exemplo de utilização. Se o dimensionamento automático não estiver a aumentar a escala com rapidez suficiente para a sua aplicação, aprovisione min_replicas suficientes para processar o tráfego de base esperado.

Atualize a configuração do escalonamento

Se especificou DedicatedResources ou AutomaticResources quando implementou o modelo, pode atualizar a configuração de escalabilidade sem reimplementar o modelo chamando mutateDeployedModel.

Por exemplo, o seguinte pedido atualiza max_replica, autoscaling_metric_specs e desativa o registo do contentor.

{
  "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"
    ]
  }
}

Notas de utilização:

  • Não pode alterar o tipo de máquina nem mudar de DedicatedResources para AutomaticResources ou vice-versa. Os únicos campos de configuração de escalabilidade que pode alterar são: min_replica, max_replica, required_replica e AutoscalingMetricSpec (apenas DedicatedResources).
  • Tem de indicar todos os campos que precisa de atualizar em updateMask. Os campos não indicados são ignorados.
  • O DeployedModel tem de estar no estado DEPLOYED. Pode haver, no máximo, uma operação mutate ativa por modelo implementado.
  • mutateDeployedModel também lhe permite ativar ou desativar o registo do contentor. Para mais informações, consulte o artigo Registo de inferências online.

O que se segue?