Buzz Mesh: Wenn die Community das Modell betreibt

Vor wenigen Wochen habe ich hier über die ungenutzte Rechenleistung um uns herum geschrieben. Die Idee war eine Art Compute-Smart-Grid: Menschen, Teams oder regionale Gemeinschaften stellen freie Kapazität freiwillig zur Verfügung, andere nutzen sie, und nicht jede KI-Anfrage muss automatisch in einem Rechenzentrum derselben grossen Anbieter landen.

Damals war das vor allem ein Architekturgedanke. Nun zeigt Buzz, wie ein erster, erstaunlich konkreter Baustein davon aussehen kann. Das Projekt verbindet einen gemeinsamen Arbeitsraum für Menschen und KI-Agenten mit Nostr-Identitäten und einem Compute-Pool innerhalb der eigenen Community. Ein Mitglied stellt ein lokales Modell bereit, andere Mitglieder lassen ihre Agenten darauf zugreifen. In der weitergehenden Vision können mehrere Geräte sogar Teile eines Modells tragen, das auf keiner einzelnen Maschine Platz hätte.

Das klingt ziemlich genau nach der Idee von damals. Es ist aber wichtig, Buzz weder kleiner noch grösser zu machen, als es derzeit ist. Hier entsteht kein weltweiter KI-Supercomputer, und ungenutzter RAM verwandelt sich nicht plötzlich in einen magischen gemeinsamen Speicher. Buzz baut zuerst eine vertrauensbasierte Zelle. Genau das könnte der vernünftigere Anfang sein.

Was Buzz eigentlich ist

Buzz ist ein Open-Source-Projekt von Block, dem von Jack Dorsey geführten Unternehmen hinter Square. Es wäre trotzdem ungenau, Buzz einfach als “Jack Dorseys neue App” zu beschreiben. Entwickelt wird es als Block-Projekt, und der öffentliche Quellcode liegt unter einer Apache-2.0-Lizenz auf GitHub.

Auf den ersten Blick wirkt Buzz wie eine Mischung aus Slack, GitHub und einer Agentenplattform. Menschen und KI-Agenten arbeiten in denselben Channels, diskutieren Aufgaben, verwalten Code und lösen Workflows aus. Agenten bekommen dabei eine eigene kryptografische Identität und klar begrenzte Berechtigungen. Dadurch lässt sich unterscheiden, welcher Mensch eine Aktion autorisiert hat und welcher Agent sie tatsächlich ausgeführt hat.

Das ist mehr als kosmetische Benutzerverwaltung. In vielen heutigen Agentensystemen verwendet ein Bot einfach ein gemeinsames Servicekonto oder einen API-Key mit viel zu grossen Rechten. Danach ist zwar bekannt, dass “die Automation” etwas getan hat, aber nicht immer sauber nachvollziehbar, welche Instanz mit welchem Auftrag dahinterstand. Buzz will Autorisierung und Urheberschaft getrennt sichtbar machen.

Der Arbeitsraum kann selbst betrieben werden. Die veröffentlichte Architektur besteht nicht aus irgendeiner geheimnisvollen Peer-to-Peer-Wolke, sondern aus bekannten Komponenten: einem Buzz Relay, PostgreSQL für Events und Suche, Redis für Pub/Sub und Präsenz sowie S3-kompatiblem Speicher für Medien. Diese Nüchternheit gefällt mir. Dezentralität wird nicht dadurch glaubwürdiger, dass man die betriebliche Realität versteckt.

Nostr ist das Fundament

Nostr steht für Notes and Other Stuff Transmitted by Relays. Das Protokoll wurde nicht speziell für Buzz entwickelt. Seine Grundidee ist klein: Nutzer besitzen ein kryptografisches Schlüsselpaar, signieren Ereignisse und veröffentlichen diese an Relays. Clients abonnieren bei einem oder mehreren Relays die Ereignisse, die sie interessieren.

Ein Nostr Event enthält unter anderem die öffentliche Identität des Absenders, einen Zeitstempel, einen Typ, Inhalt, Verweise und eine Signatur. Der private Schlüssel bleibt beim Nutzer und signiert. Der öffentliche Schlüssel dient als Identität und zur Prüfung. Technisch verwendet Nostr Schnorr-Signaturen auf secp256k1, also derselben elliptischen Kurve, die auch im Bitcoin-Umfeld eine zentrale Rolle spielt.

Ein signiertes Log, aber keine Blockchain

Dieser Unterschied ist wichtig: Nostr ist keine Blockchain. Es gibt kein Mining, keinen globalen Konsens und keine einzige Kette, auf die alle Relays warten müssen. Ein Relay nimmt Events an, speichert sie nach seinen Regeln und liefert sie an Clients aus. Andere Relays können dieselben oder andere Events halten.

Buzz verwendet dieses Event-Modell für Nachrichten, Reaktionen, Agentenaufträge, Workflow-Schritte und Git-Ereignisse. Innerhalb einer Buzz Community ist das Relay trotzdem die zentrale Quelle des Arbeitsraums. Es prüft Mitgliedschaft, verteilt Events und hält den Zustand. Das Protokoll macht Identität und Datenformate portabler. Es beseitigt aber nicht automatisch den Betreiber, die Datenbank, Backups, Aufbewahrungsregeln oder den möglichen Ausfall eines Relays.

Signaturen belegen zudem, wer ein Event mit einem bestimmten Schlüssel signiert hat. Sie garantieren nicht, dass ein Relay jedes frühere Event für immer ausliefert. Wer Buzz selbst betreibt, braucht deshalb weiterhin Backups, Exporte, Monitoring und eine saubere Schlüsselverwaltung. Ein verlorener privater Schlüssel ist kein gewöhnliches Passwort, das ein Administrator einfach zurücksetzt. Ein gestohlener Schlüssel ist eine Identität, mit der ein Angreifer gültig signieren kann.

Was Bitcoin damit zu tun hat

Nostr ist kulturell und technisch eng mit der Bitcoin-Community verbunden. Neben derselben Kurve für Signaturen gibt es mit NIP-57 sogenannte Lightning Zaps. Damit können Nostr-Clients Zahlungen in Satoshis an Personen oder Events anstossen und passende Zahlungsbelege als Events darstellen.

Das bedeutet aber nicht, dass jede Nostr-Anwendung auf Bitcoin bezahlt werden muss. Nostr funktioniert ohne Blockchain und ohne Coin. Auch Buzz Shared Compute ist derzeit kein offener Marktplatz, auf dem fremde Rechner automatisch Satoshis pro Token verdienen. Die veröffentlichte Idee basiert auf freiwillig geteilter Kapazität innerhalb einer Community. Lightning wäre später ein naheliegender Baustein für Vergütung oder Quoten, ist aber noch nicht die wirtschaftliche Antwort auf Strom, Verschleiss und Betrieb.

Wie Shared Compute in Buzz funktioniert

Buzz Mesh verbindet die Mitgliedschaft einer Community mit der Zulassung zum Compute-Pool. Ein Mitglied aktiviert die Freigabe, wählt ein Modell, das auf die eigene Hardware passt, und stellt die Inferenz anderen Mitgliedern zur Verfügung. Ein Agent kann “Buzz shared compute” wie einen Modellanbieter auswählen, ohne einen API-Key bei einem externen KI-Dienst zu hinterlegen.

Das Relay übernimmt dabei die Vertrauens- und Koordinationsschicht. Es weiss, wer zur Community gehört und welcher Knoten ein Modell anbietet. Die eigentliche Modellanfrage läuft direkt und verschlüsselt zwischen den beteiligten Maschinen. Der Prompt soll damit nicht durch den Buzz Server fliessen. Er verlässt aber sehr wohl das Gerät des Fragenden und landet auf der Maschine eines anderen Community-Mitglieds.

Dieser Satz gehört in jede Sicherheitsbetrachtung. Transportverschlüsselung schützt den Weg. Sie macht den Endpunkt nicht blind. Wer fremde Hardware für Inferenz nutzt, muss deren Betreiber innerhalb des eigenen Vertrauensraums akzeptieren. Buzz formuliert das in seiner Mesh-Vision erfreulich offen: Die Community ist nur so privat wie ihre Mitglieder vertrauenswürdig sind.

Remote Inference ist nicht automatisch verteilte Inferenz

Unter “Shared Compute” stecken zwei technisch sehr verschiedene Dinge.

Im einfacheren Fall läuft das gesamte Modell auf einer leistungsfähigen Workstation. Andere Geräte schicken Anfragen dorthin. Das ist Remote Inference innerhalb einer Community. Dafür braucht man keine Verbindung wie in einem GPU-Cluster. Über das Netz gehen vor allem Prompt, generierte Tokens und Protokoll-Overhead. Eine gute Internetverbindung und vernünftige Latenz helfen, aber das Modell selbst rechnet auf einer Maschine.

Im schwierigeren Fall wird ein Modell über mehrere Rechner aufgeteilt. Dann hält jeder Knoten nur einen Teil der Gewichte oder übernimmt einen Teil der Berechnung. Jetzt müssen während der Erzeugung von Tokens laufend Zwischenergebnisse zwischen den Knoten ausgetauscht werden. Aus einer normalen Client-Server-Verbindung wird ein gekoppeltes verteiltes System. Bandbreite, Latenz, Topologie und Ausfälle bestimmen plötzlich direkt die Modellgeschwindigkeit.

Buzz beschreibt beide Richtungen. Der aktuelle öffentliche Entwicklungsleitfaden zeigt einen realen Pfad von der Desktop-App über den Agenten bis zu lokaler oder entfernter Inferenz. Die grössere Aussage, ein Modell über mehrere Community-Geräte zu zerlegen, steht in der Mesh-Vision. Das ist ein plausibles Ziel, sollte aber nicht mit einer ausgereiften, beliebig skalierbaren Produktionsplattform verwechselt werden. Teile der Compute-Oberfläche werden im Entwicklungsbetrieb weiterhin über einen Feature-Schalter aktiviert.

Der Mac-Studio-Cluster zeigt das Netzwerkproblem

NetworkChuck liefert dafür ein sehr anschauliches Beispiel. In seinem aktuellen Aufbau verbindet er vier Mac Studios mit jeweils 512 GB Unified Memory zu einem lokalen Cluster mit insgesamt 2 TB GPU-zugänglichem Speicher. Schon sein früherer Versuch mit fünf Macs zeigte jedoch das Problem: Mehr Rechner machten die Inferenz nicht schneller, sondern laut seinem Vergleich 91 Prozent langsamer.

Das Video bleibt nicht bei der beeindruckenden RAM-Summe stehen, sondern erklärt den Unterschied zwischen Pipeline- und Tensor-Parallelismus. Bei der Pipeline verarbeitet ein Mac seine Modellschichten und reicht das Ergebnis an den nächsten weiter. Das schafft genug Speicherkapazität für ein grosses Modell, lässt die anderen Knoten aber immer wieder warten. Beim Tensor-Parallelismus arbeiten alle Macs gleichzeitig an derselben Schicht. Dafür müssen sie während jeder Schicht sehr häufig kleine Datenmengen austauschen. Genau dort wird Latenz zum entscheidenden Faktor.

NetworkChuck zeigt für seinen Aufbau eine Verringerung von ungefähr 300 auf 3 Mikrosekunden. In seinem Llama-70B-Vergleich steigt die Ausgabe dabei von etwa 5 Tokens pro Sekunde mit Pipeline-Parallelismus auf rund 16 Tokens pro Sekunde mit Tensor-Parallelismus und RDMA. Das ist ein starkes Resultat, aber auch eine wichtige sprachliche Grenze: Nicht der gesamte Cluster wird 100-mal schneller. Die gemessene Verbindungslatenz sinkt ungefähr um diesen Faktor, während der konkrete Modell-Durchsatz in diesem Test gut dreimal so hoch ausfällt.

Mit normalem IP over Thunderbolt entstehen höhere Latenz und mehr CPU-Overhead. Seit macOS 26.2 unterstützt Apple auf Apple-Silicon-Macs mit Thunderbolt 5 RDMA over Thunderbolt. RDMA erlaubt geeigneter Software, Daten mit deutlich weniger Overhead zwischen registrierten Speicherbereichen zu bewegen. Apple hat diese Funktion ausdrücklich mit MLX Distributed und dem JACCL-Backend abgestimmt.

Das Update löst ein echtes Problem, hebt die Physik aber nicht auf. Apples eigene Technote empfiehlt für minimale Latenz eine vollständig vermaschte Topologie. Zwei Macs brauchen eine Verbindung, drei bereits drei Kabel und vier sechs Kabel. Ab fünf Knoten wird wegen der begrenzten Ports beispielsweise ein Ring interessant. Dann muss die Anwendung Daten über Zwischenknoten weiterleiten. Apple nennt zudem konkrete Grenzen der aktuellen RDMA-Implementierung, darunter maximal zehn UC Queue Pairs und nur zweiseitige Send/Receive-Operationen.

Dieses Beispiel ist für Buzz wichtiger, als es zunächst scheint. Eine Community kann über das Internet problemlos mehrere vollständige Modelle auf verschiedenen Rechnern anbieten und Jobs passend verteilen. Ein einziges grosses Modell über weit entfernte Rechner zu spannen, ist eine andere Klasse. Zwischen Zürich, Berlin und New York helfen keine sechs Thunderbolt-Kabel. Jedes zusätzliche Netzwerk-Hopping verlängert die Token-Erzeugung, und ein langsamer oder verschwundener Knoten kann die ganze Pipeline bremsen.

RAM lässt sich nicht einfach addieren

Bei lokalen Sprachmodellen ist Speicher oft die härtere Grenze als rohe Rechenleistung. Die Modellgewichte müssen irgendwo liegen. Dazu kommen KV-Cache, Laufzeitdaten und Reserven für längere Kontexte oder mehrere gleichzeitige Nutzer.

Wenn zwei Mitglieder jeweils ein Modell in 64 GB RAM betreiben, besitzt die Community zwei Inferenzknoten. Sie besitzt nicht automatisch eine Maschine mit 128 GB gemeinsamem Speicher. Erst echtes Model Sharding kann diese Grenze verschieben, und dafür bezahlt man mit Kommunikation, Komplexität und höherer Fehleranfälligkeit.

Gerade 2026 trifft diese technische Grenze auf einen unangenehmen Markt. TrendForce beschreibt den DRAM-Markt im dritten Quartal als weiterhin sehr angespannt. Die Nachfrage aus AI-Servern stützt Rekordpreise, während PC- und Smartphone-Hersteller an ihre Preisgrenzen kommen. Shared Compute macht vorhandene Hardware dadurch attraktiver. Es macht neue lokale Systeme mit viel RAM aber nicht billig.

Das verändert auch die wirtschaftliche Rechnung aus meinem früheren Compute-Smart-Grid-Gedanken. Wenn eine Gruppe ohnehin drei Workstations besitzt, kann gemeinsames Nutzen sehr sinnvoll sein. Drei teure Rechner nur zu kaufen, um eine Cloud-Rechnung zu vermeiden, kann dagegen die schlechtere Investition sein. Strom, Kühlung, Ersatzteile, Internet, Administration und Ausfallrisiko verschwinden nicht, nur weil auf der Rechnung kein Hyperscaler mehr steht.

Was an Buzz Mesh wirklich cool ist

Der stärkste Punkt ist für mich nicht, dass Buzz eine neue Methode zur verteilten Inferenz erfunden hätte. Der starke Punkt ist die Verbindung bereits vorhandener Bausteine.

Die Community hat schon Mitglieder, Identitäten und Berechtigungen. Die Agenten arbeiten schon in denselben Räumen. Modelle können schon lokal über eine kompatible Schnittstelle laufen. Buzz verbindet diese Ebenen so, dass ein Nutzer Compute aktiv freigibt und ein Agent ihn wie einen normalen Anbieter verwenden kann. Aus einem Infrastrukturprojekt wird eine Produkteinstellung.

Auch die Grösse der Vertrauenszone ist vernünftig. Unser früheres Gedankenspiel reichte bis zu Städten, Genossenschaften und Millionen Geräten. Buzz beginnt mit Menschen, die ohnehin zusammenarbeiten. Das löst Vertrauen nicht vollständig, reduziert aber die Zahl unbekannter Parteien. Für eine Agentur, ein kleines Unternehmen, ein Forschungsprojekt oder eine Entwicklergruppe ist das realistischer als ein anonymer globaler GPU-Basar.

Ein weiterer Vorteil ist die Modellunabhängigkeit. Buzz kann unterschiedliche Agenten und Modellanbieter verbinden. Wer lokale Open-Weight-Modelle betreibt, kann die Gewichte, Konfiguration und Laufzeit selbst kontrollieren. “Das Modell besitzen” bleibt trotzdem eine verkürzte Formulierung. Offene Gewichte sind nicht automatisch Public Domain. Lizenzbedingungen können Nutzung, Weitergabe oder kommerziellen Betrieb begrenzen. Wirkliche Souveränität bedeutet deshalb: Gewichte verfügbar, Lizenz verstanden, Laufzeit kontrollierbar, Daten exportierbar und ein Betrieb ohne den ursprünglichen Anbieter möglich.

Was noch nicht überzeugt

Die erste offene Frage ist die Vergütung. Innerhalb eines kleinen Teams kann freiwilliges Teilen genügen, weil alle vom gemeinsamen Projekt profitieren. Sobald eine Person dauerhaft Strom und Hardware stellt, während zehn andere konsumieren, wird aus Kameradschaft Kapazitätsplanung. Es braucht Limits, Prioritäten, Messwerte und irgendwann eine faire Abrechnung. Nostr und Lightning liefern dafür interessante Bausteine, Buzz aber noch kein fertiges Wirtschaftsmodell.

Die zweite Frage ist Betrieb. Wer aktualisiert Modelle? Wer prüft ihre Herkunft und Lizenz? Wer entscheidet, welcher Knoten sensible Prompts sehen darf? Was passiert bei Überlastung, Schlafmodus, einem Notebook im Zug oder einem Rechner, der mitten in der Antwort ausgeschaltet wird? Ein Cloud-Anbieter verlangt Geld, übernimmt dafür aber auch einen grossen Teil dieser langweiligen Arbeit.

Die dritte Frage ist Sicherheit. Shared Compute in Buzz reicht Modellanfragen weiter, nicht beliebigen fremden Code an jede Workstation. Das ist eine deutlich vernünftigere Grenze als ein offener Compute-Marktplatz. Trotzdem können Prompts vertrauliche Informationen enthalten, Modelle manipuliert sein und Agenten mehr Kontext senden, als der Nutzer erwartet. Mitgliedschaft ist eine Zugangskontrolle, keine Garantie für korrektes Verhalten. Für Unternehmen braucht es zusätzlich Datenklassifikation, Protokollierung, Quoten, Modellfreigaben, Endpoint-Härtung und klare Regeln, welche Jobs lokal bleiben müssen.

Und schliesslich bleibt Buzz jung. Der öffentliche Code, die Architektur und ein konkreter Shared-Compute-Testpfad sind mehr als eine PowerPoint-Folie. Gleichzeitig zeigen Feature-Schalter, schnelle Releasefolgen und offene Entwicklungsdokumente, dass sich das System noch stark bewegt. Das ist ein guter Zeitpunkt zum Experimentieren mit unkritischen Daten. Es ist kein guter Zeitpunkt, zentrale Unternehmensprozesse ohne Exit-Plan davon abhängig zu machen.

Was hier tatsächlich umgesetzt wird

Buzz realisiert nicht das ganze Compute-Smart-Grid aus meinem früheren Artikel. Es setzt aber genau dessen sinnvollste erste Schicht um: eine begrenzte, freiwillige Compute-Zelle mit vorhandener sozialer Vertrauensstruktur.

Noch fehlen der offene Markt, stabile Credits, Hardware-Attestierung, unabhängige Ergebnisprüfung und ein Betriebsmodell für tausende unbekannte Knoten. Dafür gibt es etwas, das vielen dezentralen Projekten fehlt: eine verständliche Oberfläche und einen unmittelbaren Anwendungsfall. Ein Agent braucht ein Modell. Ein Mitglied hat einen Rechner. Beide gehören derselben Community an. Das Relay koordiniert, die Maschinen rechnen.

Vielleicht ist das die wichtigere Umsetzung als der sofortige grosse Wurf. Dezentrale Infrastruktur scheitert oft daran, dass sie zuerst ein globales Wirtschaftssystem bauen will und erst danach nach einem alltäglichen Problem sucht. Buzz beginnt umgekehrt. Es nimmt einen bestehenden Arbeitsraum und macht ungenutzte Rechenleistung darin sichtbar und verwendbar.

Wenn das stabil funktioniert, können später Quoten, Credits, Lightning-Zahlungen, regionale Föderation oder verifizierbare Jobs folgen. Aber zuerst muss der kleine Kreis zuverlässig rechnen. Erst dann lohnt es sich, den Kreis grösser zu ziehen.

Einordnung und Grenzen dieses Artikels

Ich habe Buzz Mesh für diesen Beitrag nicht selbst in einem Mehrrechner-Setup getestet. Die technische Einordnung basiert auf dem öffentlichen Buzz-Quellcode, der Architektur, der Mesh-Vision, dem Entwicklungsleitfaden, den Nostr-Spezifikationen und Apples RDMA-Dokumentation, geprüft am 21. August 2026. Aussagen über Stabilität, Durchsatz und Verhalten unter realer Last sind deshalb keine eigenen Messergebnisse.

Buzz ist für mich trotzdem das bisher greifbarste Beispiel dafür, wie aus unserer Idee verteilter Rechenleistung ein benutzbares Produkt werden kann. Noch klein, noch früh und noch ohne gelöste Ökonomie. Aber nicht mehr nur theoretisch.

Bis zum nächsten Mal,
Euer Joe