L’IA agentique se heurtera à un mur d’infrastructure avant d’atteindre un mur d’intelligence

Les modèles progressent plus vite que notre capacité à répondre à ce qu’on leur demande.

La plupart des débats sur l’avenir des agents d’IA portent sur leurs capacités. Le modèle peut-il planifier de manière fiable ? Peut-il corriger ses propres erreurs ? Peut-on lui confier une action qui aura des conséquences ?

Ce sont de vraies questions. Mais ce ne sont pas elles qui détermineront si les agents seront déployés à grande échelle au cours des prochaines années, car une contrainte plus immédiate se profile, et elle se fait sentir plus vite. Le coût de l’exécution des agents est difficile à maîtriser, et cette difficulté s’accentue avec les capacités que tout le monde souhaite leur ajouter.

Un chatbot et un agent ne représentent pas la même charge de travail

Une requête conversationnelle consiste en un seul aller-retour : le prompt est envoyé, des jetons sont générés, puis la connexion est fermée. On peut regrouper les requêtes, mettre le préfixe en cache et évaluer le débit à l’aide d’un seul chiffre.

Une requête adressée à un agent correspond à une session. Il appelle un outil, attend, lit le résultat, décide de la suite, appelle un autre outil, puis finit par répondre. Une tâche relativement simple peut nécessiter six ou huit appels au modèle, entrecoupés de temps d’attente.

Cette différence compte pour une raison qui n’a rien à voir avec l’intelligence. Entre deux étapes, l’agent conserve un état : la conversation, les résultats des outils et le raisonnement accumulé. Côté exécution, cet état réside dans la mémoire du GPU sous la forme d’un cache KV, qui occupe de la mémoire pendant toute la durée de la session, y compris pendant les secondes où l’agent attend la réponse d’une API qui ne vous appartient pas.

La capacité ne se mesure donc plus en « requêtes par seconde », mais en « sessions simultanées résidant en mémoire ». Un système capable de traiter confortablement un millier de requêtes conversationnelles par seconde sur un matériel donné ne pourra peut-être y faire tourner que quelques dizaines de sessions d’agent simultanées.

L’attente est ce qui coûte cher

Voici la réalité inconfortable : pendant un appel d’outil, l’agent ne fait rien. Aucun jeton n’est généré. Aucun calcul n’est effectué. La mémoire du GPU reste pourtant occupée, car évincer ce contexte puis le recalculer coûterait plus cher que de le conserver.

Votre matériel le plus coûteux est réservé à une requête qui, à cet instant, attend une réponse à une requête de base de données.

Dans les systèmes distribués classiques, nous avons résolu ce problème depuis longtemps : on libère la ressource, puis on reprend le travail à l’arrivée de la réponse. Pour faire de même lors de l’exécution de modèles, il faut évincer le cache KV vers la mémoire hôte ou un disque, puis le restaurer. Le coût du transfert est si élevé que la plupart des systèmes ne s’en donnent pas la peine. Des recherches sur cette question précise sont en cours, justement parce que le problème coûte cher.

L’exécution séquentielle aggrave inutilement le problème

Presque tous les frameworks d’agents exécutent les appels aux outils les uns après les autres. Le modèle demande une recherche météo, en reçoit le résultat, demande une vérification de l’agenda, en reçoit le résultat, puis demande une recherche de vols et en reçoit le résultat.

Souvent, ces trois appels ne dépendent pas les uns des autres. Ils pourraient être lancés simultanément. Exécutés séquentiellement, leur latence s’additionne. Exécutés en parallèle, elle correspond à celle de l’appel le plus long.

Ce constat n’a rien de nouveau concernant les agents : il s’agit du même principe structurel que pour tout système exécutant plusieurs modèles ou services dans un même budget de latence. La latence totale devrait correspondre au chemin le plus long dans le graphe de dépendances, et non à la somme de toutes les étapes. Ce principe compte davantage pour les agents parce que leur session reste en mémoire GPU pendant toute sa durée. Réduire le temps écoulé améliore donc non seulement l’expérience utilisateur, mais augmente directement le nombre de sessions pouvant tenir sur le matériel.

Divisez par deux la durée des sessions et vous doublerez à peu près la capacité simultanée, avec les mêmes GPU et sans modifier le modèle.

Les nouvelles tentatives s’accumulent sans que personne l’ait prévu

Les frameworks d’agents héritent des paramètres de nouvelle tentative par défaut des bibliothèques HTTP sur lesquelles ils reposent. En général, ils prévoient trois tentatives.

Le modèle effectue lui aussi des tentatives, à sa manière. Lorsqu’un outil renvoie un résultat peu utile, un modèle de raisonnement essaie souvent une autre approche : c’est une nouvelle tentative, mais personne ne l’a configurée.

Combinez les deux mécanismes : une politique de trois tentatives appliquée à un modèle qui, de son côté, explore trois autres approches aboutit à une politique de neuf tentatives que personne n’a consignée. Chacune de ces tentatives correspond à un appel complet au modèle, avec ses propres jetons et ses propres secondes d’utilisation du GPU.

Lorsqu’une dépendance ralentit, cette amplification transforme une dégradation en panne, et chaque tentative coûte alors plusieurs ordres de grandeur de plus qu’un nouvel essai d’appel REST.

À quoi ressemble réellement le mur

Ce n’est pas un plafond de capacités, mais un problème plus prosaïque : une équation économique qui bloque les projets au passage de la phase pilote à la production.

Le pilote fonctionne. Il concerne dix utilisateurs, la latence est acceptable et la facture est négligeable. Puis quelqu’un fait une projection pour dix mille utilisateurs, et les besoins en GPU paraissent irréalistes — non pas parce que le modèle est lent, mais parce que chaque session simultanée occupe de la mémoire pendant toute sa durée, y compris pendant les temps d’attente.

C’est à ce stade que bon nombre de démonstrations internes prometteuses s’arrêtent discrètement.

Ce qui permet de repousser la limite

Rien d’exotique : tout relève de l’infrastructure, pas de la modélisation :

Exécuter simultanément les appels indépendants aux outils. Le gain ponctuel le plus important, déjà possible aujourd’hui et sans nécessiter de nouveau matériel.

Prendre la durée des sessions comme mesure de la capacité. Pas le nombre de jetons par seconde. Pas l’utilisation des GPU. Mais la durée pendant laquelle l’état reste en mémoire, et le nombre de sessions qui peuvent tenir.

Répartir le budget de nouvelles tentatives sur l’ensemble du système plutôt que par appel. Une limite globale — les nouvelles tentatives ne représentant qu’un faible pourcentage du trafic total — évite l’effet cumulatif décrit plus haut. Les pratiques SRE de Google en matière de gestion de la surcharge et les budgets de nouvelles tentatives d’Envoy mettent tous deux en œuvre cette idée en dehors de la pile d’IA.

Dissocier le raisonnement de l’exécution. Un grand modèle pour planifier, un modèle beaucoup plus petit pour les étapes mécaniques. La plupart des tâches d’un agent ne nécessitent pas de modèle de pointe.

Rendre peu coûteuse l’éviction du contexte. Cache KV quantifié, attention paginée et mécanismes de déchargement pour les sessions inactives. C’est dans ce domaine que se déroule actuellement une bonne partie des travaux les plus intéressants sur le service des modèles.

Les modèles continueront de s’améliorer. Sur ce point, les perspectives semblent solides. Que les agents deviennent une infrastructure ou restent de simples démonstrations dépend d’un facteur moins spectaculaire : notre capacité à servir une charge de travail qui mobilise une mémoire coûteuse pendant les périodes d’attente, et notre capacité à cesser de payer le coût cumulé d’une séquence lorsque nous pourrions ne payer que celui de son chemin le plus long.

J’ai publié le modèle d’exécution qui sous-tend ce dernier point — l’exécution simultanée d’appels de modèles dépendants dans le cadre d’un même budget de latence — dans « Exécution asynchrone de graphes d’inférence pour le routage de modèles dans les systèmes d’apprentissage automatique », International Journal of Computer Trends and Technology 72(10), octobre 2024. Sur l’intégration des modèles génératifs aux systèmes décisionnels soumis à des contraintes de latence, voir plus précisément « Plateformes de négociation et de décision augmentées par les LLM : faire le lien entre l’intelligence générative et les systèmes de décision financière », Journal of Information Systems Engineering and Management 11(1s), 2026.