Bonsai 對決 Ternary Bonsai 2 27B：兩種低位元賭注，兩把不同的尺

把 1-bit Bonsai 2B 視覺語言模型與 Ternary Bonsai 2 27B 並列，最顯而易見的比較——20 億參數對上 270 億，語言權重 0.43 GB 對上 5.93 GB——卻是這對模型裡最不有趣的地方。有趣的是，這兩個模型出自同一家廠商、同一套壓縮計畫，卻沒有以相同方式報告其品質。Ternary Bonsai 2 27B 報告的是保留率：它保留了其全精度對應版本超過 98% 的整體基準效能，且是以自身為基準來衡量。1-bit Bonsai 2B 報告的則是一項比較：它在 4 位元量化下，相對於 Qwen 3 1.7B 模型達到了「可比較的基準結果」，而衡量基準是別人家的模型，且精度不同。前者是在陳述失去了多少。後者是在陳述它相比之下表現如何。兩者都不是在陳述任一模型在絕對意義上有多好，而且這兩者無法用同一尺度來解讀。

那個區別比參數數量更重要，因為它決定了你究竟能從廠商提供的數字中得出什麼結論——而就目前公布的證據來看，誠實的答案比那些亮眼數字所暗示的要少。

兩項品質宣稱，兩把不同的尺

Ternary Bonsai 2 27B 於 2026 年 9 月 17 日發布，是 Qwen3.8-27B 以三值 {−1, 0, +1} 重建而成的版本，每權重有效位元數為 1.76，而 PrismML 主打強調的數字，是它保留了全精度模型整體基準效能的 98% 以上。這是一項保留率宣稱，而保留率宣稱在本質上就是自我指涉的：它們告訴你的是原始模型有多少在壓縮後留存下來，而不是原始模型本身位居何處。一個保留了平庸基準模型 98% 的模型，依然是平庸的模型，而 Qwen3.8-27B 並不平庸——但單憑這個數字無法說明這一點，也無法跨基礎模型進行比較。

於 2026 年 9 月 23 日為 Snapdragon AR1 Gen 1 眼鏡平台發表的 1-bit Bonsai 2B 視覺語言模型，是由一個 1.7B 的 1-bit 語言模型，加上一個 0.3B 的 4-bit 視覺編碼器所組成。其公布的品質聲明在性質上有所不同：PrismML 在 BFCL v3、HumanEval+、MMLU Redux、IFEval、IFBench、MuSR、GSM8K 與 GPQA Diamond 上，將它與 4-bit 量化的 Qwen 3 1.7B 模型進行評估，並報告兩種配置達到了相當的結果。那是一項相對於外部基準的持平主張。它表示這種壓縮相較於你原本會採用的 4-bit 路徑，並沒有明顯讓你付出代價——而這正是裝置級別發布時該問的問題，也是比「這個模型很好」弱得多的主張。

所以，沒有任何一種解讀能讓 98.2% 勝過「comparative」，反之亦然。它們是兩個不同問題的答案；這些問題由同一家廠商，分別對照兩個不同的參考基準，在兩個不同的測試套件上提出。任何人若憑那兩句話的力道來為這兩個模型排名，其實是在為那兩句話排名。

基礎模型來自不同的地方

還有第二個結構性差異，而這正是未來一年會變得關鍵的一點。Ternary Bonsai 2 27B 是對外部模型——阿里巴巴的 Qwen3.8-27B——的重新壓縮。它的品質上限取決於別人的發布時程，而其世代更迭節奏跟隨的是 Qwen，而非 PrismML。當 Qwen 推出新的 27B 時，Bonsai 27B 系列就會獲得新的輸入，而保留率數字也會以新的基準重新計算。

1-bit Bonsai 2B 是基於 PrismML 自家的 Bonsai 1.7B 打造。它的效能上限由內部設定，更新節奏由 PrismML 自行決定，而它的進步來自壓縮配方與 kernel 路徑，而非來自上游模型的替換。這是一種截然不同的資產：在原始能力上進步較慢、完全處於供應商的掌控之下，而且——正如眼鏡版發布所示——能夠針對特定加速器進行調校，這是通用的重新壓縮所無法做到的。

兩者都是合理的策略。它們不能互換，而你要採用哪一個，取決於你的路線圖是錨定在 Qwen 上，還是錨定在裝置上。

規格對比，一次一行

• 參數 — 眼鏡模型中的 1.7B 1-bit LLM 加上 0.3B 4-bit 視覺編碼器，相較於 Ternary Bonsai 2 27B 中衍生自 Qwen3.8-27B 的 27B 級模型。

• 表示法 — 眼鏡模型中的二元 {−1, +1}，搭配 FP16 分組縮放；相對於 27B 中的三元 {−1, 0, +1}，以相同縮放達到每權重 1.76 有效位元。

• 語言模型權重 — 1-bit 1.7B 為 0.43 GB，而 Ternary Bonsai 2 27B 的 PTQ1_0 封裝則為 5.93 GB，另有 7.25 GB 的 PQ2_0 封裝可供選用。

• 上下文 — 眼鏡模型為 1,024 個符元，相較於 Ternary Bonsai 2 27B 完整的 262,000 個符元上下文。

• 加速器 — 透過具備 1 位元核心支援的 QNN SDK 使用 Qualcomm Hexagon NPU，對上透過 MLX 的 Apple 晶片與透過 CUDA 的 NVIDIA。

• 品質宣稱 — 「比較基準測試結果」是與 4-bit Qwen 3 1.7B 對比，以及相對於全精度 Qwen3.8-27B 基線的「超過 98%」保留率。兩者皆為廠商報告，均未經獨立重現，且是在不同的測試套件上測量。

• 執行階段 — 針對眼鏡模型的 Qualcomm NPU 工具鏈，對比 PrismML 自家的 llama.cpp 分支，以及為 27B 準備的 MLX 容器，而這兩者都是原版 llama.cpp 不支援的。

低比特賭注在每種情況下能換得什麼

兩個模型的壓縮哲學如出一轍，而這點值得特別點名，因為它是這個系列真正的核心主張：低位元表示貫穿整個流程——嵌入、注意力、MLP 與 LM head——採用 FP16 分組縮放，且沒有任何更高精度的退路。兩個模型都沒有為難以量化的部分保留浮點安全網。這比大多數量化研究採取的立場更為激進，而正是這一點，才讓每個權重 1.76 位元與 0.43 GB 的權重得以成真。

賭注獲得回報之處有所不同。在 Ternary Bonsai 2 27B 中，回報是你已擁有的硬體上的每位元組能力：一個 27B 級模型僅佔 5.93 GB，能在筆電或手機上運行，達到其基線的 98%。在 1-bit Bonsai 2B 中，回報是在一個原本毫無選擇的裝置類別上得以存在：一個多模態模型，語言權重僅 0.43 GB，在 NPU 上以每秒 15.36 個 token 運行。前者是對已經可行的東西做出更好的版本。後者則是以前根本行不通的東西。

層級邊界所在的位置

這兩者並非替代方案，把它們當成正面對決，會錯過這兩個版本共同指向的部署形態。眼鏡或穿戴式產品在本機端跑 2B，因為別無選擇。筆電或手機產品跑 27B，因為它跑得動。一旦產品同時橫跨兩者——手機 App 配對眼鏡、筆電 App 搭配裝置端助理——問題就不再是哪個模型，而是每一層級被允許回應哪些請求。

那道界線值得放在設定裡，而不是放在應用程式碼裡，因為兩個層級都會變動。27B 這條線會在 Qwen 發布時移動，2B 這條線會在 PrismML 改變配方時移動，而任何把上下文長度或能力寫死的規則，在這兩種情況下都會失效。將超出本地層級預算的要求升級至託管模型的路由政策，能挺過這兩種變動；本地層級會維持為數個層級之一，而不是貫穿用戶端的假設。OrcaRouter 就是負責這種升級的層——橫跨 200 多個託管模型的單一端點，包含容錯移轉，並將政策以設定形式表達。兩個 Bonsai 都不會在此路由；兩者都是本地下載。這裡放的是它們之上的層級，而有了 1,024 個 token 的本地模型，該層級正承擔大部分工作。

什麼能讓它塵埃落定

三項量測就能讓這對模型從兩項行銷說法，變成真正的比較。一是在「比較結果」那行背後提供逐項基準測試細分，讓與 4 位元版本的取捨能看得見，而不是只被概括帶過。二是 1 位元 Bonsai 2B 相對於自身全精度基準的保留率數據——也就是 PrismML 用於 27B 系列、卻未在此公布的那項量測。三是對這兩個模型中任一者的獨立評估，因為目前兩份發布中的每一項數字都來自廠商。

在其中任何一個出現之前，站得住腳的立場是數字實際上所支持的那一個：Ternary Bonsai 2 27B 是明顯好得多的模型，而 1-bit Bonsai 2B 則是這兩者中唯一能在它當初被打造來運行的裝置上執行的那一個。這兩項陳述並不衝突，而同一家廠商卻用不同的尺規來量測它們，這件事才是下次這些數字之一被引用卻未附上其基準時值得記住的一點。