mesh-llm：余っているPCのGPUを束ねて巨大LLMを動かす分散推論の新ア...

mesh-llm：余っているPCのGPUを束ねて巨大LLMを動かす分散推論の新アプローチ #AI - Qiita 20 いいねしたユーザー一覧へ移動 20 X（Twitter）でシェアする Facebookでシェアする はてなブックマークに追加する more_horiz 記事を削除する close 一度削除した記事は復旧できません。 この記事の編集中の下書きも削除されます。 削除してよろしいですか？ キャンセル 削除する delete @ nogataka mesh-llm：余っているPCのGPUを束ねて巨大LLMを動かす分散推論の新アプローチ GPU AI 分散推論 LLM ローカルLLM 20 投稿日 2026年04月07日 はじめに 巨大な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> 参考リンク GitHub - michaelneale/mesh-llm mesh-llm Roadmap GIGAZINE - 複数のPCからリソースをかき集めて巨大なAIモデルをローカル実行できる「mesh-llm」 GitHub - bigscience-workshop/petals GitHub - exo-explore/exo mesh-llm Documentation 20 いいねしたユーザー一覧へ移動 20 comment 1 コメント一覧へ移動 新規登録して、もっと便利にQiitaを使ってみよう あなたにマッチした記事をお届けします 便利な情報をあとで効率的に読み返せます ダークテーマを利用できます ログインすると使える機能について 新規登録 ログイン 20 いいねしたユーザー一覧へ移動 20 more_horiz 記事を削除する close 一度削除した記事は復旧できません。 この記事の編集中の下書きも削除されます。 削除してよろしいですか？ キャンセル 削除する delete