Otimizar e escalonar o ambiente de execução do Agent Engine da Vertex AI

Esta página descreve as práticas recomendadas sobre como otimizar e escalonar o desempenho do ambiente de execução do Vertex AI Agent Engine, abrangendo os seguintes cenários:

Os cenários mostram como usar parâmetros de implantação para resolver gargalos comuns de performance , especialmente para padrões de tráfego imprevisíveis e irregulares em aplicativos reais.

Problema de inicialização a frio

Uma inicialização a frio ocorre quando uma solicitação chega e não há instâncias ou contêineres ociosos para atendê-la, forçando o Vertex AI Agent Engine a iniciar um novo. Isso adiciona uma latência significativa à solicitação.

Por exemplo, o envio de 300 solicitações simultâneas a um agente com o valor padrão min_instances=1 pode mostrar os seguintes resultados:

  • Inicialização a frio (primeira execução): latência média de aproximadamente 4,7 segundos.

  • Inicialização com estado salvo (segunda execução imediata): latência média de aproximadamente 0,4 segundos.

A sobrecarga de mais de quatro segundos é quase inteiramente devido a novas instâncias que estão sendo iniciadas para lidar com a carga.

Tente os seguintes métodos para atenuar o problema de inicialização a frio:

  • Defina um valor min_instances que seja alto o suficiente para lidar com o tráfego de linha de base. Por exemplo, definir min_instances=10 para o agente de exemplo pode reduzir a latência média de uma inicialização a frio para aproximadamente 1,4 segundos. Para aplicativos com tráfego irregular ou alto, defina min_instances como um valor que possa lidar com a carga típica sem precisar ser escalonado de 1. O valor máximo é 75.

  • Envie uma carga estável, contínua e previsível para o Vertex AI Agent Engine Runtime usando uma fila. Por exemplo, executar um teste de carga sustentado de 1.500 consultas por minuto (25 consultas por segundo) durante 60 segundos em um agente baseado no Kit de desenvolvimento de agentes (ADK,na sigla em inglês) com min_instances=10 e concurrency padrão (9) pode gerar o seguinte resultado:

    • A latência média é consistentemente baixa, de aproximadamente 1,6 segundos.

Uma carga estável e contínua mantém o serviço aquecido e resulta em performance ideal.

Workers assíncronos subutilizados

Por padrão, container_concurrency é configurado para código síncrono, em que cada instância do Agent Engine processa apenas uma solicitação por vez. Agentes assíncronos, como aqueles baseados no Kit de desenvolvimento de agentes (ADK), podem processar várias solicitações vinculadas a E/S (como chamadas de LLM ou de ferramentas) simultaneamente.

Por exemplo, o envio de 300 solicitações simultâneas a um agente baseado no ADK com min_instances=10 e container_concurrency=9 padrão pode gerar o seguinte resultado:

  • Embora a latência mediana seja de aproximadamente 4 segundos, a latência máxima aumenta para 60 segundos. Isso indica que as solicitações são enfileiradas enquanto o serviço é escalonado lentamente.

Para atenuar os workers assíncronos subutilizados, aumente container_concurrency para permitir que cada instância do Agent Engine processe várias solicitações. O número de solicitações simultâneas que cada processo do agente pode processar é container_concurrency / 9. O valor 9 representa o número de processos do agente em execução paralela em cada contêiner.

Por exemplo, o envio de 300 solicitações simultâneas ao mesmo agente baseado no ADK com min_instances=10 e container_concurrency=36 pode gerar o seguinte resultado:

  • A latência máxima cai de 60 segundos para aproximadamente 7 segundos. Isso mostra que as instâncias atuais podem absorver o pico de tráfego com mais eficiência.

Para agentes assíncronos (como agentes baseados no ADK), defina container_concurrency como um múltiplo de 9 (por exemplo, 36) como ponto de partida. Isso melhora a capacidade de resposta a picos de tráfego e reduz a latência do escalonamento.

Definir o valor container_concurrency muito alto pode causar erros de falta de memória (OOM).

A seguir