Skip to main content
BRICKS Buttress 清楚地分為四層 — 客戶端、伺服器、後端核心，以及共用的硬體 guardrails — 透過 JSON-RPC WebSocket 協定與 UDP 自動探索傳輸串接。下方圖示為目標架構；已實作與計劃中區段會標明目前已上線與仍在路線圖上的項目。

​
完整架構

橘色實線箭頭代表執行階段的資料路徑。綠色虛線箭頭表示 Hardware Guardrails 套件在客戶端與伺服器兩側共用 — 雙方執行同一份程式碼。灰色虛線節點（Thermal Printer、Future Backends）為路線圖上尚未推出的項目。

​
各層職責

​
能力比較如何運作

當 Foundation 裝置啟動 generator 時，客戶端與伺服器會交換硬體資訊，讓系統選擇要在哪一側執行：
  1. 客戶端收集本機能力。 GPU／CPU 資訊、可用記憶體、模型 metadata（層數、embedding 大小、KV cache 需求）。
  2. 客戶端將能力資訊送至伺服器，並附帶模型識別子與要求的 context 長度。
  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。請參閱區域網路自動探索。
  • 參考計數的 generator registry — 多個客戶端可共用同一已載入模型，refcount 歸零時伺服器自動清理。
  • 佇列管理 — 針對 STT 的硬體感知請求排隊，平行 slot 狀態可於 /status 儀表板檢視。
  • 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 端點，讓 agent 在伺服器主機上執行工作。可匯入的範圍僅限 Node 內建模組、同層檔案，以及 sqlite3 與 sqlite-vec 這份允許清單。與其他所有介面不同，函式在未繫結的伺服器上採預設拒絕。參見本地函式。

​
計劃中

  • Docker 發行 — 預建好支援 CUDA／Vulkan 的映像檔。
  • 多伺服器池選擇 — 同一工作區存在多台已繫結伺服器時的能力感知排序（目前以最近見到者為準）。
  • 熱感印表機後端 — LLM／STT 之外的額外卸載目標。

​
相關文件

工作區繫結

JWT 認證如何融入此架構。

區域網路自動探索

UDP 傳輸、通告酬載與能力評分。