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

Esta página descreve as práticas recomendadas para otimizar e escalonar a performance do tempo de execução do mecanismo de agente da Vertex AI, abordando os seguintes cenários:

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

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, enviar 300 solicitações simultâneas a um agente com o min_instances=1 padrão 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 segundo.

O excesso 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 de min_instances alto o suficiente para lidar com o tráfego de referência. Por exemplo, definir min_instances=10 como o agente de exemplo pode reduzir a latência média de uma inicialização a frio para aproximadamente 1,4 segundo. Para aplicativos com tráfego alto ou instável, defina min_instances como um valor que possa processar sua carga típica sem precisar ser escalonado a partir de 1. O valor máximo é 10.

  • Envie uma carga estável, contínua e previsível para o ambiente de execução do Vertex AI Agent Engine usando uma fila. Por exemplo, executar um teste de carga sustentada de 1.500 consultas por minuto (25 consultas por segundo) durante 60 segundos em um agente baseado no Agent Development Kit (ADK) com min_instances=10 e o concurrency padrão (9) pode gerar o seguinte resultado:

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

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

Workers assíncronos subutilizados

Por padrão, 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 os baseados no Kit de Desenvolvimento de Agente (ADK), podem processar várias solicitações vinculadas a E/S (como chamadas de LLM ou de ferramentas) simultaneamente.

Por exemplo, enviar 300 solicitações simultâneas a um agente baseado no ADK com min_instances=10 e o 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 ficam em fila enquanto o serviço é escalonado lentamente.

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

Por exemplo, enviar 300 solicitações simultâneas para o 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 os 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 horizontal.

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

A seguir