Mesh LLM 评测：一个大模型能否跨多台电脑运行？

可以。若单台机器内存不足，Mesh LLM 能把受支持的大语言模型分布到多台电脑共同执行。Skippy runtime 为不同 peer 分配连续的模型层。每台机器只下载自己 stage 所需的 GGUF 分片，每生成一个 token，activation 都会依次经过这些 stage。应用仍然只调用 http://localhost:9337/v1 这一套 OpenAI-compatible API。

采购判断还需要一句话：容量相加不等于速度相加。每增加一个 stage，串行 decode 路径就多一次网络通信。最慢的 peer 可能拖住整条 pipeline。Mesh LLM 最适合“目标模型在任何单机上都装不下”的情况。若模型已经能在一台机器上良好运行，单机通常更快、更可靠。

本文基于 2026 年 7 月 18 日的项目与一手文档。我们把已记录的功能、项目方 benchmark 和必须在自有硬件上验证的结论分开。

Mesh LLM 是什么？

Mesh LLM 是 Apache-2.0 分布式 LLM inference runtime。每个 node 暴露同一套 API。系统可以在当前机器本地执行，也可以把完整请求路由到已托管该模型的 peer，还可以通过 Skippy 把一个模型拆到多台机器。

1. 本地执行：模型能装下时，由当前机器完整运行，避免网络开销。
2. Peer routing：把完整请求发给已经加载目标模型的主机。
3. Stage split：多台电脑分别执行同一请求的不同 layer 范围。

应用只看到模型、请求和响应。Placement、下载、readiness、故障恢复和安全边界仍是基础设施工作。

Skippy 如何把一个 LLM 切到多台电脑？

Skippy 官方流程是一条 pipeline：

1. Coordinator 解析模型或 layer package。
2. Topology planner 选择符合条件的 peer 和连续 layer 范围。
3. 最终 stage 先加载，上游 stage 随后加载。
4. 每台机器下载共享元数据和自己负责的 layer 文件。
5. 所有 stage 报告 ready 后，stage 0 才进入 routing。
6. Prompt 从 stage 0 进入，activation 向后传递，预测 token 返回 API stream。

例如 48 层模型可以让 A 执行 0 到 15 层，B 执行 16 到 31 层，C 执行 32 到 47 层及 output head。这里不是三个独立模型并行回答，而是一条跨越两个网络边界的单一 inference path。

Layer package 包含 manifest、hash、共享 artifact 与 GGUF 分片。项目建议生产式运行使用不可变 Hugging Face revision，并通过认证命令检查大小、SHA、缺失文件、manifest 与真实 /v1 响应。任意 GGUF 并不会自动成为安全可靠的多机 package。

这只是负载均衡吗？

不是。负载均衡把完整请求发给完整模型副本。Skippy split 让同一个请求经过多台机器，因为每台只执行一段模型层。

三张 24 GB GPU 不会变成一张字面意义上的 72 GB GPU。软件使组合容量可用，但显存带宽、计算能力和故障域并不会合并。

多机 inference 会损失多少速度？

取决于模型、切分和网络。Mesh LLM 的官方 benchmark 页面称这些数字只是 reality check，不是承诺。一个 17 GB GLM-4.7-Flash Q4 在 M4 Max 与 M4 Mac mini 之间通过 Wi-Fi 测得：

该模型本来就能装进单机，因此这组测试展示的是 overhead，没有体现多机带来的容量收益。文档也没有提供足够上下文，把它当作当前 Skippy 的通用性能比例并不严谨。可以确定的是：不要期待线性加速。

Planner 文档给出了更有用的推理模型。若假设每次 stage 传输为 10 ms，两 stage 的网络下限是 20 ms/token，三 stage 为 30 ms，四 stage 为 40 ms，还没有计算本地 compute。Topology planner 因此在内存允许时优先减少物理 hop。

哪些因素决定真实性能？

• Stage 延迟：自回归 decode 每个 token 都重复网络传输。有线 LAN 与拥塞 Wi-Fi 是完全不同的环境。
• 最慢 stage：较弱 GPU、CPU offload、过热或后台任务都会限制整条 pipeline。
• Context 与 cache：权重只是内存的一部分。KV 或 recurrent state 随 context 和 concurrency 增长。
• Activation 格式：f16 是保守默认。q8 必须针对具体 family 与 split 通过 exactness 验证。
• Peer 可用性：笔记本休眠、Wi-Fi 漂移或 stage 重启都可能中断请求。

官方支持矩阵记录推荐 artifact、split point、wire type、cache policy 与 topology constraint。“llama.cpp 能识别架构”和“这个切分已认证”不是同一件事。

支持哪些模型与硬件？

已审核矩阵包含 Qwen、Llama、DeepSeek、GLM、Gemma、Phi、Granite、Hunyuan、Mamba、RWKV、Falcon 等 family 和部分多模态模型。具体支持随量化、projector、cache、wire type 与 split boundary 变化。应从推荐 artifact 起步，并验证 package 与 runtime。

主 README 记录了 macOS 和 Linux 的 Metal、CPU、CUDA、ROCm、Vulkan release bundle。Windows 可从源码构建，但 README 同时说明 Windows 发布任务目前关闭。采购前必须查看具体版本的 release asset。

Mesh LLM 的隐私边界在哪里？

私有 mesh 通过 invite token 加入。公开 mesh 使用 Nostr 发布，方便自动发现。LAN-only mDNS 模式不会联系 Nostr relay、公共 iroh relay，也不做原始公共 STUN 探测。发现机制与信任机制必须分开理解。

Mesh 安全文档支持 owner key、allowlist、签名 bootstrap token 与 release-attestation requirement。文档也明确其限制：签名只能证明 build provenance，不能证明远程进程、操作系统或硬件没有被修改。

处理机密 prompt 时，应使用受控机器与运营人员，固定 admission policy，限制 listener，保护 token，并默认避免记录敏感请求内容。公开 discovery 不是 confidential computing 保证。

Mesh LLM 与 Exo、llama.cpp RPC、vLLM 怎么选？

本文回答容量与拓扑问题。若要算经济账，请使用本地模型与 API 盈亏平衡框架。若仍在选模型，请看开放权重 LLM 对比。把这些意图分开，才能避免由一个新奇 runtime 反向决定商业架构。

谁应该测试 Mesh LLM？

购买硬件前的七步 pilot

1. 定义 30 到 100 个真实 prompt、context、output、concurrency 与质量 rubric。
2. 测量最佳单机基线：TTFT、tok/s、peak memory、任务成功率、功耗与失败率。
3. 选择已审核 artifact、不可变 revision，并单独核查模型许可证。
4. 从两台有线 node 开始，只因内存需要才增加 stage。
5. 测试真实 context 与 concurrency，不要只跑一个“OK” prompt。
6. 主动中断 peer，验证发现、withdrawal、recovery 与客户端错误。
7. 比较每个成功任务的完整成本，包括工程、能源、折旧、冗余与 API fallback。

最终决策应明确最大模型、最少 stage、failure budget、trust boundary 与 fallback。我们的Twinsoft AI 案例和技术栈选择指南遵循同一原则：让实测约束决定架构。

来源与方法

架构、命令、API、artifact、支持状态、安全与 benchmark 均来自 Mesh LLM 仓库及上文链接的一手文档。我们没有复测硬件 benchmark。所有项目事实于 2026 年 7 月 18 日核对，并故意省略 star、release 数量和 family 总数等易变数字。