Buzz Mesh：当社区共同运行模型

Joe Goldberg • 2026年8月24日 • 2 min read

当时它主要还是一种架构设想。如今，Buzz 展示了第一个相当具体的实现组件。它把人类与 AI 代理的协作空间、Nostr 身份，以及社区内部的算力池结合起来。成员可以提供本地模型，让其他成员的代理调用。更远的愿景是，多台设备甚至可以分别承载同一个大型模型的一部分。

这与我们之前的想法非常接近。但不应夸大或贬低 Buzz：它不是全球 AI 超级计算机，闲置 RAM 也不会神奇地变成统一共享内存。Buzz 首先建立的是一个基于信任的小型单元。这也许才是更合理的起点。

Buzz 还没有把算力智能电网变成全球市场，但它第一次让这项能力成为真实工作空间中的一个开关。

Buzz 到底是什么

Buzz 是 Block 的开源项目。Block 由 Jack Dorsey 领导，也是 Square 背后的公司。不过，把 Buzz 简单称为“Jack Dorsey 的新应用”并不准确。它以 Block 项目的形式开发，公开源码以 Apache 2.0 许可证发布在 GitHub 上。

Buzz 看起来像 Slack、GitHub 与代理平台的结合体。人类和 AI 代理在相同频道中讨论任务、管理代码并触发工作流。每个代理拥有独立的加密身份和受限权限，因此可以区分是谁批准了操作，以及哪个代理实际执行了它。

这不仅是界面层面的用户管理。许多代理系统让机器人共用服务账号或权限过大的 API key。事后我们只知道“自动化”做了某件事，却未必知道具体实例及其授权来源。Buzz 试图分别呈现授权与执行身份。

工作空间可以自行托管。公开架构使用的都是熟悉组件：Buzz Relay、用于事件和搜索的 PostgreSQL、用于 Pub/Sub 与在线状态的 Redis，以及兼容 S3 的媒体存储。去中心化并不会因为隐藏运维现实而更可信。

Nostr 是基础

Nostr 是 Notes and Other Stuff Transmitted by Relays 的缩写。用户拥有一对加密密钥，签署事件并将其发布到 relay。客户端通过一个或多个 relay 订阅自己关心的事件。

Nostr 事件包含发送者的公开身份、时间戳、类型、内容、引用和签名。私钥由用户保存并负责签名，公钥用于身份与验证。Nostr 在 secp256k1 曲线上使用 Schnorr 签名，这条椭圆曲线同样是 Bitcoin 技术体系的核心。

签名日志，但不是区块链

Nostr 不是区块链。它没有挖矿、全球共识，也没有所有 relay 必须等待的单一链。relay 按自己的规则接受和保存事件，再将其提供给客户端。其他 relay 可以保存相同或不同的事件。

Buzz 用该模型承载消息、回应、代理任务、工作流步骤和 Git 事件。在一个 Buzz 社区中，relay 仍是工作空间的中心来源：它检查成员资格、分发事件并维护状态。协议提高了身份与数据格式的可迁移性，却不会自动消除运营者、数据库、备份、保留规则或故障风险。

签名可以证明某个密钥签署了事件，却不能保证 relay 永远提供历史事件。因此，自托管仍需要备份、导出、监控和妥善的密钥管理。丢失私钥并不像重置普通密码；私钥被盗则意味着攻击者可以用该身份生成有效签名。

与 Bitcoin 的关系

Nostr 在文化和技术上都与 Bitcoin 社区关系密切。NIP-57 定义了 Lightning Zaps，让客户端可以向个人或事件支付 satoshi，并把付款凭证表示为事件。

但 Bitcoin 并非 Nostr 的必要条件。Nostr 可以在没有区块链或代币的情况下工作。Buzz Shared Compute 目前也不是一个让陌生计算机按 token 自动赚取 satoshi 的开放市场。公开方案基于社区成员自愿共享容量。Lightning 未来可以支持结算或配额，却尚未解决电力、损耗与运维成本。

Buzz Shared Compute 如何工作

Buzz Mesh 把社区成员资格与算力池访问权绑定。成员启用共享，选择适合自己硬件的模型，并向其他成员提供推理。代理可以像选择普通模型供应商一样选择“Buzz shared compute”，无需保存外部 AI 服务的 API key。

relay 提供信任与协调层，知道谁属于社区、哪个节点提供什么模型。实际模型请求在参与机器之间直接加密传输。prompt 不经过 Buzz 服务器，但确实会离开请求者设备，抵达另一位成员的机器。

传输加密保护的是路径，并不会让终端看不见数据。使用他人的硬件进行推理，意味着必须信任其运营者。Buzz 的 Mesh 愿景对此非常坦率：社区隐私取决于成员是否值得信任。

远程推理不等于分布式推理

简单情况下，完整模型运行在一台强大的工作站上，其他设备向它发送请求。网络主要传输 prompt、生成的 token 和协议开销，实际计算集中在一台机器。

困难情况下，模型被拆分到多台计算机。每个节点只保存部分权重或执行部分计算，并在生成 token 时持续交换中间结果。带宽、延迟、拓扑与故障会直接决定速度。

Buzz 描述了两个方向。公开开发指南已经展示了从桌面应用和代理到本地或远程推理的真实路径。跨多台社区设备拆分一个模型仍属于 Mesh 愿景。它是合理目标，但不能当作已经成熟、可任意扩展的生产平台；部分功能仍需 feature flag。

Mac Studio 集群揭示网络瓶颈

NetworkChuck 将四台各有 512 GB Unified Memory 的 Mac Studio 连接起来，形成拥有 2 TB GPU 可访问内存的本地集群。但他此前使用五台 Mac 的实验表明，增加机器反而让推理在对比中慢了 91%。

视频解释了 pipeline parallelism 与 tensor parallelism。pipeline 让一台 Mac 处理自己的模型层，再把结果传给下一台；它能够容纳大型模型，但其他节点经常等待。tensor parallelism 让所有 Mac 同时处理同一层，却需要高频交换少量数据，因此延迟成为决定因素。

NetworkChuck 展示了延迟从约 300 微秒降到 3 微秒。Llama 70B 的输出从 pipeline 的约每秒 5 token 提高到 tensor parallelism 加 RDMA 的约每秒 16 token。需要准确描述：不是整个集群快了 100 倍，而是连接延迟大约降低了这一倍数，模型吞吐量则提高了三倍多。

从 macOS 26.2 开始，配备 Thunderbolt 5 的 Apple silicon Mac 支持 RDMA over Thunderbolt。RDMA 能以更低开销在注册内存区域之间移动数据；Apple 还与 MLX Distributed 和 JACCL 后端进行了适配。

更新解决了真实问题，却不能改变物理规律。Apple 为最低延迟建议全互联拓扑：两台 Mac 需要一条连接，三台需要三根线，四台需要六根。从五个节点起，端口限制可能迫使采用环形拓扑，此时数据必须经过中间节点。当前实现还有最多十个 UC Queue Pairs、仅支持双边 send/receive 等限制。

社区完全可以通过互联网在不同机器上提供多个完整模型并分配任务。把一个模型跨越苏黎世、柏林和纽约拆分则是另一类问题。每次网络跳转都会拖慢 token 生成，一个缓慢或掉线的节点可能阻塞整个 pipeline。

许多计算机构成算力池。只有高速互连，才能把它们变成服务于同一个模型的集群。

RAM 不能简单相加

模型权重、KV cache、运行数据以及长上下文或并发用户所需的余量都必须存放在某处。两个成员各自在 64 GB RAM 中运行模型，社区拥有的是两个推理节点，而不是一台具有 128 GB 共享内存的机器。只有真正的 model sharding 才能移动这条边界，代价是通信、复杂度和故障风险。

2026 年的 DRAM 市场仍然紧张。TrendForce 称第三季度供应持续吃紧，AI 服务器需求支撑创纪录价格。Shared Compute 能提高现有硬件的价值，却无法让大内存本地设备变便宜。

如果团队已经拥有三台工作站，共享它们很合理。仅为了避开云账单而购买三台昂贵设备，可能反而是更差的投资。电力、散热、零件、网络、管理和停机风险不会消失。

Buzz Mesh 真正吸引人的地方

它的优势不在于发明新的分布式推理方法，而在于连接已有组件。社区已经有成员、身份和权限；代理已经协作；模型已经可以本地运行。Buzz 让用户通过设置共享算力，让代理像调用普通供应商一样使用它。

信任范围也相对合理。Buzz 从本来就共同工作的人开始，而不是数百万陌生节点。对于机构、小企业、研究项目或开发团队，这比匿名全球 GPU 市场更现实。

模型独立性同样重要。开放权重模型的运营者可控制权重、配置和 runtime，但“拥有模型”只是简化说法。开放权重不等于 public domain，许可证可能限制使用、再分发或商业运营。真正的自主意味着权重可得、许可证被理解、runtime 可控、数据可导出，并能脱离原始供应商运行。

仍未令人信服的部分

首先是报酬。小团队可以自愿共享；如果一个人长期承担硬件和电费而十个人使用，就需要限制、优先级、指标与公平结算。Nostr 和 Lightning 提供了组件，但 Buzz 尚无完整经济模型。

其次是运维：谁更新并验证模型及许可证，哪些节点可以看到敏感 prompt，过载、睡眠、移动中的笔记本或回答中途掉线时怎么办。云服务收费，但也承担了许多枯燥工作。

Buzz 转发模型请求，而不是向每台工作站发送任意代码，这是合理边界。不过 prompt 可能保密、模型可能被篡改、代理可能发送过多上下文。成员资格是访问控制，不是行为保证。企业还需要数据分类、日志、配额、模型审批、终端加固，以及必须留在本地的任务规则。

最后，Buzz 仍很年轻。公开代码、架构和具体测试路径比幻灯片更真实，但 feature flag、快速发布和不断变化的文档说明系统仍在演进。适合用非关键数据实验，不适合在没有退出方案时承载核心流程。

实际实现了什么

Buzz 没有实现之前文章中的完整算力智能电网，但实现了最合理的第一层：建立在现有社会信任结构上的、有限且自愿的算力单元。

开放市场、稳定积分、硬件证明、独立结果验证和数千陌生节点的运营模式仍然缺失。但 Buzz 提供了许多去中心化项目没有的东西：容易理解的界面和直接用途。代理需要模型，成员拥有计算机，relay 负责协调，机器负责计算。

如果这个小圈子能够可靠运行，配额、积分、Lightning 支付、地区联邦或可验证任务可以随后加入。首先必须让小范围稳定工作。

本文依据与限制

我没有亲自在多机环境中测试 Buzz Mesh。技术判断基于公开源码、架构、Mesh 愿景、开发指南、Nostr 规范和 Apple 的 RDMA 文档，并于 2026 年 8 月 21 日核查。因此，关于稳定性、吞吐量和实际负载的陈述并非我的测量结果。

尽管如此，Buzz 仍是我目前见过的、最能说明分布式算力如何成为可用产品的例子。它还很小、很早，也没有解决经济问题，但已经不再只是理论。

下次见，
Joe

来源