Mesh LLM：在 Iroh 上的分散式 AI 計算

Mesh LLM：在 Iroh 上的分散式 AI 計算

Mesh LLM 讓異構硬體之間的 AI 推論得以分散執行

Mesh LLM 允許使用者將多台機器（從筆記型電腦、迷你 PC 到伺服器與雲端節點）的 GPU 與記憶體彙集起來，並將它們以單一、相容 OpenAI 的 API 形式公開。此架構透過讓團隊利用現有硬體來執行本來會超出單機 VRAM 容量的大型語言模型（LLM），從而移除對集中式資料中心與昂貴計量 API 的依賴。

分散式運算與「Skippy」切分模式

Mesh LLM 透過三種主要的路由方式處理模型推論，以最佳化硬體可用性與模型大小：

  1. 本機執行：請求由本機的 GPU 服務。
  2. 對等路由：請求被導向已載入所需模型的對等節點。
  3. 管線切分（Skippy）：對於單一節點無法容納的模型，「Skippy」引擎會依層範圍將模型切分成多個階段。例如，0‑15 層可在一台機器上執行，16‑31 層則在下一台機器上執行。激活值依序流經這些階段，使得一群規模較小的機器能共同運行巨型模型。

根據專案的模型清單，Qwen 235B MoE 模型已在兩個節點上證實能達到每秒 16 個 token 的速度，顯示即使有網路延遲，分散式推論仍能達到某些使用情境下可接受的效能。

由 Iroh 提供動力的網路架構

Mesh LLM 利用 Iroh 網路函式庫建立去中心化的 mesh，讓每個節點皆以公鑰作為身分識別。這消除了中心伺服器的需求，並透過以下關鍵技術簡化連線：

  • NAT 穿透：Iroh 處理打洞與中繼備援，以在節點之間建立直接、已驗證的 QUIC 連線。
  • 中繼基礎設施：為確保在開放網路上的連通性，Mesh LLM 於不同區域部署了兩個 Iroh 中繼作為備援路徑。
  • QUIC ALPN 協商：協定使用三個不同的 Application‑Layer Protocol Negotiation（ALPN）識別碼來管理流量：
    • mesh-llm/1：處理 gossip、路由、HTTP 隧道與插件頻道。
    • mesh-llm-control/1：管理所有者控制平面，包括設定同步與所有權驗證。
    • skippy-stage/2：為切分模型中對延遲敏感的激活傳輸提供專屬頻道。

在 mesh-llm/1 連線內，雙向 QUIC 串流會使用前導位元來區分 gossip（對等公告）、HTTP 隧道（推論請求）、路由查詢與對等生命週期事件，進行多路復用。

可插拔執行環境與 API 相容性

Mesh LLM 被設計為可插拔系統，插件在 manifest 中宣告其功能。執行環境負責管理這些插件，並透過 MCP、HTTP、推論與 mesh 事件將功能公開。目前系統內建超過 40 個模型，從適合筆記型電腦的小型模型到 235B 參數的巨型模型皆有支援。

為了確保整合的便利性，Mesh LLM 以 localhost:9337/v1 的形式呈現給任何標準的 OpenAI 客戶端，將底層的分散式複雜度對最終使用者隱蔽。

社群見解與技術考量

使用者回饋與社群討論同時突顯了系統的易用性與技術取捨：

  • 部署便利性：使用者表示加入 mesh 的流程相當順暢，提到執行 mesh-llm --auto 後即可在最小設定下貢獻 VRAM 並託管模型。
  • 效能疑慮：部分使用者對網路吞吐量持保留態度，認為消費者網路遠慢於本機記憶體。然而，Qwen 235B 模型的每秒 16 token 基準測試為「分散式推論在互動使用上仍可行」提供了反例。
  • 硬體相容性：有使用者回報「粗糙的地方」在於硬體支援，特別指出某些 llama.cpp 版本在舊款 GPU 上無法運作。
  • 安全與隱私：社群成員提出資料隱私的疑問，指出在分散式 mesh 中，處理請求的主機節點可能會看到被處理的資料。

"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

Sources