Lumabri: Mixture-of-Experts モデルのための P2P スウォーム推論

Lumabri は、モデルの重みと実際の計算の両方をピア・ツー・ピア (P2P) スウォームに分散させることで、大規模な Mixture-of-Experts (MoE) モデルの実行を可能にします。Transformer レイヤーをデバイス間で分割する従来の分散推論とは異なり、Lumabri はエキスパートの粒度で分割を行うため、GPU を持たないデバイスを含むリソースの限られたノードでも推論プロセスに貢献できます。

分散エキスパート実行

Lumabri は、密な重み、ルーター、および KV キャッシュのみをローカルの "chatter" マシンに保持することで、MoE のスパース性を最適化します。トークンに対してエキスパートが必要になった場合、chatter はその特定のエキスパートを保持しているピアに対して、小さな 4 KB のアクティベーションを送信します。ピアはエキスパートを実行し、結果を返します。

このアーキテクチャにより、エキスパートの重みが chatter に到達する必要がなくなるため、重みストリーミング方式と比較して必要な帯域幅を大幅に削減できます。chatter とピアの両方が同じエンジンソースから構築されているため、出力はローカル実行とバイト単位で完全に一致します。異なるハードウェア命令 (例: -march=native) によるサイレントエラーを防ぐため、Lumabri はピアに対し、ソースハッシュ、ISA、およびコンパイラを含む正確なビルド情報を公開することを要求します。chatter は、ビルドが異なるピアを拒否します。

P2P モデル配布と遅延読み込み

Lumabri は、LD_PRELOAD シム (liblumabri.so) を介してモデルバイトの遅延読み込みメカニズムを実装しています。このシムは、標準的な libc 呼び出し (open, fopen, opendir, pread) に割り込み、リモートのモデルファイルを疎なローカルミラーとして見せかけます。

オンデマンド取得: バイトは、推論エンジンが実際にそれらに触れたときにのみ、ピアから取得されます。
ローカルキャッシュ: 取得されたバイトは、ローカルミラーおよびチェックポイント間で共有されるコンテンツ・アドレス指定ストア (CAS) に保存されます。同じバイトへの後続のリクエストは、ローカルディスクからフルスピードで提供されます。
整合性: モデルのすべての MiB は sha256 によって検証されます。オリジンは ed25519 キーを使用してモデルルートに署名でき、これにより chatter は信頼できる公開鍵に対してすべてのブロックを検証できます。

信頼できないスウォームにおける信頼と検証

ピアは信頼できないため、Lumabri はリモート計算の正確性を確保するためにいくつかのメカニズムを採用しています:

レプリカ検証: LUMABRI_VERIFY=N 設定により、chatter はエキスパート呼び出しの一定割合を第 2 のレプリカで再実行できます。もし 2 つの正直なピアが一致しない場合、その実行は嘘の証拠となるため停止します。
ヘッジリクエスト: 遅いピアによるレイテンシを軽減するため、LUMABRI_HEDGE_MS=N は指定されたタイムアウト後に第 2 のレプリカに重複リクエストを送信し、最初に受信した有効で決定論的な結果を使用します。
暗号化トランスポート: LUMABRI_ENCRYPT=1 が有効な場合、トークン、モデルブロック、およびアクティベーションは、X25519/Ed25519 ハンドシェイクと ChaCha20-Poly1305 フレームを使用して保護されます。

サポートされているエンジンとモデル

Lumabri は Colibri エンジンと統合されており、いくつかの MoE アーキテクチャをサポートしています。決定論的な出力を確保するため、各エンジンはエンジンのソースから構築された特定のエキスパート・ノード・バイナリを必要とします。

Engine	Supported Model	Expert Node Provenance
`olmoe`	OLMoE	`phase2_test.sh`
`colibri`	GLM	`phase2_glm_test.sh`
`inkling`	Inkling	`phase2_inkling_test.sh`
`kimi_k3`	Kimi K3	`phase2_kimi_test.sh`
`deepseek`	DeepSeek V4	`phase2_deepseek_test.sh`

他の P2P 推論との比較

Lumabri は、パーティショニングのポイントにおいて Petals や llama.cpp RPC とは異なります。Petals や llama.cpp RPC は連続する Transformer レイヤーをデバイス間で分割しますが、これらは実用的にするためには高速な GPU インターコネクトが必要となるのが一般的です。一方、Lumabri はエキスパート単位で分割します。これにより、レイヤー全体のアクティベーションではなく、わずか 4 KB のアクティベーションのみがネットワークを介して移動するため、CPU や SSD のネットワーク上でもスウォームが効果的に機能することができます。

コミュニティの洞察とユースケース

ユーザー間の議論では、LAN (ローカルエリアネットワーク) で Lumabri を使用して、低電力デバイスや RAM 制約のある GPU のリソースをプールする可能性がハイポテクティブに強調されています。

"RAM 制約のある GPU で、驚くほど高いスループットで大規模なパラメータモデルの推論を実行できるようにすることが、最大のメリットだと感じています... ネットワークを介したメモリ対計算比率は、重みではなくアクティベーションによってのみ制限されます。"

他のユーザーは、この architecture が、クラウドプロバイダーによる中央集権的な検閲や監視に対する「保険」として機能し、LLM 推論をより分散化された、コミュニティ主導の文化へと戻すものであると指摘しています。