巨大MoEモデルを「誰も全部持たない」まま動かす──P2Pスワーム推論エンジンLumabri
OSSのLumabriは、colibriエンジンを使ってMixture-of-Expertsモデルをピア間で分散推論するツール。モデルは事前ダウンロードせず、推論が実際に触れたバイト列だけをピアから取得してローカルにミラーする。GLM・Kimi K3・DeepSeek V4・Qwen3.6など6エンジンでのビット同一性検証が公開されている。
目次
3行まとめ
- Lumabriは、Mixture-of-Experts（MoE）モデルをP2Pスワーム上で分散推論するC言語製・依存ゼロのエンジン。モデル全体を誰か1台が持つ必要はなく、推論が実際に触れたバイト範囲だけがピアから取得され、ローカルにミラーされる。
- GPUの有無を問わず参加でき、出力はGPUの有無にかかわらずバイト単位で同一と主張している。
- OLMoE・GLM・Inkling・Kimi K3・DeepSeek V4・Qwen3.6の6エンジンについて、エキスパートをローカルで持つ場合とピア上に置く場合とでトークンをビット単位で突き合わせるテストが用意されている。
モデルを「持たずに動かす」という発想
Lumabriは同じ作者の推論エンジン「colibri」の上に立つ薄い層で、READMEは「1台のマシンがモデルを共有し、他のどのマシンもそれと会話できる。事前に何もダウンロードしない」と説明する。推論が実際に触れたバイト列だけが、初回利用時にピアから届き、その後はローカルのミラーに残るのでディスクから全速力で読める、という仕組みだ。GPUがあってもなくても参加でき、GPUは速くするだけで結果を変えない——エンジンはまずCPUとSSDを前提に作られており、出力はどちらの経路でもバイト単位で同一だとREADMEは主張している。
仕組み──LD_PRELOADでファイルI/Oを差し替える
READMEの技術的な説明を要約すると、serveは2つの小さなプログラムを動かす。「tracker」はどのファイルを誰が持っているかを示すインデックスに過ぎず、「maintainer」はモデルディレクトリへのバイト範囲読み取りに応答する。一方chat側はliblumabri.soというLD_PRELOADシムを使い、エンジンがモデルディレクトリに対して行うopen・fopen・opendir・preadといった一握りのlibc呼び出しに割り込む。ファイルは実サイズのスパースなローカルミラーとして見え、fstat・readdir・ページキャッシュはネイティブに機能する。存在しないブロックはピアから取得されミラーに書き込まれてから、エンジン自身のpreadが続行する——つまり一度読んだ後は、テーブル参照＋通常のローカル読み取りだけで済み、読み取りパスにFUSEもデーモンも介在しない。
検証済みの1MiBごとにsha256でローカルのコンテンツアドレスストア（デフォルトは~/.lumabri/cas）にも保存され、同じチャンクは一度だけダウンロードされる。colibriから継承した原則として「ネットワークはバイトの取得元を変えても、バイトの中身は変えない」とあり、モデルファイルへの書き込みはEROFSで拒否され、誰も供給できないブロックは黙ってゼロ埋めされるのではなくEIOとして明示的に失敗する、という設計だ。
エキスパートはピア上で動く
MoEモデルの場合、手元の「chatter」（会話を行う側）は密な重み・ルーター・KVキャッシュだけを保持し、ルーティングされた各エキスパートを持つピアに4KBのアクティベーションを送る。エキスパートの重み自体はchatter側には届かない。両側とも同じエンジンのソースからビルドされているため、ローカル実行と分散実行は同じコードパスで同一のトークンを生成する、とREADMEは説明する。
ビルドの食い違いにも神経質だ。ピアは自分のビルド（エンジン・ソースハッシュ・ISA・コンパイラ・量子化・モデルルート）を正確に広告し、chatterはビルドが異なるピアに対してアクティベーションを送る前に拒否する。-march=nativeでの再ビルドで最後の1ビットが変わりうるため、それを黙って許さない、という理由だ。エンジン・ソースハッシュ・モデル・数学フラグの不一致は常に拒否、OpenMPのバージョン差は無視、コンパイラとISAの差はデフォルトで拒否するがLUMABRI_ALLOW_CODEGEN_SKEW=1で警告に格下げしスポットチェックを有効化できる、という段階的な設計になっている。
信頼できないピア対策としては、各maintainerが自分の持つ1MiBごとのsha256を登録時に送り、原点（origin）がオフライン保管のed25519鍵で署名できる。trackerはその署名を運ぶだけで新規発行はできず、chatterは自分が持つ鍵で全ブロックを検証する。リモート計算の検証にはLUMABRI_VERIFY=Nがあり、エキスパート呼び出しのN%を別レプリカで再実行して同一出力を要求する——正直な2つのピアが食い違うことはあり得ないので、食い違いはそのまま嘘の証拠になり実行を止める、とREADMEは説明している。
対応エンジンは6種、Kimi K3・DeepSeek V4・Qwen3.6を含む
READMEに掲載されている対応表は次の通り。
| engine | 対象モデル | chat | ピア上のエキスパート |
|---|---|---|---|
olmoe |
OLMoE | ○ | expert_node（phase2_test.shで検証） |
colibri |
GLM | ○ | expert_node_glm（phase2_glm_test.shで検証） |
inkling |
Inkling | ○ | expert_node_inkling（phase2_inkling_test.shで検証） |
kimi_k3 |
Kimi K3 | ○ | expert_node_kimi（phase2_kimi_test.shで検証） |
deepseek |
DeepSeek V4 | ○ | expert_node_deepseek（phase2_deepseek_test.shで検証） |
qwen36 |
Qwen3.6 | ○ | expert_node_qwen36（phase2_qwen36_test.shで検証） |
「検証済み（proven）」の意味についてもREADMEは注記している。同じエンジン・同じプロンプトを、全エキスパートをローカルに置いた場合とすべてピア上に置いた場合の両方で生成し、トークンをビット単位で突き合わせる、という実験そのものを指す。この検証プロセスが実際にバグを1件検出したこともあるとREADMEには書かれており、GLMエンジンはルーティングされた全行を一括でエキスパート計算する挙動を持つため、その特性に対応した修正が入った経緯が説明されている。
基盤エンジンcolibri──1台のマシンでも744B〜2.8Tを動かす仕組み
Lumabriが乗っかっている基盤エンジンcolibriのREADMEを直接確認すると、colibri自体は「ストレージ・RAM・VRAMを1つの推論階層として扱う（AI memory multitiering）ことで、744Bから2.8Tパラメータのフロンティア級MoEモデルを、コンシューマー向け・混在ハードウェアの上でPure C・依存ゼロで動かす」ことを目的にしたエンジンだと分かる。対応する7ファミリーは次の通り（README「Family」表より）。
| ファミリー | 総パラメータ／アクティブ | 量子化チェックポイント |
|---|---|---|
| GLM-5.2 | 744B／40B | int4-g64（約372GB） |
| Inkling（Thinking Machines） | 975B／41B | int4（約469GB） |
| GLM-5.3-Flash（Z.ai） | 321B／40B | int4-gs64（denseはBF16のまま） |
| Kimi K3（Moonshot） | 2.8T／104B | ネイティブMXFP4のまま |
| DeepSeek V4 Flash | 284B／13B | ネイティブfp4（denseはfp8-e4m3） |
| Qwen3.6（Alibaba） | 35B／3B | int4-gs64（約20GB、推奨） |
| OLMoE（AI2） | 7B／1B | int8（約7GB） |
つまりLumabriのP2Pスワーム機能は、この巨大モデル1つ1つを単体でも動かせるcolibriの上に、「モデル全体を1台が持たなくていい」という分散のレイヤーを足したものだ、と2つのREADMEを突き合わせて理解できた。
単体マシンでの実測スループットは「秒間0.05〜0.1トークン」
colibriのdocs/benchmarks.mdには、開発者自身の実機での計測値も公開されている。GLM-5.2（int4、ディスク上約370GB）を、WSL2・NVMe VHDX・24GB RAM・Intel Core Ultra 7 270K Plus（24スレッド）という開発機で動かした場合、コールドキャッシュ状態でのデコード速度は約0.05〜0.1トークン/秒だったという。同じ文書には、PCIe4 NVMe・32GBの環境で約0.5〜1トークン/秒、128〜256GBのRAMでホットなエキスパートをキャッシュできる環境で約2〜4トークン/秒、24〜32コアかAVX-512/VNNIカーネルを使う環境で約5〜15トークン/秒という、ハードウェアごとの目安表もある。つまりLumabriのREADMEが強調する「P2Pでバイト範囲だけを取得する」という設計自体は洗練されているが、その土台であるcolibri単体の生スループットは、開発機クラスのハードウェアではチャットとして快適とは言い難い水準にとどまる、という実情が公開ベンチマーク文書から読み取れた。
クイックスタート
READMEに示されているコマンドは次の通り。モデルを持つ側はmakeでビルド後、
./lumabri serve --model /path/to/model
チャットする側は、
./lumabri chat --tracker <server-ip>:7300 --engines-dir /path/to/colibri/c
手元にモデルがない場合はmake fixtureで小さな合成モデルを作り、一連の手順を実物大ではなく小規模に試せる。引数なしでlumabriと打つとテキストUIが起動し、スワームのアドレスとオペレーターの公開鍵を一度だけ聞かれ、以降は~/.lumabri/configに記憶される。参加時には「chatとして参加するだけ」か「自分のマシンも貸してモデルの一部をディスクに保持するかエキスパートの一部を実行する」かを選べ、"run experts"を選ぶと空きRAMに応じた分のエキスパートを自動的に引き受け、参加者が増えるほどエキスパートが分散されて速くなる、という設計だ。
複数マシンでの分散推論は自分では検証していない
本記事はJustVugg/lumabriとJustVugg/colibriのGitHub README、colibriのdocs/benchmarks.mdをそれぞれcurlで取得した内容にもとづく。実際に複数マシンでスワームを構築し、MoEモデルを分散推論させて動作を検証したわけではなく、colibri単体を自分の手元でビルド・実行してベンチマーク数値を再現したわけでもない。「出力がGPUの有無にかかわらずバイト単位で同一」「ビルド差を厳密に検出する」といった主張は開発者自身の説明であり、第三者による独立検証は確認できていない。colibriのベンチマーク文書に載っている数値も開発者自身の実機1台での計測であり、他のハードウェア構成やLumabriのP2P機能を実際に使った場合のスループットへの影響については、この記事の範囲では確認できていない。
P2Pでモデルを分散するという仕組みはまだ紹介されていない
Zenn・Qiitaともに言及はゼロだった。ローカルLLMをめぐる日本語記事はGGUF量子化やOllamaの使い方が中心で、「P2Pでモデルを分散して動かす」というアプローチ自体、日本語圏ではまだ紹介例が見当たらない。
関連記事
出典・参照資料
AIニュースの解説を動画でも
YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。
コメント
まだコメントはありません。最初のコメントを書いてみませんか？
AIについて聞きたいことはありますか？
質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。
質問箱を見る →新しい記事をメールで受け取る
AIの新しい発表を、出典付きで整理して届けます。
関連記事
Macで動くモデルサイズの計算式──「コンテキスト窓が広い」の裏でVRAMが消えていく仕組み
DeepSeekはローカルで動かせるのか──パラメータ数とVRAM要件で判定する
gpt-ossをローカルで動かすと何ができるか──20Bと120Bの違いを整理する
壊れたツール呼び出しを自動修復する──Unsloth Desktopの「Self-healing tool calling」を公式の実測データで読む
車をチャットルームの一員にする──Raspberry Pi 5に35BのQwenを載せて完全オフラインで動かすCarWatch
Unsloth Desktopの「Auto Compaction」──古い会話を消さずに検索可能なアーカイブへ逃がす設計
ローカルAIの最低スペックはどこまで低くて良いか──8GBメモリの実機で確かめた
