接續：Jev 社群外掛生態研究（X 20專案清單）- 2026-09-21、blog《兩顆本地 LLM 協同作業實測：Muse-Glimmer × Qwen3.8》（2026-08-16）
結論先行：Bonsai-2-27B 已正式取代 Apodex-1.1-mini 佔據 :8083，生成速度是 NVFP4 主力的 ~2.7 倍，m-a-s 實測「synthesize 輪」速度勝過 Muse baseline（585s vs 942s）且品質相當；critique 輪因 8080 審查者速度瓶頸未在時限內完成，已定位根因。
一、模型是什麼
prism-ml/Ternary-Bonsai-2-27B-gguf：Qwen3.8-27B 的 ternary 量化版（與 :8080 主力同一 base）- 真正的 1.72 bits/weight（{−1,0,+1} + 每 128 權重一個 FP16 scale，Hadamard rotated basis），官方宣稱保留 98.2% FP16 智力（14 個 thinking 基準平均 84.78，vs 傳統 IQ2_XXS 的 72.59）
- 262K context（75% linear attention）、vision tower 以 0.63GB mmproj 選載
- 兩種打包：PTQ1_0（1.75bpw，5.95GB）/ PQ2_0（2.13bpw，7.21GB）——已各下載一份備用
二、部署經驗（踩坑全記錄）
- 原版 llama.cpp 拒載：
ggml-org/llama.cpp（b11.524，2026-08 build）無法解析 PTQ1_0/PQ2_0 packing。必須用 PrismML fork（github.com/PrismML-Eng/llama.cpp）——其最新 commit 就是 CUDA PTQ1_0 MMQ tile 優化。fork 以~/mllib-bonsai獨立建置（-DGGML_CUDA=ON），不干擾~/mllib生產環境。 - CUDA OOM 於 cudaSetDevice：初次試載失敗不是模型問題，是三個現役 llama-server 已吃滿統一記憶體。解法 = 停掉 8083 Apodex（本來就是被取代對象）再載。
- systemd 化：
llama-server-bonsai.service（user unit，含 OOMScoreAdjust、Restart=on-failure），ctx 262144、KV q4_0、parallel 1、mmproj Q8_0。 - 每日重啟：
restart_llama_bonsai_daily.sh+ timer 04:20（錯開 8080 的 04:00 錯峰），重啟後 health check + TG 通知。已確認 8080 的 restart 腳本不涉及 8083，不會互踩。 - thinking model 行為：推理在
reasoning_content、答案在content（llama.cpp 分離）。max_tokens 要給足（推理也計入），否則 content 為空。 - 回滾路徑：Apodex 檔案原封不動在
~/models/Apodex/，殺 8083 重啟舊指令即回滾。
三、NVFP4 vs Ternary 對照測速（同題、各兩輪、溫熱快取）
| 指標 | :8080 Qwen3.8-27B NVFP4 (15.5GB) | :8083 Bonsai PTQ1_0 (5.95GB) |
|---|---|---|
| 生成速度 | 5.2 / 6.1 tok/s | 14.4 / 16.5 tok/s（~2.7×） |
| Prompt 處理 | 12,553 / 1,270 ms | 312 / 334 ms（~4×） |
| 權重記憶體 | 15.5GB | 5.95GB |
原理：ternary packed weights 直接被 kernel 消費不展開，weight traffic 極小 → 記憶體頻寬瓶頸大幅緩解。NVFP4 的強項（4-bit 精度）在頻寬受限場景反而是負擔。
⚠ 環境變數註記（2026-09-23）：測試當天氣候炎熱，DGX Spark 有 CPU 降頻至 ~55%、GPU 降頻至 ~60% 的熱節流現象。上表數據為同機同條件下的相對對照（Bonsai vs NVFP4 的 2.7×/4× 差距與結論不受影響），但絕對值（14–16 tok/s、6 tok/s 等）比機器涼爽時的滿血表現偏低，不宜直接引用為 DGX Spark 的標準效能基準。m-a-s 各輪耗時同理——輪內相對比較有效，與 8/16 blog baseline 的絕對秒數對照時需打折看待（該次為不同季節/溫度）。
品質觀察：簡單事實題 Bonsai 出現過一次錯答（把 P/E 講成 P/B，第二輪即正確）——ternary 量化的代價。分工建議：精確事實/審查走 8080 NVFP4；起草/規模化/輔助任務走 8083 Bonsai。
四、m-a-s 四輪任務對照（multi-agent-synthesizer，Bonsai 接任 Muse 角色）
config：[muse]（起草者）→ 8083 Bonsai；[qwen]（審查者）→ 8080 NVFP4；[synthesizer] → 8080。
| 模式 | Blog baseline（Muse×Qwen, 8/16） | 本輪（Bonsai×Qwen, 9/23） | 備註 |
|---|---|---|---|
| synthesize（Flutter 計數器+Riverpod+Logger DI） | 942s / 品質 8.5 | 585s / 品質 ≈8.5 | 完整可跑：StateNotifier + abstract DataLogger + 建構子注入 + MockDataLogger 可測性說明，零截斷 |
| pipeline（Qwen 出 JSON 規格 → Bonsai 實作 Flutter Web 圖片上傳+離線佇列） | 1020s / 品質 7 | 1444s / 品質 ≈7.5 | 1202 行完整實作（狀態機/Hive 佇列/重試/生產注意事項），零截斷 |
| critique（Bonsai 起草 → Qwen 審查修正） | ~600s / 品質 8.5 | ❌ 兩次未完成 | 見下 |
| critique —reverse | — | ❌ 未跑（跟隨 critique 失敗而停） | — |
critique 失敗根因（兩層）：
-
第一跑：Bonsai thinking 鏈 + 完整程式碼吃光 max_tokens=16384 → content 空輸出（0 bytes，2400s timeout）——與 blog 中 Qwen 的教訓完全同款。修法：config 對 muse 加
chat_template_kwargs = { enable_thinking = false }。 -
第二跑（thinking off）仍未在 2400s 內完成：真正的瓶頸是 8080 審查者只有 ~6 tok/s，16K tokens 的全篇修正版要 45 分鐘以上。timeout 是我們 benchmark 腳本設的，不是模型壞了。
修正建議（下次重跑）：critique 模式 timeout 放寬到 5400s，或 max_tokens 降到 8192，或審查階段改交給另一顆 Bonsai（用兩顆同模型互審會失去異質觀點，不建議）。
五、結論
- Bonsai-2-27B 以 1/3 記憶體、2.7× 速度，提供了接近 NVFP4 主力的智力——Apodex 槽位的正確繼任者，「小而快但不是玩具」。
- m-a-s 的 synthesize 輪證明它能在真實多模型協作中勝任起草角色（585s vs Muse 的 942s，品質持平）。
- 8080 NVFP4 仍是品質天花板（事實正確性、審查深度），但速度瓶頸真實存在——若未來 Qwen3.8 系也出 ternary 思考版，值得整組換。
- 模型/腳本位置：模型
~/models/Ternary-Bonsai-2-27B/；fork~/mllib-bonsai/；servicellama-server-bonsai.service；benchmark~/ZCodeProject/multi-agent-synthesizer/benchmarks/；產出outputs/20260923-*。