Ottimizza e scala il runtime di Vertex AI Agent Engine

Questa pagina descrive le best practice su come ottimizzare e scalare le prestazioni per Vertex AI Agent Engine Runtime, coprendo i seguenti scenari:

Gli scenari mostrano come utilizzare i parametri di deployment per risolvere i colli di bottiglia comuni delle prestazioni, in particolare per i pattern di traffico imprevedibili e a picchi nelle applicazioni reali.

Problema di avvio a freddo

Un avvio a freddo si verifica quando arriva una richiesta e non ci sono istanze o container inattivi per gestirla, il che costringe Vertex AI Agent Engine ad avviarne uno nuovo. In questo modo, la richiesta subisce un aumento significativo della latenza.

Ad esempio, l'invio di 300 richieste simultanee a un agente con il valore predefinito di min_instances=1 può mostrare i seguenti risultati:

  • Avvio a freddo (prima esecuzione): latenza media di circa 4,7 secondi.

  • Avvio tiepido (seconda esecuzione immediata): latenza media di circa 0,4 secondi.

L'overhead di oltre quattro secondi è dovuto quasi interamente all'avvio di nuove istanze per gestire il carico.

Prova i seguenti metodi per mitigare il problema dell'avvio a freddo:

  • Imposta un valore min_instances sufficientemente alto da gestire il traffico di base. Ad esempio, impostando min_instances=10 sull'agente di esempio è possibile ridurre la latenza media per un avvio a freddo a circa 1,4 secondi. Per le applicazioni con traffico elevato o a picchi, imposta min_instances su un valore in grado di gestire il carico tipico senza dover scalare da 1. Il valore massimo è 10.

  • Invia un carico stabile, continuo e prevedibile al runtime di Vertex AI Agent Engine utilizzando una coda. Ad esempio, l'esecuzione di un test di carico sostenuto di 1500 query al minuto (25 query al secondo) per 60 secondi su un agente basato su Agent Development Kit (ADK) con min_instances=10 e concurrency (9) predefinito può produrre il seguente risultato:

    • La latenza media è costantemente bassa, pari a circa 1,6 secondi.

Un carico stabile e continuo mantiene il servizio attivo e garantisce prestazioni ottimali.

Worker asincroni sottoutilizzati

Per impostazione predefinita, container_concurrency è configurato per il codice sincrono, in cui ogni istanza di Agent Engine gestisce una sola richiesta alla volta. Gli agenti asincroni, come quelli basati sull'Agent Development Kit (ADK), possono gestire più richieste con I/O vincolato (come chiamate LLM o di strumenti) contemporaneamente.

Ad esempio, l'invio di 300 richieste simultanee a un agente basato su ADK con min_instances=10 e container_concurrency=9 predefinito può produrre il seguente risultato:

  • Sebbene la latenza mediana sia di circa 4 secondi, i picchi di latenza massima raggiungono i 60 secondi. Ciò indica che le richieste sono in coda mentre il servizio esegue lentamente lo scale out.

Per ridurre il numero di worker asincroni sottoutilizzati, aumenta container_concurrency per consentire a ogni istanza di Agent Engine di gestire più richieste. Il numero di richieste simultanee che ogni processo agente può gestire è container_concurrency / 9. Il valore 9 rappresenta il numero di processi dell'agente in esecuzione in parallelo all'interno di ogni container.

Ad esempio, l'invio di 300 richieste simultanee allo stesso agente basato sull'ADK con min_instances=10 e container_concurrency=36 può produrre il seguente risultato:

  • La latenza massima scende da 60 secondi a circa 7 secondi. Ciò dimostra che le istanze esistenti possono assorbire il picco di traffico in modo più efficace.

Per gli agenti asincroni (come quelli basati sull'ADK), imposta container_concurrency su un multiplo di 9 (ad esempio, 36) come punto di partenza. Ciò migliora la reattività ai picchi di traffico e riduce la latenza dovuta allo scale out.

Tieni presente che l'impostazione di un valore container_concurrency troppo elevato può comportare il rischio di errori di esaurimento della memoria (OOM).

Passaggi successivi