Évoluer les agents LangGraph en production : d'un seul utilisateur à 1 000 collègues

TL;DR

• NVIDIA a fait évoluer un agent LangGraph (IA-Q) d’un seul utilisateur à des centaines d’utilisateurs, en s’appuyant sur le NeMo Agent Toolkit et une pile OpenShift de production.
• Le processus a commencé par une évaluation et un profilage pour quantifier le comportement, les temps et l’usage des tokens, afin d’identifier les goulots d’étranglement et de guider les décisions matérielles.
• Des tests de charge avec l’outil de dimensionnement ont exploré 10 à 50 utilisateurs simultanés, permettant de prévoir le matériel et de planifier la réplication.
• L’observabilité et un déploiement par étapes, via OTEL et Datadog, ont fourni des traces, des journaux et une visibilité des performances par session.

Contexte et arrière-plan

Vous avez construit un agent IA puissant et vous vous demandez s’il fonctionnera lorsque 10, 100 ou 1 000 collègues l’utiliseront en même temps. Cette question est au cœur de la mise en production d’un agent IA. NVIDIA a rencontré ce défi lors du déploiement interne d’un agent de recherche approfondi, construit avec LangGraph et en utilisant le blueprint AI‑Q de NVIDIA. Le blueprint est open source et conçu pour un déploiement sur site, servant de point de départ pour le déploiement en production d’un assistant de recherche. L’agent IA‑Q permet le téléversement de documents avec extraction de métadonnées, l’accès à des sources internes et des recherches sur le web pour générer des rapports de recherche. Le blueprint est implémenté avec le NeMo Agent Toolkit et utilise des modèles NVIDIA NeMo Retriever pour l’ingestion de documents, la récupération et les invocations de LLM. Notre déploiement de production tourne sur un cluster OpenShift interne, suivant une architecture de référence d’usine IA, avec accès à des microservices NVIDIA NIM déployés localement et à des outils d’observabilité tiers. Le défi central consistait à déterminer quelles parties du système devaient évoluer pour supporter des centaines d’utilisateurs répartis sur différentes équipes NVIDIA. Nous avons suivi une approche en trois étapes, en appliquant les capacités du NeMo Agent Toolkit à chaque phase. Il n’existe pas de règle générale comme « un GPU pour 100 utilisateurs » car chaque application agentique est différente. La première étape consiste à comprendre le comportement de l’application pour un seul utilisateur et à quantifier ce comportement par l’évaluation et le profilage. Le NeMo Agent Toolkit propose un système d’évaluation et de profilage qui permet de collecter des données et d’obtenir une compréhension quantitative du comportement de l’application. Pour lancer l’évaluation, nous avons ajouté une section d’évaluation dans le fichier de configuration de l’application, en incluant un ensemble de données contenant des entrées d’utilisateurs exemples. Les applications agentiques ne sont pas déterministes, il est donc utile de profiler diverses entrées afin de comprendre les performances sous une variété d’utilisations plausibles. L’application AI‑Q est une application LangGraph qui utilise les wrappers du NeMo Agent Toolkit, permettant au profiler de capturer automatiquement le temps et l’usage des tokens pour les différentes parties de l’application. Nous pouvons aussi marquer des sous-étapes à l’aide de décorateurs simples sur les fonctions qui nous intéressent. Le flux d’évaluation exécute le workflow sur l’ensemble de données et calcule une variété de métriques utiles. L’un des résultats est un graphique de Gantt (ou Waterfall) indiquant quelles fonctions s’exécutent à quel moment dans une session utilisateur, ce qui aide à identifier les goulots potentiels. Pour l’AI‑Q, le principal goulot était les appels au LLM NVIDIA Llama Nemotron Super 49B, ce qui nous a permis de centrer nos efforts sur la réplication et l’évolutivité du NIM pour ce LLM. Outre les mesures de temps et d’usage des tokens, l’outil d’évaluation peut calculer des métriques spécifiques au cas d’usage. Nous avons créé des métriques personnalisées pertinentes pour notre domaine de recherche approfondie et utilisé l’outil de profilage pour comparer différentes versions du code et nous assurer que les optimisations conservaient la qualité des rapports. L’outil peut exporter les métriques vers des plateformes comme Weights and Biases pour suivre et visualiser les expériences au fil du temps. Cette combinaison de profilage, d’évaluation et d’observabilité nous a permis de comprendre les performances d’une seule utilisateur et de préparer l’étape suivante : le test de charge multi-utilisateur. Pour passer à une montée en charge, nous avons utilisé le OpenTelemetry (OTEL) collector conjointement avec Datadog pour capturer les journaux, les performances et les traces LLM. Le collecteur OTEL permet de visualiser les traces spécifiques à chaque session utilisateur, et la consolidation des traces offre une vue d’ensemble des performances de l’application et du comportement de LLM. Cette observabilité nous a permis de déployer avec confiance une version interne du blueprint AI‑Q et de construire un agent de recherche fiable. Source

Ce qui est nouveau

L’approche en trois étapes a donné lieu à un plan de déploiement scalable, soutenu par des données et non par l’intuition. Les jalons clés incluent :

• Comprendre le flux pour un seul utilisateur via l’évaluation, afin de quantifier le temps, l’utilisation des tokens et les sous-étapes. Le profiler du NeMo Agent Toolkit capture les temps et les usages dans les wrappers de fonctions LangGraph; les décorateurs simples permettent d’évaluer les sous-étapes.
• Identification des goulots d’étranglement, notamment les appels au LLM NVIDIA Llama Nemotron Super 49B, ce qui a orienté la réplication et l’évolutivité du déploiement NIM pour gérer la charge du LLM.
• Tests de charge avec les niveaux de concurrence (10, 20, 30, 40, 50) à l’aide du NeMo Agent Toolkit sizing calculator pour simuler des flux parallèles et collecter des métriques, notamment le p95 des invocations LLM et du flux global.
• Utilisation du calculateur de dimensionnement pour estimer les besoins matériels et extrapoler les GPUs nécessaires pour une plus grande concurrence. Partant d’un seul GPU, on peut estimer environ 10 utilisateurs simultanés par GPU, ce qui conduit à environ 10 GPUs pour 100 utilisateurs simultanés.
• Détection et correction des problèmes lors des tests de charge, y compris une mauvaise configuration dans le chart Helm conduisant à une allocation CPU insuffisante pour un microservice NIM et l’ajout de retries et d’un meilleur traitement des erreurs pour éviter les pannes lors d’interruptions.
• Déploiement par étapes : démarrage avec des petites équipes puis expansion progressive, en surveillant les performances pour valider la stabilité lors de l’augmentation du nombre d’utilisateurs.
• Observabilité renforcée : collecteur OTEL avec Datadog pour capturer les traces, les journaux et les données de performance, offrant une visibilité session par session et une vue consolidée des performances.

Pourquoi cela compte (impact pour les développeurs/entreprises)

Pour les développeurs et les entreprises qui livrent des applications basées sur des agents avancés, l’approche NVIDIA montre comment réduire les risques lors d’une transition d’un prototype à la production. Points essentiels :

• Il n’existe pas de règle universelle pour escaladner les agents ; une approche fondée sur les données, démarrant par une évaluation d’un seul utilisateur, informe une planification réaliste de la capacité pour plusieurs utilisateurs.
• Un workflow d’évaluation et de profilage bien défini aide à identifier les goulots précocement, permettant de dimensionner uniquement les composants les plus exigeants (par exemple, les appels LLM) pour répondre à la demande de concurrence.
• Des outils de dimensionnement qui simulent des flux parallèles et extraient des métriques de latence fournissent un guide pratique pour les investissements en matériel et la topologie de déploiement, évitant le sur ou le sous-dimensionnement.
• L’observabilité est indispensable : traçage de bout en bout, journaux et données de performance permettent de comprendre le comportement de l’application et la dynamique du LLM sous charge, facilitant une dégradation maîtrisée et une réponse rapide en cas d’incident.
• Le déploiement par étapes et la surveillance continue minimisent les risques et permettent de valider les performances à l’échelle avant une mise à disposition large. En adoptant ces pratiques et en tirant parti des outils ouverts comme le NeMo Agent Toolkit et le blueprint NVIDIA, les organisations peuvent dimensionner correctement des applications basées sur des agents tout en préservant la qualité des rapports et l’expérience utilisateur.

Détails techniques ou Mise en œuvre

La mise en œuvre pratique suit un pattern reproductible, ancré dans le NeMo Agent Toolkit et dans le blueprint de recherche avancée de NVIDIA. Les étapes incluent :

• Établir une référence avec l’évaluation : ajouter une section d’évaluation dans le fichier de configuration, fournir un jeu de données d’entrées utilisateur représentatives et lancer l’évaluation pour collecter le temps, l’usage des tokens et les métriques des sous-étapes. Le profiler capture les temps et les tokens dans les wrappers; les décorateurs mesurent les sous-étapes.
• Visualiser et interpréter les résultats : un graphique de Gantt/Waterfall montre les fonctions actives pendant une session utilisateur, aidant à identifier les goulots sous concurrence.
• Identifier les goulots : dans AI‑Q, le goulot principal était les appels au LLM NVIDIA Llama Nemotron Super 49B, orientant les efforts vers la réplication et l’évolution du NIM pour soutenir cette charge LLM.
• Étendre aux tests multi-utilisateurs : le sizing calculator exécute des flux simulés en parallèle à différents niveaux de concurrence (10, 20, 30, 40, 50). Il enregistre le p95 pour les invocations LLM et pour le flux global, permettant le dimensionnement et la projection de performance.
• Extrapoler les besoins matériels : avec un seul GPU comme référence, on peut estimer qu’environ 10 utilisateurs simultanés tiennent par GPU, ce qui conduit à environ 10 GPUs pour 100 utilisateurs, guidant la réplication et la conception de l’assemblage.
• Résolution des problèmes détectés : une mauvaise configuration du chart Helm a conduit à une allocation CPU insuffisante pour un microservice NIM, et nous avons ajouté des retries et un traitement des erreurs plus robuste pour éviter les échecs en cas de timeout de LLM.
• Observabilité et surveillance : OTEL et Datadog capturent les traces par session et les données de performance agrégées, offrant une visibilité sur les performances de l’application et le comportement du LLM pendant la montée en charge.
• Déploiement par étapes et observation : après validation avec des équipes plus petites, le déploiement s’est poursuivi par étapes, avec une observation attentive des tendances de latence et du nombre de sessions pour assurer une opération stable lors de l’évolutivité.

Points clés à retenir

• Commencer par une évaluation approfondie d’un seul utilisateur pour quantifier le temps, l’usage des tokens et les sous-étapes.
• Utiliser le profilage et une vue de Gantt pour détecter les goulots précocement, en se concentrant sur les invocations LLM lors de l’évolutivité des agents LangGraph.
• Employer un outil de dimensionnement de charge pour simuler la concurrence réelle et prévoir les besoins matériels avant le déploiement complet.
• Planifier l’évolution du matériel par étapes, avec des répliques et une observabilité pour valider les performances à chaque palier.
• Mettre en œuvre des gestion d’erreurs robustes et des retries pour éviter que les timeouts de LLM ne provoquent des défaillances en cascade.
• Tirer parti d’OpenTelemetry et Datadog pour obtenir une visibilité de bout en bout et surveiller à la fois les performances de l’application et le comportement du LLM.

Références

• NVIDIA Dev Blog: How to Scale Your LangGraph Agents in Production From A Single User to 1,000 Coworkers — https://developer.nvidia.com/blog/how-to-scale-your-langgraph-agents-in-production-from-a-single-user-to-1000-coworkers/