Buzz Mesh：コミュニティがモデルを動かすとき

数週間前、私は身の回りに眠る未使用の計算能力について書いた。人やチーム、地域コミュニティが空き容量を自発的に提供し、他の人が利用する「コンピュートのスマートグリッド」だ。すべてのAIリクエストを、同じ巨大事業者のデータセンターへ送る必要はない。

当時は主にアーキテクチャの構想だった。Buzzは、その最初の部品がどのようなものになるかを具体的に示している。人間とAIエージェントの共有ワークスペース、Nostr ID、コミュニティ内の計算プールを組み合わせる。メンバーがローカルモデルを提供し、他のメンバーのエージェントが利用する。さらに将来は、1台には収まらないモデルを複数端末に分割して保持する構想もある。

以前のアイデアによく似ている。しかしBuzzは世界規模のAIスーパーコンピューターではなく、空きRAMが魔法の共有メモリになるわけでもない。まず信頼に基づく小さなセルを作る。それが現実的な始め方だろう。

Buzzとは何か

Buzzは、Jack Dorseyが率いるSquareの運営企業Blockによるオープンソースプロジェクトだ。単に「Jack Dorseyの新アプリ」と呼ぶのは正確ではない。Blockのプロジェクトとして開発され、公開コードはApache 2.0ライセンスでGitHubに置かれている。

見た目はSlack、GitHub、エージェント基盤を組み合わせたようなものだ。人間とAIエージェントが同じチャンネルでタスクを議論し、コードを管理し、ワークフローを起動する。各エージェントは独自の暗号IDと限定された権限を持つ。誰が操作を許可し、どのエージェントが実行したかを分けて追跡できる。

これは表面的なユーザー管理ではない。多くのシステムでは、ボットが共有サービスアカウントや強すぎるAPI keyを使う。後から「自動化」が何かをしたことは分かっても、どのインスタンスが何の指示で動いたかは曖昧だ。Buzzは認可と実行主体を別々に見えるようにする。

ワークスペースはセルフホストできる。公開アーキテクチャはBuzz Relay、イベントと検索用のPostgreSQL、Pub/Subとプレゼンス用のRedis、S3互換メディアストレージという既知の部品で構成される。運用の現実を隠しても分散化の信頼性は上がらない。

基盤はNostr

NostrはNotes and Other Stuff Transmitted by Relaysの略だ。ユーザーは暗号鍵ペアを所有し、イベントに署名してrelayへ公開する。クライアントは1つ以上のrelayを通じて必要なイベントを購読する。

イベントには送信者の公開ID、時刻、種類、内容、参照、署名が含まれる。秘密鍵はユーザーが保持し、公開鍵がIDと検証に使われる。Nostrはsecp256k1上のSchnorr署名を使う。Bitcoinでも中心的な楕円曲線だ。

署名付きログだが、ブロックチェーンではない

Nostrにはマイニング、世界的コンセンサス、全relayが待つ単一チェーンがない。relayは独自ルールでイベントを受理、保存し、クライアントへ返す。別のrelayは同じイベントを持つ場合も、持たない場合もある。

Buzzはメッセージ、リアクション、エージェントタスク、ワークフロー、Gitイベントにこのモデルを使う。コミュニティ内ではrelayが依然として中心で、メンバーシップを確認し、イベントを配布し、状態を維持する。IDと形式は移植しやすくなるが、運営者、データベース、バックアップ、保持ルール、障害は消えない。

署名は特定の鍵がイベントを署名したことを証明するが、relayが永久に配信することは保証しない。セルフホストにはバックアップ、エクスポート、監視、鍵管理が必要だ。秘密鍵の紛失は管理者がリセットできるパスワードとは違う。盗難なら攻撃者が正規の署名を作れる。

Bitcoinとの関係

NostrはBitcoinコミュニティと文化的、技術的に近い。NIP-57のLightning Zapsにより、人やイベントへsatoshiを支払い、領収情報をイベントとして表現できる。

ただしBitcoinは必須ではない。Nostrはブロックチェーンやコインなしで動く。Buzz Shared Computeも、未知のPCがtokenごとにsatoshiを稼ぐ公開市場ではない。コミュニティ内で自発的に容量を共有する。Lightningは将来の報酬やクォータに使えるかもしれないが、電力、摩耗、運用コストへの答えはまだない。

Shared Computeの仕組み

Buzz Meshはコミュニティの所属と計算プールへの参加資格を結び付ける。メンバーは共有を有効化し、ハードウェアに合うモデルを選び、推論を提供する。エージェントは外部AIサービスのAPI keyなしで「Buzz shared compute」をモデル事業者のように選べる。

relayは信頼と調整を担い、誰がメンバーで、どのノードがモデルを提供するかを知る。実際のモデル要求はマシン間で直接暗号化して送られる。promptはBuzzサーバーを通らないが、依頼者の端末を離れ、別メンバーのマシンに届く。

転送暗号化が守るのは経路であり、終端を盲目にはしない。他人のハードウェアを使うなら運営者を信頼する必要がある。Meshの構想も明言する通り、コミュニティのプライバシーはメンバーの信頼性次第だ。

リモート推論と分散推論は同じではない

簡単な形では、モデル全体が強力なワークステーション1台で動き、他端末が要求を送る。ネットワークを流れるのは主にprompt、token、プロトコル負荷で、計算は1台に残る。

難しい形では、モデルを複数PCに分割する。各ノードは重みや計算の一部を担当し、token生成中に中間結果を絶えず交換する。帯域、遅延、トポロジー、障害が速度を直接決める。

Buzzは両方を説明している。公開開発ガイドにはアプリからローカルまたはリモート推論までの実経路がある。複数端末へのモデル分割はMeshの将来像であり、妥当な目標だが、自由に拡張できる成熟基盤ではない。一部機能は今もfeature flagが必要だ。

Mac Studioクラスターが示すネットワーク問題

NetworkChuckは512 GB Unified Memoryを持つMac Studioを4台接続し、GPUから利用できる2 TBのローカルクラスターを構築した。しかし以前の5台構成では、比較上、推論が91%遅くなった。

動画はpipeline parallelismとtensor parallelismの違いを説明する。pipelineでは各Macが担当レイヤーを処理して次へ渡すため、大型モデルは入るが他ノードが待つ。tensorでは全Macが同じレイヤーを同時処理し、少量データを高頻度で交換する。ここでは遅延が決定的だ。

NetworkChuckの環境では遅延が約300から3マイクロ秒へ下がる。Llama 70Bはpipelineの毎秒約5 tokenから、tensorとRDMAで約16 tokenへ増えた。クラスター全体が100倍速いわけではない。接続遅延が約100分の1になり、モデルスループットは3倍強になった。

macOS 26.2以降、Thunderbolt 5搭載Apple silicon MacはRDMA over Thunderboltに対応する。登録メモリ領域間の転送負荷を減らし、AppleはMLX DistributedとJACCLに合わせて実装した。

それでも物理法則は残る。Appleは低遅延のため完全メッシュを推奨する。2台なら1接続、3台なら3本、4台なら6本だ。5台以上ではポート不足からringが現実的になるが、中継ノードが必要になる。現実装には最大10 UC Queue Pairs、双方向send/receiveのみという制限もある。

インターネット越しに複数の完全モデルを別々のマシンで提供し、ジョブを振り分けることはできる。1つのモデルをチューリヒ、ベルリン、ニューヨークにまたがって分割するのは別問題だ。hopごとにtoken生成は遅れ、遅いノード1台がpipeline全体を止める。

RAMは単純には足せない

モデル重み、KV cache、実行データ、長いコンテキストや同時ユーザーの余裕はどこかに置く必要がある。各64 GBでモデルを動かす2人は2つの推論ノードを持つのであって、128 GB共有メモリの1台ではない。真のmodel shardingだけが境界を動かし、その代償は通信、複雑性、障害リスクだ。

2026年のDRAM市場も厳しい。TrendForceは第3四半期も供給が逼迫し、AIサーバー需要が記録的価格を支えるとする。Shared Computeは既存ハードウェアの価値を上げるが、大容量RAMの新しいローカル機を安くはしない。

すでに3台を所有するなら共有は合理的だ。クラウド料金を避けるためだけに高価な3台を買うのは逆効果かもしれない。電力、冷却、部品、回線、管理、停止リスクは消えない。

Buzz Meshの本当に面白い点

強みは新しい分散推論手法ではなく、既存部品をつなぐことだ。コミュニティにはメンバー、ID、権限があり、エージェントとローカルモデルもある。Buzzは共有を製品設定にし、エージェントが通常のproviderとして利用できるようにする。

信頼範囲も現実的だ。何百万もの匿名ノードではなく、すでに共同作業する人から始める。代理店、小企業、研究、開発チームにとって現実的である。

モデル非依存性も利点だ。open-weightモデルなら重み、設定、runtimeを制御できる。ただし「モデルを所有する」は省略表現で、open weightsはpublic domainではない。ライセンスが利用、再配布、商用運用を制限する場合がある。主権とは、重みを入手でき、ライセンスを理解し、runtimeを制御し、データを輸出し、元providerなしで運用できることだ。

まだ納得できない点

報酬モデルがない。小チームなら自発的共有でよいが、1人が10人分の電力と機材を負担するなら、制限、優先順位、計測、公平な精算が必要だ。NostrとLightningは部品を提供するが、完成した経済ではない。

運用も課題だ。誰がモデルとライセンスを更新、検証し、どのノードが機密promptを見られるか。過負荷、sleep、移動中のノートPC、回答途中の離脱にどう対応するか。クラウドは高いが、この地味な仕事を多く引き受ける。

Buzzが転送するのはモデル要求であり任意コードではない。妥当な境界だが、promptは機密になり、モデルは改ざんされ、エージェントは過剰な文脈を送る可能性がある。メンバーシップはアクセス制御であって善良さの保証ではない。企業には分類、ログ、クォータ、モデル承認、endpoint強化、ローカル必須ジョブの規則も必要だ。

Buzzはまだ若い。公開コード、アーキテクチャ、具体的テスト経路はスライド以上だが、feature flag、速いリリース、変化する文書は発展途上を示す。非重要データの実験にはよいが、exit planなしで中核業務を依存させる段階ではない。

実際に実装されているもの

Buzzは以前のスマートグリッド全体ではなく、最も合理的な第一層を実装する。既存の社会的信頼構造に基づく、限定的で自発的な計算セルだ。

公開市場、安定したcredit、hardware attestation、独立検証、未知の数千ノードの運用はまだない。一方で、理解しやすい画面と直接的な用途がある。エージェントにはモデルが必要で、メンバーにはPCがある。relayが調整し、マシンが計算する。

小さな輪が安定すれば、クォータ、credit、Lightning決済、地域連携、検証可能jobを追加できる。まず小さな輪が確実に動く必要がある。

本記事の根拠と限界

私はBuzz Meshを複数PC環境で自らテストしていない。評価は公開コード、アーキテクチャ、Mesh構想、開発ガイド、Nostr仕様、AppleのRDMA資料に基づき、2026年8月21日に確認した。安定性、スループット、実負荷に関する記述は私自身の測定ではない。

それでもBuzzは、分散計算のアイデアが利用可能な製品になる姿を最も具体的に示す例だ。まだ小さく、初期段階で、経済も未解決だが、もはや理論だけではない。

それでは、また次回。
Joe