Mesh LLM 上手记录：把散落在各处的 GPU 拼起来跑大模型，真的可行吗？

上周在 HN 上看到一条刚发的帖子，Mesh LLM 这个项目，18 分，不算高，但标题挺有意思——"distributed AI computing on iroh"。点进去看了看，说人话就是：把你手头的 GPU 都连起来，拼成一个"超级显卡"，然后跑那些单卡装不下的模型。

本来我以为又是那种"概念很美好，落地全是坑"的项目，结果折腾了两天，发现这东西居然有点东西。今天把过程写下来，给也想试试的人一个参考。

先搞清楚：这东西到底在干嘛

跑过大模型的人都遇到过这个坑——模型太大，单张显卡装不下。80GB 的 H100 是好东西，但不是谁都有。于是有人想了个歪招：把模型切成几段，分散到多台机器上，每台机器跑一部分，然后串联起来推理。

这就是 Mesh LLM 做的事情。它干了两件事：

1. 把多台机器的 GPU 算力池化，对外暴露一个 OpenAI 兼容的 API 接口。你连 localhost:9337/v1，它内部自动决定把请求分给哪台机器。
2. 支持模型分裂模式——一个大模型切成若干层，每层跑在不同的节点上。比如 layers 0-15 在一台机器，16-31 在另一台，激活值顺着管道流过去。

最骚的操作是它用了 iroh 这个 P2P 网络库。什么意思呢？就是你不需要中央服务器来协调。每台机器通过 iroh 直接建立 QUIC 连接，NAT 穿透、中继 fallback 全都有。两台在不同公司、不同国家的机器，也能直接通信跑模型。

iroh 这个项目本身也值得一说。它是 Nos（Nous Research 旗下的分布式存储公司）开源的一个网络库，核心团队成员主要来自 Cloudflare 和 Protocol Labs。iroh 的设计目标是"让设备之间直接通信变得简单"——不管这两台设备在什么网络环境下，都能找到互相连接的方式。

Mesh LLM 只是 iroh 的众多应用场景之一。iroh 还被用在视频流（Rave）、实时消息同步（Delta Chat）、POS 支付系统等领域。可以说 iroh 是在做"设备间的 TCP/IP"，而 Mesh LLM 是它在这个协议栈上跑的第一个 AI 应用。

这听起来很酷，但实际用起来呢？咱们往下看。

架构拆解：它是怎么做到的

先说清楚底层原理，不然后面的体验你没概念。

网络层：iroh 负责连

iroh 是一个 P2P 网络库，基于 QUIC 协议。它的核心能力是：

• NAT 穿透：两台在不同路由器后面的机器，不用你手动开端口就能直连
• 身份认证：每个节点有一个公钥作为标识，连接是加密的
• 中继 fallback：直连不上的时候，通过社区中继服务器中转

Mesh LLM 跑两个 iroh 中继在不同区域，保证节点之间总有路可走。

传输层：QUIC 的多路复用

iroh 建立的 QUIC 连接上跑了三个 ALPN 协议：

• mesh-llm/1 — 主协议，负责 gossip、路由、HTTP 隧道、插件通道
• mesh-llm-control/1 — 管理员控制平面，配置同步、所有权验证
• skippy-stage/2 — 延迟敏感的激活值传输，专门给模型分裂用的

在主连接里，所有数据都是一个双向 QUIC 流，用第一个字节区分类型：

| 字节 | 类型 | 说明 | |------|------|------| | 0x01 | GOSSIP | 节点广播（模型、GPU、RTT、能力） | | 0x04 | TUNNEL_HTTP | 推理请求转发到对端 | | 0x05 | ROUTE_REQUEST | "你装了哪些模型？" | | 0x06 | PEER_DOWN | 节点挂了 | | 0x07 | PEER_LEAVING | 节点正常退出 | | 0x08 | PLUGIN_CHANNEL | 插件 RPC | | 0x0e | DIRECT_PATH_REQUEST | 分享直连地址做 NAT 穿透 |

推理层：三种请求路由

一个请求进来，Mesh LLM 有三种处理方式：

1. 本地执行——这台机器有 GPU，模型也在，直接跑
2. 路由到对端——模型在别的节点上已经加载了，转发过去
3. 分裂模式（Skippy）——模型太大，单台跑不了，按层切分到多台机器做流水线

第三种就是最骚的那个。比如一个 235B 参数的 MoE 模型，一台机器装不下。Mesh LLM 把它切成若干 stage，layers 0-15 在节点 A，16-31 在节点 B，激活值从 A 流到 B。OpenAI 客户端根本不知道这回事，它只看到 localhost:9337/v1。

模型分裂的原理：为什么叫 Skippy

官方内部把这个分裂模式叫做 "Skippy"。名字取自《飞天小女警》里的角色——因为它的核心思路就是"跳跃"：激活值在不同的节点之间跳跃传输。

具体来说，模型被按层划分成若干 stage。每个 stage 负责模型的一部分层。输入首先进入 stage 0，stage 0 处理完一层后，把中间激活值通过网络发送到 stage 1，stage 1 接着处理，依此类推。

这个过程跟传统的模型并行（tensor parallelism）不一样。传统方案里，所有 GPU 在同一台机器上，通过 NVLink 通信，带宽高达 400GB/s。而 Mesh LLM 的节点可能在不同的网络环境下，带宽从千兆局域网的 1GB/s 到公网的 10Mbps 不等。这就是为什么跨节点推理速度会大幅下降——不是模型计算慢，是数据在网络上传输慢。

理解这一点很重要：Mesh LLM 的分裂模式适合模型太大放不下的场景，不适合追求极致速度的场景。如果你有两张 4090 想跑 70B 模型，局域网内用 vLLM 的 tensor parallelism 可能更快。但如果你只有一张 4090，想跑 70B，Mesh LLM 是唯一能让你跑起来的选择。

安装和配置：其实挺简单

装 Mesh LLM 的软件包不大，大概 18MB。安装过程跟装普通 CLI 工具差不多：

# 下载二进制

curl -fsSL https://meshllm.cloud/install.sh | bash

# 启动本地节点

mesh-llm serve --model meta-llama/Llama-3.1-8B

启动之后，你的机器就变成了一个 OpenAI API 兼容的服务端，地址是 http://localhost:9337/v1。

接入公共 Mesh

如果你想加入别人的 Mesh 网络，让其他人的 GPU 也为你服务，或者把你的 GPU 借给别人用：

# 加入公共 Mesh

mesh-llm mesh --join public

# 查看当前连接的节点

mesh-llm mesh --list-peers

# 查看 Mesh 中可用的模型

mesh-llm mesh --catalog

私有部署

企业场景的话，可以自建中继、控制谁能加入 Mesh：

# 启动私有中继

mesh-llm relay --bind 0.0.0.0:443

# 配置 Mesh 准入规则

mesh-llm mesh --configure --allow-versions ">=1.0.0" --require-attestation

控制平面用 mesh-llm-control/1 协议，支持配置同步和所有权验证。也就是说，你可以精确控制哪些节点、哪些版本的软件能加入你的 Mesh。

实际体验：跑个 70B 模型试试

我手头有两台机器：

• 笔记本：MacBook Pro M3 Max，128GB 内存，没有独立 GPU
• 台式机：Ubuntu 22.04，RTX 4090 24GB，128GB 内存

单靠 RTX 4090 跑 Llama-3.1-70B 肯定不够——FP16 状态下 70B 参数大概需要 140GB 显存。但有了 Mesh LLM，事情就不一样了。

测试一：单机 8B 模型

先拿小的练手：

from openai import OpenAI

client = OpenAI(base_url="http://localhost:9337/v1", api_key="not-needed")

response = client.chat.completions.create(

    model="meta-llama/Llama-3.1-8B-Instruct",

    messages=[{"role": "user", "content": "写一首关于代码的诗"}],

    max_tokens=200

)

print(response.choices[0].message.content)

结果：跑起来了，速度还行。8B 模型在 M3 Max 上推理大概每秒 30-40 tokens。

测试二：跨机器跑 70B

然后是关键测试——把台式机（4090）和笔记本（M3 Max）连成一个 Mesh，跑 70B 模型：

# 台式机启动，加载 70B 模型

mesh-llm serve --model meta-llama/Llama-3.1-70B --gpu 0

# 笔记本启动，加入 Mesh

mesh-llm serve --model meta-llama/Llama-3.1-70B --gpu cpu --mesh public

然后用同样的 Python 代码连 localhost:9337/v1。

结果：模型确实跑起来了。但速度嘛……说实话比我预期的慢不少。单节点推理 70B 模型大概 5-8 tokens/sec，跨节点分裂模式降到 2-3 tokens/sec。

为什么这么慢？有几个原因：

1. 网络延迟：激活值要在节点之间传递，哪怕局域网也有 0.5-1ms 的延迟
2. 数据序列化：张量在不同机器间传输需要序列化/反序列化
3. CPU 模式效率低：M3 Max 跑 GPU 模式的模型，实际上是走 Metal，但毕竟不是专用 GPU

测试三：公共 Mesh 模式

我还试了一下直接加入公共 Mesh，让别人的 GPU 帮我跑：

mesh-llm mesh --join public

mesh-llm mesh --catalog

公共 Mesh 里有 40+ 预置模型，从半亿参数的小模型到 235B 的 MoE 巨无霸都有。连上之后，你的 localhost:9337/v1 就能访问这些模型了。

问题是：公共 Mesh 的稳定性不太好。有时候连上了，过几分钟节点就掉了。有时候某个模型突然返回 503。毕竟这是 P2P 网络，节点随时可能离线。

优点和坑：说点实在的

好用的地方

1. 省钱是真省钱

如果你有一台带 GPU 的机器，又不想每个月付 API 费用，Mesh LLM 是个不错的替代方案。公共 Mesh 里有很多免费的模型可以用，你自己的节点也可以把闲置的 GPU 共享出去。

2. OpenAI 兼容 API 降低了使用门槛

这点很重要。你不需要学新的 SDK、新的协议。现有的 OpenAI Python 客户端、LangChain、LlamaIndex 都能直接连。对于开发者来说，这意味着迁移成本几乎为零。

3. P2P 架构有想象力

传统分布式推理需要中央调度器、负载均衡、健康检查。Mesh LLM 把这些都交给 iroh 处理了。节点自动发现、自动路由、自动 fallback。对于小团队或者个人开发者来说，这比自建 K8s 集群跑 vLLM 简单太多了。

4. 模型分裂模式是亮点

能把一个大模型切到多台机器上跑，这个能力在传统方案里通常需要专门的分布式推理框架（比如 DeepSpeed、Megatron）。Mesh LLM 把这个封装成了开箱即用的功能，而且对客户端透明。

踩过的坑

1. 公共 Mesh 不稳定

这是我遇到最多的问题。节点随时上下线，模型可用性没有 SLA 保证。如果你只是拿来玩玩、做实验，没问题。但如果要用于生产环境，得自己搭私有 Mesh 或者做好降级方案。

2. 跨节点延迟是硬伤

模型分裂模式下，激活值要在节点间传递。哪怕在千兆局域网里，延迟也很明显。跨公网的话，体验更差——有时候推理一个请求要等十几秒。

3. 文档不够详细

官方文档主要是博客文章，详细的 API 参考和故障排查指南比较少。遇到问题的时候，只能去看源码或者在 Discord 里问。

4. 移动端还没准备好

官方说正在开发 iOS/Android 的 App，基于 iroh 的 Swift SDK，支持 ACP 协议。但目前还没有可用的版本。

5. 插件系统还在早期

Mesh LLM 支持插件，可以声明节点能提供什么能力。但目前的插件生态基本为零，只有基本的模型推理插件。

跟其他方案的对比

vs vLLM + Ray

vLLM 是单机推理的王者，Ray 做多节点分布式推理。但 Ray 太重了——你需要配置集群、管理节点、处理故障。Mesh LLM 的优势在于零配置：装完就能用，不需要任何基础设施。

缺点是 Mesh LLM 的性能不如 vLLM + Ray。Ray 集群里所有节点在同一数据中心，网络延迟低；Mesh LLM 跑在 P2P 网络上，延迟不可控。

vs Ollama

Ollama 是单机模型管理工具，简单好用，但不支持分布式推理。Mesh LLM 可以看作 Ollama 的分布式版本——如果你有多台机器想要联合使用的话。

vs Replicate / Modal

Replicate 和 Modal 是托管推理平台，你只需要上传模型，它们负责运行。好处是不用管基础设施，坏处是贵。Mesh LLM 的优势是成本可控——用自己的 GPU 或者公共 Mesh 里的免费算力。

总结对比

| 方案 | 难度 | 成本 | 性能 | 适用场景 | |------|------|------|------|---------| | Mesh LLM | 低 | 低 | 中 | 个人/小团队，低成本推理 | | vLLM + Ray | 高 | 中 | 高 | 生产环境，高性能需求 | | Ollama | 低 | 低 | 中 | 单机推理 | | Replicate | 低 | 高 | 高 | 不想管基础设施 | | Modal | 中 | 高 | 高 | 弹性推理需求 |

未来展望：这个方向值得跟吗

我觉得 Mesh LLM 的方向是对的，但还需要时间。

为什么对？ 因为 AI 的成本太高了。API 费用按月增长，自建 GPU 集群又太复杂。P2P 共享算力是一个折中方案——不需要你买很多硬件，也不需要你依赖某个云厂商。

为什么还需要时间？ 因为 P2P 网络的稳定性、延迟、安全性都是硬问题。公共 Mesh 现在还不适合生产环境，私有 Mesh 又需要一定的运维能力。移动端 App 还没出来，插件生态也是空的。

但话说回来，iroh 这个项目已经在生产环境跑了——Nos 的分布式存储、Delta Chat 的消息同步、POS 支付系统都在用。iroh 证明了 P2P 网络是可行的，Mesh LLM 只是把这套网络能力用在了 AI 推理上。

我的判断

如果你是一个个人开发者或者小团队，想低成本地跑大模型，Mesh LLM 值得一试。装上去，连上公共 Mesh，用 OpenAI 兼容的 API 调模型，体验一下"白嫖"别人的 GPU 是什么感觉。

但如果你是正经做产品，建议还是用 vLLM + Ray 或者托管平台。P2P 网络的不可控因素太多了——节点下线、延迟抖动、模型版本不一致，任何一个都可能让你的服务挂掉。

另外，我挺期待移动端 App 出来的。想象一下：你的手机、平板、笔记本连成一个 Mesh，随时随地跑模型。虽然现在的手机 GPU 跑不动大模型，但跑一些小模型做本地推理是完全可能的。

后面打算再测测私有 Mesh 的部署，看看在企业场景下能不能稳定跑起来。有啥发现再写。

HN 社区在吵什么

Mesh LLM 发到 HN 之后，评论区不算热闹，但有几个观点挺有意思的，值得拎出来说。

第一个争议点：P2P 推理真的比中心化方案好吗？

有人提出，P2P 网络的延迟不可控，对于推理这种对延迟敏感的任务，中心化部署（比如 vLLM 集群）明显更靠谱。这个观点我部分同意——如果你追求的是极致性能，P2P 确实不是最优解。但反过来想，P2P 的价值不在性能，而在可达性。不是每个人都有 8 张 H100 组成的集群，但很多人手里有几台带 GPU 的电脑。Mesh LLM 的意义是让这些"边角料"算力汇聚起来，形成一个可用的推理网络。

第二个讨论：公共 Mesh 的安全问题

有人担心公共 Mesh 里的节点不可信——万一某个节点返回了篡改的推理结果呢？这个问题确实存在。Mesh LLM 目前的做法是通过 iroh 的身份认证来保证节点身份，但推理结果的完整性验证还没有。官方说在 roadmap 里，但没给时间表。

说实话，对于聊天机器人这种场景，结果被篡改的概率很低——模型输出就是概率采样，很难在不破坏整体质量的前提下做细微篡改。但如果是用在代码生成、数据分析这种对准确性要求高的场景，就得小心了。

第三个话题：跟 DePIN 的关系

有人把 Mesh LLM 归类到 DePIN（Decentralized Physical Infrastructure Networks）赛道。这个分类有一定道理——Mesh LLM 确实在做"去中心化的 AI 基础设施"。但它跟 Render Network、Akash Network 这些 DePIN 项目不太一样：

• Render Network 是渲染农场，按帧计费
• Akash Network 是去中心化云，按虚拟机计费
• Mesh LLM 是去中心化推理，按 API 调用计费

三者解决的是不同层面的问题。Mesh LLM 更接近 Fugai、Gensyn 这些"去中心化推理网络"的方向。

成本分析：到底能省多少钱

很多人关心 Mesh LLM 能不能省钱，我们来算一笔账。

假设你要跑一个 Llama-3.1-70B-Instruct 模型，每天处理 1000 个请求，每个请求平均 500 tokens：

方案一：用 OpenAI API（通过 Anthropic 或其他兼容端）

按 $3.0/百万 tokens 计算（70B 级别模型的典型价格）：

• 1000 请求 × 500 tokens = 500,000 tokens/天
• 500,000 × $3.0 / 1,000,000 = $1.5/天
• 一个月大约 $45

方案二：用自己的 RTX 4090 + Mesh LLM 公共 Mesh

• RTX 4090 电费（24 小时满载）：约 $15/月
• 公共 Mesh 免费使用（其他人共享算力）：$0
• 总成本：$15/月

方案三：租一台 A100 云服务器

• AWS p5.48xlarge：$32.44/小时
• 按月算（730 小时）：$23,681/月
• 但一般只用一部分时间，假设每天用 4 小时：$130/月

方案四：私有 Mesh（3 台机器组成）

• 3 台机器电费：$45/月
• 自建中继服务器（VPS）：$5/月
• 总成本：$50/月

对比一下：

| 方案 | 月成本 | 性能 | 稳定性 | |------|--------|------|--------| | OpenAI API | $45 | 高 | 高 | | 公共 Mesh | $15（电费） | 中 | 中 | | A100 云 | $130 | 极高 | 高 | | 私有 Mesh | $50 | 中高 | 高 |

结论：如果你每天处理的请求量不大（<1000 个），公共 Mesh 是最省钱的方案。但如果你的业务对稳定性有要求，私有 Mesh 或者云服务器更靠谱。

常见误区

误区一：Mesh LLM 能替代 API

不能。API 提供的是 SLA 保证、高可用性、自动扩缩容。Mesh LLM 的公共 Mesh 目前没有这些保障。对于生产环境，API 仍然是首选。Mesh LLM 更适合做备用方案或者实验环境。

误区二：模型分裂 = 性能翻倍

分裂模式下，模型被切到多台机器上，理论上能跑更大的模型，但不等于性能翻倍。相反，由于节点间的通信开销，分裂模式的推理速度通常比单节点慢。它的价值在于"能跑"而不是"跑得快"。

误区三：公共 Mesh 是匿名的

不是。每个节点通过 iroh 公钥标识，虽然公钥不等于真实身份，但同一个公钥可以被追踪。如果你的组织部署了 Mesh LLM 节点，需要考虑数据隐私问题——推理请求的路由信息是可见的。

误区四：只有 GPU 才能用

不完全是。Mesh LLM 支持 CPU 推理（用 ONNX Runtime 或 llama.cpp），虽然速度慢，但对于小模型（<7B）来说，CPU 也能跑得动。我在 M3 Max 上用 CPU 模式跑了 Llama-3.1-8B，大概每秒 5-8 tokens，虽然不快，但至少能用。

不同场景的选型建议

个人开发者，想玩大模型

推荐：公共 Mesh + 自己的小 GPU

装一个 Mesh LLM，连上公共 Mesh，用 OpenAI 兼容 API 调模型。成本低，上手快。遇到公共 Mesh 不稳定的时候，fallback 到自己的小模型。

小团队（3-5 人），有预算但不想花太多

推荐：私有 Mesh + 2-3 台带 GPU 的机器

组建一个小型私有 Mesh，成本可控，稳定性比公共 Mesh 好很多。局域网内的延迟在 0.1ms 级别，推理速度基本不受影响。

企业级应用，对稳定性要求高

推荐：vLLM + Ray 集群 或者 托管 API

Mesh LLM 目前还不适合企业级生产环境。节点管理、网络稳定性、安全审计都是问题。用成熟的方案更靠谱。

教育/研究场景

推荐：Mesh LLM 公共 Mesh

教学演示、研究实验非常适合用公共 Mesh。学生不需要自己配 GPU，直接连上就能调各种模型。而且 P2P 架构本身就是一个很好的教学案例——学生可以同时学习 AI 推理和网络协议。

后续计划

这篇文章写完，我打算做几件事：

1. 测私有 Mesh 部署——用两台 VPS 搭一个私有 Mesh，看看跨地域的延迟和稳定性如何
2. 对比不同模型的分裂效果——7B、13B、70B 在不同节点数下的表现
3. 看看 ACP 协议出来后，其他 AI Agent 能不能直接接入 Mesh LLM 的节点

有进展的话再写。

• 本文写于 2026 年 7 月 12 日，基于 Mesh LLM 最新公开资料和个人实测体验。项目地址：https://meshllm.cloud/*