Mesh LLM：把辦公室、桌機、雲端 GPU 串成一個 OpenAI 相容 API

編按：本文綜合整理自 iroh.computer 官方部落格、Mesh LLM GitHub，並加入 Siami 編輯部觀點與分析。說到跑大型語言模型，多數人腦中浮現的是資料中心：一整排別人的 GPU、計價的 API、每月水漲長的帳單。把 prompt 丟進一個黑盒子，只能祈禱價格、模型版本、隱私政策都還跟當初簽約時一樣。對很多團隊來說，這是筆壞交易。你交出了對模型更新時機、資料流向、底層硬體的控制權。隨著用量成長，帳單跟著膨脹，唯一能拉的槓桿只有「付更多錢」。

Mesh LLM 走的是完全不同的路線：把你手上已有的 GPU 和記憶體集結成池，無論你想串入幾台機器都行，整個叢集以單一 OpenAI 相容 API 對外。先起一個節點，需要時再加，讓 mesh 自動決定這個請求要跑在你眼前的這台機器、轉給某個對等節點，還是切成 pipeline 分散到多台。

問題：AI 很貴，而且不屬於你主流模型都是單體怪獸。多數人透過 UI 或 API key 存取，向某家大型供應商付費跑一切。方便是方便，但也是一種投降：你控制不了模型何時更新、跑在什麼記憶體、底下是什麼硬體。大量依賴這些模型的企業和服務想要的是相反的東西：更多控制權、更高的可插拔性、更低的成本。他們的 GPU 散落在辦公室、儲藏室、桌底下。缺的只是把這些機器當成一台用的方法。

Mesh LLM：自己跑模型訴求很簡單：不用買更大的 GPU，就能跑更大的模型。在團隊內私下共享算力，或對外公開給世界用，撐起 agent 和聊天介面。把任何 OpenAI client 指向 http://localhost:9337/v1，就不用管運算實際發生在哪。底層機制上，Mesh LLM 把模型運算分散到一組 iroh endpoint。請求可以走三種路徑：

• 在本地、這台機器的 GPU 上跑
• 路由到某個已經載入該模型的對等節點
• 把大到單機塞不下的大模型，分割到多台機器上以 pipeline 形式跑

怎麼運作的架構是可插拔的。Plugin 在 manifest 宣告自己能提供什麼，runtime 啟動它們、路由呼叫，並透過 MCP、HTTP、推論、mesh events 對外開放能力。出廠的型錄內建 40 多種模型，從筆電能跑的 5 億參數小模型，到 235B 的 mixture-of-experts 巨獸都有。對大模型來說，Mesh LLM 有個 split mode（內部代號「Skippy」）：模型按 layer 範圍切成數個 stage——節點 A 跑 layer 0 到 15、節點 B 跑 16 到 31，依此類推形成 pipeline。activation 從一個 stage 流到下一個 stage，所以幾台普通的機器合力能跑出任何單機都塞不下的模型。OpenAI client 對此一無所覺，它照樣只跟 localhost 講話。

怎麼用 iroh

每個節點，無論是負責 serve 模型還是只送請求，啟動時都會 boot 一個 iroh endpoint。那個 endpoint 就是節點的身分（一把公鑰），也是唯一對外的網路介面。沒有中央伺服器。iroh 處理打洞、NAT 穿透、以及連不上時的 relay fallback，讓任意兩台機器之間都能開出一條直接、已認證的 QUIC 連線。為了在開放網際網路上保持穩定，Mesh LLM 在兩個不同地區跑了兩組 iroh relay，所以無法直接互連的節點就近有替代路徑。整個協定疊在 QUIC 的 ALPN 協商上，共三種：

mesh-llm/1 主連線裡，每個 stream 是雙向 QUIC stream，標頭一個 byte 標明 stream 類型。一條連線同時承載 gossip、推論、路由查詢、peer lifecycle 事件，全靠那個第一個 byte 解多工：

漂亮的部分在它買到了什麼。iroh 提供任意兩台機器之間、以公鑰定址的「已認證 + 可穿透 NAT」的 QUIC。所以「路由到對等節點」和「把 activation 串流給 pipeline 下一個 stage」變成跟「跟 localhost 講話」同一個 primitive，只是 endpoint ID 不同。網路層就變成不用特別去想的事。

iroh 提供安全傳輸。Mesh LLM 在上面自建 gossip 層，藉此控制誰能加入 mesh、哪些版本相容、要信任哪些 peer。

怎麼開始用使用者安裝輕量軟體（約 18MB）後，可以選擇加入公開 mesh 或設定私有部署。系統對任何標準 OpenAI client 來說就是 localhost:9337/v1。行動 app 正在開發中，基底是 iroh 的 Swift SDK。計畫支援 ACP（正在成形中的 agent 標準），讓其他 client 也能加入 mesh。貫穿一切的還是同一個初衷：更點對點、更少封閉伺服器、無鎖定。

為什麼這件事重要過去一年，AI 推論的成本結構幾乎完全由三家 hyperscaler（OpenAI / Anthropic / Google）與幾家 GPU 雲（CoreWeave、Lambda）決定。任何想脫離這個依賴的團隊，都要嘛自建 GPU 叢集（貴），要嘛忍受昂貴 API。Mesh LLM 的切入角度不是要打敗這些雲端供應商，而是讓「散落各地的閒置算力」重新變成一種資產。關鍵的設計選擇是把 mesh 抽象成一個 OpenAI 相容 API。這個決定讓所有現有 client 程式碼零修改就能切過來——包括 Cursor、Continue、Open WebUI 這類已經預設吃 OpenAI API 的工具。對於想做「私有 LLM 部署」的企業來說，導入成本從「改寫整個應用層」降為「換 base URL」。另一個值得注意的底層是 iroh。它本質上是「應用層的 Tailscale」——基於公鑰定址、QUIC 傳輸、自帶 NAT 穿透，把 P2P 連線複雜度藏到一個 endpoint 之後。Mesh LLM 沒自己造這層輪子，而是站在 iroh 之上，這跟很多類似計畫「為了 P2P 結果網路層品質一團亂」是鮮明對比。

數據解讀與質疑作者 i386 在 HN 上揭露的實測數據值得拆開看：

• Qwen 235B A22B（MoE 235B/22B）：在 2 個節點的 split 配置下跑到 16 tok/s
• GLM 5.2（實驗中）：同樣 split 架構約 10 tok/s
• 硬體：M3 Ultra（256GB 統一記憶體）+ M1 Ultra（128GB 統一記憶體），1Gbit Ethernet 串接這組數字說明幾件事：

1. 記憶體頻寬才是 LLM 推論的瓶頸。M3 Ultra 之所以值錢，是因為 800Gbps 統一記憶體頻寬，比 M5 頂規多一倍。Split 到兩台機器後，跨機傳輸只剩 1Gbit Ethernet（約 0.1GB/s 實測），等於被網路掐住脖子——所以 235B 模型在 split 模式才勉強 16 tok/s，比單機慢很多。
2. 量化策略很關鍵。他們用 Q2 但對「敏感張量」保留 Q8，這是 llama.cpp 社群近半年摸索出的折衷：對大多數 layer 拼命壓，但 attention 相關的張量不能壓太低，否則長 context 直接崩。
3. Metro latency 是甜蜜點。5ms 模擬下的 split「效果很好」，但全球 WAN 上就會被打趴。這意味著這套架構對「同一城市內的幾台機器」最有用，跨國分散就別想了。社群也丟出關鍵質疑：

• 公平性問題：如果我貢獻 1/8 VRAM，能保證拿到至少 1/16 推論配額嗎？這是公開 mesh 的經濟模型核心問題，目前沒看到白皮書說清楚。
• KV cache 切分：Lerc 指出，目前架構沒明確談 KV cache 在 split 下怎麼處理。如果每層獨立 cache，理論上能 pipeline 化跑多個查詢，把 throughput 拉回來。但這要重寫 runtime，目前還在 TODO 狀態。總結：Mesh LLM 不是要取代 OpenAI API，而是要讓「不想把 prompt 送到別人機器上」的場景變得可行。對於內部敏感資料、邊緣運算、或單純想把研究室那幾台 Mac Studio 串起來用的團隊，這是 2026 年少數看起來真的有在動手的方案。但離 production 還有一段路——特別是公平性、KV cache 切分、跨 WAN 效能三個面向還沒收尾。

參考資料：Mesh LLM 部落格原文｜Mesh LLM GitHub｜iroh 官方文件｜HN 討論串（181 points）