LastBrowser 拟推出 VolksAI：本地模型共享池构想

LastBrowser 团队近日抛出一个名为 VolksAI 的构想：让拥有闲置算力的用户把本地模型共享出来，供硬件不足的用户调用。这不是一个已上线的功能，甚至连代码都还没写——用作者的话说，它只是一份"粗糙的草图"，用来测试社区对这个方向的反应。

VolksAI 共享本地模型构想来源页面

为什么会有这个想法

LastBrowser 是一款面向 Windows 和 Linux 的浏览器（Linux 版目前处于预览阶段），内置垂直标签、Spaces、终端，以及一个叫 Sidekick 的本地模型运行器。Sidekick 既可以跑本地模型，也可以通过用户自己的 API key 连接远程服务。

这里出现了一个错位：许多 Sidekick 用户手里有性能不错的机器，本地模型一天里大部分时间闲着；而另一批用户根本没有硬件跑得动一个好模型。两拨人之间存在明显的供需缺口，却没有任何渠道对接。VolksAI 打算做的事，就是建一个共享池，把闲置算力和算力需求撮合到一起。

构思的出发点很朴素——不是要做一个新产品，而是先问一个问题：这个形状对不对。

这里说的"本地模型"通常指参数量在数十亿以内、可以在一块消费级显卡或较新 CPU 上运行的开源权重模型。Ollama、llama.cpp、LM Studio 就是三类常见的本地推理运行时：llama.cpp 用 C/C++ 实现了带量化的推理，能在 CPU 和 GPU 上跑 GGUF 格式权重；Ollama 在它之上做了模型拉取和常驻服务；LM Studio 则提供图形界面下载、加载模型并暴露一个兼容 OpenAI 协议的本地端口。三者的共同点是模型权重存在用户自己磁盘上，推理请求经由一个本地 HTTP 端点发出，因此天然适合被"接入池子"这种模式复用——只要代理层把外部请求转发到对应的本地端点即可。

机制大致怎么运作

在设置里，用户可以从 Ollama、llama.cpp 或 LM Studio 中挑一个本地模型，点"加入池子"。一个中介服务（broker）负责把等待中的请求和空闲的主机配对，真正的计算发生在主机自己的机器上。这个 broker 可能跑在类似 Cloudflare 的基础设施上。

broker 被刻意设计得很"笨"。它不存储 prompt，也读不到 prompt 内容，只拿到足够路由的信息：某个信任等级的请求在等待、哪台主机空闲。它能看到元数据——信任等级、模型名、大致长度——但看不到 prompt 的副本。整个系统里有三种角色：

用户：发出请求，选择该请求允许的最高信任等级
主机：提供模型和计算时间
broker：连接两端，但不接触内容

有一点作者特意说得很直白，因为容易被含糊带过：payload 在用户和主机之间是加密传输的，broker 只做转发；但主机能看到 prompt，因为模型必须读到它才能回答。加密保护的是传输链路，不是 GPU。任何把这种池子描述成"完全私密"的说法都是不诚实的。

四级信任模型

不是每个请求都需要同等程度的暴露。构思里把信任分成四档：

你自己的设备——只限于同一账号下的机器
朋友和团队——通过邀请加入，没有公开入口
已验证主机——LastBrowser 对主机做过检查（具体怎么检查，文中明确说"是以后的问题，这里不定义"）
公共池——任何选择加入该等级的主机

此外还有一个单独的私有组织池：学校、大学、公司可以在自己的机器上跑一个封闭池，通过自己的 API 地址或端点访问，prompt 完全不离开内网。管理员控制谁能加入，也可以选择把这个池接入更广的 LastBrowser 池，或者保持完全封闭。它不是第五个公共等级，而是组织自有的、独立于四级之外的池子。

请求只能落在用户已允许的等级上。敏感内容——凭据、私人文档、标记为机密的 Space 上下文——永远不会走第四级。发送前，界面会用直白的语言提示：主机能看到 prompt，broker 看不到。这句话会被显示出来，而不是埋在政策页里。

信任等级之外还涉及"端到端加密"与"端到端隐私"的区别，这是理解整套设计的关键。所谓传输加密通常指 TLS：数据在网络链路上是密文，中转节点无法中途窥探；但请求到达真正执行推理的主机后必须被解密成明文，模型才能读取。因此系统能承诺的是"broker 看不到 prompt"，而不能承诺"没人看得到 prompt"。要对主机也保密，需要的是可信执行环境（如基于 TEE 的机密计算）或全同态加密这类技术，两者在消费级 GPU 上都不具备可用性，这也是作者拒绝把方案称为完全私密的原因。

积分与贡献平衡

共享算力可以赚积分。考虑到不是每个人都有 GPU，没有显卡的用户可以贡献 CPU 工作来替代：跑测试、基准或 embedding。另一种方案是提供免费额度加等待队列。

无论哪种方式，积分都只是 LastBrowser 内部的记账值——不是现金，也没有提现的权利。这一点作者说得很清楚，避免用户产生误解。

滥用、质量与责任

一个谁都能提供模型的池子，天然会吸引人提供廉价甚至空壳模型。构思里包含了抽查机制：这台主机真的在提供它声称的模型吗，还是只返回空白或无关答案？速率限制会约束每台主机的请求量和共享任务量。反复抽查失败的主机会被降级，直到有人来查看。具体阈值同样没有设定。

责任归属上，作者给出的诚实立场是：主机对其机器上接收到的内容和产出的内容负责。LastBrowser 只负责撮合和等级规则，不负责模型的计算。公共池的主机不是 LastBrowser 的员工。具体合同措辞属于后续法律审查的范围。

和现有方案的区别

因为类似的东西已经存在，作者特意做了区分：

AI Horde 把图像和文本任务分发给志愿者，用积分账户结算贡献，工作者能看到任务内容。
Petals 把一个大模型拆成多层，分散到多台志愿者机器上。
Exo 主要是把你自己的设备打包成一个本地集群。
NVIDIA PAIR（Personal AI Router）在网络内显式配对的设备上连接 Ollama、llama.cpp 和 LM Studio，一个请求完整地跑在一台设备上，配对是双向的，设备间流量加密。公共池和积分系统不是它的模式。

LastBrowser 的池子想从 PAIR 那里借"一个本地模型、一个完整请求、一台选定主机"的思路，从 Horde 那里借自愿参与和积分账户，但不会像 Petals 那样把一个模型拆到多个陌生人身上。

如果将来真的要做，这个池子可以作为 Sidekick 自动路由器后端的一个 provider，但只有在请求的信任等级允许时路由器才能选它。敏感请求始终留在你自己的设备或团队内。

文中提到的几个方案代表了分布式 AI 计算的不同技术路线。Petals 属于模型并行式共享：把一个大模型按层切分，不同志愿者各持一部分，一次推理要串起多台机器，任何一层掉线都会中断，因此通常只能跑同构、通信良好的节点，隐私上每台机器只看到中间激活值而非完整 prompt。AI Horde 属于任务级众包：整项任务派给单个志愿者，志愿者能看到全部输入输出，靠积分激励志愿者持续贡献。Exo 则依赖用户自有的多台设备（如笔记本、手机、台式机）组成局域网集群，不涉及陌生人算力。VolksAI 的选择是任务级众包加单机完整推理，兼顾了实现简单和延迟可控，代价是主机必然接触明文 prompt。

作者想听到的反馈

文章结尾列出了一组问题，态度相当开放：

隐私："主机看到你的 prompt，broker 看不到"——这个取舍你能接受吗，还是任何远程计算都不可接受？
公平性：共享算力换积分看起来公平吗，CPU 工作路径会不会只是让没有 GPU 的人"感觉被包含"却没有实际收益？
滥用：什么能阻止池子被提供垃圾模型的主机填满，该由谁来 policing？
你会用吗：作为主机、作为用户、两者都是，还是都不是——"都不是"也是有价值的回答。
组织场景：你的学校、大学或团队会用这种私有池吗？管理员需要什么才会信任它？

作者最后重申：这只是一个想法，不在应用中，不属于任何当前发布计划，不构成承诺或时间表。讨论本身就是重点。

对于关注本地 AI 部署和边缘算力共享的开发者来说，这个构想提出的信任分级和"host 可见 prompt"的诚实披露，值得比很多同类方案更仔细地看待。