Buzz共享算力实测：让AI Agent免费跑在社区闲置电脑上

借用社区闲置算力：一个颠覆性的AI运行方式

每次运行AI Agent都要面对OpenAI或Anthropic的账单，这几乎是所有开发者的共同痛点。而本文展示了一种截然不同的路径：让你的AI Agent运行在同一社区成员的闲置电脑上——没有API密钥，没有账单，甚至连干活的硬件都不是你自己的。

整个思路可以一句话概括：同一个社区里的人互相借用那些落灰的闲置电脑。这个功能在Buzz应用里被称为共享算力（Shared Compute），底层依托的是一个名为MeshLM的开源项目。

MeshLM是一个专注于分布式大语言模型推理的开源框架，其设计思想源自分布式计算的经典范式。在此之前，业界已有Petals等项目允许用户通过互联网协作运行大模型，但MeshLM的独特之处在于它专注于局域网和可信社区场景，通过点对点加密通信传输推理请求，而非暴露在公开互联网上。其底层采用流水线并行（Pipeline Parallelism）策略，将模型的不同层分配到不同设备上协同完成推理任务。

Block（原Square）将MeshLM集成进了Buzz并发布了相关博客。Block由Twitter联合创始人Jack Dorsey创立，在去中心化技术领域有着深厚布局——旗下有专注比特币开源开发的Spiral团队、去中心化身份项目TBD，以及硬件钱包Bitkey。将共享算力集成进Buzz，与Block一贯减少中心化云服务依赖、让社区掌握自己基础设施的理念一脉相承。但Block的博客文章里连一条命令都没有，所以完整的实操配置才是本文的核心价值。

Buzz共享算力能实现的三种能力

这套机制实际上能实现三种不同的能力，其中第一种是普通用户最可能真正用到的：

社区共享单模型

社区里有人在本地运行了一个AI模型，那么整个社区的成员都可以调用它。这是最直接、最实用的场景——你不需要拥有强大的硬件，只要有信任的社区成员愿意共享。

Multi-Agent Blend多智能体混合

把同一个问题同时发给多个模型，再将它们的答案整合起来。这本质上是一种集体智慧的做法，能够综合多个模型的判断以提升回答质量。这种方法在学术界被称为"模型集成"（Model Ensemble），其理论基础是：不同模型在不同类型的问题上各有所长，将多个模型的输出进行聚合（如投票、加权平均或由另一个模型综合），往往能产生比任何单一模型更可靠的结果。在传统集成学习中，这通常需要同一台服务器上运行多个模型；而在分布式共享算力场景下，不同社区成员运行不同模型，天然形成了一个异构集成。

分布式拆层运行超大模型

最疯狂的一种：当模型太大、任何单台机器都跑不动时，可以用多台16GB内存的Mac mini把模型的各层拆开分布到不同机器上运行。

这种方法的技术原理基于现代大语言模型的Transformer架构。一个LLM由数十到上百个Transformer Block堆叠而成，每个Block包含自注意力机制和前馈网络。分层运行的本质是：第一台设备处理前N层后，将中间的隐藏状态（一个浮点数矩阵）传输给第二台设备继续处理后续层，依此类推直到最后一层输出Token概率分布。对于一个1万亿参数的模型，仅权重在FP16精度下就需约2TB存储空间，远超任何单台消费级设备的容量。但如果拆分到60-70台设备上，每台只需承载一小部分层的权重。

据介绍，开发团队用这个方法甚至测试过高达1万亿参数的模型。这意味着一群消费级设备联合起来，理论上能撑起过去只有数据中心才能负载的模型。当然，设备间传输中间状态的网络延迟是主要瓶颈，因此这种方案更适合对延迟不敏感的批处理任务，而非实时对话。

隐私架构：你的提示词到底去了哪里？

这是最容易引发隐私担忧的问题，也是理解整套架构的关键。

Buzz设有一个中转站（Relay），即你所在社区的服务器。但要澄清一个常见误解：中转站的作用类似电话簿——它只负责记录谁在共享、谁是成员、哪些模型在线可用，仅此一件事。

你的提示词不会经过中转服务器，而是通过加密的点对点连接直接传输到目标机器，答案也会直接传回给你。这种点对点连接很可能基于WebRTC或类似的NAT穿透协议实现。在传统的客户端-服务器架构中，所有数据经过中心服务器转发，运营方可以查看通信内容。而P2P连接让两台设备直接建立加密通道，中转站仅在初始连接建立阶段发挥"牵线搭桥"的作用——告诉双方对方的网络地址后便退出数据传输链路。加密层通常采用DTLS等协议，确保网络中间节点即使截获数据包也无法解密。这种设计从架构上根本性地消除了中心服务器的隐私风险。

使用前必须理解的信任前提

必须强调一点：接听你请求的那台机器的主人，理论上能读到你发送的内容。这不是漏洞，而是这套机制的运作方式。原因在于：数据最终需要在接收端解密才能被模型处理（模型无法对加密的密文进行推理），因此运行模型的设备主人确实能够访问明文内容。虽然同态加密（Homomorphic Encryption）等技术理论上可以在密文上直接计算，但其计算开销目前仍高出明文推理数个数量级，远未达到实用阶段。

开发工程师用了一个很贴切的比喻：这就像邻居之间共享电动工具，归根结底是一个信任问题。也正因如此，Buzz把共享范围严格限制在你的社区成员身份上——只有你社区的成员才能接入你的Mesh网络，而不是整个互联网。

完整配置教程：从零开启共享算力

配置过程简单到令人意外。核心路径是：设置 → 计算（Compute）→ 共享计算（Share Compute），然后启用开关即可。

Buzz会根据你的硬件自动挑选合适的模型：

• 64GB或更大内存：推荐Gemma系列260亿参数模型，占用磁盘约17GB
• 较小容量：推荐更小的模型（如2B级别）
• 完全不匹配：不推荐任何模型

这里提到的Gemma是Google DeepMind发布的开源大语言模型系列，名称源自拉丁语"宝石"。Gemma系列包含2B、7B、9B、27B等多个规模版本，均基于与Google旗舰模型Gemini相同的研究技术构建，采用仅解码器的Transformer架构，支持GGUF等多种量化格式。17GB的磁盘占用对应的是4-bit量化版本——通过将模型权重从FP16（每个参数占2字节）压缩为INT4（每个参数占0.5字节），在牺牲少量精度的前提下将存储和内存需求降低约75%。Buzz推荐Gemma可能是因为其在同参数量级中具有较好的性能-效率平衡，且开源许可证允许社区共享用途。

你可能没注意到，即便你的机器无法贡献算力（不匹配任何模型），你依然可以使用其他人的算力，只是无法反向贡献。启用后，系统会自动下载对应模型（实测在Apple M1 Max、24GB内存的机器上下载了小型Gemma模型），且只需下载一次。

关键一步：把Agent指向共享模型

仅仅共享模型本身不会做任何事，你必须创建一个Agent并将其指向共享算力：

1. 进入侧边栏的Agents，创建一个新Agent
2. Agent指令可以留空
3. 在自定义AI配置中，智能体框架选择Buzz Agent（以使用社区计算资源）
4. LLM提供商选择Buzz Shared Compute

整个流程不需要任何API密钥，用的完全是社区共享的计算资源。创建完成后，把这个Agent加入频道成员列表，向它提问即可得到由他人机器生成的、完全免费的回答。

多机联动实测：把工作室变成小型AI集群

实测者在自己的工作室里同时运行了三台机器共享算力：

• MacBook Pro：打开共享开关贡献算力
• 原版Mac Studio：运行MeshLM并共享
• Mac Studio M3 Ultra（256GB内存）：能跑更大的模型，甚至加入了比单机所能承载更大的分布式任务

这些Mac设备之所以特别适合本地AI推理，核心原因在于Apple Silicon的统一内存架构（Unified Memory Architecture, UMA）。传统PC架构中CPU和GPU拥有各自独立的内存，运行AI模型时数据需要在系统内存和显存之间搬运，且消费级显卡显存通常上限24GB。而Apple Silicon将CPU、GPU、神经引擎共享同一块高带宽内存池——M1 Max最高64GB、M2 Ultra支持192GB、M3/M4 Ultra支持高达512GB统一内存。这意味着消费级Mac也能将大模型全部权重加载到GPU可直接访问的内存中进行推理，无需昂贵的专业GPU。文中256GB的Mac Studio M3 Ultra理论上可以单机运行超过100B参数的4-bit量化模型。

随着成员加入，社区的可用算力数字不断上涨。想象一下四个成员在不同的房子里同时开启共享——这就构成了一个真正意义上的去中心化本地AI集群。

即将上线：可视化的算力网络界面

目前有一个正在开发的Pull Request，将重新设计整个功能界面。新界面会出现在侧边栏（收件箱和Agents下方），通过彩色圆点直观展示网络状态：

• 绿色：你正在共享算力
• 蓝色：你正在使用别人的算力
• 橙色：正在建立连接
• 灰色小点：社区成员但尚未开启共享

更巧妙的设计细节是：圆点大小代表被借用机器的内存规模，节点离你越近（本地网络）响应越快，世界另一端的成员则位于外环。这种设计暗示了一个重要的物理事实：P2P连接的延迟与物理距离高度相关，局域网内的设备间延迟可低至毫秒级，而跨洲际连接可能达到数百毫秒，对于需要逐Token生成的LLM推理来说，这种延迟差异会显著影响用户体验。

而且界面上没有任何数据包动画在连线上滑动——因为软件本身也不知道每个请求究竟发往哪台机器，与其做一个假动画，团队选择什么都不动。这被认为是一处精巧的工程诚实。

三个必须避开的坑

在兴奋之余，有三点必须提前知晓：

共享功能目前仅限Mac

贡献算力（接入自己设备）的功能仅支持Mac，Windows和Linux用户暂时无法共享自己的设备——但仍可使用社区算力。这一限制可能与Apple Silicon统一内存架构带来的推理优势有关：在同等价位下，Mac设备能提供远超传统PC的可用"显存"容量，使得本地运行大模型变得切实可行。此外，macOS上的Core ML和Metal Performance Shaders等框架也为本地推理提供了高度优化的底层支持。团队发布节奏很快，使用前应先检查自己的版本。

注意未修复的启动Bug

共享开关有时会永远卡在"正在启动"状态，且应用不会给出任何错误提示。如果卡住超过10分钟以上，那就是这个Bug，不是你的操作问题。

模型选择：别贪大，用推荐的就好

实测者一开始自作聪明地选了机器能勉强装下的最大模型，但Buzz官方代码并不建议这么做。直接采用系统推荐的模型即可。原因在于：推荐的模型是直接回答型的，而推理/思考型（reasoning）模型会在后台消耗大量Token、让Agent响应变得迟钝。

这里涉及到一个重要的模型类型区分。"直接回答型"模型（如标准的Gemma、Llama）收到问题后直接生成答案；而"推理型"模型（如DeepSeek-R1、QwQ等）会先进行长链条的内部思考（Chain-of-Thought），生成大量中间推理Token后才给出最终答案。在本地推理场景中，每个Token的生成速度受限于设备算力，推理型模型可能在"思考"阶段就消耗数百甚至数千个Token，导致用户等待时间成倍增加。在共享算力场景中，快速回答比慢慢思考更重要——因为你占用的是别人的设备资源，长时间推理不仅让自己等待更久，也会阻塞其他社区成员的请求。

总结：一个开关背后的去中心化AI实验

Buzz Shared Compute的核心可以浓缩为几句话：它只是一个开关；它会为你自动挑选模型；它只允许你社区的成员加入；你的提示词点对点传输、不经过中继服务器；但回答你的那台机器能读到你的内容——所以，请只和你信任的人共享。

这套方案真正的意义，不在于省下几美元的API费用，而在于它提供了一种社区化、去中心化的AI基础设施范式：那些楼梯下的服务器、落灰的游戏PC、抽屉里的旧Mac，都可能重新成为集群的一部分。当信任成为前提、闲置算力被激活，个人和小社区也能拥有过去只属于大厂的推理能力。

从更宏观的视角来看，这代表了AI基础设施的一种可能演化方向：与当前高度集中于少数云服务商的推理市场形成互补。正如互联网早期从中心化的大型机时代走向分布式的个人电脑网络，AI推理能力也可能经历从集中式数据中心向边缘设备网络的部分回流。Buzz Shared Compute虽然还处于早期阶段，但它验证了这条路径的技术可行性——剩下的，是社区信任和网络效应能否真正规模化。

核心要点