Buzz Mesh: quando la comunità esegue il modello

Poche settimane fa ho scritto della potenza di calcolo inutilizzata che ci circonda. L’idea era una sorta di smart grid del calcolo: persone, team o comunità regionali mettono volontariamente a disposizione la capacità libera, altri la usano e non ogni richiesta IA deve finire nei data center dei soliti grandi provider.

Allora era soprattutto un’idea architetturale. Buzz mostra ora come potrebbe apparire un primo elemento sorprendentemente concreto. Il progetto combina uno spazio di lavoro per persone e agenti IA, identità Nostr e un pool di calcolo comunitario. Un membro offre un modello locale agli agenti degli altri. Nella visione più ampia, più dispositivi possono persino ospitare parti di un modello che non entra in una singola macchina.

Somiglia molto alla nostra idea. Ma Buzz non è un supercomputer IA globale e la RAM libera non diventa memoria condivisa per magia. Prima costruisce una cellula basata sulla fiducia. Potrebbe essere il punto di partenza più sensato.

Che cos’è davvero Buzz

Buzz è un progetto open source di Block, l’azienda dietro Square guidata da Jack Dorsey. Definirlo semplicemente «la nuova app di Jack Dorsey» sarebbe impreciso. È sviluppato come progetto Block e il codice pubblico è su GitHub con licenza Apache 2.0.

Ricorda un mix di Slack, GitHub e una piattaforma per agenti. Persone e agenti lavorano negli stessi canali, discutono compiti, gestiscono codice e avviano workflow. Ogni agente riceve una propria identità crittografica e permessi limitati. Si può così distinguere chi ha autorizzato un’azione dall’agente che l’ha eseguita.

Non è solo gestione cosmetica. Molti bot usano un account di servizio condiviso o una chiave API troppo potente; sappiamo che «l’automazione» ha agito, ma non sempre quale istanza e con quale mandato. Buzz rende separatamente visibili autorizzazione e paternità.

Lo spazio può essere self-hosted. L’architettura pubblicata usa componenti noti: Buzz Relay, PostgreSQL per eventi e ricerca, Redis per Pub/Sub e presenza e storage compatibile S3 per i media. Questa concretezza mi piace: nascondere la realtà operativa non rende più credibile la decentralizzazione.

Nostr è la base

Nostr significa Notes and Other Stuff Transmitted by Relays. Gli utenti possiedono una coppia di chiavi, firmano eventi e li pubblicano su relay. I client si abbonano agli eventi desiderati tramite uno o più relay.

Un evento contiene identità pubblica del mittente, timestamp, tipo, contenuto, riferimenti e firma. La chiave privata resta all’utente; quella pubblica identifica e verifica. Nostr usa firme Schnorr su secp256k1, la stessa curva ellittica centrale anche per Bitcoin.

Un registro firmato, non una blockchain

Nostr non è una blockchain: niente mining, consenso globale o catena unica. Un relay accetta e conserva eventi secondo le proprie regole e li distribuisce ai client. Altri relay possono avere gli stessi eventi o altri.

Buzz usa il modello per messaggi, reazioni, incarichi agli agenti, workflow ed eventi Git. Nella comunità, il relay resta la fonte centrale: verifica l’appartenenza, distribuisce gli eventi e mantiene lo stato. Il protocollo rende identità e formati portabili, ma non elimina operatore, database, backup, conservazione o possibili guasti.

Le firme provano quale chiave ha firmato, non che un relay consegnerà ogni evento per sempre. Servono backup, esportazioni, monitoraggio e gestione delle chiavi. Una chiave privata persa non è una password reimpostabile; una chiave rubata consente all’attaccante di firmare validamente con quell’identità.

Il rapporto con Bitcoin

Nostr è vicino a Bitcoin per cultura e tecnica. NIP-57 definisce i Lightning Zaps, pagamenti in satoshi a persone o eventi con ricevute rappresentate come eventi.

Bitcoin non è però obbligatorio. Nostr funziona senza blockchain o moneta. Buzz Shared Compute non è oggi un mercato aperto che paga automaticamente satoshi per token a computer sconosciuti. La capacità è condivisa volontariamente nella comunità. Lightning potrebbe servire in futuro per compensi o quote, ma non risolve ancora elettricità, usura e gestione.

Come funziona Shared Compute

Buzz Mesh lega l’appartenenza alla comunità all’accesso al pool. Un membro abilita la condivisione, sceglie un modello adatto all’hardware e offre inferenza agli altri. Un agente seleziona «Buzz shared compute» come provider senza una chiave API esterna.

Il relay coordina: sa chi è membro e quale nodo offre un modello. La richiesta viaggia direttamente e cifrata fra le macchine. Il prompt non passa dal server Buzz, ma lascia il dispositivo del richiedente e raggiunge quello di un altro membro.

La cifratura protegge il percorso, non rende cieco l’endpoint. Usare hardware altrui richiede fiducia nel suo operatore. La visione Mesh lo dichiara apertamente: la comunità è privata solo quanto sono affidabili i membri.

Inferenza remota e distribuita sono diverse

Nel caso semplice, il modello completo gira su una workstation potente e gli altri inviano richieste. In rete passano soprattutto prompt, token e overhead; il calcolo resta su una macchina.

Nel caso difficile, il modello è suddiviso. Ogni nodo conserva parte dei pesi o del calcolo e scambia continuamente risultati intermedi. Banda, latenza, topologia e guasti determinano direttamente la velocità.

Buzz descrive entrambe le direzioni. La guida pubblica mostra un percorso concreto dall’app all’inferenza locale o remota. La suddivisione fra dispositivi appartiene alla visione Mesh: obiettivo plausibile, non piattaforma produttiva illimitata. Alcune funzioni richiedono ancora un feature flag.

Il cluster Mac Studio mostra il limite della rete

NetworkChuck collega quattro Mac Studio con 512 GB di memoria unificata ciascuno, ottenendo 2 TB accessibili alle GPU. Il precedente tentativo con cinque Mac aveva però reso l’inferenza, nel suo confronto, più lenta del 91%.

Il video distingue parallelismo pipeline e tensoriale. Nel pipeline ogni Mac elabora i propri layer e passa il risultato al successivo: il modello entra, ma i nodi attendono. Nel tensoriale tutti lavorano sullo stesso layer e scambiano piccole quantità di dati molto spesso. La latenza diventa decisiva.

NetworkChuck mostra un calo da circa 300 a 3 microsecondi. Con Llama 70B passa da circa 5 token al secondo in pipeline a 16 con parallelismo tensoriale e RDMA. Non significa che il cluster sia cento volte più veloce: la latenza della connessione cala di quel fattore, mentre il throughput del modello poco più che triplica.

Da macOS 26.2, i Mac Apple silicon con Thunderbolt 5 supportano RDMA over Thunderbolt. RDMA sposta dati tra regioni di memoria registrate con meno overhead; Apple lo ha coordinato con MLX Distributed e JACCL.

La fisica resta. Apple raccomanda una topologia fully meshed: due Mac richiedono un collegamento, tre tre cavi, quattro sei. Da cinque nodi un anello può essere necessario per i limiti delle porte, con inoltro tramite nodi intermedi. L’implementazione limita inoltre a dieci UC Queue Pairs e operazioni send/receive a due lati.

Una comunità può offrire via Internet diversi modelli completi su macchine distinte. Distribuire un singolo modello tra Zurigo, Berlino e New York è un altro problema: ogni hop rallenta i token e un nodo lento può bloccare l’intera pipeline.

La RAM non si somma automaticamente

Pesi, cache KV, dati runtime e riserve per contesti lunghi devono stare da qualche parte. Due membri con modelli in 64 GB hanno due nodi, non una macchina con 128 GB condivisi. Solo il vero sharding sposta il limite, pagando comunicazione, complessità e rischio.

Nel 2026 la DRAM resta un mercato difficile. TrendForce descrive il terzo trimestre come molto teso: la domanda dei server IA sostiene prezzi record. Shared Compute valorizza l’hardware esistente, ma non rende economiche nuove macchine locali con molta RAM.

Condividere tre workstation già possedute può essere sensato. Comprarli solo per evitare il cloud può essere un investimento peggiore. Elettricità, raffreddamento, ricambi, Internet, amministrazione e guasti non scompaiono.

Cosa rende interessante Buzz Mesh

Il punto forte non è una nuova tecnica d’inferenza, ma l’unione di elementi esistenti. Comunità, identità, permessi, agenti e modelli locali sono già presenti. Buzz rende la condivisione un’impostazione e il calcolo un provider ordinario per l’agente.

Anche la zona di fiducia è ragionevole: persone che collaborano già, non milioni di sconosciuti. È realistico per agenzie, piccole imprese, ricerca e gruppi di sviluppo.

L’indipendenza dai modelli è un vantaggio. Con pesi aperti si controllano pesi, configurazione e runtime, ma «possedere il modello» è una scorciatoia. Pesi aperti non significa pubblico dominio; le licenze possono limitare uso, ridistribuzione o attività commerciale. Sovranità significa pesi disponibili, licenza compresa, runtime controllabile, dati esportabili e funzionamento senza il provider originario.

Cosa non convince ancora

Manca un modello di compensazione. In un piccolo team basta la condivisione; quando una persona fornisce sempre hardware ed energia a dieci utenti, servono limiti, priorità, metriche e contabilità. Nostr e Lightning offrono componenti, non un’economia completa.

Resta la gestione: chi aggiorna e verifica modelli e licenze, quali nodi vedono prompt sensibili, cosa accade con sovraccarico, sleep, un notebook in viaggio o un computer che sparisce durante la risposta. Il cloud costa, ma assume molto di questo lavoro.

Buzz inoltra richieste di modello, non codice arbitrario: un limite sensato. Tuttavia prompt riservati, modelli manipolati e agenti troppo generosi con il contesto restano possibili. L’appartenenza controlla l’accesso, non il comportamento. Le aziende necessitano classificazione, log, quote, approvazione dei modelli, endpoint protetti e regole per i lavori locali.

Buzz è inoltre giovane. Codice, architettura e test concreti sono più di slide, ma feature flag, rilasci rapidi e documenti in evoluzione indicano un sistema ancora mobile. Va sperimentato con dati non critici, non adottato senza piano d’uscita.

Cosa viene davvero implementato

Buzz non realizza l’intera smart grid del calcolo, ma la sua prima parte più sensata: una cellula volontaria e limitata basata su una struttura sociale di fiducia.

Mancano mercato aperto, crediti stabili, attestazione hardware, verifica indipendente e gestione di migliaia di nodi sconosciuti. Ma esistono un’interfaccia comprensibile e un caso immediato: un agente ha bisogno di un modello, un membro ha un computer, il relay coordina e le macchine calcolano.

Se il piccolo cerchio funziona in modo affidabile, potranno seguire quote, crediti, pagamenti Lightning, federazione regionale e job verificabili. Prima deve funzionare il cerchio piccolo.

Base e limiti dell’articolo

Non ho testato personalmente Buzz Mesh su più computer. L’analisi si basa su codice pubblico, architettura, visione Mesh, guida di sviluppo, specifiche Nostr e documentazione RDMA Apple, verificati il 21 agosto 2026. Stabilità, throughput e carico reale non sono quindi mie misurazioni.

Buzz resta l’esempio più concreto di come la nostra idea di calcolo distribuito possa diventare un prodotto utilizzabile. Ancora piccolo, precoce e senza economia risolta, ma non più solo teorico.

Alla prossima,
Joe