本文内容
SwarmLLM 评测 2026：浏览器能否让手机与笔记本共同运行一个 27B LLM？
SwarmLLM 已经相当可信地证明，不同设备上的浏览器标签页可以共同执行同一个大型语言模型。 MacBook 可以承担大多数 Layer，iPhone 贡献一个较小的 Slice，WebGPU 在设备本地执行计算，WebRTC 在设备之间传递 Hidden State。参与者不需要安装 Python 环境或原生 Inference Daemon。
对技术买方来说，关键问题并不是 Demo 能不能跑，而是当延迟、Browser Support、Peer Trust、故障恢复和运维成本都进入现实后，这个架构是否仍然值得。我们当前的判断很明确：适合可信设备上的 Browser AI 实验，以及确实需要聚合内存容量的 Pilot，但还不应被视为成熟的生产推理基础设施。
公开的 SwarmLLM Repository 使用 MIT License，包含自研 WebGPU Engine 与 WebRTC Room Runtime。2026 年 9 月的主 Demo 展示了 Qwen 3.8 27B 在 MacBook 与 iPhone 之间协同运行。SwarmLLM 是 Nehanth Narendrula 的独立开源项目，不是 Wavect 产品。
SwarmLLM 到底做了什么？
SwarmLLM 在浏览器之间做 Pipeline Model Parallelism。它不会让每台设备都加载完整模型，而是把连续的 Transformer Layer 区间分配给不同设备。Host 保留 Tokenizer、Embedding、Final Norm、LM Head 与 Sampler。生成时，中间激活按模型顺序穿过所有设备，最后回到 Host 选择下一个 Token。
真正的价值首先是 Capacity Pooling。项目当前使用的 Qwen 3.8 27B Q4_0 权重大约 15 GB。手机无法独立运行完整 27B，但可以贡献少量 Layer，让更强的笔记本承担其余部分。
一个 Token 如何跨设备移动？
公开的 SwarmLLM Architecture 描述了 Qwen 3.8 的 5,120 维 Hidden State。打包为 f16 后大约 10 KB。每个 Peer 执行自己的 Layer 区间，再把更新后的 State 发给下一个设备，最后由 Host 执行 LM Head 与 Sampling。
Prompt -> Host Embed -> Laptop Layers -> Phone Layers -> Host LM Head -> Next Token
Prompt Prefill 可以 Batch，Autoregressive Decode 则需要重复往返。SwarmLLM 因此结合 Batched Prefill 与 Qwen 的 Multi-Token Prediction，让一次网络往返尽可能验证多个候选 Token。这里网络本身就是 Inference Engine 的一部分。
SwarmLLM、Mesh LLM、Browser AI 与传统 Self-hosting 的区别
Wavect 已经有一篇 Mesh LLM 评测，它负责更广泛的多电脑 Distributed Inference 搜索意图。本页刻意拥有更窄的主题：让手机、笔记本与 PC 通过浏览器直接组成 P2P LLM 推理链，几乎不需要安装。
| 方案 | 模型位置 | 主要取舍 |
|---|---|---|
| SwarmLLM | Layer Slice 分布在浏览器设备 | 加入门槛低，但 Browser 与 Network 成为 Runtime 依赖 |
| Mesh LLM | Layer Stage 分布在电脑 | Setup 更多，更适合稳定的私有多机 Mesh |
| WebLLM / Transformers.js | 完整模型放在单个浏览器 | 拓扑更简单，受单机内存限制 |
| Ollama / llama.cpp / vLLM | 原生本地或 Server Runtime | 需要安装，但运维边界更清晰 |
| Cloud API | Provider Infrastructure | 无需本地容量，但有 Provider 与 Data Path 取舍 |
如果问题是单设备 Browser AI，请看 Transformers.js Browser AI Guide。如果问题是本地模型与 API 的经济性，请看 Local Models vs APIs Break-even。
公开 Benchmark 真正证明了什么？
项目的 Benchmark Log 比 Launch Video 更有价值，因为它记录了 Hardware、Prompt、Transport 修改以及失败的 Scaling 结果。项目在 NVIDIA GB10 上报告约 9 tok/s Plain Decode，以及约 16 tok/s Speculative Decode。MacBook Pro 单机 Chrome 大约为 6.7 tok/s Plain 与 10.8 tok/s Speculative。
MacBook 加 iPhone 的数字需要分开理解。9 月 7 日 Demo Caption 写的是 10.7 tok/s，对应 400 Token 输出。但结构化 Performance Table 仍写着 7.7 tok/s，详细 Bench Log 也记录 9 月 4 日真实设备测试为 7.7 tok/s。因此，10.7 更适合作为较新的 Demo Evidence，而不是普遍 Baseline。
更重要的是，设备数量不会线性带来速度。三设备 Emulator 大约达到 10.4 tok/s，而十六设备拓扑即使在零网络延迟的本地环境，也下降到约 3.8 到 4.7 tok/s，因为每一个 Hop 都增加 Pack、Upload、Readback 与 Forwarding 开销。
SwarmLLM 首先解决容量聚合，速度提升取决于具体拓扑。 商业 Pilot 应该在自己的 Hardware、Browser、Network 与 Prompt 上重测。
安全边界：P2P 不等于对 Peer 保密
项目的 Security 文档非常直接。WebRTC Transport 本身加密，Signaling Broker 不承载模型流量。但中间 Activation 不是 Encryption。项目明确指出 Activation Inversion 研究能够从中间表示恢复文本，因此应假设 Room 中的参与者有能力获取 Prompt 信息。
目前也没有 Remote Compute Verification。恶意或故障 Peer 可以返回被修改的 Activation，而 Host 还无法证明那一段计算正确。生产使用的 Trust Model 应该是：只加入本来就愿意分享对话内容的人和设备，而不是匿名公共算力。
WebGPU 让 No-install 成立，也限制了覆盖面
SwarmLLM 依赖 WebGPU Support。MDN 目前仍把 WebGPU 标记为 Limited Availability，而不是 Baseline，正常 Web Deployment 还要求 Secure Context。SwarmLLM 当前主要测试 Chrome on macOS，iPhone Safari 可以承担小 Slice，Mac Safari 在 27B 大 Slice 下可能因内存压力重载，Firefox 与 Linux Chromium 的项目测试较少。
企业部署时，Managed Browser Policy、GPU Driver、Memory Pressure 与手机 Thermal Limit 都必须纳入 Compatibility Matrix。
WebRTC 解决了什么，又没有解决什么？
WebRTC Data Channel 可以在 Peer 之间传输任意 Binary Data，并通过 DTLS 保护 RTCDataChannel 流量。它非常适合传输 Hidden State，同时避免要求用户开放自定义 TCP Port。
但 WebRTC 不会消除 NAT、Relay、Packet Loss 或 Latency。生产设计仍需要 Signaling Policy、TURN 或 Relay Strategy、Observability，以及 Corporate Firewall 阻断直连时的处理方式。
2026 年 9 月的 SwarmLLM 有多成熟？
最清晰的答案来自 Multi-turn Context Roadmap。它记录了当前每次 Send 都会 Reset Model State，512 Token Context Limit 还没有安全强制执行，回答会在 400 Token 停止。真正的 Multi-turn History、更大的 Context、可见 Token Counter 与安全 Overflow Handling 都还在计划中。
Peer Recovery、Compute Auditing 与更多模型支持也仍是 Roadmap 项目。这些限制意味着 SwarmLLM 很适合 Research 与 Pilot，但还不适合作为客户关键生产依赖。
谁应该现在 Pilot？
| 场景 | 建议 | 原因 |
|---|---|---|
| Browser-native Local AI Research | Pilot | 架构透明，演示门槛很低 |
| 可信设备的实验室、教学或 Hackathon | Pilot | No-install Participation 是真实优势 |
| 模型略大于单机内存 | 比较 | Memory Pooling 可能有用，Native Split 可能更稳 |
| 敏感数据生产助手 | 等待或隔离 | Peer Trust 与 Recovery 控制仍不成熟 |
| 陌生人公共 Swarm | 暂不使用 | Activation 不对 Peer 保密，Compute 也未验证 |
14 天商业 Pilot
- 固定十个真实 Prompt 与目标输出长度。
- 记录每台设备的 RAM、GPU、OS、Browser Version 与 WebGPU 状态。
- 先做 Single-device Baseline，包括 Prefill、Decode、Memory 与 Thermal。
- 一次只增加一个 Peer，区分新增 Capacity 与新增 Hop。
- 比较同一 Wi-Fi、其他 Network 与 Cross-network Room。
- 主动关闭 Peer Tab、让手机 Sleep、切换 Network。
- 整个评估只使用非敏感 Prompt。
- 把 Browser Failure 与人工 Support Time 纳入 TCO。
- 设定 Kill Criterion：如果 Native Runtime 更快、更安全、更易维护，就选 Native。
Wavect 在哪里有价值？
Browser Inference 是技术选择，不是业务结果。Wavect 的 AI Enablement 覆盖 Workload Evaluation、Model Selection、Local vs API Architecture、Privacy Boundary、Device Compatibility、Observability、Fallback 与 Production Handover。Twinsoft AI Case Study 展示了更大的原则：真正有用的 AI 来自模型周围的系统。
如果吸引力来自降低 Cloud Inference Cost，请同时参考 欧洲 LLM Self-hosting 成本指南。现有闲置设备在计入 Engineering、Support 与 Failure 后并不是免费基础设施。
在真实硬件上测试 Browser Swarm Inference
需要比较 SwarmLLM、Native Distributed Inference 与传统 Local 或 Cloud Stack？Wavect 可以围绕真实 Workload 设计 Benchmark、安全边界与 Production Decision。
可选服务路径：
结论
SwarmLLM 是 2026 年最值得关注的 Browser-native Inference 项目之一，因为它把严肃的 WebGPU Engine 与真正低门槛的 WebRTC Room 组合在一起。 它公开的工程证据也明显强于单纯的 Viral Demo。
边界同样明确：Multi-turn 尚未完成，Context Handling 不成熟，Peer Loss 会带来问题，Remote Compute 未验证，而且 Activation 不应被视为对 Room Member 保密。
对于可信团队在已有硬件上探索 Local AI，它值得做 Controlled Pilot。对于生产环境，最终只需要回答一个问题：Browser-native Participation 是否解决了稳定 Native Runtime 或 API 无法解决的 Deployment Problem？ 如果没有，更简单的架构就是更好的架构。