Buzz Mesh: cuando la comunidad ejecuta el modelo

Hace unas semanas escribí sobre la capacidad informática sin usar que nos rodea. La idea era una especie de red eléctrica inteligente para cómputo: personas, equipos o comunidades regionales ofrecen voluntariamente su capacidad libre, otros la utilizan y no todas las consultas de IA terminan automáticamente en los centros de datos de los mismos grandes proveedores.

Entonces era sobre todo una idea de arquitectura. Buzz muestra ahora cómo podría ser un primer componente sorprendentemente concreto. El proyecto combina un espacio de trabajo para personas y agentes de IA con identidades Nostr y un fondo de cómputo dentro de la comunidad. Un miembro ofrece un modelo local y los agentes de los demás lo utilizan. En una visión más ambiciosa, varios dispositivos incluso podrían alojar partes de un modelo que no cabe en ninguno por separado.

Se parece mucho a nuestra idea anterior. Pero no conviene presentar Buzz como menos ni como más de lo que es. No estamos ante un superordenador mundial de IA, y la RAM libre no se convierte por arte de magia en memoria compartida. Buzz empieza creando una célula basada en la confianza. Quizá sea el comienzo más razonable.

Qué es realmente Buzz

Buzz es un proyecto de código abierto de Block, la empresa dirigida por Jack Dorsey y responsable de Square. Aun así, sería impreciso llamarlo simplemente «la nueva aplicación de Jack Dorsey». Se desarrolla como proyecto de Block y su código público está disponible en GitHub con licencia Apache 2.0.

A primera vista parece una mezcla de Slack, GitHub y una plataforma de agentes. Personas y agentes de IA trabajan en los mismos canales, debaten tareas, gestionan código y activan flujos de trabajo. Cada agente recibe una identidad criptográfica propia y permisos delimitados. Así se distingue qué persona autorizó una acción y qué agente la ejecutó.

No es un detalle cosmético. Muchos sistemas actuales utilizan una cuenta de servicio común o una clave API con demasiados permisos. Después sabemos que «la automatización» hizo algo, pero no siempre qué instancia actuó ni con qué encargo. Buzz quiere mostrar por separado autorización y autoría.

El espacio puede autogestionarse. La arquitectura publicada usa componentes conocidos: Buzz Relay, PostgreSQL para eventos y búsqueda, Redis para Pub/Sub y presencia, y almacenamiento compatible con S3 para medios. Esa sobriedad me gusta. Ocultar la realidad operativa no hace más creíble la descentralización.

Nostr es la base

Nostr significa Notes and Other Stuff Transmitted by Relays. No nació específicamente para Buzz. Su principio es sencillo: los usuarios poseen un par de claves criptográficas, firman eventos y los publican en relays. Los clientes se suscriben, a través de uno o varios relays, a los eventos que les interesan.

Un evento Nostr contiene la identidad pública del remitente, una marca temporal, un tipo, contenido, referencias y una firma. La clave privada permanece con el usuario; la pública sirve como identidad y para verificar. Nostr utiliza firmas Schnorr sobre secp256k1, la misma curva elíptica que ocupa un lugar central en Bitcoin.

Un registro firmado, pero no una blockchain

Nostr no es una blockchain. No hay minería, consenso global ni una única cadena que todos los relays deban esperar. Cada relay acepta eventos, los conserva según sus reglas y los entrega a los clientes. Otros relays pueden guardar los mismos eventos u otros distintos.

Buzz emplea este modelo para mensajes, reacciones, encargos de agentes, pasos de flujos y eventos Git. Dentro de una comunidad, el relay sigue siendo la fuente central del espacio: comprueba la membresía, distribuye eventos y mantiene el estado. El protocolo hace más portables las identidades y los formatos, pero no elimina al operador, la base de datos, las copias de seguridad, las reglas de conservación ni la posibilidad de una caída.

Las firmas prueban qué clave firmó un evento, no que un relay vaya a entregarlo para siempre. Quien aloje Buzz necesita copias, exportaciones, monitorización y una buena gestión de claves. Una clave privada perdida no es una contraseña que un administrador pueda restablecer. Una clave robada permite al atacante firmar válidamente con esa identidad.

Qué tiene que ver Bitcoin

Nostr está cultural y técnicamente próximo a Bitcoin. Además de compartir la curva de firma, NIP-57 define los Lightning Zaps, con los que un cliente puede iniciar pagos en satoshis a personas o eventos y representar los recibos como eventos.

Eso no obliga a toda aplicación Nostr a usar Bitcoin. Nostr funciona sin blockchain ni moneda. Buzz Shared Compute tampoco es hoy un mercado abierto donde ordenadores desconocidos cobran automáticamente satoshis por token. La propuesta publicada se basa en compartir voluntariamente capacidad dentro de una comunidad. Lightning podría servir más adelante para pagos o cuotas, pero todavía no resuelve la economía de electricidad, desgaste y operación.

Cómo funciona Shared Compute en Buzz

Buzz Mesh vincula la pertenencia a la comunidad con el acceso al fondo de cómputo. Un miembro activa el uso compartido, elige un modelo adecuado para su hardware y ofrece inferencia a los demás. Un agente puede seleccionar «Buzz shared compute» como proveedor sin guardar una clave API de un servicio externo.

El relay aporta confianza y coordinación: conoce a los miembros y qué nodo ofrece cada modelo. La petición real viaja de forma directa y cifrada entre las máquinas. El prompt no debería pasar por el servidor Buzz, pero sí abandona el dispositivo del solicitante y llega al ordenador de otro miembro.

Ese detalle es esencial para la seguridad. El cifrado de transporte protege el trayecto, no vuelve ciego al destino. Quien use hardware ajeno para inferencia debe confiar en su operador. La visión Mesh lo expresa con claridad: la comunidad solo es tan privada como fiables sean sus miembros.

Inferencia remota no significa inferencia distribuida

«Shared Compute» puede describir dos sistemas muy diferentes. En el caso sencillo, el modelo completo funciona en una estación potente y los demás dispositivos le envían solicitudes. Es inferencia remota comunitaria. La red transporta principalmente prompts, tokens y sobrecarga del protocolo; el modelo calcula en una sola máquina.

En el caso difícil, el modelo se reparte entre varios ordenadores. Cada nodo guarda parte de los pesos o de la operación y, al generar tokens, intercambia continuamente resultados intermedios. La conexión cliente-servidor se convierte en un sistema distribuido estrechamente acoplado. Ancho de banda, latencia, topología y fallos determinan directamente la velocidad.

Buzz contempla ambas direcciones. La guía pública muestra un camino real desde la aplicación y el agente hasta inferencia local o remota. Dividir un modelo entre varios equipos pertenece a la visión Mesh. Es un objetivo plausible, no una plataforma madura de escala ilimitada; parte de la interfaz todavía se activa mediante una opción experimental.

El clúster de Mac Studio muestra el problema de red

NetworkChuck ofrece un ejemplo claro. Conecta cuatro Mac Studio con 512 GB de memoria unificada cada uno, un clúster local con 2 TB accesibles para la GPU. Pero su intento anterior con cinco Mac mostró el límite: añadir equipos hizo la inferencia un 91 % más lenta según su comparación.

El vídeo explica la diferencia entre paralelismo de pipeline y de tensores. En el pipeline, un Mac procesa sus capas y pasa el resultado al siguiente. Permite alojar un modelo grande, pero los demás nodos esperan repetidamente. En el paralelismo tensorial, todos trabajan a la vez en la misma capa y deben intercambiar pequeñas cantidades de datos con enorme frecuencia. Ahí la latencia es decisiva.

NetworkChuck reduce la latencia aproximada de 300 a 3 microsegundos. Con Llama 70B, el rendimiento sube de unos 5 tokens por segundo mediante pipeline a unos 16 con paralelismo tensorial y RDMA. Es un gran resultado, pero no significa que todo el clúster sea cien veces más rápido. La latencia de conexión cae aproximadamente por ese factor; el rendimiento del modelo mejora algo más de tres veces.

IP normal sobre Thunderbolt genera más latencia y carga de CPU. Desde macOS 26.2, los Mac con Apple silicon y Thunderbolt 5 admiten RDMA over Thunderbolt. RDMA mueve datos entre regiones de memoria registradas con mucho menos coste. Apple coordinó esta función con MLX Distributed y el backend JACCL.

La actualización resuelve un problema real, no la física. Apple recomienda una topología completamente mallada para minimizar la latencia: dos Mac necesitan una conexión, tres necesitan tres cables y cuatro necesitan seis. Con cinco nodos puede resultar práctico un anillo por la falta de puertos, pero entonces hay que reenviar datos por nodos intermedios. La implementación actual también limita a diez UC Queue Pairs y operaciones send/receive de dos lados.

Para Buzz, varios modelos completos en distintos equipos y una asignación inteligente de trabajos son viables por internet. Extender un solo modelo entre Zúrich, Berlín y Nueva York es otra categoría. Cada salto retrasa los tokens y un nodo lento o ausente puede frenar todo el pipeline.

La RAM no se suma sin más

En modelos locales, la memoria suele limitar más que la potencia bruta. Los pesos, la caché KV, los datos de ejecución y la reserva para contextos largos o usuarios simultáneos deben caber en algún sitio.

Dos miembros con modelos en 64 GB de RAM crean dos nodos de inferencia, no una máquina con 128 GB compartidos. Solo un verdadero sharding desplaza esa frontera, pagando con comunicación, complejidad y más fallos.

En 2026 esto coincide con un mercado difícil. TrendForce describe un tercer trimestre con DRAM muy escasa. La demanda de servidores de IA sostiene precios récord, mientras fabricantes de PC y móviles alcanzan sus límites. Shared Compute hace más útil el hardware existente, pero no abarata nuevos equipos locales con mucha RAM.

Si un grupo ya posee tres estaciones, compartirlas puede tener mucho sentido. Comprar tres equipos caros solo para evitar la nube puede ser peor inversión. Electricidad, refrigeración, repuestos, internet, administración y riesgo de caída no desaparecen porque no figure un hyperscaler en la factura.

Qué tiene de bueno Buzz Mesh

Su punto fuerte no es haber inventado la inferencia distribuida, sino conectar piezas existentes. La comunidad ya tiene miembros, identidades y permisos. Los agentes ya trabajan juntos. Los modelos ya pueden ejecutarse localmente. Buzz une esas capas: el usuario comparte capacidad y el agente la usa como un proveedor normal. Un proyecto de infraestructura se convierte en una opción de producto.

La zona de confianza también tiene un tamaño razonable. Buzz empieza con personas que ya colaboran, no con millones de desconocidos. Para una agencia, una pyme, un proyecto científico o un grupo de desarrollo es más realista que un bazar mundial anónimo de GPU.

La independencia del modelo ayuda. Quien opera modelos locales de pesos abiertos controla pesos, configuración y runtime. Pero «poseer el modelo» es una abreviatura: pesos abiertos no significa dominio público. Las licencias pueden limitar uso, distribución o explotación comercial. Soberanía real implica disponer de los pesos, comprender la licencia, controlar la ejecución, exportar datos y poder operar sin el proveedor original.

Lo que aún no convence

Primero falta una remuneración clara. En un equipo pequeño basta compartir; si una persona paga siempre electricidad y hardware para diez consumidores, hacen falta límites, prioridades, métricas y contabilidad justa. Nostr y Lightning ofrecen piezas, pero Buzz no un modelo económico acabado.

También falta resolver la operación: quién actualiza y verifica modelos y licencias, qué nodos pueden ver prompts sensibles y qué ocurre con sobrecarga, reposo, un portátil en movimiento o un equipo que desaparece a mitad de respuesta. La nube cobra, pero asume gran parte de ese trabajo aburrido.

En seguridad, Buzz reenvía peticiones de modelo, no código extraño arbitrario. Es un límite sensato, aunque los prompts pueden ser confidenciales, los modelos manipulados y los agentes enviar demasiado contexto. La membresía controla acceso, no garantiza buen comportamiento. Las empresas necesitan clasificación, registros, cuotas, aprobación de modelos, endpoints reforzados y reglas para trabajos que deben seguir locales.

Por último, Buzz es joven. Código público, arquitectura y una ruta concreta de prueba son más que una presentación, pero las opciones experimentales, las versiones rápidas y la documentación cambiante muestran un sistema en movimiento. Es buen momento para experimentar con datos no críticos, no para depender de él sin plan de salida.

Qué se está implementando realmente

Buzz no materializa toda la red inteligente de cómputo del artículo anterior, pero sí su primera capa más sensata: una célula limitada y voluntaria apoyada en una estructura social de confianza existente.

Faltan un mercado abierto, créditos estables, atestación de hardware, verificación independiente y operación para miles de nodos desconocidos. A cambio hay algo que muchos proyectos descentralizados no tienen: una interfaz comprensible y un caso inmediato. Un agente necesita un modelo, un miembro posee un ordenador, ambos pertenecen a la comunidad, el relay coordina y las máquinas calculan.

Buzz empieza con un problema cotidiano en vez de construir primero una economía mundial. Si el círculo pequeño funciona de forma fiable, después pueden llegar cuotas, créditos, pagos Lightning, federación regional o trabajos verificables. Primero debe calcular bien; luego vale la pena ampliarlo.

Base y límites de este artículo

No probé personalmente Buzz Mesh en una configuración con varios ordenadores. El análisis se basa en el código público, la arquitectura, la visión Mesh, la guía de desarrollo, las especificaciones Nostr y la documentación RDMA de Apple, revisados el 21 de agosto de 2026. Las afirmaciones sobre estabilidad, rendimiento y carga real no son mediciones propias.

Aun así, Buzz es el ejemplo más tangible que he visto de cómo nuestra idea de cómputo distribuido puede convertirse en un producto utilizable. Todavía pequeño, temprano y sin economía resuelta, pero ya no solo teórico.

Hasta la próxima,
Joe