
大規模言語モデルを実行する様子を想像すると、多くの人はデータセンターを思い浮かべます。誰か他人の所有するGPUラック、メーター制のAPI、そして成功するたびに増えていく請求書。プロンプトをブラックボックスに送り、価格やモデル、プライバシーポリシーが契約時と同じ状態で維持されることを願うだけです。
多くのチームにとって、これは不利益な取引です。モデルがいつ変わるか、データがどこへ行くか、どのハードウェアでワークロードが実行されるかといった制御を放棄することになるからです。そして利用量が増えるにつれ、請求額も増え、引き出せるレバーは「もっと支払う」以外にありません。
Mesh LLMは異なる形を提供します。すでに持っているGPUとメモリを、追加したいだけ多くのマシンにまたがってプールし、全体を1つのOpenAI互換APIとして公開します。1つのノードから始め、後からノードを追加できます。メッシュが、モデルを目の前のマシンで実行するか、ピアにルーティングするか、複数のマシンに分割するかを判断します。
問題:AIは高価で、他人のもの
人気のモデルはモノリスです。ほとんどの人はUIやAPIキーを通じてアクセスし、大規模プロバイダにすべてを実行させ、支払います。それは便利ですが、同時に降伏でもあります。モデルがいつ更新されるか、どのメモリで実行されるか、その下にどのようなハードウェアがあるかを制御できないのです。
これらのモデルに依存する多くのビジネスやサービスは、その逆を望んでいます。より多くの制御、より多くのプラグ可能性、そしてより低いコストです。彼らはオフィスやクローゼット、机の下にGPUを抱えています。欠けているのは、それらのマシンを1つのように動作させる方法です。
その提案はシンプルです。より大きなGPUを購入することなく、より大きなモデルを実行できます。チーム内ではプライベートに、または世界に対してパブリックにコンピュートを共有し、エージェントやチャットを動かします。任意のOpenAIクライアントをhttp://localhost:9337/v1に向けるだけで、実際にどこで処理が行われているかを気にする必要がなくなります。
内部では、Mesh LLMはirohエンドポイントのメッシュ全体にモデルコンピュートを分散させます。リクエストは3つの方法で処理できます:
- このマシンのGPUでローカルに実行する。
- すでにモデルがロードされているピアにルーティングする。
- 1台のマシンでは大きすぎるモデルを、複数のマシンにパイプラインとして分割する。
アーキテクチャはプラグ可能になっています。プラグインはマニフェストで提供する内容を宣言し、ランタイムがそれらを起動して呼び出しをルーティングし、MCP、HTTP、推論、メッシュイベントを通じて機能を公開します。カタログには40以上のモデルが含まれており、ラップトップに収まる5億パラメータ程度のモデルから、235BのMixture-of-Experts型巨大モデルまで揃っています。
巨大モデル向けに、Mesh LLMには分割モード(内部では「Skippy」)があります。モデルはレイヤーの範囲でステージに分割されます。たとえばレイヤー0〜15を1つのノード、16〜31を次のノードというようにパイプラインを構成します。活性化はステージ間を流れ、どのマシン単体でも保持できないモデルを、控えめな複数マシンで実行可能にします。OpenAIクライアントはこの仕組みを一切認識しません。依然としてlocalhostとだけ通信します。
モデルを提供するノードも、リクエストのみを送信するノードも、すべてirohエンドポイントを起動します。そのエンドポイントがノードのアイデンティティ(公開鍵)であり、唯一のネットワーク表面となります。中央サーバーは存在しません。irohがホールパンチング、NATトラバーサル、リレーフォールバックを処理し、任意の2つのノード間で直接かつ認証されたQUIC接続を開くことを可能にします。
オープンインターネット上でこれを動作させるため、Mesh LLMは異なるリージョンに2つのirohリレーを運用しており、直接到達できないノード同士にも常に近隣のフォールバック経路を提供します。
プロトコル全体はQUICのALPNネゴシエーションに乗っています。3種類あります:
| ALPN | What it carries |
|---|---|
| mesh-llm/1 | メインメッシュ:ゴシップ、ルーティング、HTTPトンネル、プラグインチャネル |
| mesh-llm-control/1 | オーナーコントロールプレーン(設定同期、所有権証明) |
| skippy-stage/2 | 分割モデル向けの低遅延活性化転送 |
メインのmesh-llm/1接続内では、すべてが双方向QUICストリームで、先頭の1バイトでストリームの種類を示します。1つの接続でゴシップ、推論、ルートクエリ、ピアライフサイクルイベントを運び、最初のバイトでデマルチプレックスされます:
| Byte | Stream type | Description |
|---|---|---|
| 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は任意の2台のマシン間で、公開鍵でアドレス指定された認証済みNATトラバーサルQUICを提供します。そのため「ピアにルーティングする」「次のパイプラインステージへ活性化をストリーミングする」という操作は、「localhostと通信する」という操作と同じプリミティブになり、エンドポイントIDが異なるだけです。ネットワークは意識する必要がなくなります。
irohはセキュアなトランスポートを提供します。Mesh LLMはその上に独自のゴシップレイヤーを構築し、メッシュに参加できる相手、互換性のあるバージョン、信頼できるピアを正確に制御します。
ユーザーは軽量ソフトウェア(約18MB)をインストールし、パブリックメッシュに参加するか、プライベート展開を設定できます。システムは任意の標準OpenAIクライアントに対してlocalhost:9337/v1として振る舞います。
irohのSwift SDKで構築されたモバイルアプリも近日公開予定です。計画では新興のエージェント標準であるACPに対応し、他のクライアントもメッシュに参加できるようにします。プロジェクト全体を動かした一貫した考え方は同じです。より多くのピアツーピア、より少ないクローズドサーバー、そしてロックインのない世界です。
Irohは「ただ動く」ダイヤル・エニー・デバイス型ネットワーキングライブラリです。必要な機能を得るために既製プロトコルのエコシステムから構成したり、ダムパイプ上のクリーンな抽象化レイヤーで完全にカスタム実装したりできます。Irohはオープンソースで、すでに数十万台のデバイスで本番運用されています。
始めるには、ドキュメントをご覧いただくか、コードに直接飛び込むか、Discordチャンネルで私たちとチャットしてください。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.