你在书房的桌下有一块 RTX 4090，办公室的机柜里有一台插着 A6000 的服务器，朋友在另一个城市有一台 Linux 工作站，还空着一半显存。这些 GPU 加起来，显存已经超过了一个 235B 参数 MoE 大模型的装载需求。但它们被墙体、被网络策略、被不同的操作系统分隔——各自为政。
Mesh LLM 要解决的，正是这个局面。
2026 年 7 月 11 日，iroh 团队（即 n0 公司）正式发布了这个开源项目。它的承诺简单直接：把你已经拥有的 GPU 和内存聚合起来，跨越任意数量的机器，对外暴露为一个兼容 OpenAI 的 API。启动一个节点，再加入更多节点，让 Mesh 决定模型是在你的本地 GPU 上跑、路由到某个对等节点跑，还是拆分到多台机器上一起跑。
当人们想象运行一个大语言模型时，他们想象的是数据中心。Mesh LLM 的官方博客开篇这样写道，一排排属于别人的 GPU，一个按量计费的 API，和一张每个月都在增长的账单。你把 prompt 发送到一个黑盒里，然后祈祷价格、模型和隐私政策都和你注册时一样。
这听起来像一个技术团队的抱怨。但背后是一个正在急剧膨胀的产业矛盾。
推理的算力，还在用训练的规则定价
先看几组数据。
2026 年，全球 AI 支出预计达到 2.52 万亿美元。其中约 70% 的 GPU 算力需求来自推理——模型服务、实时 API 调用、企业级部署和 AI Agent 的规模化运行。这是 Aethir 在 2026 年 6 月的一份报告中给出的判断。训练时代正在退潮，推理时代已经涨满。
但推理的算力分配方式，依然停留在数据中心时代。
OpenAI GPT-5.4，目前大多数团队在生产中调用的中端旗舰模型，输入价格每百万 token 2.50 美元，输出价格每百万 token 15.00 美元。如果依赖缓存输入，可以降到 0.25 美元。假设一个产品每天处理约 500 万输入 token 和 300 万输出 token，对一款中等规模的 AI 应用来说这并不夸张，每天的推理成本大约在 57.50 美元，一个月超过 1,700 美元。随着用户增长，这张账单只会越来越厚。
那么自托管呢？市场调研数据显示，对于月 token 量达到 1 亿以上的大规模团队，自托管可以将成本削减 50% 以上。Llama 4 Maverick 在自托管 A100 上的推理成本约为每百万 token 0.30 到 0.50 美元，对比 OpenAI API 15 美元的输出价格，相差大约 30 到 50 倍。
但成本只是问题的一个面。你无法控制模型何时被更新，你的数据流向哪里，你的工作负载跑在谁家的硬件上。当你的核心产品依赖一个黑盒 API 时，你实际上在用整个业务做抵押。
三种模式，一个 API
Mesh LLM 的架构设计围绕三个核心场景展开。
第一种，本地运行。 如果模型能装进你当前机器的 GPU，就在本地跑。这是最直接的使用方式，也是开销最小的路径。
第二种，路由到对等节点。 如果你的机器装不下某个模型，但网络中的另一台机器已经加载了它，推理请求会被自动路由过去。办公室的服务器和家里的游戏 PC 之间因此建立了一条推理隧道——你不用知道模型在哪，你只需要知道它能跑。
第三种，也是最激进的——拆分，内部代号 Skippy。 当一个模型太大、没有任何单机装得下时，Mesh LLM 会按层范围将模型分区成多个阶段：第 0 到 15 层放在节点 A，第 16 到 31 层放在节点 B，以此类推。激活值从一个阶段流向下一个阶段，形成一条推理流水线。几台中端配置的机器，因此能联合运行一台机器根本装不下的模型。
这三种模式对外完全透明。任何兼容 OpenAI 的客户端，只要把 API 地址指向 http://localhost:9337/v1，就把整个 Mesh 当成了一台超级 GPU——它完全不关心请求实际在哪里被处理。
Mesh LLM 的插件目录目前支持 40 多种模型，从 5 亿参数的小模型（笔记本上流畅运行）到 235B 参数的混合专家巨无霸。每个插件通过 manifest 声明自己能提供什么，运行时负责启动插件、路由调用，并通过 MCP、HTTP 和 Mesh 事件暴露能力。
18MB 里的网络魔法
Mesh LLM 的二进制文件只有大约 18MB。如此小的体积能实现如此复杂的分布式推理，关键在于它没有自己重新发明网络层——它直接站在 iroh 的肩膀上。
iroh 是 n0 公司开发的开源 P2P 网络库。它的核心能力可以用一句话概括：用公钥做地址，让任何两台设备之间建立直接、加密的 QUIC 连接，无论它们在什么 NAT 后面、用什么网络协议。
在 Mesh LLM 中，每个节点都会启动一个 iroh 端点。这个端点的身份就是一把公钥——这是它在网络中唯一的标识。没有中央服务器，没有 DNS 解析，没有 IP 绑定。iroh 负责处理 NAT 穿透、打洞和中继回退，确保任意两个节点之间总能找到一条可用的通信路径。
为了在公网环境中保持稳定，Mesh LLM 运行了两个分布在不同区域的 iroh 中继服务器——当节点之间无法直接连接时，它们总能通过中继找到一条回退路径。
整个 Mesh LLM 的通信协议构建在 QUIC 的 ALPN 协商之上，定义了三种协议：
mesh-llm/1：主 Mesh 协议，负责 gossip、路由、HTTP 隧道和插件通道mesh-llm-control/1：所有者控制面，用于配置同步和所有权认证skippy-stage/2：延迟敏感的激活值传输，用于拆分模型的流水线通信
在 mesh-llm/1 连接内部，所有通信复用同一条 QUIC 连接，通过一个字节的首部标识来区分流类型：0x01 是 gossip 广播，0x04 是 HTTP 推理请求，0x05 是路由查询，0x06 是节点离线通知，0x07 是优雅退出，0x08 是插件 RPC，0x0e 是直连路径请求。
iroh 带来的最大价值是：无论路由到对等节点还是将激活值流到下一个流水线阶段，在协议层面都变成了和请求本地 localhost 一样的原语——只是目标端点 ID 不同。网络层从此不需要你操心。
一个正在萌芽的航向
在 Mesh LLM 之前，分布式推理的探索已经有很多尝试。vLLM 用 PagedAttention 优化了推理吞吐，llama.cpp 让本地推理成为可能，ExLlamaV3 在 2 到 4 卡的多 GPU 场景中表现出色，llm-d 在 Kubernetes 上实现了高性能分布式推理，InferMesh 构建了 GPU 感知的推理网格。开源社区从未停止过对让推理更快更便宜的追求。
但 Mesh LLM 的不同之处在于它的出发点。它不是如何在数据中心里更高效地跑推理，而是如何让推理不再必须依赖数据中心。这不是一个技术路线问题，而是一个关于 AI 权力结构的假设——谁有权运行大模型？只有拥有大型数据中心和数十亿美元预算的公司吗？还是说，任何拥有几张 GPU 的个人和团队，都应当能聚合起自己的算力，运行自己的模型，保护自己的数据？
Mesh LLM 的路线图已经指向了更远的方向。一个基于 iroh Swift SDK 的移动端应用正在开发中，未来将支持 ACP（Agent 通信协议）标准，让其他客户端也能加入 Mesh。你的手机，未来也可能成为这张推理网中的一个节点。
当然，Mesh LLM 还面临巨大的挑战。P2P 网络的延迟和可靠性天然不如数据中心内的高带宽互联；模型拆分后的流水线推理效率仍然是一个活跃的研究问题；在安全性方面，开放的 P2P 推理网络需要解决信任问题——你如何确保模型权重不会被对等节点窃取？Mesh LLM 目前通过基于 iroh 的端到端加密和公钥身份认证来解决这个问题，但大规模部署时的安全性仍待检验。
但这些挑战，恰恰也是 Mesh LLM 最让人兴奋的地方。它不是在解决一个已经有人解决的问题，而是在探索一个几乎没有人认真尝试过的方向。
回到文章开头的那句话：当人们想象运行一个大语言模型时，他们想象的是数据中心。
Mesh LLM 告诉我们，也许我们不应该继续这样想象了。
从 2026 年往回看，AI 行业在过去三年里经历了从 Scaling Law 到推理效率的范式转换。训练阶段的军备竞赛正在降温，而推理阶段的算力需求却以更快的速度在膨胀。在这个节点上，一个能让任何人聚合自己散落算力的开源工具，可能就是这个行业最需要的东西。
不是因为 Mesh LLM 今天就能替代数据中心的推理性能。而是因为，它第一次让 AI 推理的去中心化从一个抽象概念变成了一个可以下载、可以运行、可以参与的真实系统。
你的 GPU，你说了算。
快报