Optimiser et mettre à l'échelle l'environnement d'exécution Vertex AI Agent Engine

Cette page décrit les bonnes pratiques pour optimiser et adapter les performances du runtime Vertex AI Agent Engine. Elle aborde les scénarios suivants :

Les scénarios montrent comment utiliser les paramètres de déploiement pour résoudre les goulots d'étranglement courants en termes de performances, en particulier pour les schémas de trafic imprévisibles et irréguliers dans les applications réelles.

Problème de démarrage à froid

Un démarrage à froid se produit lorsqu'une requête arrive et qu'il n'y a pas d'instances ni de conteneurs inactifs pour la traiter, ce qui oblige Vertex AI Agent Engine à en démarrer un nouveau. Cela ajoute une latence importante à la requête.

Par exemple, l'envoi de 300 requêtes simultanées à un agent avec la valeur min_instances=1 par défaut peut donner les résultats suivants :

  • Démarrage à froid (première exécution) : latence moyenne d'environ 4,7 secondes.

  • Démarrage à chaud (deuxième exécution immédiate) : latence moyenne d'environ 0,4 seconde.

Le délai supplémentaire de plus de quatre secondes est presque entièrement dû au démarrage de nouvelles instances pour gérer la charge.

Essayez les méthodes suivantes pour atténuer le problème de démarrage à froid :

  • Définissez une valeur min_instances suffisamment élevée pour gérer votre trafic de référence. Par exemple, définir min_instances=10 sur l'agent exemple peut réduire la latence moyenne d'un démarrage à froid à environ 1,4 seconde. Pour les applications dont le trafic est élevé ou irrégulier, définissez min_instances sur une valeur capable de gérer votre charge typique sans avoir besoin de passer de 1 à une autre valeur. La valeur maximale est de 10.

  • Envoyez une charge stable, continue et prévisible à l'environnement d'exécution Vertex AI Agent Engine à l'aide d'une file d'attente. Par exemple, l'exécution d'un test de charge soutenu de 1 500 requêtes par minute (25 requêtes par seconde) pendant 60 secondes sur un agent basé sur l'Agent Development Kit (ADK) avec min_instances=10 et la valeur par défaut concurrency (9) peut donner le résultat suivant :

    • La latence moyenne est constamment faible, à environ 1,6 seconde.

Une charge stable et continue permet de maintenir le service au chaud et d'obtenir des performances optimales.

Nœuds de calcul asynchrones sous-utilisés

Par défaut, container_concurrency est configuré pour le code synchrone, où chaque instance Agent Engine ne traite qu'une seule requête à la fois. Les agents asynchrones, tels que ceux basés sur l'Agent Development Kit (ADK), peuvent traiter plusieurs requêtes liées aux E/S (comme les appels de LLM ou d'outils) simultanément.

Par exemple, l'envoi de 300 requêtes simultanées à un agent basé sur l'ADK avec min_instances=10 et container_concurrency=9 par défaut peut donner le résultat suivant :

  • Alors que la latence médiane est d'environ quatre secondes, la latence maximale atteint 60 secondes. Cela indique que les requêtes sont fortement mises en file d'attente pendant que le service évolue lentement.

Pour atténuer le problème des nœuds de calcul asynchrones sous-utilisés, augmentez container_concurrency afin de permettre à chaque instance Agent Engine de gérer plusieurs requêtes. Le nombre de requêtes simultanées que chaque agent peut traiter est de container_concurrency / 9. La valeur 9 représente le nombre de processus d'agent exécutés en parallèle dans chaque conteneur.

Par exemple, l'envoi de 300 requêtes simultanées au même agent basé sur le kit ADK avec min_instances=10 et container_concurrency=36 peut donner le résultat suivant :

  • La latence maximale passe de 60 secondes à environ 7 secondes. Cela montre que les instances existantes peuvent absorber le pic de trafic plus efficacement.

Pour les agents asynchrones (tels que les agents basés sur ADK), définissez container_concurrency sur un multiple de 9 (par exemple, 36) comme point de départ. Cela améliore la réactivité aux pics de trafic et réduit la latence du scaling horizontal.

Notez que si vous définissez une valeur container_concurrency trop élevée, vous risquez de rencontrer des erreurs de mémoire insuffisante (OOM).

Étapes suivantes