ハクソク

世界を動かす技術を、日本語で。

メッシュLLM：iroh上の分散AIコンピューティング

2026年7月12日原文(iroh.computer)

概要

  • Mesh LLM は、手持ちのGPUを活用し分散型LLM運用を実現するソリューション
  • OpenAI互換API を通じて、ローカルとクラウドを意識せず利用可能
  • プラグインアーキテクチャ で柔軟な機能追加とモデル管理が可能
  • irohネットワーキング により、セキュアなP2P通信とNAT越えを自動化
  • コスト削減・プライバシー確保・ロックイン回避 を重視するチーム向け

Mesh LLMによる分散型LLM運用の新提案

  • 従来のLLM運用は データセンター依存、API課金、外部GPUリソース利用が前提
  • モデルバージョン変更やデータの管理、ハードウェア選択における コントロール喪失
  • 利用量増加に伴う コスト増大、柔軟性の欠如
  • Mesh LLMは、 手元や社内にあるGPU・メモリを統合 し、1つのOpenAI互換APIとして提供
  • ノード追加の柔軟性 ：最初は1台から、後で台数拡張可能
  • 自動ルーティング ：モデルをローカル/他ノード/分割実行で最適運用
  • コスト削減 と プライバシー強化 を両立

Mesh LLMの技術的特徴

  • GPUリソースのプライベート/パブリック共有 による効率的な計算資源活用
  • OpenAIクライアントは http://localhost:9337/v1 に接続するだけで利用可能
  • irohエンドポイント を活用した分散処理
    • ローカル実行
    • モデルロード済みピアへのルーティング
    • 大規模モデルの パイプライン分割実行（Skippyモード）
  • プラグインアーキテクチャ ：manifestで機能宣言、MCP/HTTP/メッシュイベント経由で呼び出し
  • 40種類以上のモデル をカタログ収録、ノートPC対応の小型モデルから235B規模のMixture-of-Expertsまで対応

分割実行（Skippyモード）の仕組み

  • 巨大モデル をレイヤー単位でノードごとに分割配置
    • 例：レイヤー0-15をノードA、16-31をノードBで担当
  • アクティベーション伝播 で複数ノードが協調して1つの推論を実行
  • OpenAIクライアントは 分割実行の存在を意識せず、単一APIとして利用可能

irohによるセキュアな分散ネットワーク

  • 各ノードは irohエンドポイント で識別、公的鍵がIDとなる
  • 中央サーバー不要、P2Pで直接接続
  • NAT越え・リレー中継 を自動化
    • 世界中のノード間で直接・安全にQUIC通信
  • 3種類のALPN で用途別プロトコルを分離
    • mesh-llm/1：メインメッシュ（ゴシップ・ルーティング等）
    • mesh-llm-control/1：オーナー制御プレーン
    • skippy-stage/2：分割モデル用低遅延伝送

メッシュ内部の通信ストリーム

  • バイト先頭で種別判別、1接続で複数用途の通信を多重化
    • 例：GOSSIP（ピア情報共有）、TUNNEL_HTTP（推論リクエスト転送）、ROUTE_REQUEST（ホストモデル照会）など

Mesh LLMのメリットと導入方法

  • irohによる認証・NAT越え・セキュア通信 を自動化
  • ネットワーク構成や通信経路を意識せず、ローカルと同様に利用可能
  • 信頼できるピア管理・バージョン互換性管理 も独自ゴシップ層で制御
  • 18MB程度の軽量ソフトウェア、パブリック/プライベートメッシュ構築が容易
  • OpenAIクライアントと互換、将来的にACP（エージェント標準）対応予定
  • P2P志向・ロックイン回避・オープンな拡張性 を重視

参考：Irohネットワーキングライブラリの概要

  • Iroh は「どこでもダイヤル」可能なネットワーク抽象化ライブラリ
  • 既成プロトコルの組み合わせ や独自プロトコル実装も可能
  • オープンソース、数十万台規模での商用運用実績
  • ドキュメント・コード・Discordコミュニティ でサポート

まとめ

  • Mesh LLMは 手持ちのGPUを最大限活用し、分散型・セキュア・オープンなLLM運用 を実現
  • コスト削減・プライバシー確保・柔軟な拡張性 を求める企業や開発者に最適

Hackerたちの意見

パフォーマンス情報がないのが気になるな。おそらく、他の大きなモデルを動かす方法に比べて、めちゃくちゃ遅いんじゃないかな（例えば、システムRAMを使ったり、ディスクからストリーミングしたりする方法に比べて）。消費者向けのネットワーク、10ギガビットイーサネットですら、ローカルのRAMやディスクに比べたらめっちゃ遅いよね。スプリットモデルで1秒あたり1トークンとか？それ以下？ 編集: 数字を見つけた。モデルリストの中で、Qwen 235B A22Bは「MoE 235B/22B、2ノードで16トークン/秒で実証済み」と言ってる。ノードが何か、どんなネットワーク接続かは書いてないけど、これはなかなかのスピードだね。インタラクティブに使うにはちょっと不安だけど、かなり近い感じ。

└

パフォーマンスはざっくりと予測できるはず。オートリグレッシブデコーディング中は、トークンごとにネットワーク越しに約2 × hidden_size × num_shardsバイトを転送する必要があるよ。それをプレフィル中にチャンクサイズで割る感じ。

└

これは自宅のラボで、機械間のレイテンシとジッターを5msにシミュレートして行ったものだよ。ノードがメトロレイテンシのWANにあるなら、スプリットはかなりうまくいくけど、グローバルWANではそんなに速くない。アイデアとしては、専用のRDMAやNVLINKファブリックなしでいくつかのマシンを使って、自分のハードウェアで大きなモデルを提供し、他の人と共有できるってこと。今は、ラボ環境でGLM 5.2に取り組んでいて、同じスプリットで約10トークン/秒出てるよ。

└

それ、AMD Ryzen AI 9 HX 370（Framework 13の中）で得られる速度と同じくらいだよ。Qwen3.6-35B-A3Bでやってるから、もっと大きなモデルで同じことをするのは…

└

パフォーマンス情報が欠けてるのが気になる。大きなモデルを動かす他の方法よりも、ずっと遅いんだろうな（例えば、システムRAMを使ったり、ディスクから何かをストリーミングしたりするのを含めて）。必ずしもそうじゃないと思うし、これが当てはまらない設定もたくさんあると思う。理由を説明するね： - 重みをRAMやNVMeにオフロードすると、各トークンを処理するたびに、遅いストレージからGPUに重いデータを転送する必要がある。だから、転送帯域幅がボトルネックになる（それはDRAMのメモリ帯域幅か、ディスクの読み取り速度）。 - 分散セットアップを使うと、重みは各マシンのVRAMに残るから、重みのために重要なのはGPUのメモリ帯域幅で、これは上で話した2つの帯域幅よりもずっと高い。だから、ここではボトルネックにはならない。1つのデバイスにあるレイヤーのデータを次のデバイスに転送する必要があるけど、そのデータ量は重みよりずっと少ない（キロバイト単位のデータで、ギガバイトじゃない）から、ネットワークのスループットは制限要因にはならない。制限要因はネットワークの遅延だね：モデルを4つのデバイスに分けると、トークンごとに3倍のネットワーク遅延が発生する。もし1msの遅延のネットワークなら、トークンごとに3msの遅延になる。つまり、推測デコーディングなしでの推論速度の理論的上限は30tps（この理論的限界は計算自体が瞬時に行われることを前提としている）。だから、インターネット上では実用的じゃない可能性が高い（遅延が高すぎる）けど、ローカルや企業のネットワークで推測デコーディングを使えば、全然動くと思う。編集：上記はトークン生成についての話で、プリフィルやプロンプト処理では分散セットアップがほぼ確実に勝つだろうね（この場合、ネットワークの遅延は加算されないから）。

Mesh LLMの貢献者の一人で、質問があれば喜んで答えるよ。大きなモデルをノード間で分割するためのスキッピーエンジンを作ったんだ。

└

これはすごいね！いろんなエピックやモデルがあるラボを持ってるけど、こうやってまとめるのは素晴らしい。お疲れ様！

└

kvキャッシュの実装についてはあまり詳しくないんだけど、レイヤーごとに効果的に別々のキャッシュを動かしてるの？もしそうなら、計算とデータサイズ的にうまく分割できそうだし、唯一の遅延は検索レイヤーが順番を待つことになると思う。パイプライン化すれば、複数のクエリを同時に処理できるかも。誰か、n段階のパイプラインで各クエリを1つずつオフセットして処理してる人いる？

└

気になるんだけど、もし機械の1つが推論中にダウンしたら、フォールトトレランスはあるの？動的にルーティングできるのか、それともただリトライするだけなのかな？

└

これ、めっちゃクールなプロジェクトだね！IPFSの関連がまた復活してるのを見るのは嬉しい。いくつか質問があるんだけど、1.) プライバシーはどうなってるの？こうやって計算を分散させると、計算グラフに関わる全員が計算されている順序を知ることになるよね。2.) 悪意のあるアクターがモデルのアクティベーションを汚染することに対する対策はあるの？

└

明らかに気になるのは、標準的なモデルで異なるネットワーク条件下でのパフォーマンスがどうなるかだよね。ベンチマークはどれくらいやったの？主にレイテンシーに影響されるのか、それとも分散されているせいで全体のスループットがGPUのキャパシティを下回るの？

└

このエンジンのセキュリティがどうなってるのか気になるな。誰からでも入力を受け付けてるからね。llama.cppのRPCレイヤーは、公開環境で動かすべきじゃないって言ってるみたい（おそらく、低レベルでGPUでRCEが起こる可能性があるからだと思う）。

Hacker Newsで議論の続きを見る