7月12日、iroh.computerが「Mesh LLM: distributed AI computing on iroh」と題した記事を公開した。注目すべきは「Split Mode（Skippy）」と呼ばれるパイプライン分割推論機構だ。単一マシンに収まらない235Bパラメータ級のMixture-of-Expertsモデルを、手頃なマシン複数台に分割して実行しながら、クライアントからはlocalhost:9337/v1への単一OpenAI互換APIとして透過的に見せる。クラウドAPIのコスト・モデル制御・データ主権の問題に悩むチームにとって、現実的な自己ホスト型の選択肢となりうる設計が詳しく解説されている。
「手元のGPUをひとつのAPIに」というアプローチ
クラウドのLLM APIは手軽な反面、コストの増大・モデルの勝手なアップデート・データのコントロール喪失という問題を抱えている。オフィスや自宅に眠るGPUを持つチームが「これらをまとめてひとつのエンドポイントとして扱えないか」と考えるのは自然な発想だ。
Mesh LLMはその発想を実装したプロジェクトである。複数マシンのGPU・メモリをメッシュネットワークで束ね、**localhost:9337/v1** というOpenAI互換エンドポイントを提供する。既存のOpenAIクライアントは変更不要で、処理がどのマシンで実行されているかを意識する必要がない。
インストールサイズは約18MBと軽量で、パブリックメッシュへの参加とプライベートデプロイの両方に対応する。
推論リクエストの3つのルーティング
1つのリクエストは以下の3通りで処理される：
- ローカル実行 — 自マシンのGPUでそのまま推論
- ピアへのルーティング — 対象モデルをすでにロード済みの別ノードに転送
- パイプライン分割（Split Mode） — 単一マシンに収まらない大規模モデルを複数ノードに分割して実行
3番目の「Split Mode」（内部コード名：Skippy）が特に面白い。モデルをレイヤー範囲ごとにステージに分割し、「ノードAがlayer 0〜15、ノードBがlayer 16〜31…」という形でパイプラインを構成する。各ステージ間では活性化（activation）がストリームで流れ、クライアントからはすべてlocalhostへの単一APIに見える。235BパラメータのMixture-of-Expertsモデルも、このアーキテクチャで複数の手頃なマシンに分散実行できる。カタログには40種類以上のモデルが収録されており、ラップトップで動く0.5Bクラスから上記235Bクラスまで揃う。
なおSplit Modeは、ステージ間で活性化テンソルをネットワーク越しに転送する構造上、ノード間の帯域と遅延がスループットに直接影響する。後述のとおり専用ALPN（skippy-stage/2）を用いた低レイテンシ転送で対処しているが、WAN越えの高遅延環境での運用は現実的にはLAN・専用線環境が前提になると考えられる点は留意が必要だ。
ネットワーク層：irohとQUIC
メッシュのネットワーク基盤として使われているのがirohだ。「ダイヤルするだけで繋がる」をコンセプトにしたP2Pネットワーキングライブラリで、NAT越えのホールパンチング・リレーフォールバック・QUIC上の認証済み通信をまとめて提供する。各ノードは公開鍵をIDとして持ち、中央サーバーは存在しない。
Mesh LLMはQUICのALPN（Application-Layer Protocol Negotiation）で3種類のプロトコルを使い分けている：
| ALPN | 用途 |
|---|---|
mesh-llm/1 |
ゴシップ・ルーティング・HTTPトンネル・プラグインチャネル |
mesh-llm-control/1 |
オーナーコントロールプレーン（設定同期・所有権証明） |
skippy-stage/2 |
Split Mode用の低レイテンシ活性化転送 |
メインのmesh-llm/1接続内では、先頭1バイトのタグで双方向QUICストリームを多重化している。同一コネクションの上でゴシップ・推論リクエスト・ルートクエリ・ピアライフサイクルイベントが共存する設計だ。
| バイト | ストリーム種別 | 内容 |
|---|---|---|
0x01 |
GOSSIP | ピアのモデル・GPU・RTT・ケイパビリティのアナウンス |
0x04 |
TUNNEL_HTTP | ピアへのプロキシ推論リクエスト |
0x05 |
ROUTE_REQUEST | 「どのモデルをホストしているか？」の問い合わせ |
0x06 |
PEER_DOWN | 死活監視の通知 |
0x07 |
PEER_LEAVING | グレースフルシャットダウン |
0x08 |
PLUGIN_CHANNEL | プラグインRPC |
0x0e |
DIRECT_PATH_REQUEST | NAT越えのための直接アドレス共有 |
この設計の利点は「ピアへのルーティング」と「パイプラインの次ステージへの活性化ストリーミング」が、同じプリミティブ（irohのエンドポイントID指定）で表現できる点だ。ネットワーク層の複雑さをirohが吸収することで、Mesh LLM側のコードはエンドポイントIDを変えるだけでローカルとリモートを透過的に扱える。
インターネット越えの接続を安定させるため、異なるリージョンに2つのirohリレーを運用しており、直接接続できないノード同士のフォールバックパスを確保している。
現状と今後
ゴシップ層はirohの上にMesh LLM独自実装で構築されており、メッシュへの参加制御・バージョン互換性チェック・ピアの信頼管理を自前で行う。プラグインはマニフェストでケイパビリティを宣言し、ランタイムがMCP・HTTP・推論・メッシュイベントにわたるルーティングを処理する。
今後の計画として、irohのSwift SDKを用いたモバイルアプリの開発と、ACP（Agent Communication Protocol）への対応が挙げられている。ACPはAnthropicが2025年に提唱したエージェント間通信の標準仕様で（公式ドキュメント）、AIエージェントがタスク・コンテキスト・成果物を標準化されたメッセージ形式でやり取りするためのプロトコルだ。Mesh LLMがACPに対応することで、分散推論基盤がマルチエージェントワークフローの実行レイヤーとして機能する構成が視野に入る。
iroh本体はオープンソースで、すでに数十万台のデバイスで本番稼働している。ドキュメントはiroh.computer/docs、コードはGitHubで公開されている。
詳細はMesh LLM: distributed AI computing on irohを参照していただきたい。
