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 年 9 月 2 日的项目与一手文档。当时最新稳定版为 v0.75.1，v0.76.0-rc9 于当天作为预发布版发布。Mesh LLM 仍是快速变化的实验性项目。我们把已记录的功能、项目方 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 让同一个请求经过多台机器，因为每台只执行一段模型层。

如果每个模型都能装进单台机器，真正问题是独立智能体调用排队，请阅读我们的NVIDIA PAIR 与 AMD ROCm 分析。PAIR 把每个完整请求放到一个合格本地节点上，解决的问题不同于 Mesh LLM 的 layer-stage pipeline。

三张 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。当前 placement 会评估 coordinator 到 node 的延迟，但生产路径尚未接收 peer-to-peer RTT 矩阵，因此无法完整优化远端 stage 彼此之间的邻近关系。

哪些因素决定真实性能？

• Stage 延迟：自回归 decode 每个 token 都重复网络传输。有线 LAN 与拥塞 Wi-Fi 是完全不同的环境。
• 最慢 stage：较弱 GPU、CPU offload、过热或后台任务都会限制整条 pipeline。
• Context 与 cache：权重只是内存的一部分。KV 或 recurrent state 随 context 和 concurrency 增长。
• Activation 格式：当前每个边界都使用 raw little-endian f32。历史 f16 与 q8 结果是研究证据，不是可选的生产 wire format。
• 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。

当前带 tag 的 release 已包含 macOS Metal、Linux CPU/CUDA/ROCm/Vulkan，以及 Windows x86-64 CPU/CUDA/ROCm/Vulkan bundle。v0.76.0-rc9 的 release asset还包含 Linux ARM64 CPU 与 CUDA。Windows 原生版本不再只能从源码构建，但当前指南仍记录安装/runtime workaround，且 executable 尚未签名。应把它视为试点路径，并核查具体 asset、backend、driver 与安装流程。

Mesh LLM 的隐私边界在哪里？

私有 mesh 通过 invite token 加入。公开 mesh 使用 Nostr 发布，方便自动发现。LAN-only mDNS 模式不会联系 Nostr relay、公共 iroh relay，也不做 raw public STUN 探测。Node 之间的 prompt、response 与 split activation 均通过 QUIC 端到端加密。默认 Nostr 模式下，若没有直连路径，iroh 可以通过只转发加密 packet 的托管 relay 连接。

Mesh 安全文档支持 owner key、allowlist、requirement-aware mesh 的签名 bootstrap token 与 release-attestation requirement。不受限的 legacy 和 private mesh 仍保留较旧的未签名 invite-token 路径。Attestation 只能证明 build provenance，不能证明远程进程、操作系统或硬件没有被修改。除非 mesh policy 要求 certified build，默认启动甚至会接受 invalid attestation。

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

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

本文回答容量与拓扑问题。若要算经济账，请使用本地模型与 API 盈亏平衡框架。如果希望通过 API 使用分布式 Apple Silicon，而不是自行运维私有 mesh，请看Darkbloom AI 隐私、价格与节点收益评测。若仍在选模型，请看开放权重 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 仓库及上文链接的 Skippy、planner、family、mesh security、release 与 benchmark 一手文档，并参考了官方 llama.cpp RPC 文档。我们没有复测硬件 benchmark。所有项目事实于 2026 年 9 月 2 日核对，并故意省略 star 和 family 总数等易变数字。