hyperspaceai/agi: Ein P2P-Netz für autonome Agenten, kein fertiges AGI-System

Was das Projekt lösen will, und für wen

Das Repository positioniert sich als verteiltes System, in dem autonome Agenten Experimente ausführen, Ergebnisse per Gossip austauschen und die Resultate in dasselbe Repository pushen. Die Zielgruppe ist eng umrissen: Betreiber kleiner Maschinengruppen, die Rechenleistung bündeln wollen, und Agenten, die über eine OpenAI-kompatible Schnittstelle auf lokaler Hardware arbeiten. Der README beschreibt zwei Einstiegspunkte, einen Browser unter agents.hyper.space und eine CLI, die sich per curl installieren lässt. Der Anspruch im Titel, AGI, ist eine Setzung des Projekts, keine überprüfbare Eigenschaft. Die Beschreibung im Repository nennt es selbst experimentell. Wer den Namen als Produktversprechen liest, wird enttäuscht. Wer ihn als Forschungsbezeichnung liest, bekommt eine Reihe konkreter Mechanismen, die einzeln nachvollziehbar sind.

Pods: geteilte Inferenz statt zentraler API

Ein Pod ist laut README ein privater Verbund, in dem mehrere Maschinen zu einem gemeinsamen Cluster werden. Der Ablauf ist knapp beschrieben: hyperspace pod create "my-lab" legt den Pod an, hyperspace pod invite erzeugt einen Einladungslink, hyperspace pod members zeigt verbundene Knoten, hyperspace pod models listet die im Verbund verfügbaren Modelle. Anfragen werden an das Mitglied geleitet, das das passende Modell geladen hat, genannt werden Qwen 3.5 32B, GLM-5 Turbo und beliebige GGUF-Modelle. Zusätzlich lassen sich Provider-Schlüssel von OpenRouter, Groq oder Together mit Budgets pro Mitglied teilen. Das ist der praktisch nützlichste Teil des Projekts, weil er ein Alltagsproblem löst: mehrere Rechner, unterschiedliche Modelle, kein gemeinsamer Einstiegspunkt. Der Pod Capsule, ein tar.gz-Archiv aus Vault, Providern und Einstellungen mit AES-256-GCM, erlaubt es, diesen Zustand zu verschieben oder per docker compose up selbst zu hosten. Wer schon einmal Modellgewichte und Zugangsdaten zwischen Rechnern manuell synchronisiert hat, erkennt den Aufwand, der hier eingespart wird.

Der Trainingspfad: DiLoCo, Top-k-Sparsity und BitTorrent

Das verteilte Training folgt laut README dem DiLoCo-Ansatz: Jeder Knoten trainiert lokal, danach werden komprimierte Gewichts-Deltas über das P2P-Netz geteilt. Die Kompression besteht aus zwei Stufen. SparseLoCo wendet Top-k-Sparsity auf LoRA-Deltas an und erreicht laut Dokumentation den Faktor 45 gegenüber Rohdaten. Parcae Gradient Pooling fasst benachbarte Transformer-Schichten in Blöcken von sechs zusammen und mittelt Gradienten innerhalb eines Blocks, was den Faktor sechs zusätzlich bringt. Zusammen ergibt das nach Angabe des Projekts 195-fache Kompression, konkret 5,5 MB auf 28 KB pro Runde. Adaptive Inner Steps messen die Hardwaregeschwindigkeit eines Knotens und leiten daraus die Schrittzahl für ein Budget von 25 Minuten ab. Das ist der interessanteste Teil der Architektur, weil er das eigentliche Problem heterogener Verbünde adressiert: Ein Beschleuniger schafft über 100 Schritte, eine CPU fünf bis zehn. Der Transport läuft über einen BitTorrent-Sidecar, der Trainingsworker und Gewichte verteilt, ohne zentralen Downloadserver. Diese Zahlen stammen aus der Projektdokumentation, nicht aus einer unabhängigen Messung. Ob 195-fache Kompression den Trainingserfolg erhält oder nur die Übertragung schont, lässt sich aus dem Material nicht beantworten.

Installation und Betrieb: was tatsächlich in der Shell steht

Die Installation ist ein Einzeiler: curl -fsSL https://agents.hyper.space/api/install | bash. Für den Trainingsbeitritt genügt hyperspace train, für lokales Training auf eigenen Daten hyperspace train --solo. Wer einen Chain-Knoten betreiben will, startet ihn mit hyperspace start --chain-role fullnode. Die Chain selbst nutzt Mysticeti-Konsens, beschrieben als uncertified DAG aus Sui, angebunden über Rust FFI, mit Chain ID 808080. Für Agenten stellt der lokale Daemon eine OpenAI-kompatible API unter http://localhost:8080/v1 bereit, mit den Endpunkten /chat/completions, /models und /embeddings. Das ist der Punkt, an dem sich das Projekt am leichtesten bewerten lässt: Ein Agent oder ein bestehendes Werkzeug, das die OpenAI-Schnittstelle spricht, kann auf die lokale Basis-URL umgestellt werden, ohne den Client zu ändern. Eine Skill-Datei unter agents.hyper.space/skill.md ist ebenfalls dokumentiert. Wer den Einzeiler ausführt, sollte sich im Klaren sein, dass er ein Skript von einer entfernten Domain ausführt, nicht ein signiertes Paket aus einer Registry. Der README gibt dazu keine Prüfsumme an.

Die Chain und ihr Ökosystem sind der schwächste belegte Teil

Die Blockchain-Komponente wird über eigene Release-Kanäle ausgeliefert, zuletzt mehrfach in Folge als chain-v1.7.x mit dem identischen Hinweis auf einen Mysticeti force-commit-at-frontier Fix. Drei Releases mit derselben Fehlerbehebungsnotiz an einem Tag deuten auf eine instabile Front, nicht auf einen ruhigen Wartungsstand. Die Zahlen im README, 695 oder 660 Agenten und über 27.000 Experimente, sind Momentaufnahmen aus Snapshots und ausdrücklich keine Qualitätsbelege. Der Snapshot selbst enthält den Satz, dass keine statistische Signifikanzprüfung stattfindet und die Zahlen selbst interpretiert werden müssen. Genau so sollte man sie lesen. Auffällig ist auch die Verteilung der Experimentzähler im dokumentierten Beispiel: 1369 Läufe im Bereich Machine Learning, 13 im Suchmaschinenbereich, null im Finanzbereich. Ein Netz, das fünf Domänen bewirbt, aber faktisch in einer arbeitet, ist keine fünfgliedrige Forschungsplattform. Das ist keine Schwäche der Mechanik, sondern eine Frage der Beteiligung, und sie gehört zur Bewertung dazu.

Grenzen und Fälle, in denen das Projekt das falsche Werkzeug ist

Der wichtigste Vorbehalt steht im Projekt selbst: Das Repository ist ein lebendes Forschungsartefakt, geschrieben von autonomen Agenten. Wer reproduzierbare Ergebnisse braucht, etwa für eine Veröffentlichung oder eine Regressionsprüfung, bekommt hier keine feste Baseline. Die Leaderboards sind CRDT-Zustand, der sich laufend ändert, und die Snapshots sind stündliche Momentaufnahmen davon. Ein weiterer Punkt ist die Vertrauensfrage: Ein Netz, in dem anonyme Knoten Gewichts-Deltas beisteuern, kann vergiftete Updates nicht ausschließen, und das Material beschreibt keine Aggregationsregel, die das auffängt. Die Kompression über Top-k-Sparsity und Schicht-Pooling ist eine bewusste Genauigkeits-Geschwindigkeits-Abwägung, deren Kosten das Projekt nicht quantifiziert. Und die Chain mit eigenen Konsensregeln bringt einen zweiten Fehlerraum mit, der bei reinem Modelltraining nichts beiträgt. Für ein Team, das einfach nur einen Inferenzserver mit mehreren GPUs betreiben will, ist vLLM oder ein schlichtes Kubernetes-Deployment mit einem HTTP-Router die direktere Wahl. Der Pod lohnt sich erst, wenn die Maschinen über Standorte verteilt sind und keine gemeinsame Steuerungsebene existiert.

Wartung, Versionen und Lizenz

Die Wartungslast verteilt sich auf mehrere bewegliche Teile. Der README nennt CLI v5.20.0 als aktuellen Stand, während die Release-Liste unter chain-v1.7.8 einen eigenen Versionsstrang zeigt. Zwei Versionslinien mit unterschiedlichen Nummern bedeuten, dass Aktualisierungen nicht an einer Stelle ansetzen. Der Autonomous Worker installiert Abhängigkeiten selbst, startet einen Python-Sidecar und überlebt CLI-Neustarts mit exponentiellem Backoff. Das senkt den Betriebsaufwand, verschiebt aber die Fehlersuche: Wenn der Worker selbst heilt, ist die Ursache eines Ausfalls nicht mehr im Shell-Verlauf sichtbar. Wer den Pod selbst hostet, übernimmt mit docker compose up auch die Pflege des Containers. Die Lizenz ist MIT, was Weitergabe und Änderung erlaubt, solange der Copyright-Hinweis erhalten bleibt. Der README benennt keine Haftungs- oder Gewährleistungszusagen für das verteilte Training. Wer Pods mit geteilten Provider-Schlüsseln betreibt, sollte klären, ob die Nutzungsbedingungen von OpenRouter, Groq oder Together das Weiterreichen eines Schlüssels an Dritte überhaupt zulassen. Das ist eine Vertragsfrage, keine Lizenzfrage, und sie wird im Repository nicht behandelt.

Redaktionelles Fazit

Wer verteiltes Training auf heterogener Consumer-Hardware oder einen privaten Inferenzverbund über mehrere Standorte ausprobieren will, findet hier eine dokumentierte CLI mit konkreten Befehlen. Wer ein belastbares AGI-System, reproduzierbare Benchmarks oder eine produktionsreife Chain sucht, sollte zuerst snapshots/latest.json und den Disclaimer darin lesen: dort steht ausdrücklich, dass keine statistische Signifikanzprüfung stattfindet.

Offizielle Quellen

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