はじめに
巨大なLLMを動かすにはA100やH100のような高性能GPUが必要。これが今までの常識でした。
しかし「使っていないGPU」は身の回りに大量にあります。ゲーミングPCの日中の空き時間、会社のワークステーションの夜間、研究室のGPUクラスタの低い稼働率。こうした余剰リソースを束ねて1つの推論エンドポイントにする。それがmesh-llmの発想です。
2026年4月にGIGAZINEやHacker Newsで話題になり、GitHubで公開されています。この記事では、mesh-llmの技術的な仕組みを深掘りしつつ、既存ツールとの違いやセキュリティ上の注意点まで整理します。
mesh-llmとは
mesh-llmは、複数のPCにあるGPUリソースをネットワーク経由で束ね、分散推論を実現するシステムです。Rustで実装されたコアシステムがllama.cppのフォーク版と連携して動作します。
主な特徴は以下の通りです。
- モデル構造とノード構成から最適な並列化戦略を自動選択
- OpenAI互換APIを搭載（
http://localhost:9337/v1で既存ツールからそのまま利用可能） - トークンベースのプライベートメッシュで信頼できるノードだけを招待
- マルチモデル対応（異なるノードで異なるモデルを同時に提供）
- Webコンソール（ポート3131）でトポロジ、VRAM使用率をリアルタイム監視
なぜ分散推論が注目されるのか
LLMのパラメータサイズは増加の一途をたどっています。DeepSeek V3は671Bパラメータ、Qwen3-MoEも数百Bクラスのモデルが登場しています。一方、個人が購入できるGPUのVRAMは限られています。
| GPU | VRAM | 概算価格 |
|---|---|---|
| RTX 4090 | 24GB | 約30万円 |
| RTX 5090 | 32GB | 約40万円 |
| A100 (クラウド) | 80GB | 約500円/時間 |
70Bパラメータのモデルをfp16で動かすには約140GBのVRAMが必要です。RTX 4090が6枚相当になります。クラウドGPUのレンタルも時間単価が高く、常時利用には向きません。
この余剰GPUを集約して1つの推論基盤にするのがmesh-llmの着眼点です。
技術的な仕組み：2つの並列化戦略
mesh-llmはモデルの種類を自動判定し、最適な並列化戦略を選択します。この自動選択がmesh-llmの核心であり、ユーザーは並列化方式を意識する必要がありません。
パイプライン並列（Dense Model向け）
Llama系やQwen系のDenseモデルに適用される方式です。モデルのレイヤーを複数ノードに分割し、データを順番に流していきます。
データの流れは次の通りです。
- 入力トークンがノードA（前半レイヤー担当）に送られる
- ノードAが中間表現（hidden states）を計算し、ノードBに転送する
- ノードB（後半レイヤー担当）が最終出力を生成する
各ノードに割り当てるレイヤー数はVRAM容量に比例して自動決定されます。最もVRAMの大きいノードがコーディネーターとなり、llama-serverを実行します。他のノードはRPCサーバーとして割り当てられたレイヤーのみをローカルディスクから読み込みます。
この方式のボトルネックはノード間のデータ転送です。各トークン生成ごとに中間表現のやり取りが発生するため、ネットワーク帯域幅が直接スループットに影響します。mesh-llmでは中間テンソルをピアツーピアで直接転送する最適化を実装しており、コーディネーター経由のリレーを排除しています。
エキスパート並列（MoE Model向け）
DeepSeek V3やQwen3-MoEなどのMixture of Expertsモデルに適用される方式です。パイプライン並列とは根本的にデータの流れ方が異なります。
MoEモデルは多数のエキスパート（専門的なサブネットワーク）を持ち、入力に応じてルーターが一部のエキスパートだけを活性化します。mesh-llmはこの構造を利用して、以下のように分散配置します。
- GGUFヘッダからMoEモデルを自動検出し、ルーティング統計を読み取る
- 頻繁に使われるコアエキスパートは全ノードに複製する
- 残りのエキスパートを各ノードに分散配置する
- 各ノードがトランク（共有部分）+ 割り当てられたエキスパートサブセットを持つ独立したllama-serverを実行する
この方式の決定的な利点は、推論中のノード間通信がゼロになることです。各ノードが独立して推論を実行するため、ネットワークレイテンシの影響を受けません。セッションはハッシュルーティングでノードに振り分けられ、KVキャッシュの局所性も確保されます。
2つの方式の比較
| 観点 | パイプライン並列 | エキスパート並列 |
|---|---|---|
| 適用モデル | Dense（Llama, Qwen等） | MoE（DeepSeek V3, Qwen3-MoE等） |
| データの流れ | レイヤー間で中間表現を順次転送 | 各ノードが独立して推論を完結 |
| 推論中のノード間通信 | 毎トークンで発生 | ゼロ |
| ネットワーク帯域の影響 | 大きい（帯域がスループットに直結） | 小さい（初期ロード時のみ） |
| 最低帯域の目安 | 10Gbps推奨 | 1Gbpsでも実用的 |
| レイテンシ感度 | 高い | 低い |
ネットワークレイテンシの設計判断
mesh-llmはネットワーク品質に対して明確な設計判断を持っています。
80msレイテンシキャップ
mesh-llmはノード間のレイテンシに80msのハードキャップを設けています。この閾値を超えるノードはモデル分割には参加させず、APIクライアントとしてのみ機能します。
この設計判断の背景には、HTTPストリーミングとRPCのレイテンシ特性の違いがあります。READMEでは「HTTPストリーミングはレイテンシ耐性があるが、RPCはレイテンシが乗算される」と説明されています。パイプライン並列ではトークン生成ごとにRPCラウンドトリップが発生するため、80msを超えるレイテンシは致命的な性能劣化を招きます。
帯域幅による実用性の違い
パイプライン並列とエキスパート並列で、ネットワーク要件は大きく異なります。
- MoEモデルのエキスパート並列では、推論中のノード間通信がゼロです。したがって1Gbpsの回線でも10Gbpsでもトークン生成速度にほぼ差が出ません。モデルの初期ロードさえ完了すれば、あとはローカル推論と同等です
- Denseモデルのパイプライン並列では、帯域幅が直接スループットに影響します。有線LANの1Gbps環境では実用的ですが、WiFiでは安定性に不安が残ります。10Gbps環境であれば、ほぼローカル推論に近い体験が得られます
実際の環境選択としては、MoEモデルであればWiFi環境でも十分実用的です。Denseモデルのパイプライン並列を使う場合は、有線LAN接続を強く推奨します。
ネットワーク最適化の実装
mesh-llmはネットワーク負荷を最小化するために複数の最適化を実装しています。
| 最適化 | 効果 |
|---|---|
| ゼロ転送GGUFローディング | モデル重みをネットワーク転送せずローカル読み込み（111秒→5秒） |
| RPCコール削減 | キャッシュ済みルックアップで1トークンあたり558回→8回に削減 |
| ピアツーピア転送 | 中間テンソルをコーディネーター経由せず直接転送 |
| 投機的デコーディング | 小さなモデルで候補生成→大きなモデルで検証（コードタスクで+38%、受容率75%） |
セキュリティモデル：パブリック vs プライベート
mesh-llmのメッシュには3つの構成方法があり、セキュリティレベルが異なります。この違いを理解することは実運用において非常に重要です。
パブリックメッシュ
mesh-llm serve --auto
--autoで起動すると、最も強力な公開メッシュを自動的に発見して参加します。--publishフラグで自分のメッシュを公開することもできます。
リスクは明確です。パブリックメッシュに参加すると、他ユーザーのリクエストが自分のノードで処理される可能性があります。逆に、自分の推論リクエスト（プロンプトの内容）が他ノードを経由します。パイプライン並列の場合、中間表現が他のノードに送信されるため、推論内容が間接的に露出するリスクがあります。
名前付きメッシュ（Buddy Mode）
mesh-llm serve --auto --mesh-name "poker-night"
名前でメッシュを発見・参加する方式です。全参加者が同じコマンドを実行するだけで接続できます。手軽ですが、メッシュ名を知っている人なら誰でも参加できるため、セキュリティは名前の秘匿性に依存します。社内LANなど限定的な環境での利用に向いています。
トークンベースのプライベートメッシュ（推奨）
# 1台目：メッシュを作成（招待トークンが表示される）
mesh-llm serve --model Qwen2.5-32B
# 2台目：トークンで参加（GPU提供）
mesh-llm serve --join <token>
# GPU非搭載PC：APIクライアントとして参加
mesh-llm client --join <token>
最初のノードがメッシュを作成すると招待トークンが発行されます。このトークンを知っているノードだけが参加できるため、最もセキュアな構成です。機密データを扱う場合や、本番環境での利用にはこの方式を使うべきです。
セキュリティのベストプラクティス
- 機密データを扱う場合はトークンベースのプライベートメッシュを使う
- パブリックメッシュには機密性のないタスク（公開情報の要約、コード補完等）のみ投げる
- 名前付きメッシュは社内LANなど、ネットワーク自体が信頼できる環境で使う
- 招待トークンはパスワードと同等に管理する
セットアップ手順（プライベートメッシュ）
インストール
curl -fsSL https://raw.githubusercontent.com/michaelneale/mesh-llm/main/install.sh | bash
バックグラウンドサービスとしてインストールする場合は以下の通りです。
curl -fsSL https://raw.githubusercontent.com/michaelneale/mesh-llm/main/install.sh | bash -s -- --service
2台構成で試す
1台目（メッシュの作成。招待トークンが表示される）:
mesh-llm serve --model Qwen2.5-32B
# → Invite token: abc123xyz... （このトークンを2台目に共有）
2台目（トークンで参加）:
mesh-llm serve --join abc123xyz...
GPU非搭載のPCからAPIだけ利用する場合:
mesh-llm client --join abc123xyz...
接続テスト
curl http://localhost:9337/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen2.5-32B",
"messages": [{"role": "user", "content": "Hello"}]
}'
設定ファイル
~/.mesh-llm/config.toml で永続的な設定が可能です。
version = 1
[gpu]
assignment = "auto"
[[models]]
model = "Qwen3-8B-Q4_K_M"
[[models]]
model = "bartowski/Qwen2.5-VL-7B-Instruct-GGUF/model.gguf"
mmproj = "bartowski/Qwen2.5-VL-7B-Instruct-GGUF/mmproj-f16.gguf"
ctx_size = 8192
ノード障害時の挙動
mesh-llmはノードの離脱を自動検出し、リバランスを行います。
- 各ノードはデマンドマップを持ち、どのモデルがメッシュ内で必要とされているかをゴシッププロトコルで伝播します
- デマンドシグナルはTTLで減衰するため、不要になったモデルは自然に消えます
- モデルの最後のサーバーが失われた場合、スタンバイノードが約60秒で検出し、自動的にプロモートされます
- 特定モデルへのリクエストが集中した場合、デマンドベースのリバランスが発動します
既存ツールとの比較
分散推論ツールはmesh-llm以外にも存在します。それぞれ設計思想が異なるため、用途に応じた選択が重要です。
比較
| 観点 | mesh-llm | Petals | exo |
|---|---|---|---|
| 実装言語 | Rust + C++ | Python | Python |
| モデル形式 | GGUF | Hugging Face | MLX/Hugging Face |
| 並列化方式 | パイプライン + エキスパート | パイプラインのみ | テンソル + パイプライン |
| MoEエキスパート並列 | あり（通信ゼロ） | なし | なし |
| プライベートメッシュ | トークンベース | プライベートスワーム | namespace分離 |
| プラットフォーム | macOS/Linux/Windows | Linux中心 | macOS（Apple Silicon）中心 |
| GPU対応 | CUDA, ROCm, Vulkan, Metal | CUDA中心 | Metal（Apple Silicon） |
PetalsはBitTorrentのようなP2Pアーキテクチャで、インターネット越しのボランティアノードを前提としたパブリックスワームが中心です。Llama 2 70Bで最大6 tok/sと報告されています。exoはApple Siliconに最適化されており、Thunderbolt 5でのRDMAによる超低レイテンシが特徴ですが、Linuxでは現時点でCPU実行のみです。
mesh-llmのユニークな点は、MoEモデルでのエキスパート並列（推論中通信ゼロ）、CUDA/ROCm/Vulkan/Metalの幅広いGPU対応、そしてトークンベースのプライベートメッシュによるセキュリティモデルの3点です。
制約と注意点
- リレー接続が約10時間で劣化するノードがある（既知のバグ）
- 現時点でGGUFフォーマットのモデルのみ対応
- MoEモデルのランキング最適化が未知のアーキテクチャで不十分な場合がある
- 80msを超えるレイテンシのノードはモデル分割に参加できない
まとめ
mesh-llmは「GPUを買い足す」以外の選択肢を提供します。手元にある複数のGPUをネットワークで束ね、1台では動かせないモデルを分散推論で実行する。特にMoEモデルではノード間通信ゼロのエキスパート並列が使えるため、WiFi環境でも実用的な速度が出ます。
PetalsやexoとはMoEエキスパート並列の有無、プライベートメッシュのセキュリティモデル、プラットフォーム対応の幅で差別化されています。まずは手元の2台のPCでトークンベースのプライベートメッシュを試してみてください。
# 1台目
mesh-llm serve --model Qwen2.5-32B
# 表示されたトークンを2台目で使う
mesh-llm serve --join <token>