Optimiser et faire évoluer les performances d'Agent Runtime

L'environnement d'exécution de l'agent fournit des paramètres de déploiement qui vous permettent d'optimiser et de faire évoluer les performances de vos agents. En configurant ces paramètres, vous pouvez gérer efficacement les schémas de trafic imprévisibles ou irréguliers.

Cette page décrit les bonnes pratiques pour optimiser et adapter les performances d'Agent Runtime, 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 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 Agent Runtime à 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, en définissant min_instances=10 sur l'agent exemple, vous pouvez réduire la latence moyenne d'un démarrage à froid à environ 1,4 seconde. Pour les applications dont le trafic est irrégulier ou élevé, 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 à Agent Runtime à 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 actif 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 de plate-forme d'agent ne traite qu'une seule requête à la fois. Les agents asynchrones, tels que ceux basés sur l'Agent Development Kit (ADK), peuvent gérer 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 de plate-forme d'agent de gérer plusieurs requêtes. Le nombre de requêtes simultanées que chaque processus d'agent peut gérer est de container_concurrency / 9. La valeur 9 représente le nombre de processus d'agent s'exécutant 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

Guide

Découvrez comment gérer les agents déployés sur le runtime géré Agent Platform.

Guide

Utilisez un agent avec Agent Platform Runtime.

Ressource

Découvrez les quotas et les limites d'Agent Platform.