Mesh LLM：基于 Iroh 的分布式 AI 计算
Mesh LLM：基于 Iroh 的分布式 AI 计算
Mesh LLM 实现跨异构硬件的分布式 AI 推理
Mesh LLM 允许用户将多台机器（从笔记本、迷你 PC 到服务器和云节点）的 GPU 与内存汇聚在一起，并将其暴露为单一的、兼容 OpenAI 的 API。该架构通过让团队利用现有硬件运行本来超出单机显存容量的大语言模型（LLM），消除了对集中式数据中心和昂贵计量 API 的依赖。
分布式计算与 “Skippy” 切分模式
Mesh LLM 通过三种主要路由方式处理模型推理，以优化硬件可用性和模型规模：
- 本地执行：请求由本机的 GPU 处理。
- 对等路由：请求被路由到已经加载所需模型的对等节点。
- 流水线切分（Skippy）：对于单个节点无法容纳的模型，"Skippy" 引擎按层范围将模型划分为多个阶段。例如，层 0‑15 在一台机器上运行，层 16‑31 在下一台机器上运行。激活值按顺序在这些阶段之间流动，使得一组普通机器能够共同运行巨型模型。
根据项目的模型列表，Qwen 235B MoE 模型已在两节点上实现 16 token/秒的运行速度，这表明尽管存在网络延迟，分布式推理仍能达到某些使用场景可接受的速度。
由 Iroh 提供动力的网络架构
Mesh LLM 利用 Iroh 网络库创建去中心化的网格，每个节点通过公钥进行标识。这消除了对中心服务器的需求，并通过以下关键技术简化了连接：
- NAT 穿透：Iroh 处理打洞和中继回退，以在节点之间建立直接、已认证的 QUIC 连接。
- 中继基础设施：为确保跨公网的连通性，Mesh LLM 在不同地区使用了两个 Iroh 中继作为回退路径。
- QUIC ALPN 协商：协议使用三种不同的应用层协议协商（ALPN）标识符来管理流量：
mesh-llm/1：处理 gossip、路由、HTTP 隧道和插件通道。mesh-llm-control/1：管理所有者控制平面，包括配置同步和所有权证明。skippy-stage/2：用于切分模型中对延迟敏感的激活传输的专用通道。
在 mesh-llm/1 连接内部，双向 QUIC 流通过前导字节进行复用，以区分 gossip（对等公告）、HTTP 隧道（推理请求）、路由查询和对等生命周期事件。
可插拔运行时与 API 兼容性
Mesh LLM 被设计为可插拔系统，插件在清单中声明其能力。运行时随后管理这些插件，并通过 MCP、HTTP、推理和网格事件暴露其功能。系统目前随附超过 40 种模型的目录，涵盖从适合笔记本的小模型到 235B 参数的巨型模型。
为确保易于集成，Mesh LLM 对任何标准 OpenAI 客户端表现为 localhost:9337/v1，将底层的分布式复杂性对终端用户隐藏。
社区洞察与技术考量
用户反馈和社区讨论突显了系统的易用性以及技术权衡：
- 部署简便：用户报告加入网格非常顺畅，指出运行
mesh-llm --auto即可在几乎无需配置的情况下贡献显存并托管模型。 - 性能顾虑：部分用户对网络吞吐量持怀疑态度，认为消费级网络远慢于本地内存。然而，Qwen 235B 模型的 16 token/秒基准为分布式推理在交互式使用中的可用性提供了反例。
- 硬件兼容性：有用户反馈硬件支持存在“粗糙边缘”，特别是某些
llama.cpp构建在旧 GPU 上无法工作。 - 安全与隐私：社区成员提出数据隐私问题，指出在分布式网格中，处理请求的主机节点可能会看到被处理的数据。
"I have a macbook pro... The swarm page thing had a little 'join' button and said to run 'mesh-llm --auto'. And I did. And it worked first try." — @maccam912