mesh-llm入門: 遊休GPUをP2Pで束ねてOpenAI互換APIを作る

こんにちは。

もるふぉです。

「家のRTX 4090と、実家の古いM1 Max、オフィスの余ってるA6000。全部束ねて235Bクラスのモデルが動いたら面白い」——そう思ったことがある人は、今週いちばんアツいニュースを見逃してます。

2026年7月11日、n0-computerがirohのP2Pネットワーク上に構築した分散推論ランタイム「Mesh LLM」を発表しました。

Rustバイナリを配って起動するだけで、手元の遊休GPUがひとつのOpenAI互換APIエンドポイントに化けます。

この記事では、Mesh LLMが何者でなぜirohと組んだのか、既存のexoやPetalsと何がどう違うのかを実務で選定する視点から整理します。

Mesh LLM: distributed AI computing on iroh

How Mesh LLM pools existing GPU resources across machines into a single OpenAI-compatible API, built on iroh.

www.iroh.computer

mesh-llmとは何か：irohが解決した分散推論の課題

Mesh LLMは、複数マシンに散らばったGPUをP2Pネットワークで束ね、単一のOpenAI互換APIとして公開する分散推論エンジンです。

実装はRust、配布形式は単一バイナリ（公式ブログ記載値で約18MB）、ライセンスはApache-2.0。

デフォルトで localhost:9337/v1 にエンドポイントが立つので、既存のOpenAI SDKやLangChainのbase_urlを差し替えるだけで接続できます。

GitHub - Mesh-LLM/mesh-llm: Distributed AI/LLM for the people. Share compute privately or publicly to power your agents and chat.

Distributed AI/LLM for the people. Share compute privately or publicly to power your agents and chat. - Mesh-LLM/mesh-llm

github.com

これまでの分散推論の問題（NATの壁・設定の複雑さ）

exoやPetalsを一度でも試したことがある人なら、ここで折れた記憶が一度はあるはずです。

Petalsはpublicなswarmに参加する形式で自宅ホームラボへの応用がしにくく、exoはApple Silicon優遇の色が強い。

llama.cppのrpc-serverはプロトコルこそシンプルですが、複数拠点で使おうとするとポート開放とVPN設定が待ち構えます。

「GPUを持ち寄る」の前に「ネットワークをどう繋ぐか」で消耗するのが従来の実態でした。

Mesh LLMはそこを丸ごとひっくり返します。

irohがQUICとNAT越えで変えたこと

Mesh LLMがこの摩擦を消せているのは、下回りにirohを採用しているからです。

irohはIPアドレスではなく公開鍵でピアを識別するQUICベースのP2Pライブラリで、リレーサーバー経由のホールパンチングでNAT越えを自動化します。

QUIC + TLS 1.3による端点間暗号化、ストリーム多重化、そしてALPNで複数プロトコルを同一エンドポイントに同居させられる設計。

「鍵をダイヤルする」——この設計思想が、拠点をまたぐ分散推論と非常に相性がいい。

ポート開放やVPN構成なしで、遠隔地のマシンをその場でクラスタに合流させられます。

この「土台の選択」が、Mesh LLMの面白さの核心です。

Rust製18MBバイナリが意味すること

「Rustで書かれた単一バイナリ」という一行に、実務上のメリットがかなり詰まっています。

依存ゼロ配布のメリット（Docker・Python環境不要）

Python製の分散推論ツールを新しいマシンにセットアップした経験がある人なら、CUDAのバージョン合わせとPyTorchのwheel探しで半日溶かした記憶があると思います。

Mesh LLMは単一バイナリなので、curlで落として実行するだけで動く。

Dockerイメージも、Python仮想環境も、pipの依存解決も要らない。

CI/CDに組み込むときも、Dockerfileが数行で書けます。

exoでセットアップを諦めた経験がある人なら、この差は体感で分かるはずです。

エンジニアの視点で見たバイナリ設計の正しさ

公式ブログ記載の約18MBというサイズは、Rustのstatic linkingとCUDAカーネルを外部に切り出す設計をきちんとやった結果です（現在のリリース版はさらに増えている）。

推論ランタイム本体をスリムに保ち、GPU依存の重い部分は実行時にロードする。

この分離ができているから、CPUのみのマシンをメッシュに混ぜたときにも「ルーティング専用ノード」として素直に振る舞います。

設計の判断が運用の柔軟性に直結している——「18MB」という数字の裏にある選択が、そのまま現場での自由度に繋がっています。

既存OpenAI SDK・LangChainとの接続方法

実務で一番効くポイントです。

Mesh LLMを立てても、既存アプリのコードはほぼ書き換え不要です。

エンドポイントをlocalhost:9337に切り替えるだけ

Mesh LLMは起動時に localhost:9337/v1 にOpenAI互換のエンドポイントを立てます。

既存コードでやることは、base_urlを差し替えるだけ。

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:9337/v1",
    api_key="mesh-llm",  # ダミーで可
)

response = client.chat.completions.create(
    model="qwen2.5-72b-instruct",
    messages=[{"role": "user", "content": "こんにちは"}],
)

裏側では、要求されたモデルを持つピアが自動で選ばれ、必要ならパイプライン分割されて応答が返ります。

呼び出し側のコードからは、OpenAI APIを叩いているのと区別がつきません。

エージェントフレームワークとの実用シナリオ

LangChain、LlamaIndex、DifyといったツールはOpenAI互換エンドポイントを前提にしているものが多く、そのまま差し込めます。

社内Botのバックエンドを手元のGPUクラスタに置き換える、エージェントのツール呼び出しを自宅の遊休GPUで捌く、みたいな構成が現実的なコストで組める。

従量課金APIを叩き続けていた部分を、電気代だけで動かせる形にリプレイスできます。

「base_urlの1行だけ変える」で、ここまで変わります。

mesh-llmの3つの動作モード（ローカル/ルーティング/分割実行）

Mesh LLMは1つのバイナリで3つの動作モードを内包しています。

呼び出しが来たときに、そのノードが自分で処理するか、他ノードに転送するか、パイプラインで分割するかを自動判定します。

ローカル実行モード：シングルGPUでそのまま動く

対象モデルが自マシンのVRAMに収まるなら、ローカル実行です。

外部通信は発生しません。

動作確認や小規模モデルの日常運用はこのモードで完結します。

ルーティングモード：すでにモデルを持つピアに転送する

自分がモデルを持っていないケースでは、同じメッシュに参加している別ノードでそのモデルをロード済みのピアを探し、リクエストごと転送します。

呼び出し側から見ればエンドポイントは変わらず、内部で経路だけが変わる。

手元のノートPCから「あの重いモデルはリビングのワークステーションで動かす」といった振り分けが、明示的なプロキシ設定なしで成立します。

Skippyによるパイプライン分割：235Bを複数台で動かす仕組み

Mesh LLMの本命はここです。

内部名「Skippy」と呼ばれる分割モードでは、単一マシンのVRAMに収まらない巨大モデルをレイヤー範囲で切り、複数ノードにまたがせてパイプライン実行します。

アクティベーションがステージ間を流れていくイメージです。

公式では500M〜235Bまで40以上のモデルが動作対象として挙がっており、家庭用GPUを3〜4台束ねれば70B級までは現実的な射程に入ります。

モード設計が分かると、他ツールとの差も具体的に見えてくる。

exo・Petals・llama.cpp rpcと何が違うか（比較表）

ネットワーク技術の違い（QUIC vs TCP/gRPC）

QUICはTCPと違ってストリームごとに独立したフロー制御を持つので、パイプライン推論のようにステージ間で複数の活性値が並行に流れるワークロードとは筋がいい。

Head of Line blockingが起きにくいという意味です。

exoやllama.cppのTCPベースだと、拠点間で少しでもロスがあると全ストリームが引きずられます。

対応モデル形式（GGUF・safetensors・vLLM）

Mesh LLMはGGUFとsafetensorsの両方に対応しており、Hugging Faceからダウンロードしたモデルをそのまま食わせられます。

exoはApple Silicon＋MLX優遇、Petalsは公開swarmで扱えるモデルが限られる。

「持ってるモデルがそのまま使えるか」で選ぶなら、mesh-llmが素直です。

NAT・ファイアウォール越えの難易度

自宅と実家、あるいは自宅とオフィスをまたぐ構成を組もうとした瞬間、他ツールは急にハードルが上がります。

mesh-llmは公開鍵さえ交換すれば繋がる。

拠点をまたぐNAT越え構成なら、現状これが最も摩擦が少ない選択肢です。

パイプライン並列とMoEエキスパート並列の違い

分割実行と一口に言っても、モデルアーキテクチャによって最適な分け方が変わります。

ここを押さえておくと、Mesh LLMの動作を裏で追いやすくなります。

Denseモデルはなぜレイヤー分割なのか

Llama系のようなDenseモデルは、全レイヤーが順番に処理される直列構造です。

だからレイヤー範囲でノードに割り振り、活性値を次段へ渡す「パイプライン並列」が素直な選択になります。

いわば、工場の流れ作業ラインをマシン間に分散させるイメージです。

Skippyがやっているのはまさにこれで、モデルグラフを見て各ノードのVRAM容量に合わせて分割点を決めます。

MoEモデルはなぜエキスパートシャーディングなのか

一方、MixtralやDeepSeek系のMoE（Mixture of Experts）モデルは、レイヤーごとに複数のエキスパートFFNが並列に配置されていて、入力トークンごとに使うエキスパートが選ばれます。

この形状なら「エキスパートを別ノードに分ける」エキスパート並列のほうが通信量を抑えやすい。

DenseモデルへのパイプラインはSkippyで実装済みで、MoEのエキスパートシャーディングはロードマップ上で開発が進行中です。

ユーザー側で分散戦略を書く必要はなく、完成すれば自動で切り替わる設計になっています。

mesh-llmを今すぐ使うべきか：限界と向いているユースケース

熱狂だけでは仕事にならないので、正直な線引きも書いておきます。

レイテンシとスループットの現実的なトレードオフ

拠点をまたぐ構成は、ネットワークのRTTがそのままレイテンシに乗ります。

同一LAN内なら数十ミリ秒で済むところが、家と実家をまたぐと数百ミリ秒。

パイプライン並列はステージ数だけ通信が発生するので、リアルタイム対話用途では体感差が出ます。

向いている用途（バッチ処理・ホームラボ実験・コスト削減）

バッチでの要約・分類・埋め込み生成、非同期のエージェント処理、モデル評価のスイート実行あたりは相性がいい。

夜間に大量トークンを流したい系のワークロードは、遊休GPUの活用先として理想的です。

ホームラボで巨大モデルを触ってみたいという目的なら、迷わず選んでいい選択肢です。

まだ向いていない用途（低レイテンシのリアルタイム推論）

音声対話やコード補完のような、100ms単位のレスポンスが要る用途は現時点では厳しい。

この領域は素直にvLLMやTGIをシングルノードで立てるか、専用のホスティング推論を使うほうが実務的です。

まとめ：irohが開いた「個人が持てる分散推論クラスタ」

Mesh LLMのおもしろさは、機能の派手さよりも「土台の選択が正しい」ことにあります。

irohというP2P基盤があったから、Rustの単一バイナリを配って起動するだけで、NATの向こう側にあるGPUまで束ねられるようになった。

しかもインターフェースはOpenAI互換で、既存のSDKやエージェントフレームワークがそのまま繋がる。

個人や小さなチームでも「自分たちのクラスタ」を持てる時代が、道具立ての面で本当に揃ってきました。

次の週末、机の下で埃をかぶってるマシンに curl でバイナリを落として、1ノードだけメッシュに参加させてみるところから始めてみてください。