Optimiser et faire évoluer les performances d'Agent Runtime

Agent Runtime 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 modèles de trafic imprévisibles ou irréguliers.

Cette page décrit les bonnes pratiques pour optimiser et faire évoluer les performances d'Agent Runtime, en couvrant les scénarios suivants :

• Problème de démarrage à froid
• Workers asynchrones sous-utilisés

Les scénarios montrent comment utiliser les paramètres de déploiement pour résoudre les goulots d'étranglement courants, 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 ou conteneur inactif n'est disponible 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 tiède (deuxième exécution immédiate) : latence moyenne d'environ 0,4 seconde.

Le temps système 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'exemple d'agent peut réduire la latence moyenne d'un démarrage à froid à environ 1,4 seconde. Pour les applications à trafic élevé ou irrégulier, définissez min_instances sur une valeur capable de gérer votre charge habituelle sans avoir à effectuer un scaling à partir de 1. Pour connaître la plage de valeurs acceptées, consultez la documentation de référence sur la ressource REST ReasoningEngineSpec.

• 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 soutenue 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 maintient le service actif 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 Agent Platform ne gère qu'une seule requête à la fois. Les agents asynchrones, tels que ceux basés sur l'Agent Development Kit (ADK), peuvent gérer simultanément plusieurs requêtes liées aux E/S (comme les appels de LLM ou d'outils).

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 :

• Alors que la latence médiane est 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 horizontal lent.

Pour limiter la sous-utilisation des nœuds de calcul asynchrones, augmentez container_concurrency pour permettre à chaque instance Agent Platform 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 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 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 liée au 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