Buzz Mesh: quando a comunidade executa o modelo

Há poucas semanas escrevi sobre a capacidade de computação não utilizada à nossa volta. A ideia era uma espécie de rede inteligente de computação: pessoas, equipas ou comunidades disponibilizam voluntariamente capacidade livre, outros utilizam-na e nem todo o pedido de IA acaba nos centros de dados dos mesmos grandes fornecedores.

Na altura era sobretudo uma ideia de arquitetura. O Buzz mostra agora uma primeira peça surpreendentemente concreta. O projeto combina um espaço de trabalho para pessoas e agentes de IA com identidades Nostr e um pool de computação da comunidade. Um membro fornece um modelo local aos agentes dos restantes. Na visão mais ampla, vários dispositivos podem até guardar partes de um modelo que não cabe numa única máquina.

Isto parece muito com a nossa ideia anterior. Mas o Buzz não é um supercomputador mundial de IA, nem transforma RAM livre em memória partilhada mágica. Primeiro cria uma célula baseada na confiança. Talvez seja o início mais sensato.

O que é realmente o Buzz

O Buzz é um projeto open source da Block, a empresa liderada por Jack Dorsey por trás da Square. Ainda assim, seria impreciso chamá-lo simplesmente «a nova aplicação de Jack Dorsey». É desenvolvido como projeto da Block e o código público está no GitHub sob licença Apache 2.0.

À primeira vista parece uma mistura de Slack, GitHub e plataforma de agentes. Pessoas e agentes trabalham nos mesmos canais, discutem tarefas, gerem código e acionam workflows. Cada agente recebe identidade criptográfica própria e permissões limitadas. Assim distingue-se quem autorizou uma ação do agente que a executou.

Não é apenas gestão cosmética. Muitos bots usam uma conta de serviço comum ou uma chave API com privilégios excessivos. Depois sabemos que «a automação» fez algo, mas nem sempre que instância atuou e com que instrução. O Buzz torna autorização e autoria visíveis em separado.

O espaço pode ser alojado pelo utilizador. A arquitetura publicada usa componentes conhecidos: Buzz Relay, PostgreSQL para eventos e pesquisa, Redis para Pub/Sub e presença, e armazenamento compatível com S3 para multimédia. Esconder a realidade operacional não torna a descentralização mais credível.

Nostr é a base

Nostr significa Notes and Other Stuff Transmitted by Relays. Os utilizadores possuem um par de chaves, assinam eventos e publicam-nos em relays. Os clientes subscrevem os eventos relevantes através de um ou mais relays.

Um evento contém identidade pública, data, tipo, conteúdo, referências e assinatura. A chave privada fica com o utilizador; a pública identifica e verifica. O Nostr usa assinaturas Schnorr em secp256k1, a mesma curva elíptica central no ecossistema Bitcoin.

Um registo assinado, não uma blockchain

O Nostr não é uma blockchain. Não há mineração, consenso global ou cadeia única. Um relay aceita e guarda eventos segundo as suas regras e entrega-os aos clientes. Outros relays podem guardar eventos iguais ou diferentes.

O Buzz usa este modelo para mensagens, reações, tarefas de agentes, passos de workflows e eventos Git. Na comunidade, o relay continua a ser a fonte central: verifica membros, distribui eventos e mantém o estado. O protocolo torna identidades e formatos portáteis, mas não elimina operador, base de dados, backups, retenção ou falhas.

As assinaturas provam qual chave assinou, não que um relay preserve tudo para sempre. Quem aloja Buzz precisa de backups, exportações, monitorização e gestão de chaves. Uma chave privada perdida não é uma palavra-passe recuperável; uma chave roubada permite assinar validamente com essa identidade.

A relação com Bitcoin

O Nostr é próximo de Bitcoin em cultura e tecnologia. O NIP-57 define Lightning Zaps, pagamentos em satoshis a pessoas ou eventos com recibos representados como eventos.

Isso não torna Bitcoin obrigatório. Nostr funciona sem blockchain ou moeda. Buzz Shared Compute também não é hoje um mercado aberto onde máquinas desconhecidas recebem satoshis por token. A capacidade é partilhada voluntariamente. Lightning pode vir a apoiar pagamentos ou quotas, mas ainda não resolve eletricidade, desgaste e operação.

Como funciona Shared Compute

Buzz Mesh associa a pertença à comunidade ao acesso ao pool. Um membro ativa a partilha, escolhe um modelo adequado ao hardware e oferece inferência aos restantes. Um agente seleciona «Buzz shared compute» como fornecedor sem chave API externa.

O relay coordena: sabe quem pertence à comunidade e que nó oferece um modelo. O pedido real viaja direta e cifradamente entre máquinas. O prompt não passa pelo servidor Buzz, mas sai do dispositivo do requerente e chega ao computador de outro membro.

A cifragem protege o caminho, não torna o endpoint cego. Usar hardware de terceiros exige confiança no operador. A visão Mesh é clara: a comunidade é tão privada quanto os seus membros são fiáveis.

Inferência remota não é inferência distribuída

No caso simples, o modelo completo corre numa workstation potente e os restantes enviam pedidos. Pela rede passam sobretudo prompts, tokens e overhead; o cálculo fica numa máquina.

No caso difícil, o modelo é repartido. Cada nó guarda alguns pesos ou executa parte do cálculo e troca continuamente resultados intermédios. Largura de banda, latência, topologia e falhas determinam diretamente a velocidade.

O Buzz descreve ambas as direções. O guia público mostra um caminho real da aplicação até inferência local ou remota. Dividir um modelo por vários dispositivos pertence à visão Mesh: objetivo plausível, ainda não uma plataforma de produção arbitrariamente escalável. Algumas funções continuam atrás de um feature flag.

O cluster Mac Studio mostra o problema da rede

NetworkChuck liga quatro Mac Studio com 512 GB de memória unificada cada, formando 2 TB acessíveis às GPUs. Mas a experiência anterior com cinco Macs tornou a inferência, segundo a sua comparação, 91% mais lenta.

O vídeo explica paralelismo pipeline e tensorial. No pipeline, cada Mac processa camadas e passa o resultado ao seguinte: cabe um modelo grande, mas os nós esperam. No tensorial, todos trabalham simultaneamente na mesma camada e trocam pequenas quantidades de dados com muita frequência. A latência torna-se decisiva.

NetworkChuck mostra uma queda de cerca de 300 para 3 microssegundos. Com Llama 70B, passa de cerca de 5 tokens por segundo em pipeline para 16 com paralelismo tensorial e RDMA. O cluster não fica cem vezes mais rápido: a latência da ligação cai aproximadamente por esse fator, enquanto o throughput do modelo pouco mais do que triplica.

Desde macOS 26.2, Macs Apple silicon com Thunderbolt 5 suportam RDMA over Thunderbolt. O RDMA move dados entre regiões de memória registadas com menos overhead; a Apple coordenou a função com MLX Distributed e JACCL.

A física mantém-se. A Apple recomenda uma topologia totalmente interligada: dois Macs precisam de uma ligação, três de três cabos, quatro de seis. A partir de cinco, um anel pode ser necessário devido às portas, obrigando a encaminhar dados por nós intermédios. A implementação atual também limita a dez UC Queue Pairs e operações send/receive bilaterais.

Uma comunidade pode oferecer pela Internet vários modelos completos em computadores diferentes. Dividir um único modelo entre Zurique, Berlim e Nova Iorque é outra classe: cada salto atrasa os tokens e um nó lento pode bloquear o pipeline.

A RAM não se soma automaticamente

Pesos, cache KV, dados de execução e reservas para contextos longos têm de caber algures. Dois membros com modelos em 64 GB têm dois nós, não uma máquina com 128 GB partilhados. Apenas verdadeiro sharding desloca o limite, à custa de comunicação, complexidade e falhas.

Em 2026, o mercado de DRAM continua difícil. A TrendForce descreve o terceiro trimestre como muito apertado, com a procura de servidores de IA a sustentar preços recorde. Shared Compute valoriza hardware existente, mas não torna baratas novas máquinas locais com muita RAM.

Partilhar três workstations já existentes pode fazer sentido. Comprá-las apenas para evitar cloud pode ser pior investimento. Eletricidade, refrigeração, peças, Internet, administração e risco de falha não desaparecem.

O que é realmente interessante

O Buzz não inventa uma nova técnica de inferência; liga componentes existentes. A comunidade já tem membros, identidades e permissões. Agentes e modelos locais já existem. O utilizador ativa a partilha e o agente usa-a como fornecedor normal. Infraestrutura torna-se uma definição do produto.

A zona de confiança também é razoável: pessoas que já colaboram em vez de milhões de desconhecidos. É realista para agências, pequenas empresas, investigação e grupos de desenvolvimento.

A independência de modelos ajuda. Pesos abertos permitem controlar pesos, configuração e runtime, mas «possuir o modelo» é uma abreviatura. Pesos abertos não significam domínio público; licenças podem limitar uso, distribuição ou exploração comercial. Soberania exige pesos disponíveis, licença compreendida, runtime controlável, dados exportáveis e operação sem o fornecedor original.

O que ainda não convence

Falta remuneração. Numa equipa pequena a partilha basta; quando uma pessoa fornece sempre energia e hardware a dez consumidores, são necessários limites, prioridades, métricas e contabilidade. Nostr e Lightning oferecem componentes, não uma economia pronta.

Falta também operação: quem atualiza e valida modelos e licenças, que nós podem ver prompts sensíveis e o que acontece com sobrecarga, suspensão, um portátil em viagem ou um computador que desaparece durante a resposta. A cloud cobra, mas assume muito deste trabalho.

O Buzz encaminha pedidos de modelo, não código arbitrário, uma fronteira sensata. Ainda assim, prompts podem ser confidenciais, modelos manipulados e agentes enviar contexto excessivo. Ser membro controla acesso, não comportamento. Empresas precisam de classificação, registos, quotas, aprovação de modelos, endpoints protegidos e regras para tarefas locais.

O Buzz é jovem. Código, arquitetura e teste concreto são mais do que slides, mas feature flags, lançamentos rápidos e documentação em mudança mostram um sistema em evolução. É adequado a experiências com dados não críticos, não a dependências sem plano de saída.

O que está realmente a ser implementado

O Buzz não implementa toda a smart grid anterior, mas a primeira camada mais sensata: uma célula voluntária e limitada sobre uma estrutura social de confiança.

Faltam mercado aberto, créditos estáveis, atestação de hardware, verificação independente e operação para milhares de nós desconhecidos. Em troca há uma interface compreensível e um caso imediato: um agente precisa de um modelo, um membro tem um computador, o relay coordena e as máquinas calculam.

Se o círculo pequeno funcionar, quotas, créditos, pagamentos Lightning, federação regional e tarefas verificáveis podem seguir. Primeiro, o círculo pequeno tem de calcular de forma fiável.

Base e limites deste artigo

Não testei pessoalmente o Buzz Mesh numa configuração com vários computadores. A análise baseia-se no código público, arquitetura, visão Mesh, guia de desenvolvimento, especificações Nostr e documentação RDMA da Apple, verificados em 21 de agosto de 2026. Estabilidade, throughput e carga real não são medições próprias.

O Buzz continua a ser o exemplo mais concreto de como a nossa ideia de computação distribuída pode tornar-se um produto utilizável. Ainda pequeno, inicial e sem economia resolvida, mas já não apenas teórico.

Até à próxima,
Joe