Otimizar e escalonar a performance do Agent Runtime

O Agent Runtime fornece parâmetros de implantação que permitem otimizar e escalonar o desempenho dos seus agentes. Ao configurar esses parâmetros, é possível lidar com padrões de tráfego imprevisíveis ou com picos de forma eficaz.

Nesta página, descrevemos as práticas recomendadas para otimizar e escalonar o desempenho do Agent Runtime, abrangendo os seguintes cenários:

• Problema de inicialização a frio
• Workers assíncronos subutilizados

Os cenários mostram como usar parâmetros de implantação para resolver gargalos de desempenho comuns, especialmente para padrões de tráfego imprevisíveis e com picos 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 Agent Runtime a iniciar uma nova instância. Isso adiciona uma latência significativa à solicitação.

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

A sobrecarga de mais de quatro segundos é quase inteiramente devido à inicialização de novas instâncias para lidar com a carga.

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

• Defina um valor de min_instances que seja 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 com picos, defina min_instances como um valor que possa lidar com a carga típica sem precisar escalonar a partir de 1. Para ver o intervalo de valores aceitos, consulte a referência de recursos REST ReasoningEngineSpec.

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

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

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

Workers assíncronos subutilizados

Por padrão, o container_concurrency é configurado para código síncrono, em que cada instância da Agent Platform processa apenas uma solicitação por vez. Os 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 para um agente baseado em ADK com min_instances=10 e o container_concurrency=9 padrão pode gerar o seguinte resultado:

• Enquanto a latência mediana é de aproximadamente 4 segundos, a latência máxima chega a 60 segundos. Isso indica que as solicitações estão em uma fila longa enquanto o serviço é escalonado horizontalmente de forma lenta.

Para reduzir os workers assíncronos subutilizados, aumente container_concurrency para permitir que cada instância da Agent Platform 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 em 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 de forma mais eficaz.

Para agentes assíncronos (como agentes baseados em 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 o valor de container_concurrency como muito alto pode causar erros de falta de memória (OOM).

A seguir