眠っているGPUを束ねて大きなモデルを動かす — Blockのmesh-llmが示す「分散ローカル推論」の現在地

自宅にGPUを積んだマシンが2台あるのに、片方でしか大きなLLMを動かせない。これはローカルAI派が一度はぶつかる壁だ。70BクラスのDense modelを動かそうとするとVRAMが足りず、結局クラウドAPIに逃げる、という経験を筆者も何度もしてきた。

その壁にOSSで真正面から挑むプロジェクトが4月初旬に公開されて、静かに話題を広げている。Jack Dorseyが率いるBlockのエンジニアMichael Neale氏が公開した mesh-llm だ。

何をするツールなのか

mesh-llmは、複数マシンのGPUをピアツーピアでプールし、OpenAI互換APIとして公開するOSSプロジェクトである。ライセンスはMIT。

やっていることを一言で言うと、「1台に収まらないモデルを、ネットワーク越しに束ねたGPU群で動かす」。それだけならすでに分散推論の先行事例はあるが、mesh-llmは次の設計思想を打ち出している。

• 自動判定: モデルが1台のGPUに収まるなら、その1台でローカル実行する。収まらないときだけ分散する。
• モデル形状に応じた並列化: Dense model（例: Llama系、DeepSeek系）はレイヤーをVRAM比で分散配置。MoE model（例: Qwen3系、GLM系）はエキスパートごとにシャーディングし、ノード間のクロス通信を減らす。
• デマンド対応のリバランス: アクティブな需要があるモデルに、スタンバイノードが自動昇格する。
• プライベート/公開メッシュの両対応: 家族や社内だけのクローズドなメッシュも、オープンに共有する公開メッシュも作れる。

サポート済みのモデルファミリーはLlama、Qwen3、DeepSeek、GLMなど、ローカルAIコミュニティで主流の面々。gooseやClaude Codeといったコーディングエージェントのバックエンドにも差し込める。

書いてみて改めて思ったが、「家庭の余剰GPU」を現実のインフラ資源として扱う発想がOSSで動き始めているのは素直に面白い。

なぜBlock（Jack Dorsey）が

mesh-llmが話題になっている理由のひとつは、出元がBlockである点だ。

BlockはSquareとCashAppで知られる決済企業だが、ここ数年はオープンソースAIへの投資を強めている。同社のgooseというオープンソースAIエージェントもすでに走っており、mesh-llmはそのgooseの裏側に差し込むことを最初から想定した設計になっている。Block内部では、手元のgooseエージェントに対してmesh-llm経由で大規模モデルを叩かせる、という使い方が検証されているようだ。

Jack Dorsey自身の思想——中央集権の反対側に立つ、Bitcoin寄りの分散主義——とも一貫している。Blockがこういうプロジェクトを出してくることには、企業戦略というより設計哲学としての筋が通っている。

「家のPC＋Mac Studio＋もう1台」で動かせるようになるもの

個人の環境で想定できる構成を書き出してみる。

• Mac Studio (M2 Ultra, 192GB Unified Memory)
• ゲーミングPC (RTX 4090 24GB)
• サブ用Mac mini (M4, 24GB)

この3台をmesh-llmで束ねると、単体では動かせないサイズのモデル——たとえばLlama 3.1 70Bや、量子化次第ではさらに大きなサイズ——を、全体として「1つのOpenAI互換エンドポイント」として提供できる。

普段、この種の規模になるとクラウドAPIに頼るしかなかった。でもここで重要なのは、推論内容がネットワークの外に出ないということだ。個人情報や社内コードを巨大モデルに投げたいのに、プライバシー上の懸念でクラウドには置けない、というユースケースはかなり多い。mesh-llmは、その層を「家庭内のローカルAIインフラ」として解いてくる。

懸念点を正直に書いておく

当然、完璧なツールではない。いくつか触れておく。

まず、公式にExperimentalと明言されている。READMEにもROADMAPにも「これは参考実装で、実験段階です」と書かれている。本番業務に載せる段階ではない。

次に、ネットワークレイテンシへの依存が強い。MoEモデルはクロス通信を減らす工夫があるが、Dense modelをレイヤー分散する場合、ノード間通信の遅延がトークン生成速度に直撃する。家庭のGbE（1Gbps）環境で70Bを動かすと、VRAMが足りて動くことと、快適に動くことは別の話になる。10GbEや40GbEを家に持っていないと、体感上は「ゆっくり」になるケースが多いだろう。

そして、セットアップの敷居。一般の非エンジニアには、まだハードルが高い。ポート開放、peer discovery、モデルの事前配置、このあたりを全部手でやる必要がある。ここがUIレイヤーで自動化されれば爆発的に広がるポテンシャルはあるが、現時点では「知っている人の道具」である。

最後に、公開メッシュのセキュリティ・プライバシー設計。他人のGPUを借りるモード、あるいは自分のGPUを貸すモードは、推論内容が誰に見られるのか、悪意あるノードからの汚染をどう検知するのかが重要になる。現在のドキュメントでは、この領域はまだ発展途上という印象だ。

実現しそうな未来

触って眺めたあと、筆者が「これが進むとこうなるかも」と妄想したことを2つ書いておく。

ひとつは、ローカルAIコミュニティがクラスタ単位で動き始める可能性。今までローカルAIは「1人1マシン」の世界だった。mesh-llmのような層が整うと、「友人数人で束ねる」「勉強会サークルで束ねる」「会社の遊休GPUをまとめる」といった、クラスタとしての運用が現実化する。70Bや100Bクラスを「自分たちの資産」として扱える環境が、OSSで手に入るようになる。

もうひとつは、ローカル推論＋コーディングエージェントの統合である。mesh-llmはすでにgooseやClaude Codeの裏に挿す前提で作られている。つまり、クラウドに機密コードを投げずに、大きなモデルをコーディングエージェントに使わせる道筋がOSSで引けてきた、ということだ。守秘義務の厳しい受託開発や社内ツール開発で、この発想が効いてくる企業はそれなりにあると思う。

まとめると

mesh-llmは、今日から本番に載せるツールではない。ただ、「家庭に眠る余剰GPUを束ねて、大きなモデルをローカルで動かす」という方向にOSSが本気で投資し始めた、という事実の価値は小さくない。

クラウドLLMの料金が上がり続け、プライバシー要件が厳しくなる流れの中で、「複数台を束ねて自前で動かす」という選択肢がまともな選択肢になってきている。Apfel（Apple Silicon直接駆動）、OpenClaw（個人AIアシスタント）、litert-lm（Googleの軽量LLMランタイム）といった最近のローカルAI潮流と並べて眺めると、mesh-llmが埋めにきているのは「単体マシンでは足りない規模」という最後のピースだ。

experimentalのうちに触っておくと、半年後にどこで仕事に使えるかが見えてくる、そういうタイプのOSSだと思っている。