メインコンテンツへスキップ

Documentation Index

Fetch the complete documentation index at: https://docs.bricks.tools/llms.txt

Use this file to discover all available pages before exploring further.

Foundation launcher にはハードコードされたサーバー URL は不要です。各 Buttress サーバーが LAN 上で自身を通知し、バインド済み launcher が generator の種類ごとに最も適したサーバーを選びます。

​
仕組み

各 Buttress サーバーはポート 8089 で UDP トランスポートを実行します：
  • ANNOUNCE — 5 秒ごとにブロードキャストし、サーバーの serverInfo（能力、generator、認証ステータス）を含めます。
  • QUERY — launcher がクエリをブロードキャストでき、サーバーがユニキャストで RESPONSE を返します。レスポンス遅延はランダム化され、多数のサーバーが同時に応答してストームになるのを防ぎます。
トランスポートは 0.0.0.0:8089 で受信ソケットをバインドして受信クエリを受け取り、ローカルブロードキャストインターフェースごとに送信ソケットを 1 つずつバインドして、各サブネットのブロードキャストが正しい NIC から出るようにします。

​
アナウンスのペイロード

serverInfo には起動時に算出された各バックエンドのハードウェア能力を含む generators[] 配列があります： 
{
  "id": "buttress-mac-studio",
  "name": "Studio LLM",
  "version": "2.25.0-beta.9",
  "authentication": {
    "required": true,
    "type": "workspace-jwt",
    "kid": "<key id>",
    "bound": true
  },
  "generators": [
    { "type": "ggml-llm", "score": 57, "hasGpu": true, "usableBytes": 21474836480 },
    { "type": "ggml-stt", "score": 57, "hasGpu": true, "usableBytes": 21474836480 }
  ]
}
Foundation launcher は generator の種類（LLM、STT、MLX）でアナウンスをフィルターし、要求されたバックエンドを実行できる中で最高スコアのサーバーを優先します。

​
能力スコア

スコアは 0〜100 の数値で、次の項目を組み合わせています：
項目最大点出典
GPU の有無40hasGpu
バックエンドバリアント20CUDA = 20、Metal = 15、Vulkan = 10、CPU = 5
GPU メモリ2012 GB を基準にスケール
CPU メモリ1032 GB を基準にスケール
サーバー稼働状況10ok ヘルスフラグ
GPU なしのノート PC で 15〜25 点ほど、RTX 4090 を積んだワークステーションで 80〜90 点に達します。

​
信頼モデル

バインド済みサーバーも未バインドサーバーもどちらもアナウンスしますが、launcher の扱いは異なります：
  • 未バインドサーバー（authentication.required = false）は信頼されないエンドポイントとして表示されます。手動／パブリッククライアントからは引き続き利用できますが、バインド済み launcher は無視します。
  • バインド済みサーバー（authentication.required = true）は、serverId がワークスペースのバインド済みサーバー一覧に含まれており、かつ ワークスペースがバインド時に登録した該当サーバー専用のアナウンス鍵で署名されている場合にのみ信頼されます。

​
署名付きアナウンス

各 Buttress サーバーは独自の Ed25519 アナウンス鍵ペアを持ち、bricks buttress bind 実行時に生成されます。公開鍵は BRICKS クラウドに登録され、launcher へは myWorkspaceButtress.buttressServers[].serverPublicKey 経由で公開されます。秘密鍵はサーバーホストの ~/.bricks-cli/buttress/state.json に保管されます。 バインド済みサーバーが送出するすべての UDP ANNOUNCE と RESPONSE には、{ t, d, ts } に対する署名が付きます。launcher は登録済みの鍵で署名を検証し、30 秒のリプレイウィンドウを適用します。有効な署名のないパケットはエンドポイントプールに入りません。これにより、LAN 上のピアがバインド済み serverId を再アナウンスしてワークスペースの bearer トークンを得ようとするなりすまし経路が塞がれます。 ワイヤープロトコルのバージョンは 2.0 に上がりました。プロトコル 1.0 と 2.0 を実行している launcher／サーバーは互いのパケットを無音で破棄するため、新旧の組み合わせは未署名のまま信頼を交換するのではなく、互いに見えなくなる形で共存します。既存のバインド済みサーバーをアップグレードするには、bricks buttress bind を再実行（新しいアナウンス鍵ペアが生成されます）し、bricks-buttress を再起動してください。

​
手動指定

自動検出が現実的でない場合（デバイスが別サブネットにある、Buttress サーバーがクラウドにあるなど）、BRICKS Controller の Config Editor で各 LLM/STT brick を Auto から Manual に切り替え、WebSocket URL を直接入力できます。Foundation から Buttress を使用を参照してください。

​
HTTP フォールバック

launcher は既知の IP に対して直接 HTTP で問い合わせることもできます： 
curl http://<サーバーホスト>:2080/buttress/info
このエンドポイントは UDP ANNOUNCE と同じ serverInfo ペイロードを返します。Foundation launcher は UDP ブロードキャストがブロックされている環境（一部の企業 Wi-Fi など）で内部的にこの経路を使用します。

​
トラブルシューティング

症状原因と思われるもの対処
デバイスがサーバーをまったく見つけられないスイッチや AP で UDP ブロードキャストがブロックされている有線ネットワークに切り替える、udp/8089 のブロードキャストを許可、または手動 URL を使用
iOS デバイスがセルラーでのみサーバーを見つけ、Wi-Fi では見つけられないブロードキャストソケット上の iOS IP_BOUND_IF の癖launcher 側で対応済み — アクティブクエリを Wi-Fi の IP に再バインドして自動的に解決
サーバーは通知しているがデバイスが無視するサーバーが未バインド、または別ワークスペースにバインドbricks buttress status を実行し、必要に応じて再バインド
serverInfo.generators[] が空TOML 設定に generator がないか、すべてロードに失敗サーバーログでダウンロードやハードウェア検出のエラーを確認

​
次のステップ

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

サーバーの kid とバインド済みサーバー一覧の発行方法。

Foundation から利用

brick ごとの接続設定：Auto と Manual、ストラテジー、フォールバック。