Skip to main content
BRICKS Foundation は LLM、MLX、音声認識、音声合成の推論と Vector Store の埋め込み処理を、同じ LAN 上の BRICKS Buttress サーバーへオフロードできます。brick の generator API は変わらず、サーバー側で実行する方が速い(あるいはローカルでは動かない)場合に、デバイスは透過的に処理を委譲します。

要件

仕組み

  1. デバイスのワークスペースに少なくとも 1 つのバインド済み Buttress サーバーがあると、launcher はディスカバリーマネージャーを起動し、ワークスペーススコープの JWT を取得します。
  2. マネージャーはポート 8089 で UDP アナウンスを待ち受け、serverId がワークスペースのバインド済み一覧にあるサーバーをすべてプールします。
  3. 各 LLM、MLX、Speech-to-Text (GGML)、Text-to-Speech (GGML)、Vector Store brick は Buttress (Remote Inference) グループを読み、自動でサーバーを選ぶか、手動で設定された URL を使います。Speech-to-Text (ONNX) と Text-to-Speech (ONNX) の Generator は、利用可能なサーバーを自動で検出します。
  4. ハードウェア能力比較によりローカル・リモート・どちらでも実行のいずれかが推奨され、brick で選んだストラテジーがその推奨をどう解釈するかを決めます。
launcher がサーバーに到達できない(LAN なし、サーバーオフライン、ワークスペース不一致)場合、ローカル実行にフォールバックします。明示的にオフにしている場合を除きます。

brick でオフロードを設定

BRICKS Controller > Config Editor で任意の LLM、MLX、Speech-to-Text (GGML)、Text-to-Speech (GGML)、Vector Store brick を開きます。Buttress (Remote Inference) プロパティグループは Connection の下に表示されます。Speech-to-Text (ONNX) と Text-to-Speech (ONNX) の Generator にはまだこのグループがなく、LAN 上の利用可能なサーバーを自動で検出します。

ストラテジー

prefer-buttress がデフォルトなのは、Buttress を有効化する Foundation デバイスのほとんどがローカルハードウェアでは最速ではないからです。

フォールバック

LAN が切れたときも brick を動かし続けたいなら use-local、デバイスが扱えないモデルをこっそり動かしてバッテリーを消費するより明確に失敗させたいなら no-op を選んでください。

Vector Store

Vector Store brick は埋め込みモデル tokenizer の両方をオフロードするため、デバイスはどちらの GGUF もダウンロードせずにドキュメントをインデックスし検索できます。オフロードされるのは GGML ソースだけで、OpenAI Compatible ソースでは brick がその API を直接呼び出し、Buttress は関与しません。 brick が要求するのは LLM brick と同じバックエンド種別の ggml-llm generator なので、自動検出はその種別を提供するサーバーを選びます。サーバーは brick 自身の埋め込みモデルを埋め込みモードで読み込み、まだ持っていなければダウンロードします。Vector Store には専用の埋め込みモデルを指定してください。近くの LLM brick が使う chat モデルを指しても動きません。 埋め込みモデルと tokenizer モデルは、モデルの URL を直接貼り付けるのではなく Hugging Face のピッカーから選んでください。Buttress にはリポジトリ id が必要で、URL しかない brick は何も言わずにローカル実行のままになります。 リモートで動く範囲は tokenizer の設定によって変わります。 リモートのモデルが書き込んだ埋め込みには、ローカルで生成したものと同じモデル記述が付きます。そのため同じモデルであれば、デバイス上で作ったインデックスは brick を Buttress に切り替えたあとも、戻したあとも検索できます。

Text-to-Speech (GGML)

Text-to-Speech (GGML) brick は、サーバーの ggml-tts generator に音声合成をオフロードします。サーバーはローカルで読み込むのと同じバックボーンと codec / ボコーダーの組み合わせを読み込みます。サーバーは WAV を返し、デバイスはそれを brick 自身の音声キャッシュにダウンロードします。そのため、デバイス側で合成してもリモートで合成しても、ローカルのキャッシュヒットとクリーンアップの挙動は変わりません。 Model URLVocoder URL には Hugging Face の resolve URL を指定するか、Hugging Face ピッカーで選択してください。brick は URL からリポジトリ ID を復元してサーバーに読み込む対象を伝えます。モデル URL が Hugging Face の resolve URL でない場合、brick はローカル推論のままになります。 OuteTTS 以外のモデルをオフロードする前に、brick はそのモデルのファミリー — OuteTTS、Soprano、NeuTTS、CSM、Qwen3-TTS、MOSS-TTSD、MOSS-TTS-Realtime、Chatterbox、BlueMagpie — をサーバーがアナウンスしているか確認します。アナウンスされていない場合、brick は内容の異なる音声を返す代わりにローカル実行のままになります。このチェックは prefer-buttress を含むすべての strategy で実行されます。

ワークスペースが変わったとき

デバイスのワークスペースが変わると(例:管理者が BRICKS Controller から再割り当て)、launcher は次の処理を行います:
  1. 動作中の Buttress マネージャーを停止し、開いている WebSocket 接続をすべて閉じる。
  2. キャッシュされた access token を破棄する。
  3. 新しいワークスペースのバインド済みサーバー一覧と、新たに発行されたトークンでマネージャーを再起動する。
旧ワークスペースで認証されていた進行中の generator は無限再接続ループに陥らず、きれいにエラーで終わります。

音声アップロード(STT)

音声認識の文字起こしには音声ファイルがサーバーに必要です。brick は HTTPS で POST /buttress/upload にアップロードし、サーバーは [server] temp_file_dir で設定された一時ディレクトリ(デフォルトは <os-tmpdir>/.buttress)に保存します。文字起こし後、ファイルはセッションの他の一時ファイルとともに自動でクリーンアップされます。 音声合成は逆方向です。サーバーは合成した音声を WAV ファイルとして返し、繰り返されるフレーズはサーバーのディスク上の出力キャッシュから即座に提供されます。

トラブルシューティング

関連項目

Buttress 概要

Buttress とは何か、いつ使うか、システム全体の構成。

ワークスペースバインディング

サーバーとデバイスが同じワークスペースに所属する仕組み。