要件
- BRICKS Foundation 2.25 以降
- LAN 上で到達可能な Buttress サーバー — Buttress インストールを参照
- サーバーがデバイスと同じワークスペースにバインドされている — ワークスペースバインディングを参照
仕組み
- デバイスのワークスペースに少なくとも 1 つのバインド済み Buttress サーバーがあると、launcher はディスカバリーマネージャーを起動し、ワークスペーススコープの JWT を取得します。
- マネージャーはポート
8089で UDP アナウンスを待ち受け、serverIdがワークスペースのバインド済み一覧にあるサーバーをすべてプールします。 - 各 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 は、利用可能なサーバーを自動で検出します。
- ハードウェア能力比較によりローカル・リモート・どちらでも実行のいずれかが推奨され、brick で選んだストラテジーがその推奨をどう解釈するかを決めます。
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 URL と Vocoder 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 は次の処理を行います:- 動作中の Buttress マネージャーを停止し、開いている WebSocket 接続をすべて閉じる。
- キャッシュされた access token を破棄する。
- 新しいワークスペースのバインド済みサーバー一覧と、新たに発行されたトークンでマネージャーを再起動する。
音声アップロード(STT)
音声認識の文字起こしには音声ファイルがサーバーに必要です。brick は HTTPS でPOST /buttress/upload にアップロードし、サーバーは [server] temp_file_dir で設定された一時ディレクトリ(デフォルトは <os-tmpdir>/.buttress)に保存します。文字起こし後、ファイルはセッションの他の一時ファイルとともに自動でクリーンアップされます。
音声合成は逆方向です。サーバーは合成した音声を WAV ファイルとして返し、繰り返されるフレーズはサーバーのディスク上の出力キャッシュから即座に提供されます。
トラブルシューティング
関連項目
Buttress 概要
Buttress とは何か、いつ使うか、システム全体の構成。
ワークスペースバインディング
サーバーとデバイスが同じワークスペースに所属する仕組み。