【2026 最新】Bonsai 2 27B 完整解析：5.9GB 真能保留 98.2% 能力？（含硬體預算＋安裝＋12 題驗收）

2026 年 9 月 17 日，PrismML 發布 Bonsai 2 27B：把 Qwen3.8-27B 的語言模型權重壓到 5.9GB，並宣稱保留 98.2% 的彙總 benchmark 表現。這兩個數字很吸睛，但也最容易讓人誤判——5.9GB 是模型檔大小，不是整台電腦的記憶體需求；98.2% 是廠商測試的平均分數比，不是每個任務都只退步 1.8%。

這篇 Bonsai 2 27B 教學不把來源研究包裝成 AlphaLab 親跑結果：本次工作環境沒有已安裝的配對 runtime，也沒有足夠的安全磁碟餘裕下載 6～9GB 權重與依賴。本文改用目前可下載的 GGUF／MLX 檔案、官方 demo 原始碼、白皮書方法與外部實跑紀錄，教你看懂證據，再提供一套可在自己硬體重跑的 12 題驗收法。

如果你完全不懂 ternary、GGUF、KV cache，也可以從零讀完。先記住全文的核心公式：

可日用性 ＝ 權重能放進去 × runtime 能正確跑 × 你的任務能過關。

先說結論：Bonsai 2 27B 值得試，但 98.2% 還不是採購答案

• 壓縮是真的：目前 Hugging Face 檔案列出的 PTQ1_0 是 5.95GB、PQ2_0 是 7.21GB，FP16 對照檔約 53.81GB；視覺 projector 另計 0.63GB。
• 98.2% 不能橫推：官方模型卡的 14 項平均是 84.78／86.32，白皮書的 20 項平均是 83.9／85.4，兩者四捨五入後都是 98.2%，卻不是同一套分數。
• 長流程掉得更多：白皮書另列的 Terminal-Bench 2.1 與 SWE-bench Verified，大約只保留完整精度基線的四分之三；它們沒有納入 98.2% 的 20 項平均。
• 硬體先保守估：6GB 不應當成完整執行目標；8GB 的 PTQ1_0＋短 context 目前只能列為待量的容量假設；16GB 才是這三檔中較合理的起點，仍要關掉重型 App 並量峰值。
• runtime 不能亂配：Bonsai 2 需要理解 Hadamard rotation 的配對 runtime；截至 2026 年 9 月 18 日，GGUF 驗收應使用 PrismML fork／demo binary，不能交給 stock llama.cpp。

Bonsai 2 27B 是什麼？先把 ternary 想成「三段音量」

一般 FP16 模型像是讓每個權重旋鈕保留非常多刻度；ternary weight（三元權重）則先把大量權重收斂到 −1、0、+1 三個值，再用每 128 個權重共用的一個 FP16 scale 還原大小。白話說：方向只留「向左、關閉、向右」，音量由同組的 scale 控制。

Bonsai 2 27B 不是只把檔案換副檔名。依目前的 官方 GGUF 模型卡，它以 Qwen3.8-27B 為底，模型架構不變，最大 context 是 262,144 tokens；權重先進行區塊大小 1024 的 Hadamard transform，推理時 runtime 也要做配對的 activation transform。這就是為什麼「檔案讀得進去」和「輸出正確」是兩回事。

目前可下載的兩個 GGUF packing 不是「品質版」與「劣化版」，而是相同 ternary weights 的不同容器取捨：PTQ1_0 約 1.75 bits per weight、檔案最小；PQ2_0 約 2.13 bits per weight，多花約 1.26GB。依 PrismML 官方表格，PQ2_0 的 unpack 較便宜、prompt processing 普遍較快；哪個 decode 較快則會隨 GPU 世代改變，不能只看 bit 數。若你想先理解一般 Q4／Q6／Q8 和 KV cache 的差別，可接著看 GGUF 量化完整指南。

Bonsai 2 27B 的 98.2% 到底怎麼算？

算法沒有神祕處：Bonsai 平均分 ÷ Qwen3.8-27B FP16 平均分。問題在分母與測試集合。發布文與白皮書採用 20 項版本，Hugging Face 模型卡則同時呈現另一套 14 項表格：

1. 官方白皮書列 20 項、xhigh reasoning effort：83.9 ÷ 85.4 ≈ 98.2%。
2. Hugging Face 模型卡的另一套 14 項表格則是：84.78 ÷ 86.32 ≈ 98.2%。

兩組數字都能四捨五入成 98.2%，但科目、個別分數與比較用的 IQ2_XXS 檔案大小都不同，不能把兩張表的漂亮數字拼成一套新結論。它們也都是 PrismML 自行執行的結果，不是獨立稽核。最準確的寫法只能是：PrismML 在指定的彙總方法下自報 98.2% retention。

更有判斷力的是白皮書自己留下的反例。Terminal-Bench 2.1 是 52.8 對 69.7，SWE-bench Verified 是 60.8 對 80.6，分別約保留 75.8% 與 75.4%；這兩項另列，沒有放進 20 項平均。把 reasoning effort 從 xhigh 改成 medium 時，白皮書 20 項平均則是 79.3 對 82.6，約 96.0%。所以「98.2%」描述的是一張特定成績單，不能改寫成「coding、tool calling、vision、繁中和長 context 都只掉 1.8%」。

首發隔日能找到的第三方證據仍很早期。Simon Willison 在 Hacker News 留下 M5 Pro 紀錄：使用 PTQ1_0、PrismML llama.cpp fork 與 32K context，第一次約 20 tok/s，重啟後約 44 tok/s，原因不明，並伴隨 Metal tensor API warning。這能支持「指定設定確實載入並生成」，不能支持通用 M5 Pro 速度、峰值記憶體或 98.2% 品質。

靜態 benchmark 也不等於 native tool loop。這份白皮書的 BFCL v3 是把 function schema 放進 system prompt，再從模型文字輸出解析 call，不是 OpenAI-style tool_calls API loop。它能反映函式選擇與參數能力，卻不保證你的錯誤回傳、重試策略與 chat template 組合後仍可靠。要把模型差異和 runtime 差異拆開，可用 本機 LLM 五關 A/B Test；要看同一個 27B 級別如何驗 Agent，可對照 Qwen3.8-27B 本機 Agent 六關協定。

Bonsai 2 27B 要多少記憶體？6／8／16GB 先這樣抓

模型檔只是搬進房間的家具；runtime、activation、KV cache、作業系統和其他 App 都還要佔空間。固定版 README 的 peak-memory 表只列較早的 27B 家族，不能拿它推算 Bonsai 2 的額外 overhead；這一項要在目標機量。較直接的規格是 FP16 KV cache 約 64KiB／token；Q8 vision projector 的磁碟檔是 0.629GB，官方 runtime 容量指引則約 0.9GiB。用這些數字做容量規劃，仍比把 5.95 直接和 RAM 標示相比可靠。

• 6GB：PTQ1_0 檔案本身已接近容量上限，沒有合理的 runtime、KV 與 OS 餘裕。不要把「5.9GB」翻譯成「6GB 裝置可日用」。
• 8GB：PTQ1_0、text-only、4K 左右 context 只是一個待量的容量假設，不是本文提供的可交付路徑；共享記憶體還要扣掉 OS，本文不替它承諾峰值或速度。不要照下一節的預設 PQ2_0 指令在 8GB 機器開跑。
• 16GB：三檔中最合理的入門點。先用 PTQ1_0 或官方預設 PQ2_0、8K／16K context、單一 request，關閉重型 App 後記錄峰值；vision、長 context 和並行數一次只加一項。

262K 是模型支援上限，不是小記憶體裝置的預設建議。單算 FP16 KV，262,144 tokens 就約 16GiB，尚未加入權重與 overhead；官方啟動腳本因此依 RAM 分級選 context，而不是直接把最大值塞滿。想把 UMA、VRAM、offload 與 context 放進同一棵決策樹，可看 本機 LLM 顯存怎麼選。

Bonsai 2 27B 安裝路徑：先選 llama.cpp、MLX 還是 WebGPU

路徑 A：官方 Bonsai-demo＋配對 llama.cpp，最適合完整驗收

對 Mac、Linux 或受支援 GPU 的新手，先用 官方 demo 的固定版本。下列是 16GB 以上裝置的預設 PQ2_0 smoke path，不是 8GB 路徑。llama-only setup 關掉 MLX、Open WebUI 與 code interpreter，減少額外下載；執行前先用 df -h . 檢查空間，並閱讀腳本。GGUF 預設仍會下載 7.206GB 的 PQ2_0 加 0.629GB projector，合計約 7.835GB，還沒算 binary 與依賴；它不是廣告主打的 5.95GB PTQ1_0。

git clone https://github.com/PrismML-Eng/Bonsai-demo.git
cd Bonsai-demo
git checkout --detach c398c6eeef7533dd9398682cc1297e33670df0cd

# 精簡安裝：保留 GGUF 與 runtime，略過 MLX／WebUI／code interpreter
BONSAI_SKIP_MLX=1 BONSAI_OPENWEBUI=0 BONSAI_CODE_INTERPRETER=0 ./setup.sh

# 先以 8K context 做文字 smoke test
BONSAI_CTX=8192 ./scripts/run_llama.sh \
  -p "請用繁體中文解釋：5.9GB 模型檔為何不等於 5.9GB 執行記憶體？"

看到通順答案只是第一關。若要接 OpenAI-compatible client，再用 BONSAI_CTX=8192 ./scripts/start_llama_server.sh，先保持預設 loopback 位址。不要把 Bonsai 2 檔案改丟給電腦上既有的 stock llama.cpp：目前官方 README 明確說 PQ2_0／PTQ1_0 需要 PrismML fork 的 Hadamard runtime；開發用 Q2_0 甚至可能在錯誤 runtime 載入後輸出亂碼。

路徑 B：Apple Silicon 用 MLX，一次性文字／圖片推理

官方 MLX 的單一 model.safetensors 檔為 8.595GB，並打包 vision tensors。它帶有自己的 Hadamard-aware loader，不能用會跳過該轉換的普通 loader。要走 MLX-only 路徑，可用 BONSAI_SKIP_GGUF=1 略過額外的 7.835GB GGUF 下載；完成後，Apple Silicon 可這樣跑：

BONSAI_SKIP_GGUF=1 BONSAI_OPENWEBUI=0 BONSAI_CODE_INTERPRETER=0 ./setup.sh
./scripts/run_mlx.sh -p "請只輸出一個含 summary、risks、next_step 的 JSON 物件"

# 圖片測試：把 test.png 換成實際圖片路徑
./scripts/run_mlx.sh -p "列出畫面中三個可驗證元素" --image test.png

截至本次固定版本，Bonsai 2 的 start_mlx_server.sh 會主動拒絕啟動，並指向一次性 MLX 或 llama.cpp server，原因是該固定版的 mlx_lm.server／mlx_vlm.server 沒有使用模型包內 loader。這是目前腳本的明示行為，不應推廣成永遠不會有 server；更新前重新檢查官方 repo。

路徑 C：WebGPU 只當瀏覽器相容性 smoke test

webml-community 發布的 WebGPU Space能在瀏覽器端載入 Bonsai 2，與 PrismML demo／llama.cpp fork 是不同實作。瀏覽器記憶體政策、shader 編譯與 driver 都會混進結果；適合回答「這台機器能不能啟動與完成短回覆」，不適合把 tok/s 直接和官方 Metal／CUDA 表格放在一起。若你的目標是 Agent、原生 tool call 或可重跑 benchmark，回到路徑 A。

用 12 題驗收 Bonsai 2 27B：繁中、coding、tools、vision、long context

不要問一句「台北有什麼好吃」就宣布模型可用。建立一個小而固定的 acceptance set（驗收題組），每題都有輸入、預期輸出、評分規則與禁止行為。最少分成五組：

1. 繁中 3 題：一題 12 個事實的忠實摘要、一題嚴格 JSON 格式、一題需要理解上下文而非逐字翻譯的繁中指令。
2. Coding 3 題：真實 repo 的小 bug、帶 hidden cases 的函式、閱讀 diff 後找出測試遺漏；以測試結果和不該改動的檔案為準，不用「看起來合理」評分。
3. Tool calling 3 題：單工具選擇、兩步相依工具、第一次回傳錯誤後修正參數；檢查 function 名稱、JSON schema、呼叫順序和停止條件。
4. Vision 2 題：UI 截圖定位與小字／表格 OCR。記下 image token cap；若前處理不同，不能歸因給權重。
5. Long context 1 題：在逐步加長的文件中埋五個可核對 facts，要求跨段引用與拒答不存在資訊；不要一開始就跳到 262K。

每次 A/B 必須固定 prompt、system prompt、chat template、reasoning effort、sampling、context、輸出上限與 runtime commit。Bonsai 官方 thinking 設定是 temperature=1.0、top_p=0.95、top_k=20；既然有抽樣，每題至少重跑數次並保留原始輸出。每列記錄五件事：正確性、格式／tool schema、失敗型態、首 token／tok/s、峰值 RAM／VRAM。

最理想的品質對照是同 prompt 的 Qwen3.8-27B FP16；硬體放不下時，至少保留你現有的同記憶體級模型當 operational baseline。先決定門檻，例如「三次都產生合法 JSON」「hidden tests 全過」「工具錯誤後只重試一次」，再跑模型，避免看到答案後才移動球門。完整的 case、grader、trace 與 release gate 方法可延伸到 AI Evals 七步教學。

Bonsai 2 27B 適合聊天、Agent，還是只適合 demo？

• 一般本機聊天：最有希望先過關。短 context、text-only、單一使用者能把變因壓到最少；前提是繁中題組沒有出現語意漂移或格式失敗。
• 私密文件摘要：可以測，但先用短文件核對忠實度，再逐級加 context。262K 支援值不能代替長文召回與記憶體驗收。
• Coding copilot：以 repo 內可執行測試做 gate。官方 coding 平均接近基線，不代表你的語言、框架與 patch discipline 也接近。
• 本機 Agent：目前應列為「候選、需驗收」，不是「直接上線」。官方長流程成績掉幅明顯，tool schema、重試與 stop condition 還會放大差異。
• 瀏覽器 demo：WebGPU 最方便展示，但 browser runtime 的相容性與速度不能回推官方 GGUF／MLX 表現。

若你打算為一個模型買新主機，先租或借硬體跑完同一份 12 題，再用「每個通過品質門檻的任務成本」比較本機與 API；本機 LLM 主機成本損益表提供這一層決策框架。

六個最容易踩的坑

1. 把 5.9GB 當成 RAM：權重、KV、vision、runtime 和 OS 必須分帳。
2. 只看 aggregate：先找最差的任務類別，再看平均；Agent 會把小錯誤累積成長流程失敗。
3. stock runtime 輸出亂碼還怪模型：先記錄 binary、commit、packing 與 chat template。
4. 把 PQ2_0 當成品質較差：它和 PTQ1_0 是相同 ternary weights 的 packing 取捨；速度要在你的 backend 實量。
5. 一次改五個變因：context、KV4、vision、reasoning、並行數每次只改一項，否則無法歸因。
6. 把成功 demo 當穩定 Agent：至少保留多次 trial、錯誤回傳、恢復路徑與停止條件；可參考 80 次工具呼叫驗收的判讀方式。

常見問題 FAQ

1. 6GB 記憶體可以跑 Bonsai 2 27B 嗎？

不建議當成完整執行目標。5.95GB 只是最小語言模型檔；runtime、KV 與 OS 沒有合理餘裕。離散 GPU 可用 CPU offload 改變配置，但那已不是「6GB 總記憶體」。

2. 16GB Mac 可以跑嗎？

可從短 context、text-only 開始驗證，但不能先保證速度。先用 8K、單一 request、關閉重型 App，記錄 memory pressure 與 swap，再逐步加 vision 或 context。

3. 可以直接用官方 mainline llama.cpp 嗎？

截至 2026 年 9 月 18 日，不要這樣驗。目前 PrismML README 明示 Bonsai 2 的 Hadamard activation transform 尚未 upstream；用 demo 下載的配對 binary。

4. PTQ1_0 一定比 PQ2_0 慢嗎？

不一定。PTQ1_0 讀取資料更少，但解包 trits 的計算較重；官方數據中不同 GPU 世代的贏家不同，prompt processing 則偏向 PQ2_0。請在相同 backend 測兩者。

5. 98.2% 代表繁中也保留 98.2% 嗎？

不代表。那是指定 benchmark 集合的平均比值，不是語言別保證。繁中摘要、格式、語境和專有名詞要用自己的三題驗收。

6. 262K context 在 16GB 上也能直接開滿嗎？

不能從規格表推出這個結論。FP16 KV 約 64KiB／token，262K 單是 KV 就約 16GiB；先用 RAM-tiered 預設或 8K／16K，再量你的實際峰值。

7. BFCL 分數不錯，就能當可靠本機 Agent 嗎？

還不夠。BFCL／τ²-bench 是重要訊號，但真實 loop 還包含 schema、工具錯誤、觀察結果、重試與停止條件；白皮書的長流程結果也顯示落差可能更大。

8. Bonsai 2 27B 現在值得下載嗎？

值得研究本機 27B 的人測，但先不要因 98.2% 直接換掉 production 模型。它把可測門檻大幅降低；是否可交付，仍由你的 12 題、硬體峰值與重跑穩定性決定。

給新手的五個重點

1. 5.95GB 是 PTQ1_0 語言模型檔，不是完整 runtime 記憶體。
2. 98.2% 是 PrismML 的 aggregate ratio；永遠回到個別任務與測試設定。
3. Bonsai 2 27B 要配對 Hadamard-aware runtime，先用官方 demo。
4. 16GB 從 text-only、8K context、單 request 開始；不要一口氣開 vision 和 262K。
5. 先跑固定 12 題再談 tok/s：速度快但答案不過關，等於更快得到錯誤。

如果你想把這套方法擴展成可回歸的 AI 專案，而不是只測一次模型，可以到 AlphaLab 課程把 eval、Agent 與本機部署串成完整工作流。