Mesh-LLM/mesh-llm とは何ですか？

複数マシンのGPUとメモリをプールし、localhost:9337/v1 で単一のOpenAI互換APIとして見せる分散推論ランタイム。単一ノードで収まるモデルを優先する設計と、収まらない場合のSkippyステージ分割の使い分けが導入判断の軸になる。

Mesh-LLM/mesh-llm は商用利用できますか？

できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。

Mesh-LLM/mesh-llm は今もメンテナンスされていますか？

されています。直近 1 日以内に新しいコミットがあります。

Mesh-LLM/mesh-llm はどのプログラミング言語で書かれていますか？

主に Rust です（GitHub の言語統計による）。

Mesh LLM レビュー: 分散LLM推論をOpenAI互換APIで提供するRust製ツール

ひと目でわかる

これは何？: 複数マシンのGPUとメモリをプールし、localhost:9337/v1 で単一のOpenAI互換APIとして見せる分散推論ランタイム。単一ノードで収まるモデルを優先する設計と、収まらない場合のSkippyステージ分割の使い分けが導入判断の軸になる。
誰に向いている？: 1台で収まらないGGUFモデルを手持ちの複数マシンで動かしたい、あるいはエージェントから単一のOpenAI互換エンドポイントを叩きたい場合に検討する価値がある。逆に、モデルが1台に収まるならmesh-llm serve --local-model-onlyで十分で、QUICもディスカバリも起動しない分だけ構成が単純になる。
商用利用できる？: できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている？: されています。直近 1 日以内に新しいコミットがあります。
何の言語で書かれている？: 主に Rust です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · Mesh-LLM/mesh-llm

Mesh LLMが埋めようとしている穴は「VRAMの合計が足りない」ではない

単一マシンに収まらないモデルを動かす方法は既にある。量子化を強める、CPUオフロードを増やす、あるいは複数台にレイヤを割る。Mesh LLMが扱うのは三番目で、READMEによればSkippyステージ分割として、大きなdenseモデルをパッケージ化されたレイヤステージとしてロードする。コーディネータが連続したレイヤ範囲を計画し、下流ステージを先に起動し、準備完了を待ってからステージ0のルートを公開する。対象読者は、家庭や小規模オフィスにGPU付きマシンが複数あり、それぞれは単独では足りないが合算すれば足りる、という状況の運用者だ。クラウドのGPU時間を買う代わりに、すでに持っているハードウェアのアイドル時間を使うという発想になる。

単一ノード優先というルーティング方針が、分散の複雑さを普段は隠す

READMEの「How the mesh works」は最初にSingle-machine fit firstを挙げている。1ノードがモデル全体をホストできるなら、ステージ間の通信なしでローカルに提供する。つまり分散レイヤは常時使われるものではなく、収まらない場合の逃げ道として存在する。その上で、各ノードは同じ/v1 APIを公開し、リクエストはmodelフィールドによってそのモデルを提供できるピアへルーティングされる。ノード間の転送はQUICでエンドツーエンド暗号化され、推論リクエスト、応答、分割モデルのアクティベーションを含む。Irohリレーは暗号化されたパケットを中継するがペイロードは読めない、と説明されている。運用者向けの設定とインベントリ操作はmesh-llm-control/1という追加レーンに分離され、公開メッシュの参加、ゴシップ、ルーティング、推論は公開メッシュプレーンに残る。これは混在バージョン間の互換性のためだとREADMEは述べている。

動かすまでの手順と、モードごとに何が起動するか

インストールはinstall.shまたはinstall.ps1をcurl/irmで流す。Apple Siliconはbrew install Mesh-LLM/tap/mesh-llm。その後mesh-llm setupを実行し、公開メッシュに参加して提供を始めるならmesh-llm serve --autoとなる。このコマンドはバックエンドのフレーバーを選び、必要ならモデルをダウンロードし、見つかった最良の公開メッシュに参加し、9337でローカルAPI、3131でWebコンソールを起動する。モデル一覧はcurl -s http://localhost:9337/v1/models | jq '.data[].id'で確認できる。サーバ配備では--headlessを付けてWeb UIを隠し、--consoleポートの管理APIだけ残す。ここで重要なのは、モードによって起動するコンポーネントが違う点だ。--local-model-onlyを指定すると、OpenAIフロントエンドとローカルのSkippyランタイム1つだけが起動し、QUIC、ディスカバリ、ピア維持、分割計画、プラグイン、リリース検索、Webコンソール、管理APIは起動しない。完全なモデルが検出されたローカル容量（または--max-vram）に収まらない場合、起動は失敗し、分散提供へのフォールバックはしない。また--local-model-only、--model、--gguf、--mmprojの値は絶対パスでなければならず、シンボリックリンクであってはならない。

公開メッシュと招待トークン式のプライベートメッシュは別物として設計されている

公開メッシュはNostrディスカバリで広告される。プライベートメッシュは招待トークンベースのままだ。mesh-llm serve --autoは公開メッシュに参加するが、mesh-llm serve --model Qwen3-8B-Q4_K_Mはプライベートメッシュを開始し、--publishを足すと自分のメッシュを公開し、--join <token>でトークン経由の参加になる。APIだけのクライアントとして動かすならmesh-llm client --autoがある。この分離は、他人のGPUに自分の推論を載せたくない場合と、逆に自分のGPUを公開したい場合で設定が明確に分かれることを意味する。ただしプライベート側のアクセス制御が招待トークン以外に何を含むのかは、READMEからは読み取れない。

Mixture-of-Agentsゲートウェイはプレビュー扱いで、本番経路には向かない

modelにmeshを指定すると、プロキシがメッシュ内の全モデルへ並列にファンアウトし、決定論的なロジックで仲裁して1つのOpenAI互換応答を返す。アービタはコードとして動き、別のモデル呼び出しではない。真の衝突が起きた場合だけリデューサLLMにエスカレートする。ツール呼び出しもパイプライン全体を通る。ただしREADME自身がExperimentalと明記し、動作、ルーティングのヒューリスティクス、エラーの形、チューニングノブはバージョン間で変わりうるとしている。安定したセマンティクスが必要なときは具体的なモデルIDを使えという指示も付いている。同じプロンプトを複数モデルに投げる用途では面白いが、応答の再現性を前提にするワークフローに組み込むのは現時点では勧められない。

向かないケース: モデルが1台に収まる、あるいはレイヤ分割できない

第一の落とし穴はSkippy分割の前提そのものだ。READMEによれば、レイヤパッケージのリポジトリにはmodel-package.jsonとGGUFフラグメントが含まれ、ピアは自分の担当ステージに必要な断片だけを取得する。つまり分割して動かすには、モデルがパッケージ化されている必要がある。例としてhf://meshllm/<repo>@<rev>という参照形式が示されている。手元の任意のGGUFをそのまま分割できるのか、それともパッケージ側の用意が要るのかは、READMEの記述だけでは判断できない。docs/SKIPPY_SPLITS.mdを読むまで、自分のモデルが対象になるかは確定しない。第二に、--local-model-onlyは容量不足時にフォールバックせず起動失敗する。これは意図的な設計で、単一ノードで完結させたいのに知らないうちに分散へ流れる事故を防ぐ。第三に、レイヤ分割はステージ間でアクティベーションを転送するため、ノード間の帯域とレイテンシがそのまま生成速度に効く。家庭内LANで足りるかどうかは構成次第で、READMEには具体的な要件の数値がない。

代替となる選択肢と、アプローチの違い

同じ「複数マシンで1つの大きなモデルを動かす」問題に対して、llama.cppのRPCバックエンドは別の解き方をする。レイヤをリモートのllama.cppプロセスへ委譲する構成で、モデルファイルは各ノードに同じものを置くのが基本になる。Mesh LLMのSkippyはパッケージから必要なGGUF断片だけをピアが取得する点が異なり、全ノードに全モデルを複製する必要がない。一方で、その利点はパッケージが用意されている場合に限られる。もう一つの比較軸はAPI面だ。vLLMやSGLangのような推論サーバは1台のマシン上でスループットを最大化する方向に最適化されており、複数ノードへの分割は想定外か、パイプライン並列として別途設定が要る。Mesh LLMは最初から「各ノードが同じ/v1を公開し、modelフィールドでルーティングする」という前提で組まれている。単一マシンのスループットを競うなら前者、手元の複数台を寄せ集めて1つのAPIに見せたいならMesh LLMという住み分けになる。

保守コストとライセンス、そして最初に確かめること

リリースはv0.76.0-rc9、rc8、rc7と、プレリリース候補が短期間で並んでいる。これは活発に動いている証拠であると同時に、破壊的変更が入りうる段階であることも意味する。実際、MoAゲートウェイについてはREADMEが挙動やエラー形状がバージョン間で変わりうると明記している。運用に組み込むなら、バージョンを固定してアップグレードを自分のタイミングで行う前提で考えるべきだ。アンインストールはmesh-llm uninstall --dry-runで内容を確認してからmesh-llm uninstall --yesを実行する。~/.mesh-llmの設定とIDデータは--purge-configを明示しない限り残る。ライセンスはApache-2.0で、特許許諾条項と変更点の明示義務を含む標準的な条件だが、これは法的助言ではないので、再配布や商用利用の判断は自組織の基準で行ってほしい。導入前に確認する順序はこうだ。まず対象モデルがSkippyのレイヤパッケージとして取得可能か、次に自分の配置が--local-model-onlyの絶対パス・非シンボリックリンク制約を満たすか、最後にノード間の帯域でステージ転送が実用速度に乗るか。三番目はREADMEに数値がないため、実際に動かして測る以外に方法がない。

編集部の結論

1台で収まらないGGUFモデルを手持ちの複数マシンで動かしたい、あるいはエージェントから単一のOpenAI互換エンドポイントを叩きたい場合に検討する価値がある。逆に、モデルが1台に収まるならmesh-llm serve --local-model-onlyで十分で、QUICもディスカバリも起動しない分だけ構成が単純になる。最初に確認すべきは、対象モデルのレイヤ分割がdocs/SKIPPY_SPLITS.mdの手順でパッケージ化できるか、そして--local-model-onlyで絶対パスと非シンボリックリンクという制約を自分の配置が満たすかどうかだ。

公式情報源

コミュニティノート