hyperspaceai/agi : un réseau pair-à-pair où des agents autonomes publient leurs expériences

Un dépôt qui se présente comme le produit de ses propres agents

Le README affirme que ce dépôt est écrit par des agents IA autonomes sur le réseau Hyperspace. Chaque agent lance des expériences, échange ses résultats avec ses pairs par gossip, et pousse le tout ici. C'est la proposition centrale, et elle est inhabituelle : la plupart des projets d'IA distribuée publient du code que des humains exécutent. Ici, le dépôt est présenté comme une archive de recherche alimentée par des processus autonomes, avec des snapshots horaires dans snapshots/latest.json et des archives datées du type snapshots/2026-03-11/04.json. Le public visé est donc double. D'un côté des développeurs curieux de mécanismes P2P appliqués à l'entraînement de modèles. De l'autre des agents logiciels eux-mêmes, puisque le projet expose une API compatible OpenAI sur http://localhost:8080/v1 avec /chat/completions, /models et /embeddings, plus un fichier de compétences à l'adresse agents.hyper.space/skill.md. Ce second public explique une partie des choix : une API locale, un daemon en arrière-plan, un démarrage automatique au boot. Le projet ne cherche pas seulement des contributeurs humains, il cherche des clients automatisés.

Pods, capsules et modèles répartis sur un maillage privé

La fonctionnalité la plus concrète du dépôt est le Pod, décrit comme un cluster IA privé formé par quelques machines. Le mécanisme est simple à suivre : chaque participant installe le CLI, une personne crée le pod, partage un lien d'invitation, et les machines forment un maillage. Les commandes citées dans le README sont hyperspace pod create "my-lab", hyperspace pod invite, hyperspace pod members et hyperspace pod models. La documentation indique que les requêtes sont routées vers le membre qui a le meilleur modèle chargé, avec des exemples nommés Qwen 3.5 32B, GLM-5 Turbo, ou n'importe quel modèle GGUF présent sur le maillage. Deux autres briques sont mentionnées : le partage de clés OpenRouter, Groq et Together avec des budgets par membre, et le Pod VM, un daemon d'agent toujours actif sur neuf fournisseurs listés (Oracle Free, Scaleway, Fly, Vultr, Lightsail, DigitalOcean, Linode, Hetzner, Vercel). Le Pod Capsule est décrit comme une archive .tar.gz de l'état complet du pod (vault, providers, settings), chiffrée en AES-256-GCM, avec migration ou auto-hébergement via docker compose up. Le point à retenir est que le routage vers le meilleur modèle n'est pas décrit plus loin : le README ne dit pas comment le meilleur modèle est déterminé, ni ce qui se passe quand deux membres annoncent des capacités équivalentes. C'est une zone d'ombre réelle pour quiconque voudrait dimensionner un pod sérieusement.

DiLoCo, SparseLoCo et le budget de 25 minutes

L'entraînement distribué repose sur DiLoCo, cité avec un lien vers arXiv. Le principe rapporté : chaque nœud entraîne localement, puis partage des deltas de poids compressés via le réseau P2P. Trois mécanismes de compression sont détaillés dans un tableau. SparseLoCo applique une sparsité top-k sur les deltas LoRA, annoncée à 45 fois de compression par rapport au brut. Le pooling de gradients Parcae regroupe les couches de transformeur voisines par blocs de 6 et moyenne les gradients à l'intérieur de chaque bloc, pour un facteur 6 supplémentaire. Le README annonce 195 fois de compression au total, avec un passage de 5,5 Mo à 28 Ko par tour. Les étapes internes adaptatives complètent le dispositif : la vitesse matérielle de chaque nœud est mesurée, puis le nombre d'étapes est calculé pour remplir un budget d'entraînement de 25 minutes. Le README affirme que les nœuds GPU rapides dépassent 100 étapes tandis que les nœuds CPU lents en font 5 à 10. Un sidecar BitTorrent distribue le worker d'entraînement et les poids via WebTorrent, sans serveur de téléchargement central. Ces chiffres viennent du README et des notes de version, ils n'ont pas été reproduits ici. Le fait que le budget soit fixe à 25 minutes est en soi un compromis : il égalise la participation entre matériels hétérogènes, mais il plafonne aussi la contribution utile d'un nœud très rapide.

Mysticeti, chaîne 808080 et paiements à la fraction de cent

Le volet blockchain est présenté dans un README séparé, sous blockchain/README.md. Le consensus retenu est Mysticeti, décrit comme le DAG non certifié de Sui, atteint via Rust FFI. L'exécution est dite sans état, avec des transactions porteuses de preuve, conformes au document Hyperpaper section V depuis la v1.0.0. Les canaux de paiement en streaming servent aux micropaiements entre agents : on ouvre une fois, on diffuse des montants inférieurs au centime, on ferme on-chain. L'identifiant de chaîne est 808080. Les notes de version récentes portent sur un correctif répété, Mysticeti force-commit-at-frontier fix, présent dans chain-v1.7.6, chain-v1.7.7 et chain-v1.7.8, toutes datées du 29 avril 2026. Trois publications le même jour pour le même correctif méritent l'attention : cela suggère des itérations rapprochées sur un point de consensus délicat, ce qui est cohérent avec la nature du sujet mais peu rassurant pour qui voudrait faire tourner un fullnode en production dès maintenant. Le README mentionne aussi une économie avec 695+ agents et 54 versions livrées de v0.2.0-alpha à v1.5.7.

Installation : deux chemins, un daemon, une API locale

Deux commandes d'installation figurent dans le matériel. Pour le CLI complet, avec inférence GPU, daemon en arrière-plan et démarrage automatique : curl -fsSL https://agents.hyper.space/api/install | bash. Le README blockchain donne une variante : curl -sSL https://download.hyper.space/api/install | bash, suivie de hyperspace start --chain-role fullnode. Pour rejoindre un tour d'entraînement, le README indique hyperspace train, et hyperspace train --solo pour entraîner localement sur ses propres données. L'installation depuis le navigateur passe par https://agents.hyper.space et crée un agent immédiatement, sans GPU. Côté API, la base locale est http://localhost:8080/v1 avec trois endpoints documentés. La version du CLI annoncée est la v5.20.0, avec le pooling de gradients inspiré de Parcae et les étapes internes adaptatives. Un point pratique : les commandes d'installation passent par un pipe curl vers bash, ce qui suppose de faire confiance au domaine de distribution à un instant donné. Le dépôt ne documente pas de somme de contrôle ni de paquet signé, du moins pas dans les extraits fournis.

Ce que les snapshots horaires ne disent pas

Chaque heure, un nœud publie l'état complet de la recherche réseau dans le dépôt, sous forme de JSON. Le fichier snapshots/latest.json pointe toujours vers le plus récent, les archives étant datées. La structure inclut un résumé textuel du type "660 agents, 27,247 experiments, 5 domains active", des classements par domaine (machineLearning, searchEngine, finance, skills, causes), et des compteurs d'expériences comme mlTotalRuns, searchTotalRuns et financeTotalRuns. Un champ disclaimer accompagne le tout : "Raw CRDT leaderboard state. No statistical significance testing. Interpret the numbers yourself." C'est l'élément le plus honnête du dépôt, et aussi le plus important à comprendre. Les chiffres publiés ne sont pas des résultats scientifiques validés, ce sont des états de classement CRDT sans test de significativité. Un lecteur qui citerait ces nombres comme preuve de progrès ferait exactement ce que le disclaimer demande de ne pas faire. Le README suggère de pointer n'importe quel LLM vers cette URL et de lui demander une analyse, ce qui est une manière de déléguer l'interprétation plutôt que de la fournir.

Limites et cas où ce n'est pas le bon outil

Le projet se décrit lui-même comme expérimental, et le README le dit sans détour : "This is Day 1, but this is how it starts." Plusieurs éléments confirment qu'il ne faut pas le traiter comme une infrastructure stable. Le routage des requêtes vers le meilleur modèle dans un pod n'est pas spécifié au-delà de l'intention. Les domaines de recherche sont inégalement actifs : les compteurs cités dans l'exemple de snapshot montrent 13 exécutions pour la recherche d'information et 0 pour la finance, ce qui relativise l'idée de cinq domaines simultanément productifs. Trois correctifs de consensus publiés le même jour sur Mysticeti indiquent une surface encore mouvante. Enfin, l'API compatible OpenAI est locale, pas un service distant : elle ne remplace pas un fournisseur d'inférence si vous cherchez de la disponibilité. Si votre besoin est d'entraîner un modèle de façon reproductible sur un cluster que vous contrôlez, ce dépôt n'est pas l'outil : il optimise pour la participation hétérogène et anonyme, pas pour la reproductibilité. Si votre besoin est un proxy résidentiel, un stockage DHT ou des embeddings CPU, les capacités listées avec leurs pondérations (+10% inférence, +12% recherche, +8% proxy, +6% stockage, +5% embeddings, +5% mémoire, +5% orchestration, +4% validation, +3% relais) décrivent un système de points, pas un contrat de service.

Alternatives : ce que change vraiment l'approche P2P

Pour l'entraînement distribué sur matériel hétérogène, l'alternative documentée la plus directe est le cadre DiLoCo lui-même, dont ce projet reprend l'article fondateur. La différence d'approche est nette : DiLoCo décrit la méthode, Hyperspace l'enveloppe dans un réseau libp2p avec gossip, sidecar BitTorrent et worker autonome qui réinstalle ses dépendances et applique un backoff exponentiel en cas d'échec. Vous gagnez la coordination et la distribution des poids, vous perdez le contrôle sur qui participe et sur la reproductibilité des tours. Pour l'inférence partagée entre quelques machines, une alternative plus classique est un serveur d'inférence unique exposant une API compatible OpenAI, avec répartition en amont. Ici, la différence est que le routage se fait vers le membre qui a le meilleur modèle chargé, ce qui suppose que les membres se font confiance et que le maillage tient. Pour le volet consensus, Mysticeti est décrit comme repris de Sui via Rust FFI ; l'alternative consiste à utiliser directement une chaîne existante plutôt que d'en faire tourner une avec l'identifiant 808080. Le choix d'Hyperspace est de tout intégrer dans un seul CLI, au prix d'une surface plus large à maintenir.

Conclusion éditoriale

À adopter si vous voulez observer ou rejoindre un réseau d'agents expérimental sans infrastructure centralisée, et que vous acceptez de lire des snapshots JSON bruts plutôt qu'une interface soignée. À éviter si vous cherchez un service d'inférence stable ou une bibliothèque d'entraînement distribué réutilisable : le dépôt est un journal de recherche vivant, pas un produit. Avant de lancer quoi que ce soit, ouvrez snapshots/latest.json, lisez le champ disclaimer et vérifiez par vous-même que les compteurs de expérimentCounts correspondent à ce que vous attendez d'un réseau de cette taille.

Sources officielles

1. hyperspaceai/agi on GitHub
2. License: MIT
3. Project website
4. README
5. Releases