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 de l'environnement d'exécution de Vertex AI Agent Engine, en couvrant 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 modèles 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'aucune instance ni aucun conteneur inactif n'est disponible 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 par défaut min_instances=1 peut afficher 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.

La surcharge de plus de quatre secondes est presque entièrement due 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 pour l'agent d'exemple peut réduire la latence moyenne d'un démarrage à froid à environ 1,4 seconde. Pour les applications avec un trafic irrégulier ou élevé, définissez min_instances sur une valeur qui peut gérer votre charge typique sans avoir à effectuer un scaling à partir de 1. La valeur maximale est 75.

  • Envoyez une charge stable, continue et prévisible à l'environnement d'exécution de 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 le kit de développement d'agent (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 maintient le service chaud et permet 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 d'Agent Engine ne gère qu'une seule requête à la fois. Les agents asynchrones, tels que ceux basés sur le kit de développement d'agent (ADK), peuvent gérer plusieurs requêtes liées aux E/S (comme les appels 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 la valeur par défaut container_concurrency=9 peut donner le résultat suivant :

  • Bien que la latence médiane soit d'environ 4 secondes, la latence maximale atteint 60 secondes. Cela indique que les requêtes sont fortement mises en file d'attente pendant que le service effectue un scaling lent.

Pour atténuer le problème des nœuds de calcul asynchrones sous-utilisés, augmentez container_concurrency afin de permettre à chaque instance d'Agent Engine de gérer plusieurs requêtes. Le nombre de requêtes simultanées que chaque processus d'agent peut gérer est 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 l'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 plus efficacement le pic de trafic.

Pour les agents asynchrones (tels que les agents basés sur l'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.

Notez que si vous définissez une valeur container_concurrency trop élevée, vous risquez de générer des erreurs de mémoire insuffisante.

Étape suivante