Show HN: Lumabri – Colibri を使って P2P スウォームで MoE モデルを実行する

Colibri エンジンを使用して、ピアのスウォーム上で大規模な Mixture-of-Experts (MoE) モデルを実行します。依存関係のない純粋な C 言語で記述されています。 1台のマシンがモデルを共有します。他のどのマシンもそれとチャットできます。事前に何もダウンロードされません。推論が実際に触れるバイトは、初回使用時にピアから到着し、ローカルミラーに保持されるため、2回目の質問はローカルディスクからフルスピードで提供されます。 エンジンバイナリは変更されません。GPU があってもなくても、どのマシンでも参加できます。このエンジンは CPU と SSD を第一に考えて構築されました。GPU はそれを速くするだけで、違いを生むことはなく、出力はどちらの場合でもバイト単位で同じです。GPU をプールするネットワークは少数のリソースを募集しますが、lumabri はすべての人から募集します。 クイックスタート モデルを持つマシンで (任意の Colibri モデルディレクトリ): ./lumabri serve --model /path/to/model チャットしたいマシンで (エンジン用の Colibri ビルドが必要です): ./lumabri chat --tracker <server-ip>:7300 --engines-dir /path/to/colibri/c これで完了です。最初の応答は、ワーキングセットがネットワークを横断するため遅くなります。その後、~/.lumabri のミラーはサーバーがオフラインになっても提供を続けます。 モデルがない場合？ make fixture は小さな合成モデルをビルドするため、上記の各ステップは実際のものですが、小さいだけです。 ターミナル UI のみ lumabri 引数なし。 スウォームアドレスと、一度だけオペレーターの公開鍵を尋ね、エンジンを自分で見つけ、それらをすべて ~/.lumabri/config に記憶します。2回目は Enter, Enter で、接続完了です。フラグを指定すると、スクリプトは誰かの保存された応答を継承しません。 チャット内では、/swarm はネットワークをライブかつ匿名で表示し (ピアは番号付けされ、名前は付けられません)、/model はスウォーム上のモデルをリストし、オンザフライで切り替えます。 仕組み バイトの共有。 serve は 2 つの小さなプログラムを実行します。トラッカーは、誰がどのファイルを持っているかのインデックスにすぎません。メンテナーは、モデルディレクトリに対するバイト範囲の読み取り要求に応答します。メンテナーはモデルのスライスを保持でき、複数のメンテナーが 1 つを共有できます。 バイトの読み取り。 chat は liblumabri.so を介してモデルをマウントします。これは、エンジンがモデルディレクトリに対して行う少数の libc 呼び出し (open, fopen, opendir, pread) をインターセプトする LD_PRELOAD シムです。ファイルは実際のサイズのスパースなローカルミラーとして表示されるため、fstat, readdir, ページキャッシュはネイティブに機能します。欠落しているブロックはピアから取得され、ミラーに書き込まれ、その後エンジンの pread が続行されます。ウォームリードはテーブルルックアップと通常のローカルリードです。FUSE も読み取りパス上のデーモンもありません。 検証済みの各 MiB は、ローカルのコンテンツアドレス指定ストアに sha256 で保存されます。デフォルトの CLI パスである ~/.lumabri/cas は、すべてのチェックポイントで共有されるため、同じチャンクは一度だけダウンロードされ、バイトサーバーなしで異なるスパースミラーを再構築できます。 Colibri から継承された 1 つのルール: ネットワークはバイトの出所を変更できますが、どのバイトを変更することはできません。モデルファイルへの書き込みは EROFS を返します。ピアが提供できないブロックは、サイレントゼロではなく、大きな EIO です。バイトの同一性は、コールド、ウォーム、および各ピアがダウンしている状態で検証されます。 エキスパートはピア上で実行されます。 Mixture-of-Experts モデルの場合、チャッターは密な重み、ルーター、KV キャッシュのみを保持し、ルーティングされた各エキスパートを保持するピアに 4 KB のアクティベーションを送信します。エキスパートの重みはチャッターに到達しません。 両方のサイドはエンジンのソース自体からビルドされるため、ローカル実行と分散実行は 1 つのコードパスであり、同一のトークンを生成します。 ピアは、その正確なビルド (エンジン、ソースハッシュ、ISA、コンパイラ、量子化、モデルルート) もアドバタイズし、チャッターは、1 バイトのアクティベーションを送信する前にビルドが異なるピアを拒否します。なぜなら、-march=native リビルドは最後のビットを変更する可能性があり、それは決してサイレントに起こってはならないからです。 ピアは信頼されません。 各メンテナーは、保持しているものの MiB ごとに sha256 を計算し、登録時に送信します。オリジンは、オフラインに保持する ed25519 キーでその真実を署名できます。トラッカーは署名のみを運び、署名を作成できないため、チャッターは自身が保持するキーに対して各ブロックを検証します。嘘をつくピアは、バイトが拒否され、他の場所から再取得されます。 リモートコンピューティングは、唯一可能な方法でチェックされます。LUMABRI_VERIFY=N は、2番目のレプリカでエキスパート呼び出しの N パーセントを再実行し、同一の出力を要求します。2つの正直なピアは同意できないため、不一致は嘘の証拠であり、実行は停止します。 プリフィルとターゲット検証はすでに複数の行として MoE に到着します。lumabri はそのユニオンをそのまま保持し、選択されたエキスパートごとに 1 つのマルチ行 EXEC を送信します。これには投機的ドラフト検証も含まれます。バッチを行サイズの要求にシリアライズすることはありません。 LUMABRI_HEDGE_MS=N は、最も近いレプリカが N ミリ秒応答しない場合に、オプションで次のレプリカに重複を送信し、最初の有効な決定論的結果を使用します。固定遅延は意図的に公開メカニズムであり、自動 SLA ポリシーではありません。 エンジン Colibri はいくつかのエンジンを提供しており、それらは形状を共有しないため、エキスパート側はエンジンごとです。MoE 関数をフックする小さなパッチと、そのエンジンのソース自体からビルドされた expert-node バイナリです。エンジンは決して変更されず、パッチはコピーに適用され、ソースアンカーから再生成されるため、間違った場所に適用される代わりに大声で失敗します。 エンジン モデル チャット エキスパート (ピア上) 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 で証明済み 「証明済み」とは、主張ではなく実験を意味します。同じエンジンとプロンプトを 2 回生成し、一度はエキスパートをローカルで、もう一度は各エキスパートをピア上で実行し、トークンをビット単位で比較しました。そのテストは一度、実際のバグを捉えました。GLM は、ルーティングされたすべての行に対して一度にエキスパートを計算するため、1 行ずつピアにフィードすると異なる浮動小数点数になり、4 つの位置後にトークンがドリフトしました。実行しなければ見つからなかったでしょう。 Colibri チェックアウトに実際にあるエンジンについては、make engines でピアをビルドし、make chatters でパッチされたチャットエンジンをビルドするか、make phase2-all ENGINE=/path/to/colibri/c で両方をビルドします。 スウォームの実行 完全なサーバーウォークスルー (systemd, ファイアウォール, オペレーターキー, クライアント) は DEPLOY.md にあります。 短いバージョン: make && make phase2-all ENGINE=/path/to/colibri/c # phase2-all はオプション sudo make install # または PREFIX=$HOME/.local サーバーでは、lumabri serve --model /srv/model が TCP 7300 から 7302 (トラッカー, メンテナー, エグゼキューター) を開きます。最速の直接パスには --advertise <public-ip> を追加し、モデルに署名するには --key swarm.key を使用します。バイトまたはコンピューティングドナーがインバウンドトラフィックを受け入れられない場合、アウトバウンドハートビートがトラッカーリレーとして機能します。直接 P2P が引き続き優先されます。対称 NAT はもはやスウォームから除外されません。 他のすべてのマシンでは、役割を選択します。 チャットを実行したい場合 lumabri chat --tracker SERVER:7300 --engines-dir /path/to/colibri/c モデルを保持するマシンでチャット lumabri chat --local DIR ディスクを寄付する (バイトを保持) lumabri serve --model ./slice --join SERVER:7300 --model-name NAME --donate GB コンピューティングを寄付する (エキスパートを実行) expert_node<engine> --model DIR --tracker SERVER:7300 --cache N ディスクドナーは、トラッカーによって最も希少なものから順に保持するファイルについて指示されます。コンピューティングドナーは、保持できるエキスパートの数 (--hold N) のみを指定し、トラッカーは誰もカバーしていないセットをそれに与えます。どちらも他方の存在を知る必要はありません。 応答が生成されている間にドナーをキルできます。フェイルオーバーラインが 1 つ得られ、トークンは同一のまま続行されます。 手動での署名キーローテーションの場合、各行に 1 つの公開キーを含むキーリングを配布します。--pubkey keyring および LUMABRI_PUBKEY=keyring は、その中のすべてのキー (最大 16 個) を受け入れます。最初に古いキーと新しいキーをデプロイし、次に新しい秘密鍵で署名を開始し、クライアントとドナーが移動した後のみ古い行を削除します。最も新しいキーを最後に配置します。トラッカーは、最高優先度 (最新) のキーによって作成された有効な署名を保持するため、古いドナーハートビートはそれをロールバックできません。カンマ区切りの公開キーも受け入れられます。t