hero

當大部分人在討論怎麼讓 GPU 更便宜、怎麼讓 API 降價的時候，Mesh LLM 問了一個不一樣的問題：如果不用買 GPU 呢？直接把你辦公室裡、桌子底下、儲藏室角落那些閒置的機器串起來，組成一張 P2P 推論網路。iroh 團隊把這件事的網路層做到了一個令人驚豔的程度——但網路層從來就不是分散式推論真正的瓶頸。

原文摘要

現在講到跑大語言模型，多數人腦中浮現的畫面是機房——一整排不屬於你的 GPU、按用量計費的 API、每個月穩定成長的帳單。你把 prompt 丟進一個黑盒子，然後祈禱價格、模型版本跟隱私政策都不要在你簽約之後偷偷改變。

對很多團隊來說，這是一筆爛交易。你交出控制權：模型什麼時候更新你管不著、資料流去哪你控制不了、底層硬體是誰的你也沒得選。用量越大帳單越肥，而你唯一能拉的槓桿就是「付更多錢」。

Mesh LLM 給了另一種形狀。它把你已經有的 GPU 和記憶體集中起來——你想加幾台機器就加幾台——然後對外暴露成一個標準的 OpenAI 相容 API。先啟動一個節點，之後再加更多。讓 mesh 自己決定模型要在你面前的機器跑、路由到其他節點、還是拆開來分散到好幾台機器上。

問題：AI 很貴，而且不是你的

主流的模型是龐然巨物。多數人透過介面或 API key 存取，付錢給大供應商跑所有東西。這很方便——同時也是一種投降。你控制不了模型何時更新、跑在什麼記憶體配置上、底下是什麼硬體。

很多依賴這些模型的企業和服務想要的正好相反：更多控制權、更高的可替換性、更低的成本。他們辦公室裡、儲藏室裡、桌子底下就躺著 GPU。缺的只是一個讓這些機器像一台一樣協同運作的方法。

Mesh LLM：模型自己跑

訴求很簡單：不用買更大的 GPU 也能跑更大的模型。在團隊內私下共享算力，或對外公開，拿來驅動 agent 和對話。把任何 OpenAI 客戶端指向 http://localhost:9337/v1，然後就不用管運算實際上發生在哪了。

底層機制是：Mesh LLM 把模型運算分散在一張由 iroh endpoint 構成的 mesh 上。一個請求有三種服務方式：

  • 本地執行：就在這台機器的 GPU 上跑。
  • 路由到對等節點：某個節點已經載入了模型，直接轉過去。
  • 管線拆分：把單一機器塞不下的超大模型，沿著網路拆到多台機器上，像一條管線一樣跑。

怎麼運作的

架構是插拔式的。Plugin 在 manifest 裡宣告自己提供什麼，runtime 啟動它們、路由呼叫、然後透過 MCP、HTTP、推論和 mesh 事件暴露能力。內建目錄收錄了 40 多個模型——從 5 億參數、筆電就能跑的小模型，到 2,350 億參數的 MoE 怪獸，全部包在裡面。

遇到怪物級模型時，Mesh LLM 有一個拆分模式（內部代號「Skippy」）。模型被按照層數範圍切成多個階段：0 到 15 層在一個節點、16 到 31 層在下一個、依此類推，串成一條管線。activation 從一個階段流向下一個階段，讓幾台規格普通的機器協力跑一個它們單獨根本塞不下的模型。OpenAI 客戶端完全看不到這些——它還是只跟 localhost 講話。

怎麼用 iroh 的

每一個節點——不管它是提供模型還是只發請求——都會啟動一個 iroh endpoint。這個 endpoint 就是節點的身分（一把公鑰），也是它唯一的網路接觸面。沒有中央伺服器。iroh 負責處理打洞、NAT 穿透和中繼回退，在任何兩個節點之間建立一條直接、已驗證的 QUIC 連線，不管它們坐在哪個網路後面。

為了讓這些在公開網路上也能穩定運作，Mesh LLM 跑了兩個 iroh relay 在不同地區，確保彼此連不上的節點永遠有一條附近的回退路徑。

整個協定跑在 QUIC 的 ALPN 協商上，定義了三條通道：

  • mesh-llm/1：主 mesh——gossip、路由、HTTP 隧道、plugin 通道。
  • mesh-llm-control/1：擁有者控制層，處理設定同步和擁有權證明。
  • skippy-stage/2：拆分模型時專用的低延遲 activation 傳輸通道。

在主 mesh-llm/1 連線裡面，所有東西都是雙向 QUIC 串流，用一個前導 byte 標記串流類型。一條連線同時處理 gossip、推論、路由查詢和節點生命週期事件，全部靠第一個 byte 分流：

  • 0x01 GOSSIP：節點公告（模型、GPU、RTT、能力）。
  • 0x04 TUNNEL_HTTP：代理到對等節點的推論請求。
  • 0x05 ROUTE_REQUEST：「你 host 了哪些模型？」
  • 0x06 PEER_DOWN：節點掛掉的通知。
  • 0x07 PEER_LEAVING：優雅關機通知。
  • 0x08 PLUGIN_CHANNEL：plugin 之間的 RPC。
  • 0x0e DIRECT_PATH_REQUEST：分享直接位址以進行 NAT 穿透。

精妙的地方在於它買到了什麼。iroh 在任意兩台機器之間提供已驗證、可穿透 NAT 的 QUIC 連線，用公鑰定址。所以「路由到某個節點」和「把 activation 串流給下一個管線階段」變成跟「跟 localhost 講話」一樣的基本操作——只是 endpoint ID 不同。網路層變成你不需要思考的東西。

iroh 提供安全傳輸層。Mesh LLM 在上面蓋了自己的 gossip 層，所以它可以精確控制誰能加入 mesh、哪些版本相容、哪些節點值得信任。

怎麼開始

使用者可以安裝輕量軟體（約 18 MB），選擇加入公開 mesh 或設定私有部署。系統對任何標準 OpenAI 客戶端表現為 localhost:9337/v1。

手機 app 正在路上，基於 iroh 的 Swift SDK。計畫是支援 ACP——那個還在發展中的 agent 標準——讓其他客戶端也能加入 mesh。貫穿全局的思微跟推動這個專案最初的動機一樣：更多 peer-to-peer、更少封閉伺服器、零鎖定。

iroh 本身是一個「撥任何裝置」的網路函式庫，開了就能用。你可以從現成的協定生態系中組合需要的功能，或是在乾淨的 dumb pipe 抽象層上從零打造自己的協定。iroh 是開源的，已經在數十萬台裝置的正式環境中運作。

城武觀點

第一，這條路是對的，但他們在解決一個已經被解決的問題。

Mesh LLM 最讓人驚豔的部分是 iroh 的網路層——P2P 打洞、QUIC 傳輸、gossip 路由、NAT 穿透，這些全部做得乾淨漂亮。讀完技術細節你會忍不住點頭：對，分散式推論的網路層就該長這樣。

但問題是：網路層從來就不是分散式推論真正的瓶頸。真正的瓶頸在模型層。

Skippy 的管線拆分模式——把模型沿層數切開、activations 跨網路送到下一個階段——在紙上看起來很美，在現實中會碰到物理的牆。大模型的每一層 activation 都是高維張量，transformer 的每一層都要等上一層的輸出。你今天把這些層拆到不同機器上，每一層的結果都要透過網路送到下一台機器，延遲會疊加。跑一個 70B 模型、拆成四台機器的管線，光是網路來回的延遲就足以讓每個 token 的生成時間變成單機的數倍。這不是 iroh 的錯——iroh 把 QUIC 連線做得再快，也無法改變「每一層 activation 都要跨機器傳」這個物理事實。

分散式推論的難題不在「怎麼把模型拆開」，而在「拆開之後 latency 會不會讓整件事失去實用價值」。目前來說：會。Mesh LLM 的方向是對的——去中心化推論是 AI 基礎設施必然的演化方向。但他們目前解決的這一段（網路層），是整個難題裡面最容易被解決的那一段。最難的那一段（模型拆分後延遲可接受的推論）留著沒碰，然後說「網路已經不是問題了」——這句以經有點像蓋好了高速公路之後說「車子在哪不是我的問題」。

第二，Mesh LLM 真正的價值不是省錢，是不想把資料送進別人機房。

仔細看 Mesh LLM 的訴求，你會發現它打的其實不是 cost play——至少不是主要賣點。P2P 推論要真的比 API 便宜，前提是你有足夠多閒置 GPU、網路品質穩定、模型拆分後的效率損失可控。這三個前提在大多數場景下都不成立。

但它有一個場景是成立的：你就是不想把資料送到 OpenAI 或 Anthropic 的伺服器。法規要求、客戶合約、軍事應用、醫療資料——這些場景裡成本不是第一考量，資料主權才是。Mesh LLM 讓你可以用自己機器跑推論，同時又不用每一台都塞得下完整模型。

這是 sovereignty play，不是 cost play。

但 sovereignty play 的市場有多大？願意為資料主權付出「自己管機器、自己搞定網路、忍受較高的推論延遲」這個代價的組織，數量有限。大部分的企業嘴上說在乎隱私，但月底看到 API 帳單跟自建成本一比，身體還是很誠實地刷了 OpenAI 的信用卡。Mesh LLM 最適合的那一小撮用戶——在乎主權到願意忍受 P2P 推論的各種不方便——是真實存在的。但把產品定位在這一小撮人身上，然後期待它變成「每個人都該用的東西」，這個期待本身就是整個專案最大的風險。

城武的未解檔案——iroh 把分散式推論的高速公路蓋好了，但上面跑的車都還在用撥接網路傳 activation。