Mesh LLM - irohベースの分散AIコンピューティング

 (iroh.computer)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • 複数のマシンに分散したGPUとメモリを1つのコンピューティングリソースとして束ね、ローカル実行・ピア転送・分割実行を1つのOpenAI互換APIで提供する
  • リクエストはローカルGPUまたはモデルをロード済みのピアで処理され、1台のマシンに収まらないモデルは複数ノードにパイプライン段階として分けて実行できる
  • プラグインベースのカタログには、ノートPC向けの5億パラメータモデルから235B MoEモデルまで40以上が含まれ、クライアントは内部配置に関係なくlocalhost:9337/v1だけを呼び出す
  • 各ノードは公開鍵をIDかつ唯一のネットワーク面として使うirohエンドポイントを実行し、中央サーバーなしでNAT越え・ホールパンチング・リレー代替経路を経て認証済みQUIC接続を構成する
  • 約18MBのソフトウェアで公開メッシュやプライベートデプロイを構成でき、今後はiroh Swift SDKとACPをサポートするモバイルアプリを通じてクローズドなサーバーへの依存度を下げる計画

外部データセンターの代わりに既存ハードウェアを活用

  • 一般的なLLMの利用方法は、外部事業者のGPUデータセンターと従量課金APIに依存するため、利用量が増えるほどコストも大きくなる
  • 外部サービスにプロンプトを送ると、ユーザーは次の要素を直接制御しにくい
    • モデルの更新タイミング
    • データが送られる場所
    • モデルが使用するメモリと基盤ハードウェア
    • 価格と個人情報処理ポリシーの変更
  • オフィス・倉庫・デスク下にすでにGPUを保有している企業やサービスには、複数のマシンを1つのコンピューティングリソースのように活用する手段が必要
  • Mesh LLMは、保有するGPUとメモリを任意の数のマシンにわたって束ね、より大きなモデルを実行し、計算リソースをチーム内で非公開に、または外部と公開で共有できるよう設計されている

リクエストを処理する3つの経路

  • 標準のOpenAIクライアントからhttp://localhost:9337/v1を呼び出すと、メッシュがリクエストの実際の実行場所を決定する
  • リクエストは次の3つの経路のいずれかで処理される
    • 現在のマシンのローカルGPUでモデルを実行
    • 必要なモデルをすでにロードしているピアへリクエストを転送
    • 1台のマシンに収まらないモデルを複数マシンにわたってパイプライン方式で分割
  • ユーザーは1つのノードから始め、必要なときに追加できる。OpenAIクライアントは内部ルーティングや分割実行方式を知る必要がない

プラグイン構造とモデルカタログ

  • プラグインはマニフェストで提供機能を宣言し、ランタイムはそれを起動して呼び出しをルーティングする
  • 各プラグインの機能はMCP・HTTP・推論・メッシュイベントを通じて公開される
  • デフォルトカタログには40以上のモデルが含まれる
    • ノートPCで実行できる約5億パラメータモデル
    • 最大235B規模のMixture-of-Expertsモデル

Skippy分割実行

  • 大型モデル向けの分割モードは内部的にSkippyと呼ばれる
  • モデルのレイヤー範囲を段階ごとに分け、各ノードに配置する
    • あるノードがレイヤー0〜15を担当
    • 次のノードがレイヤー16〜31を担当
    • 以降のレイヤーも同じ方式でパイプラインの終端まで分配
  • ある段階で生成されたアクティベーションが次の段階へ渡されるため、個別のマシンには収まらないモデルも、複数のミドルレンジマシンを組み合わせて実行できる
  • 分割プロセスはOpenAIクライアントには見えず、クライアントは引き続きローカルエンドポイントだけを呼び出す

irohベースのP2Pネットワーク

  • モデルを提供するノードも、リクエストだけを送るノードも、どちらもirohエンドポイントを起動する
  • エンドポイントは3つの役割を担う
    • ノードのID
    • 公開鍵
    • ノードが外部に公開する唯一のネットワーク面
  • irohは中央サーバーなしでホールパンチング、NAT越え、リレー代替経路を処理し、異なる場所にあるノード間に直接かつ認証済みのQUIC接続を構成する
  • 直接接続できないノードのために、異なる地域で2つのirohリレーを運用し、近い代替経路を提供する
  • 公開鍵でマシンを指定し、認証済みNAT越えQUICを使用できるため、ピアへリクエストを転送したり、次のパイプライン段階へアクティベーションを送ったりする作業は、エンドポイントIDが異なるだけの同じ通信プリミティブで処理される

QUIC ALPNでプロトコルを区別

  • プロトコル全体はQUICのALPNネゴシエーションを使用し、用途に応じて3つに分かれる
    • mesh-llm/1: ゴシップ、ルーティング、HTTPトンネル、プラグインチャネルを含む基本メッシュ
    • mesh-llm-control/1: 設定同期と所有権証明を担うオーナー制御プレーン
    • skippy-stage/2: 分割モデルでレイテンシに敏感なアクティベーション転送
  • mesh-llm/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越えのための直接アドレス共有
  • 1つの接続でゴシップ、推論、経路照会、ピアのライフサイクルイベントを処理し、先頭バイトで各ストリームを逆多重化する

セキュア転送とメッシュ制御の分離

  • irohはマシン間のセキュアな転送層を提供する
  • Mesh LLMはその上に独自のゴシップ層を構築し、次のポリシーを直接制御する
    • メッシュ参加を許可する対象
    • 互換性のあるバージョン
    • 信頼するピア

インストールと今後のサポート

  • 約18MBの軽量ソフトウェアをインストールして公開メッシュに参加したり、プライベートデプロイを構成したりできる
  • 標準のOpenAIクライアントにはlocalhost:9337/v1エンドポイントとして公開される
  • iroh Swift SDKでモバイルアプリを開発する計画で、他のクライアントもメッシュに参加できるよう、新しいエージェント標準であるACPのサポートを準備している
  • プロジェクトはP2P活用を増やし、クローズドなサーバーと依存関係を減らすことを目指している
  • ソースコードとMesh LLMウェブサイトでプロジェクトを確認できる

irohネットワーキングライブラリ

  • irohはデバイス間接続を提供するオープンソースのネットワーキングライブラリで、用意されたプロトコルを組み合わせたり、シンプルな通信抽象化の上にカスタムプロトコルを構成したりできる
  • すでに本番環境の数十万台のデバイスで実行されている
  • ドキュメント、ソースコード、Discordチャンネルを提供している

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker News の意見

  • 最初の画像にある GPU 機材、ノート PC、サーバー、クラウドノードなどを見ると、自分の持っている計算リソースがどれほど少ないかを実感した。24GB VRAM のノート PC も 96GB のワークステーションもなく、友人たちのゲーミング PC を総動員して LLM を動かしても、写真の総 VRAM には届かなさそうだ。
    記事では公開メッシュネットワークも紹介されていたが、詳しい情報は見つけられなかった。

  • 性能情報が不足している点が目につく。システム RAM やディスクストリーミングを含め、他のどんな大規模モデル実行方式よりもずっと遅いだろうと予想していた。コンシューマー向けネットワークは 10Gbps Ethernet でさえローカル RAM やディスクに比べると非常に遅いので、分割モデルが毎秒 1 トークンか、それ以下なのかが気になった。
    モデル一覧を見ると、Qwen 235B A22B は「2 ノードで 16 tok/s と検証済みの MoE 235B/22B」とされていた。ノードの仕様やネットワーク接続は公開されていないが、かなり良好な速度で、対話用途で快適な水準にはやや届かないとしても相当近い。

    • 必ずしも遅くなるわけではなく、むしろそうではない構成も多そうだ。重みを RAM や NVMe にオフロードすると、トークンごとに各層を処理する際、巨大な重みを遅いストレージから GPU へ移さなければならず、DRAM 帯域幅やディスク読み取り速度がボトルネックになる。
      分散構成では、各マシンの VRAM に重みが残るため、はるかに高速な GPU メモリ帯域幅を活用できる。デバイス間で渡す層の出力はギガバイト級の重みではなくキロバイト級なので、ネットワークスループットがボトルネックにはならない。
      実際の制約はネットワーク遅延だ。モデルを 4 台のデバイスに分けると、トークンごとにネットワーク遅延が 3 回発生し、遅延時間が 1ms なら 1 トークンあたり 3ms が追加される。計算時間が 0 だと仮定しても、投機的デコーディングなしの理論上の最大速度は約 30 tok/s だ。
      インターネット上では遅延が大きすぎて実用的でない可能性が高いが、ローカルネットワークや企業ネットワークで投機的デコーディングを使えば十分可能だ。プリフィルやプロンプト処理では遅延時間が累積しないため、分散構成のほうがほぼ確実に高速になる。
    • 自宅ラボで機器間の5ms の遅延とジッターを模擬して測定した。分割実行は大都市圏レベルの WAN 遅延ではかなりうまく動くが、世界規模の WAN ではそれほど速くない。
      専用の RDMA や NVLink ファブリックがない複数の機器を束ね、手持ちのハードウェアで大規模モデルを提供し、他の人と共有することが目標だ。現在、同じ分割構成で GLM 5.2 を約 10 tok/s で動かす作業を進めている。
    • 性能は比較的簡単に概算できる。自己回帰デコーディングでは、トークンごとにおおよそ 2 × hidden_size × num_shards バイトをネットワークで転送する必要があり、プリフィルではこの値をチャンクサイズで割ればよい。
    • AMD Ryzen AI 9 HX 370 搭載の Framework 13 で Qwen3.6-35B-A3B を実行したときに自分が得ている速度と似ている。はるかに大きなモデルでも同じ速度が出るなら印象的だ。

  • コーディング用 LLM よりも、目的に合わせて作った小型言語モデルの分散推論により関心がある。画像処理、ソフトウェア定義無線（SDR）、地域の気象観測などに活用すれば、平凡なスペックでも実行でき、信頼できる出力を出せる。

    • アクティブなエキスパートを X 個持つモデル 1 つではなく、特定の情報で学習した小さく密な互いに異なるモデル 10 個を 10 台のサーバーに載せ、1 つのルーターで接続する構成が適していそうだ。

  • Mesh LLM のコントリビューターで、大規模モデルを複数ノードに分割できるようにする skippy エンジンを作った。質問があれば答える。

    • IPFS 関連技術がまた登場してうれしい。2 つ気になる。
      まず、このように計算を分散すると、計算グラフのすべての参加者が処理中のシーケンスを知ることになるが、プライバシー保護はどう扱うのか。次に、悪意ある参加者がモデルの活性値を汚染できないようにする保護策はあるのか。
    • 公開メッシュに参加するインセンティブが何なのか気になる。特定モデルの実行に必要な VRAM の 1/8 を提供すれば、少なくとも推論使用量の 1/16 を受け取れる、といった公平性の保証はあるのか。
    • 数日前に公開された Colibri プロジェクトと統合すると利点はあるだろうか。
    • KV キャッシュの実装を深く見たことはないが、層ごとに実質的に独立したキャッシュを運用しているのか気になる。
      そうなら、計算量とデータサイズの面できれいに分割され、各層が順番を待つ時間だけ遅くなるように思える。パイプラインを組めば複数のクエリを同時に実行することもできる。
      クエリを 1 段階ずつずらして投入する N 段パイプラインで best-of-N を実装した事例はあるのか。
    • 異なる EPYC プロセッサとモデルが多数ある研究室を運営しているが、これをこの方式で 1 つに束ねられるという点は印象的だ。

  • 似た分散コンピューティング方式の LLM を探していて、AI Horde、Aphrodite 周辺の小規模な試み、Nous Research の分散学習などを見つけた。
    この中では AI Horde が最も大きいようだ。API はチャット補完ではなく KoboldCPP のテキスト補完形式を使う。より多くの調整変数を公開しており、ロールプレイで結果が良くなるため、コミュニティの活発なメンバーはこの方式を強く好んでいるようだ。他の用途の多くはツール呼び出しが必要になるだろうから、ロールプレイ以外でどこに使えるのかはよく分からない。
    今週は、チャットテンプレートと応答パースをサポートするよう OpenAI ブリッジの改善を始めた。正式リリースに成功すれば、ロールプレイモデルを使わざるを得ないとしてもコーディングに活用できるだろう。
    悪用防止策もより充実している。組織的な攻撃を防ぐため、ワーカーは累積稼働時間 1 週間を満たして初めて信頼対象として認められ、ユーザーは信頼済みワーカーだけを選択できる。ワーカーを運用すると kudos を得られ、最大 512 トークンを超える生成に使うことができ、無料リクエストはキューの最後尾に回される。

  • 1 つ以上の分散 LLM を実行する多態的ボットネットに何ができるのか気になっていた。ボットネットのすべてのホストをクラスタ計算リソースとして活用して LLM を動かし、各ボットネットクラスタの伝播方式とペイロードが進化するよう導くという構想だ。
    悪い変種は検出されて削除され、効果のない伝播方式は広がらないが、最も優れたバージョンは生き残って成長を続ける。ここで紹介されている構造とかなり似ており、QUIC は非常に動的に動作するため、思ったより検出が難しい可能性がある。

  • https://query.mt/ プロジェクトは、しばらく前から iroh ベースのメッシュを使っている。メッシュモデルを携帯電話でも使いたいなら試してみる価値がある。

  • mesh-llm を実行しようとしばらく格闘したが、インストール可能な llama.cpp ビルドの中に自分の古い GPU で動くものがなかった。外部の llama.cpp サービスをプロキシできそうだったが、その設定もうまくいかなかった。
    とても興味深いプロジェクトだが、まだ洗練されていない部分がかなりある。

    • バグレポートを送ってくれれば、動くように一緒に解決してみたい。

  • この方式は可能だと思って約 1 年前に ChatGPT に尋ねたが、遅延時間が大きすぎて不可能だという答えだった。当時、ほぼ 1 年間 libp2p を勉強しながら、活用できるプロジェクトを探していた。