Reason Machines met en open source Aspen, un serveur Git conçu pour les agents d'IA
Reason Machines a publié Aspen, un serveur Git open source conçu pour le trafic des agents d'IA, destiné aux dépôts où des centaines d'agents poussent du code simultanément. Distribué sous la forme d'un unique binaire Rust, Aspen stocke l'historique des branches dans PostgreSQL (ou SQLite) et les paquets Git dans un stockage objet compatible S3. Il fonctionne sur un portable via la commande « aspen dev », sur un hôte unique avec Docker Compose, ou dans le cloud avec Helm et Terraform, et parle le Git standard en HTTPS et SSH. Selon les mesures de l'éditeur, non vérifiées de façon indépendante, le serveur a tenu 567 pushs par seconde pendant cinq minutes sur une machine à huit cœurs. Les intégrations sur la branche principale tombent en revanche à environ quatre par seconde. Le projet reste en pré-alpha, sans version publiée ni interface web, et l'objectif de durabilité sur 24 heures n'est pas encore atteint.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de MarkTechPost. Lire l'article original →
L'enjeu est concret pour toute équipe qui confie du développement à des flottes d'agents. Sur un serveur Git classique, tous les pushs vers un même dépôt passent dans une file commune, et chaque récupération déclenche la construction d'un nouveau paquet. La charge du serveur croît alors avec le nombre de clients plutôt qu'avec la quantité de code réellement produite. Comme un agent pousse toutes les quelques minutes et que l'intégration continue récupère le dépôt après chaque push, ce modèle sature vite. Aspen supprime le plafond de pushs par dépôt : les écritures sur des branches différentes ne s'attendent jamais. Le compromis est que certaines branches peuvent être lues à des instants légèrement différents, et que, lorsque deux pushs se disputent la même branche, l'un échoue avec l'erreur habituelle « fetch first ».
Techniquement, Aspen reprend la conception décrite par OpenAI pour son système Pando, qu'il réimplémente de manière indépendante. Chaque branche est une chaîne de versions stockée dans une ligne PostgreSQL, et un push téléverse son paquet puis déplace la branche par une seule opération de comparaison et d'échange. Le serveur ne décompresse jamais un push : il vérifie le paquet, complète les bases manquantes et le conserve tel quel. Lors d'une récupération, il diffuse les paquets que le client n'a pas, sans recompression, et peut déléguer leur service à un CDN grâce à des URL signées. Un push ne voit que la branche principale, ce qui garde la négociation légère même avec un million de branches. Une compaction en arrière-plan fusionne les paquets par lots de 16, à la manière d'un arbre LSM, de sorte qu'un client très en retard reçoit quelques dizaines de paquets plutôt que des milliers. Les récupérations CI de profondeur 1 profitent d'un paquet de pointe construit une fois et servi à tous les jobs.
Ce travail s'inscrit dans le mur que ses auteurs disent avoir rencontré chez OpenAI, qui a construit Pando pour y échapper. Selon eux, Pando a réduit la latence médiane des pushs d'un facteur proche de cinq et sert près d'un pétaoctet par jour. Aspen en propose une version ouverte et auto-hébergeable, à un moment où les agents de code multiplient les écritures automatisées sur les dépôts. Reste à voir si le projet franchira l'étape de la durabilité, publiera ses premières versions et améliorera le débit sur la branche principale, point faible actuel.
Pas d'impact direct sur la France/UE