Infinity : AWS et UC Berkeley suspendent 75 000 agents dans 8 Go — le runtime serverless où un agent qui attend ne coûte rien

Infinity : AWS et UC Berkeley suspendent 75 000 agents dans 8 Go — le runtime serverless où un agent qui attend ne coûte rien

🔎 Un agent IA passe l'essentiel de sa vie à attendre. Et vous payez pour ce temps mort.

Le 23 octobre 2025, AWS a publié Infinity, un runtime d'agents open source (Apache 2.0) développé avec UC Berkeley dans le cadre du projet Hydro. Le projet attaque un angle mort que personne ne traitait frontalement : la quasi-totalité des harness — l'environnement d'exécution qui fait tourner un agent — garde un process résident en mémoire pendant que l'agent... attend. Attend une réponse d'API, une validation humaine, une pipeline CI de trois jours.

C'est un problème d'argent autant que d'architecture. Un agent, dans la vraie vie, passe la majorité de son cycle à attendre des outils, pas à « réfléchir ». Pendant ce temps, votre RAM est occupée, votre conteneur tourne, votre fonction serverless brûle son timeout.

Pourquoi maintenant ? Parce que le nombre d'agents explose — la guerre des coding agents, avec Grok Build : xAI lance son premier agent coding CLI — la guerre des coding agents s'intensifie, en est la dernière illustration — et que les tâches longues deviennent la norme. Le panorama des meilleurs agents IA autonomes se remplit de harness toujours plus capables, mais l'infrastructure sous-jacente, elle, n'a pas bougé. Infinity propose de la faire bouger.

L'essentiel

• Le projet : Infinity, runtime d'agents open source (Apache 2.0), publié le 23 octobre 2025 par AWS avec UC Berkeley, dans le projet Hydro.
• L'idée centrale : chaque appel d'outil est traité comme un point de suspension. L'historique est persisté, l'agent disparaît de la mémoire, le résultat le réveille.
• Le headline : ~100 Ko par agent inactif, soit « 75 000 agents dans 8 Go » — une arithmétique sur Raspberry Pi 5, pas une mesure.
• La mesure réelle : 80 000 agents suspendus sur un seul thread AMD EPYC, avec un modèle simulé. Avec des agents réalistes (~1 Mo d'historique), la capacité retombe à ~8 000 agents pour 8 Go.
• L'architecture : Lambda + SQS + Aurora DSQL, slices d'exécution bornées. Un agent qui attend une CI de 3 jours ne consomme strictement aucun compute.
• L'orchestration : outils spawn_thread / report_to_parent, événements traités côté child threads.

Outils recommandés

Le problème : vos agents dorment, votre facture non

La plupart des harness traitent l'attente d'un outil comme un état actif : le process reste résident, la mémoire reste allouée, le runtime continue de « posséder » l'agent. Infinity part du postulat inverse — une attente n'est pas un travail, donc elle ne devrait rien coûter.

Prenons trois cas banals. Un agent de veille qui interroge une API toutes les heures. Un agent de code qui attend le verdict d'une CI. Un agent de recherche qui attend une validation humaine. Dans les trois cas, le harness classique maintient un process et un contexte en RAM. À l'échelle — 1 000, 10 000 agents — vous allouez des centaines de gigaoctets de mémoire pour stocker, très littéralement, du néant en cours d'attente.

Les fonctions serverless ne règlent pas seules ce problème : Lambda plafonne à 15 minutes par exécution. Un agent qui doit survivre trois jours doit soit payer un conteneur permanent, soit bricoler des checkpoints manuels. C'est exactement le trou qu'Infinity comble, en faisant de la suspension une primitive du runtime plutôt qu'une responsabilité du développeur.

Comment Infinity fonctionne : l'appel d'outil comme point de suspension

Infinity modélise les agents comme des coroutines sans pile (stackless coroutines) : à chaque appel d'outil, l'état minimal de l'agent est sérialisé et persisté, puis le process disparaît purement et simplement.

Le détail technique compte. Une coroutine sans pile n'a pas de pile d'appels à préserver — seulement l'état essentiel, celui qui suffit à reprendre l'exécution au bon endroit. Le cycle complet :

1. L'agent s'exécute dans une slice bornée, une tranche de calcul dont la durée maximale est imposée par le runtime.
2. Il émet un appel d'outil → l'historique est persisté, l'agent est suspendu, le process disparaît.
3. Le résultat arrive → un événement réveille l'agent, qui se réhydrate et reprend exactement là où il s'était arrêté.

Résultat : un agent inactif ne coûte que son état, environ 100 Ko selon les chiffres d'AWS. Pas de process, pas de thread, pas de RAM résidente. L'agent n'est plus un programme qui tourne, c'est une donnée qui dort.

spawn_thread et report_to_parent : la délégation comme primitive du runtime

Infinity expose deux outils natifs : spawn_thread, qui crée un agent enfant, et report_to_parent, qui remonte un résultat au parent. Détail d'architecture important : les événements sont traités côté child threads — le parent ne poll pas en boucle, ce sont les slices des threads enfants qui traitent les remontées.

C'est le même schéma mental que la délégation de sous-agents décrite dans Hermes Agent #14 : Délégation de tâches — orchestrer des sous-agents, mais poussé dans l'infrastructure : l'orchestration n'est plus un pattern de framework, c'est une primitive du runtime, avec la suspension « gratuite » qui va avec.

Mon avis : c'est la bonne couche pour ça. Un framework peut imiter la délégation ; seul un runtime peut rendre l'attente d'un sous-agent réellement gratuite.

75 000 agents dans 8 Go : ce que dit vraiment le benchmark

Le chiffre du titre est une arithmétique, pas une mesure. La mesure, c'est autre chose — et elle reste impressionnante. Décomposons, chiffres sourcés.

Ce qui est mesuré. AWS a fait tourner 80 000 agents suspendus sur un seul thread d'un AMD EPYC, avec un modèle simulé — pas d'appels LLM réels. Ce test valide le coût mémoire d'environ 100 Ko par agent inactif. Notez que les chiffres se tiennent entre eux : 80 000 agents × ~100 Ko ≈ 8 Go d'état. Source : le blog open source d'AWS.

Ce qui est extrapolé. Les 8 Go de RAM d'un Raspberry Pi 5 divisés par ~100 Ko donnent 75 000 à 80 000 agents. Le « 75 000 agents dans 8 Go sur un Pi » du headline est donc un calcul, pas un banc d'essai. L'analyse d'ALFW le souligne sans détour.

Ce qu'on ne dit pas assez. Les vrais agents accumulent des sorties d'outils : logs, dumps JSON, rapports. Avec ~1 Mo par agent — déjà modeste pour un agent qui a réellement travaillé — les 8 Go du Pi n'accueillent plus que ~8 000 agents. Un facteur 10 entre le headline et la réalité du terrain.

Mon avis : la nuance n'enlève rien à l'essentiel. Un agent inactif à ~100 Ko, c'est un changement d'ordre de grandeur face aux centaines de Mo d'un process résident. Mais quiconque reprend le « 75 000 sur un Pi » sans mentionner le « ~8 000 en conditions réalistes » vend du rêve. Le projet assume lui-même une démo honnête ; à nous, journalistes et développeurs, de la relayer telle quelle.

Lambda + SQS + Aurora DSQL : l'architecture derrière la démo

Le déploiement de référence d'Infinity repose sur trois briques AWS : Lambda pour exécuter des slices bornées, SQS pour réveiller les agents, Aurora DSQL pour persister les historiques.

Le flux est simple à décrire. Une slice Lambda exécute l'agent jusqu'à son prochain appel d'outil. L'état part dans Aurora DSQL, l'appel d'outil part dans le monde — API, CI, humain. L'agent cesse alors d'exister en mémoire. Quand le résultat revient, un message SQS déclenche une nouvelle slice Lambda, qui réhydrate l'agent depuis DSQL et reprend l'exécution. Les slices bornées garantissent au passage qu'aucun agent ne peut monopoliser un worker : chaque tranche a un budget de temps.

La conséquence économique est la plus intéressante. Un agent qui attend une CI de trois jours ne consomme aucun compute pendant ces trois jours — ni instance, ni fonction en veille, ni conteneur. Vous payez du stockage (~100 Ko à quelques Mo) et, à chaque réveil, quelques millisecondes de Lambda. C'est l'inverse exact du modèle « un conteneur par agent ».

Note d'honnêteté : ce stack de référence est profondément AWS. Le runtime est Apache 2.0 et auto-hébergeable, mais reproduire le mode « concurrence extrême » ailleurs suppose de recâbler vous-même la persistance et le réveil. Ce n'est pas un défaut — c'est un choix, et il faut le connaître avant de s'engager.

Ce que ça change pour l'infrastructure des agents

Infinity fait passer la concurrence d'agents d'une contrainte de RAM à une contrainte de stockage — et cela ouvre des charges de travail jusque-là économiquement impossibles.

Trois conséquences concrètes :

1. Le coût marginal d'un agent inactif tend vers zéro. Des flottes de 10 000 agents de veille, de supervision ou de reprise sur incident deviennent raisonnables à exploiter.
2. Les tâches longues redeviennent normales. Attendre trois jours une CI, une semaine une revue humaine, un mois un renouvellement de domaine : fini les hacks de checkpoint et les conteneurs payés à ne rien faire.
3. La couche runtime se standardise. Le mouvement va dans le sens de l'histoire récente : Agent Skills : le framework d'addyosmani qui standardise les workflows des agents IA de codage standardise les workflows, Infinity standardise l'exécution. Quand les deux se rencontrent, un agent devient un artefact portable — skills d'un côté, runtime suspendable de l'autre.

Mon avis tranché : c'est le morceau d'infrastructure le plus intéressant publié cet automne côté agents. Pas parce que le benchmark est flatteur — il est honnête — mais parce que la primitive est la bonne. Les frameworks se battent depuis deux ans sur l'orchestration ; le prochain front, c'est le runtime, et les harness dominants du moment devront tôt ou tard répondre à ce type de projet.

Limites : ce que la démo ne dit pas

Infinity est prometteur mais très jeune, et sa démo phare repose sur un modèle simulé. Trois réserves s'imposent avant d'en faire votre socle de production.

Modèle simulé ≠ LLM réel. Le test des 80 000 agents n'appelle pas de vrais modèles. Avec des appels réels — GPT-5.5, Claude Opus 4.7, Gemini 3 Pro ou un modèle open source — la latence réseau et les erreurs d'API changent la dynamique des réveils. Pas la mémoire au repos, mais le profil de charge et le coût par réveil.

La mémoire réelle est pilotée par les sorties d'outils. Les historiques grossissent vite : logs de CI, réponses d'API verbeuses, captures d'écran. Sans politique d'élagage, le facteur 10 entre le headline et la réalité se vérifie en production.

La maturité. Projet publié le 23 octobre : API potentiellement instable, recul de production inexistant, documentation à évaluer. Traitez Infinity comme un projet à suivre de près, pas comme un standard établi.

Si vous préférez garder la main sur toute la chaîne, l'alternative reste l'auto-hébergement : des agents IA open source en local avec Ollama sur un VPS que vous contrôlez — Hostinger propose des VPS adaptés à cet usage (prix à vérifier sur hostinger.com). Vous ne récupérez pas la suspension gratuite d'Infinity, mais vous maîtrisez chaque octet et chaque euro.

Tester Infinity en dix minutes

Le dépôt est public et la prise en main passe par les exemples du README. Le strict minimum pour commencer :

git clone https://github.com/hydro-project/infinity
cd infinity
less README.md

Le dépôt hydro-project/infinity fournit des exemples d'agents et la documentation du runtime. Deux conseils avant de vous lancer : commencez par un agent à un seul outil pour observer le cycle suspension/réveil, puis étudiez la gestion des slices bornées — c'est elle qui garantit qu'aucune exécution ne part en vrille. Si vous partez de zéro, notre guide comment créer un agent IA couvre les fondamentaux à maîtriser avant de choisir un runtime.

❌ Erreurs courantes

Erreur 1 : Reprendre « 75 000 agents dans 8 Go » comme un fait mesuré

Ce qui ne va pas : c'est une extrapolation arithmétique à partir de ~100 Ko par agent, validée sur un thread EPYC avec modèle simulé — pas sur un Pi avec de vrais agents.
La solution : citez les deux chiffres. 80 000 mesurés (modèle simulé, EPYC), ~8 000 réalistes (1 Mo par agent, 8 Go). C'est plus crédible, et plus utile à vos lecteurs.

Erreur 2 : Confondre suspension et compression mémoire

Ce qui ne va pas : la suspension ne réduit pas la taille de l'historique, elle retire le process de la RAM. Un agent bavard aux grosses sorties d'outils reste un agent lourd à persister.
La solution : offloadez les sorties vers du stockage objet, élagage systématique des historiques, budget mémoire explicite par agent.

Erreur 3 : Migrer toute sa flotte vers Lambda du jour au lendemain

Ce qui ne va pas : chaque réveil coûte — invocation Lambda, lectures DSQL. Un agent qui enchaîne les appels d'outils courts peut coûter plus cher en mode suspendu/réveillé qu'en process résident.
La solution : profilez d'abord. Infinity brille sur les attentes longues et fréquentes, pas sur les agents qui mitraillent cinquante appels API à la minute.

Erreur 4 : Oublier que la délégation multiplie les états

Ce qui ne va pas : chaque spawn_thread crée un état persisté supplémentaire. Une hiérarchie de 10 parents × 10 enfants, c'est 100 historiques à gérer, réveiller et clôturer.
La solution : bornez la profondeur de délégation, tracez les arbres de threads, définissez une politique de fin de vie des child threads.

❓ Questions fréquentes

Infinity est-il vraiment open source ?

Oui. Le code est publié sous licence Apache 2.0 dans le dépôt GitHub du projet Hydro, co-développé par AWS et UC Berkeley, et rendu public le 23 octobre 2025. Vous pouvez l'inspecter, le modifier et l'auto-héberger librement. Le stack de référence AWS (Lambda, SQS, Aurora DSQL) reste un choix d'implémentation, pas une obligation de licence.

Peut-on vraiment faire tourner 75 000 agents sur un Raspberry Pi 5 ?

Personne ne l'a démontré publiquement. Le chiffre est une arithmétique (8 Go ÷ ~100 Ko) dérivée d'un test mesuré sur AMD EPYC avec modèle simulé. Avec des agents réalistes accumulant ~1 Mo de sorties d'outils, comptez plutôt ~8 000 agents pour 8 Go. Le headline est directionnel, pas factuel — c'est le point clé à retenir.

Faut-il AWS pour utiliser Infinity ?

Non pour le runtime, oui pour le déploiement de référence. Infinity est Apache 2.0 et auto-hébergeable, mais le mode « concurrence extrême » documenté s'appuie sur Lambda, SQS et Aurora DSQL. Reproduire ce mode sur une autre cloud ou on-premise suppose d'implémenter vous-même la persistance des historiques et le mécanisme de réveil.

Infinity remplace-t-il LangGraph ou les frameworks d'agents ?

Non, il se place en dessous. Les frameworks gèrent l'orchestration : graphes d'étapes, prompts, mémoire applicative. Infinity gère l'exécution : suspension, persistance, réveil. Les deux sont complémentaires — un framework pourrait s'appuyer sur ce type de runtime pour rendre l'attente gratuite sans changer son API.

Quels modèles LLM peut-on utiliser avec Infinity ?

Le runtime est agnostique : l'agent appelle le modèle de votre choix via API — GPT-5.5, Claude Opus 4.7, Gemini 3 Pro ou un modèle open source auto-hébergé. Restez toutefois conscient que les benchmarks publiés reposent sur un modèle simulé : les profils de latence et de coût avec de vrais appels restent à mesurer dans votre contexte.

✅ Conclusion

En transformant chaque appel d'outil en point de suspension, Infinity (AWS + UC Berkeley, Apache 2.0) fait passer le coût d'un agent inactif de « un process résident » à « ~100 Ko de stockage » — et même si le headline des 75 000 agents sur Pi mérite le contexte des ~8 000 agents réalistes, la primitive est la bonne et elle va faire des émules. Clonez le dépôt, testez le cycle suspension/réveil, et surveillez ce que les grands harness en tireront.