Buzz Mesh : quand la communauté fait tourner le modèle

Il y a quelques semaines, j’écrivais sur la puissance de calcul inutilisée autour de nous. L’idée ressemblait à un réseau électrique intelligent du calcul : des personnes, équipes ou communautés mettent volontairement leur capacité libre à disposition, d’autres l’utilisent, et chaque requête IA ne finit pas automatiquement dans les centres de données des mêmes grands fournisseurs.

C’était surtout une idée d’architecture. Buzz montre aujourd’hui à quoi pourrait ressembler une première brique étonnamment concrète. Le projet associe un espace de travail pour humains et agents IA, des identités Nostr et un pool de calcul communautaire. Un membre propose un modèle local aux agents des autres. À terme, plusieurs appareils pourraient même héberger les parties d’un modèle qui ne tient sur aucune machine isolée.

Cela ressemble beaucoup à notre idée précédente. Mais Buzz n’est ni un supercalculateur mondial, ni une mémoire partagée magique faite de RAM libre. Il construit d’abord une cellule fondée sur la confiance. C’est peut-être le meilleur point de départ.

Ce qu’est réellement Buzz

Buzz est un projet open source de Block, l’entreprise dirigée par Jack Dorsey derrière Square. Le réduire à « la nouvelle application de Jack Dorsey » serait pourtant inexact. Il est développé comme projet Block et son code public est disponible sur GitHub sous licence Apache 2.0.

Buzz évoque un mélange de Slack, GitHub et d’une plateforme d’agents. Humains et agents IA travaillent dans les mêmes canaux, discutent des tâches, gèrent du code et déclenchent des workflows. Chaque agent reçoit sa propre identité cryptographique et des droits limités. On peut ainsi distinguer la personne qui a autorisé l’action de l’agent qui l’a exécutée.

Ce n’est pas cosmétique. Beaucoup de systèmes donnent à un bot un compte de service partagé ou une clé API trop puissante. On sait ensuite que « l’automatisation » a agi, sans toujours savoir quelle instance ni pour quelle instruction. Buzz sépare visiblement autorisation et attribution.

L’espace de travail peut être auto-hébergé. L’architecture publiée repose sur des composants connus : Buzz Relay, PostgreSQL pour les événements et la recherche, Redis pour Pub/Sub et la présence, et un stockage compatible S3 pour les médias. Cette sobriété me plaît. Masquer la réalité opérationnelle ne rend pas la décentralisation plus crédible.

Nostr comme fondation

Nostr signifie Notes and Other Stuff Transmitted by Relays. Son principe est simple : les utilisateurs possèdent une paire de clés cryptographiques, signent des événements et les publient auprès de relais. Les clients s’abonnent aux événements pertinents via un ou plusieurs relais.

Un événement contient notamment l’identité publique de l’expéditeur, un horodatage, un type, du contenu, des références et une signature. La clé privée reste chez l’utilisateur ; la clé publique sert d’identité et de vérification. Nostr utilise des signatures Schnorr sur secp256k1, la même courbe elliptique qui joue un rôle central dans Bitcoin.

Un journal signé, pas une blockchain

Nostr n’est pas une blockchain. Il n’y a ni minage, ni consensus mondial, ni chaîne unique attendue par tous les relais. Un relais accepte et conserve les événements selon ses règles, puis les transmet aux clients. D’autres peuvent conserver les mêmes événements ou non.

Buzz utilise ce modèle pour messages, réactions, tâches d’agents, étapes de workflows et événements Git. Dans une communauté Buzz, le relais reste la source centrale de l’espace : il contrôle l’adhésion, distribue les événements et maintient l’état. Le protocole rend identités et formats plus portables, sans éliminer opérateur, base de données, sauvegardes, rétention ou panne possible.

Une signature prouve quelle clé a signé, pas qu’un relais conservera tout éternellement. Un hébergement Buzz exige donc sauvegardes, exports, supervision et gestion rigoureuse des clés. Une clé privée perdue n’est pas un mot de passe réinitialisable. Une clé volée permet à l’attaquant de signer valablement avec cette identité.

Le lien avec Bitcoin

Nostr est proche culturellement et techniquement de Bitcoin. NIP-57 définit les Lightning Zaps, qui permettent d’envoyer des satoshis à des personnes ou événements et de représenter les reçus sous forme d’événements.

Cela ne rend pas Bitcoin obligatoire. Nostr fonctionne sans blockchain ni jeton. Buzz Shared Compute n’est pas non plus un marché ouvert où des machines inconnues gagnent automatiquement des satoshis par token. La capacité est partagée volontairement au sein d’une communauté. Lightning pourrait plus tard servir à la rémunération ou aux quotas, mais ne répond pas encore aux coûts d’électricité, d’usure et d’exploitation.

Le fonctionnement de Shared Compute

Buzz Mesh lie l’appartenance à la communauté à l’accès au pool. Un membre active le partage, choisit un modèle adapté à son matériel et propose l’inférence aux autres. Un agent peut sélectionner « Buzz shared compute » comme fournisseur sans clé API d’un service externe.

Le relais fournit la coordination et la confiance. Il connaît les membres et les modèles proposés. La requête réelle circule directement et de manière chiffrée entre les machines. Le prompt ne passe pas par le serveur Buzz, mais quitte bien l’appareil du demandeur pour atteindre celui d’un autre membre.

Le chiffrement protège le trajet, pas le terminal. Utiliser le matériel d’autrui suppose de faire confiance à son opérateur. La vision Mesh le dit clairement : la confidentialité de la communauté dépend de la fiabilité de ses membres.

Inférence distante et inférence distribuée ne sont pas synonymes

Dans le cas simple, le modèle entier tourne sur une station puissante et les autres appareils lui envoient leurs demandes. Le réseau transporte surtout prompts, tokens et surcharge de protocole ; le calcul reste sur une machine.

Dans le cas difficile, le modèle est réparti. Chaque nœud conserve certains poids ou effectue une partie du calcul, tandis que les résultats intermédiaires circulent continuellement pendant la génération. Bande passante, latence, topologie et pannes déterminent alors directement la vitesse.

Buzz décrit les deux voies. Le guide public montre un chemin concret de l’application à l’inférence locale ou distante. Le partage d’un modèle entre plusieurs machines relève de la vision Mesh. C’est un objectif crédible, pas encore une plateforme de production à l’échelle illimitée ; certaines fonctions restent derrière un feature flag.

Le cluster Mac Studio révèle le problème réseau

NetworkChuck relie quatre Mac Studio dotés chacun de 512 Go de mémoire unifiée, soit 2 To accessibles aux GPU. Son précédent essai avec cinq Mac a pourtant montré que davantage de machines pouvaient rendre l’inférence 91 % plus lente.

La vidéo distingue parallélisme pipeline et tensoriel. Dans un pipeline, chaque Mac traite ses couches puis transmet le résultat ; cela permet de charger un grand modèle, mais les nœuds attendent. En tensoriel, tous travaillent simultanément sur la même couche et échangent très souvent de petites données. La latence devient alors critique.

NetworkChuck montre une baisse d’environ 300 à 3 microsecondes. Avec Llama 70B, il passe d’environ 5 tokens par seconde en pipeline à près de 16 avec parallélisme tensoriel et RDMA. Le cluster n’est pas cent fois plus rapide : c’est la latence de liaison qui baisse de cet ordre, tandis que le débit du modèle fait un peu plus que tripler.

Depuis macOS 26.2, les Mac Apple silicon avec Thunderbolt 5 prennent en charge RDMA over Thunderbolt. Les données circulent entre régions mémoire enregistrées avec moins de surcharge. Apple a coordonné cette fonction avec MLX Distributed et JACCL.

La physique demeure. Apple recommande un maillage complet : deux Mac exigent un lien, trois trois câbles, quatre six. À partir de cinq, un anneau peut devenir nécessaire faute de ports, mais les données passent alors par des intermédiaires. La mise en œuvre actuelle est aussi limitée à dix UC Queue Pairs et aux opérations send/receive bilatérales.

Une communauté peut proposer plusieurs modèles complets sur différentes machines via Internet. Répartir un seul grand modèle entre Zurich, Berlin et New York est tout autre chose. Chaque saut ralentit la génération et un nœud lent ou absent peut bloquer tout le pipeline.

La RAM ne s’additionne pas simplement

Les poids, le cache KV, les données d’exécution et les réserves pour les longs contextes doivent résider quelque part. Deux membres exploitant chacun un modèle dans 64 Go disposent de deux nœuds, pas d’une machine à 128 Go partagés. Seul un véritable sharding déplace cette limite, au prix de communications, de complexité et de fragilité.

En 2026, la contrainte rencontre un marché difficile. TrendForce décrit un troisième trimestre toujours très tendu pour la DRAM. La demande des serveurs IA soutient des prix records. Shared Compute valorise le matériel existant, mais ne rend pas les nouvelles machines riches en RAM bon marché.

Partager trois stations déjà possédées peut être judicieux. En acheter trois uniquement pour éviter une facture cloud peut être une mauvaise affaire. Électricité, refroidissement, pièces, Internet, administration et risque de panne ne disparaissent pas avec le nom du fournisseur sur la facture.

Ce qui est vraiment intéressant

Buzz n’invente pas une nouvelle inférence distribuée ; il relie des briques existantes. La communauté possède déjà membres, identités et droits. Les agents travaillent déjà ensemble. Les modèles tournent déjà localement. Buzz permet à l’utilisateur d’activer le partage et à l’agent de l’employer comme un fournisseur ordinaire. L’infrastructure devient un réglage de produit.

La zone de confiance reste raisonnable : des personnes qui collaborent déjà plutôt que des millions d’inconnus. C’est réaliste pour une agence, une PME, un projet de recherche ou un groupe de développeurs.

Buzz reste indépendant des modèles. Les opérateurs de modèles à poids ouverts contrôlent poids, configuration et runtime. Mais « posséder le modèle » est un raccourci. Poids ouverts ne signifie pas domaine public ; les licences peuvent limiter usage, redistribution ou commerce. La souveraineté suppose des poids disponibles, une licence comprise, un runtime contrôlé, des données exportables et un fonctionnement sans le fournisseur initial.

Ce qui ne convainc pas encore

La rémunération reste ouverte. Le partage volontaire fonctionne dans une petite équipe ; lorsqu’une personne fournit durablement matériel et électricité à dix autres, il faut limites, priorités, mesures et comptabilité équitable. Nostr et Lightning offrent des briques, pas encore un modèle économique complet.

L’exploitation pose aussi question : mises à jour, origine et licences des modèles, autorisation de voir les prompts sensibles, surcharge, veille, portable en déplacement ou nœud qui disparaît en pleine réponse. Le cloud facture, mais prend en charge une grande partie de ce travail.

Buzz transmet des requêtes de modèle et non du code arbitraire, une frontière raisonnable. Les prompts peuvent néanmoins être confidentiels, les modèles manipulés et les agents trop bavards. L’adhésion contrôle l’accès, pas le comportement. Les entreprises ont aussi besoin de classification, journalisation, quotas, validation des modèles, durcissement des terminaux et règles pour les travaux strictement locaux.

Enfin, Buzz est jeune. Code, architecture et parcours de test dépassent la présentation PowerPoint, mais feature flags, versions rapides et documentation mouvante le confirment. C’est le moment d’expérimenter avec des données non critiques, pas de dépendre de Buzz sans stratégie de sortie.

Ce qui est réellement mis en œuvre

Buzz ne réalise pas tout le réseau intelligent imaginé précédemment. Il en réalise la première couche raisonnable : une cellule volontaire et limitée sur une structure sociale de confiance existante.

Il manque marché ouvert, crédits stables, attestation matérielle, vérification indépendante et exploitation de milliers de nœuds inconnus. Mais Buzz apporte une interface claire et un cas immédiat : un agent a besoin d’un modèle, un membre possède une machine, le relais coordonne et les ordinateurs calculent.

Si ce petit cercle fonctionne, quotas, crédits, paiements Lightning, fédération régionale ou tâches vérifiables pourront suivre. Il faut d’abord que le petit cercle calcule de manière fiable.

Base et limites de cet article

Je n’ai pas testé Buzz Mesh moi-même sur plusieurs machines. L’analyse repose sur le code public, l’architecture, la vision Mesh, le guide de développement, les spécifications Nostr et la documentation RDMA d’Apple, vérifiés le 21 août 2026. Les affirmations sur stabilité, débit et charge réelle ne sont donc pas mes mesures.

Buzz reste l’exemple le plus concret que j’aie vu pour transformer notre idée de calcul distribué en produit utilisable. Encore petit, précoce et sans économie résolue, mais plus seulement théorique.

À la prochaine,
Joe