アーキテクチャ

BRICKS Buttress はクライアント、サーバー、バックエンドコア、共有ハードウェアガードレールの 4 層に明確に分かれており、JSON-RPC WebSocket プロトコルと UDP 自動検出トランスポートで接続されます。下図は目標アーキテクチャです。実装済みと計画中セクションで、現在出荷されているものとロードマップ上のものを示します。

​

完全なアーキテクチャ

​

各層の役割

​

能力比較の仕組み

Foundation デバイスが generator を起動すると、クライアントとサーバーがハードウェア情報を交換し、どちら側で実行するかを決めます：

1. クライアントがローカルの能力を収集。 GPU/CPU 情報、利用可能メモリ、モデルメタデータ（層数、embedding サイズ、KV cache 要件）。
2. クライアントが能力情報をサーバーに送信。 モデル識別子と要求コンテキストサイズも一緒に送ります。
3. サーバーが両側を評価。 クライアントが報告した能力とサーバー自身に対して同じ guardrails コードを実行し、双方に 0〜100 のパフォーマンススコアとメモリ収まり判定を返します。
4. サーバーが推奨を返却 — local、buttress、either のいずれか。
5. クライアントが決定。 自身のストラテジー（prefer-local、prefer-buttress、prefer-best）と推奨結果から最終的に選びます。詳細は Foundation から Buttress を使用を参照してください。

クライアントとサーバーが同じ guardrails パッケージを共有しているため、スコアは直接比較可能です — 双方間に較正のずれは生じません。

​

実装済みと計画中

​

実装済み

• ワークスペース JWT 認証 — ワークスペースごとに Ed25519 発行者、短命な { k:'ba', w_id, … } access token。ワークスペースバインディングを参照。
• UDP 自動検出と署名付きアナウンス — UDP 8089 上の ANNOUNCE／QUERY／RESPONSE、アナウンスにバックエンドごとのハードウェア能力を含めます。バインド済みサーバーは登録済みの Ed25519 アナウンス鍵で全パケットに署名し、launcher は 30 秒のリプレイウィンドウで署名を検証します。プロトコルバージョンは 2.0。LAN 自動検出を参照。
• 参照カウント方式の generator registry — 複数クライアントで読み込み済みモデルを共有でき、refcount が 0 になるとサーバーが自動クリーンアップ。
• GGML LLM、MLX LLM、GGML STT、GGML TTS、ONNX STT、ONNX TTS バックエンド — GGML TTS は GGUF のバックボーンとその codec / vocoder GGUF を組み合わせ、モデルファミリーをネイティブに判別します。ONNX バックエンドは ONNX Runtime で動作します（STT は Whisper、TTS は Kokoro、VITS、Bert-VITS2、SpeechT5）。
• 能力検出とスコアリング — 双方で同じ guardrails コードを実行。
• STT のファイル転送 — デバイスが POST /buttress/upload に音声をアップロード。
• ローカル関数（実験的）— 運用者が書いた .ts / .js ファイルを MCP ツールと HTTP エンドポイントとして公開し、エージェントがサーバーホスト上で処理を実行できます。import できるのは Node の組み込みモジュール、同階層ファイル、そして sqlite3 と sqlite-vec の許可リストに限られます。他のすべての面と違い、未バインドのサーバーではデフォルト拒否です。ローカル関数を参照してください。

​

計画中

• キュー管理 — 優先度サポート付きのハードウェア対応リクエストキュー。
• Docker 配布 — CUDA／Vulkan サポート付きのプリビルドイメージ。
• 複数サーバープール選択 — 同一ワークスペースに複数のバインド済みサーバーがある場合の能力ベースのランキング（現在は最終視認者が勝ち）。
• サーマルプリンターバックエンド — LLM／STT 以外のオフロードターゲット。

​

関連項目