Otimize e dimensione o tempo de execução do Vertex AI Agent Engine

Esta página descreve as práticas recomendadas sobre como otimizar e dimensionar o desempenho do tempo de execução do motor de agentes da Vertex AI, abrangendo os seguintes cenários:

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

Problema de início a frio

Um início a frio ocorre quando chega um pedido e não existem instâncias nem contentores inativos para o processar, o que força o Vertex AI Agent Engine a iniciar um novo. Isto adiciona uma latência significativa ao pedido.

Por exemplo, o envio de 300 pedidos simultâneos a um agente com o valor min_instances=1 predefinido pode mostrar os seguintes resultados:

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

  • Início a quente (execução imediata): latência média de aproximadamente 0,4 segundos.

A sobrecarga de mais de quatro segundos deve-se quase inteiramente ao início de novas instâncias para processar a carga.

Experimente os seguintes métodos para mitigar o problema de arranque a frio:

  • Defina um valor min_instances suficientemente elevado para processar o seu tráfego de base. Por exemplo, definir min_instances=10 para o agente de exemplo pode reduzir a latência média de um início a frio para aproximadamente 1,4 segundos. Para aplicações com picos ou tráfego elevado, defina min_instances para um valor que possa processar a sua carga típica sem ter de ser dimensionado a partir de 1. O valor máximo é 10.

  • Envie uma carga estável, contínua e previsível para o tempo de execução do Vertex AI Agent Engine através de uma fila. Por exemplo, executar um teste de carga sustentado de 1500 consultas por minuto (25 consultas por segundo) durante 60 segundos num agente baseado no Agent Development Kit (ADK) com min_instances=10 e o valor predefinido concurrency (9) pode produzir 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 ativo e resulta num desempenho ideal.

Trabalhadores assíncronos subutilizados

Por predefinição, o container_concurrency está configurado para código síncrono, em que cada instância do motor do agente processa apenas um pedido de cada vez. Os agentes assíncronos, como os baseados no Agent Development Kit (ADK), podem processar vários pedidos associados a E/S (como chamadas de ferramentas ou LLMs) em simultâneo.

Por exemplo, o envio de 300 pedidos simultâneos a um agente baseado no ADK com min_instances=10 e o container_concurrency=9 predefinido pode produzir o seguinte resultado:

  • Embora a latência mediana seja de aproximadamente 4 segundos, a latência máxima aumenta para 60 segundos. Isto indica que os pedidos estão muito em fila de espera enquanto o serviço é expandido lentamente.

Para mitigar os trabalhadores assíncronos subutilizados, aumente container_concurrency para permitir que cada instância do Agent Engine processe vários pedidos. O número de pedidos simultâneos que cada processo de agente pode processar é container_concurrency / 9. O valor 9 representa o número de processos de agentes em execução em paralelo em cada contentor.

Por exemplo, o envio de 300 pedidos simultâneos 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 diminui de 60 segundos para aproximadamente 7 segundos. Isto mostra que as instâncias existentes podem absorver o pico de tráfego de forma mais eficaz.

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

Tenha em atenção que definir o valor container_concurrency demasiado elevado pode originar erros de falta de memória (OOM).

O que se segue?