Ternary Bonsai 2 27B 對比 Bonsai 27B：兩個月、兩個基礎模型、一個缺失的變體

Ternary Bonsai 2 27B 於 2026 年 9 月 17 日問世，距離 Bonsai 27B 在 2026 年 7 月 14 日登場已有兩個月，而兩者最受矚目的比較，就是一對數字：第一代保留了其全精度基礎模型約 95% 的基準平均分數，第二代則保留了 98.2%。這讀起來像是單純的世代改良，而大致上確實如此——但這兩個數字衡量的並不是同一件事，因為它們底下的基礎模型已經改變。七月發布的版本壓縮的是 Qwen3.6-27B。九月發布的版本壓縮的是 Qwen3.8-27B。品質提升有一部分來自壓縮配方，另一部分來自較新的 Qwen3.8-27B，而沒有任何已公布的數字能區分這兩者。

世代之間還有第二個差異，這個差異受到的關注少得多，但對特定一群使用者來說更為重要：第一代 Bonsai 推出時有兩種變體，而第二代只有一種。那個讓 27B 級模型得以塞進 iPhone 17 Pro 的 3.9 GB 版本，在這次發布中沒有後繼者。如果那個佔用空間正是你當初對 Bonsai 感興趣的原因，那麼較新的世代並不是升級——它是一款不同的產品，無法涵蓋你的使用情境。

第一代實際上推出了什麼

Bonsai 27B 於 2026 年 7 月 14 日以 Apache 2.0 授權發布，形式為兩個建構於相同基礎模型上的產物，而兩者之間的區分正是此次發布的重點。

• Ternary Bonsai 27B — 三元 {−1, 0, +1} 權重，搭配 FP16 分組縮放，每權重有效位元數 1.71，佔用空間 5.9 GB。此為品質導向版本，鎖定日常筆電，具備完整推理、工具呼叫與代理式能力。

• 1 位元 Bonsai 27B — 二值 {−1, +1} 權重，採用相同的群組式縮放，每個權重有效 1.125 位元，佔用 3.9 GB。這款以佔用空間為導向的版本，其大小設定為符合 iPhone 17 Pro 的記憶體預算。

兩者都具備 262K token 的上下文，都保留了精簡的 4 位元視覺塔，讓模型維持多模態能力，也都支援搭配 DSpark 草稿模型的推測解碼。Prism ML 當時的說法是，低位元表示法是端到端運行的——包括嵌入、注意力、MLP 與 LM 頭——沒有任何更高精度的後路，而 1 位元版本更是第一個能在手機上運行、哪怕是勉強運行的 27B 等級模型。據報 1 位元變體的吞吐量在 iPhone 17 Pro 上約為每秒 11 個 token，在 Apple M5 Max 上為 87 tok/s，在 RTX 5090 上為 163 tok/s；三值變體則據稱在 M5 Max 上為 58 tok/s，在 5090 上為 134 tok/s。

品質成本與那些數字並列公布，而非被掩蓋。在一個包含 15 項基準的思考模式套件上，全精度基礎版得分為 85.0，三值版本為 80.5——約 95%——而 1 位元版本為 76.1，約 90%。效能下降集中在代理式工具呼叫——在 1 位元版本上從 80.0 降至 66.0——以及視覺，從 72.6 降至 59.6。數學與程式設計在兩個變體中都保持得明顯較好。

第二代改變了什麼

Ternary Bonsai 2 27B 沿用相同的配方，只改變輸入。三元表示法依然是 {−1, 0, +1}，每 128 個權重共用一個 FP16 縮放係數，如今在 5.93 GB 的檔案中壓縮至每權重 1.76 位元，具備 262K 上下文，並搭載同樣獨立的視覺塔 — 在此版本中為 4 位元的 0.63 GB，僅在有圖片送入時才載入。

有兩件事確實是新的，而兩者都被描述為留存數字變動的原因。

第一個是選擇性精度。與七月版本幾乎將所有內容都三值化不同，Bonsai 2 以全精度保留了 26,238,464 個參數——占語言模型的 0.0976%，在 bf16 下約 52 MB，集中於線性注意力層的遞迴狀態路徑以及正規化權重。這在位元組上是個小讓步，但在行為上顯然是個大讓步。

第二種是旋轉後的權重基底。權重矩陣是在以區塊大小 1,024 進行分塊 Walsh–Hadamard 旋轉後儲存，並在執行時對活化值套用對應的轉換；其理論依據是，將離群值分散到各個座標可讓三級近似的損失較小。它不會造成額外的儲存成本，因為旋轉已摺疊進權重中，但它確實位於計算路徑上。

接著還有一項根本算不上技巧的改變：基礎模型。Qwen3.8-27B 採用混合注意力設計——大約 75% 線性注意力、25% 全注意力——而它的前代並非如此。Prism ML 回報的各類別分數顯示了這項轉變帶來了什麼。Bonsai 2 的指令遵循為 82.66，相較之下 Qwen3.6-27B（第一代所壓縮的基礎模型）為 74.53。推理與知識為 83.95，對比舊基礎模型的 84.71；程式編寫則為 81.58，對比 82.57。新基礎模型在指令遵循上大幅勝出，但在另外兩個類別上略微落後，而這正是讓跨世代保留率百分比單獨來看毫無幫助的那種概況。

為什麼這兩個留存數字無法互相比較

95% 與 98.2% 看起來像是同一個尺度上的兩個讀數。但它們不是，有三個理由值得在得出該配方提升了 3.2 個百分點的結論之前先分清楚。

• 分母不同。第一代的 95% 是在一套 15 項基準測試上、對比 Qwen3.6-27B 測得的。第二代的 98.2% 則來自一套 20 項基準測試、對比 Qwen3.8-27B。不同的測試套件、不同的基線、不同的難度組合。

• 基準線各自獨立變動。保留率提升有一部分是壓縮後的模型變得更善於壓縮，另一部分則是基礎模型出現了某些恰好對三值權重更友善的變化。目前沒有任何已發表的文獻能區分這些貢獻。

• 保留率是相對的，因此它可能上升，而某個類別的絕對能力卻下降。一個保留較弱父模型 99% 能力的模型，仍可能落後於一個保留較強父模型 96% 能力的模型。

絕對比較比相對比較更有資訊量，而在這個基礎上，整體脈絡也更清楚。Bonsai 2 的總分 83.9，高於全精度 Qwen3.6-27B 在較舊測試套件上取得的 83.6——這意味著這個壓縮後的後繼模型，如今已領先它在前一代所取代的未壓縮模型。第一代三值版本在其自己的測試套件上得分 80.5。這兩個數字都來自 Prism ML，而且測試套件不同，所以要看的是排名先後，而不是小數點。

沒有回來的變異株

這是比較中會改變購買決定的部分，而不是一張基準測試圖表。

沒有 1-bit Bonsai 2。九月發佈的版本推出的是三元版本，提供兩種封裝——PTQ1_0 為每權重 1.76 位元、5.93 GB，以及 PQ2_0 為每權重 2.16 位元、7.25 GB——另有一個適用於 Apple Silicon 的 MLX 容器。沒有 3.9 GB 的二進位變體，也沒有任何相關公告。目前報導中出現的 3.9 GB 手機等級數字，仍然是指七月的模型。

實際後果很直接。如果你的目標裝置是 iPhone 或 iPad，或任何無法同時容納 5.9 GB 語言模型、0.63 GB 視覺塔以及上下文預算的裝置，那麼第一代 1-bit 版本仍是這個系列中唯一的選項，而且在 1-bit Bonsai 2 問世之前都會是如此。升級 ternary 路徑並不會連帶升級那條路徑。任何人只要讀到「Bonsai 2 更好」就重新下載到手機上，都會發現檔案根本裝不下。

如果你使用的是筆記型電腦或桌上型電腦，情況正好相反：當九月的版本在每單位品質上更小、在重要的基準測試上表現更好，且同樣具備 262K 上下文時，就沒有理由執行七月的三元建置。

速度，在這裡各世代真的很難排名

在這項比較中，吞吐量這部分，誠實的答案是已公佈的數字並不支持明確的排名，而這一點值得說出來，而不是挑出好看的那一組。

第二代的標準化測量結果（批次大小為 1、排除視覺塔）為：在 PQ2_0 打包下，RTX 5090 上的解碼速度為 142.5 tok/s，Apple M5 Max 為 46.8 tok/s，M5 Pro 為 27.7，M4 Pro 為 18.0。第一代針對其三元版本宣稱 RTX 5090 為 134 tok/s、M5 Max 為 58 tok/s。5090 的數字朝預期方向小幅變動。M5 Max 的數字則朝反方向變動——從 58 降至 46.8——這可不是兩個月的世代演進該有的樣子。

兩點但書使這無法成為一項確切結論。各版本之間的量測基準並不相同，而且至少一項已發表、針對較新機型的 M5 Max 數據，被歸因於一個早於旋轉最佳化之前的建置版本。但這值得標記為一個未解問題，因為能解釋此現象的機制就寫在發行說明裡：在批次大小為 1 時，旋轉基底會把一個轉換放到每一次投影的關鍵路徑上，而 Apple Silicon 解碼正是這種情況傷害最嚴重的情境。換取品質的技術可能犧牲解碼吞吐量，而在統一記憶體硬體上，這種取捨最為尖銳。

MLX 容器為 Apple 使用者帶來了另一項麻煩。它是一種仿射 2 位元格式，其區塊會為每 128 個權重組同時儲存縮放值與偏置值，但三元權重只需要縮放值，所以偏置值便成了累贅——每 128 個權重的區塊要花費 36 位元組，而非 34 位元組，打包後位元率落在每個權重 2.25 位元，實測檔案大小為 8.005 GiB。它是裝著相同數值的另一種容器，而且它是示範設定預設下載的封裝檔。

執行任一世代

這兩代共享一項這個模型的任何版本都無法擺脫的運作限制：兩者都無法在官方原版 llama.cpp 上執行。這個架構的三值核心位於 Prism ML 自家的分支中，官方原版 llama.cpp 會將目前的封裝格式視為未知而拒絕，而且——更糟的是——它會毫無怨言地載入較舊的三值格式並產生流暢的垃圾，因為它不會套用權重所假設的旋轉。MLX 建置版本帶有 Metal 與 CPU 核心，但沒有 CUDA 路徑。無論你選擇哪一代，執行環境的問題都是由 Prism ML 自家的發行版，或是由已採用其核心的執行環境來解答，而不是由整個 ggml 生態系來解答。

OrcaRouter 在這類決策中的定位，是再往上一層。這兩代 Bonsai 都不是託管在這裡——它們是你下載後在自己硬體上執行的。路由層的用處在於處理邊界：那些你的本地模型不該負責回應的請求。在路由設定中一次定義好升級政策，而不是寫在應用程式碼裡，如此一來，本地服務的層級就能把長脈絡、視覺負載繁重或其他超出範圍的請求往上傳給託管模型，而不是讓它們直接失敗；也能讓備援機制在你安裝的是哪一代 Bonsai 時都依然有效。接著，本地層級與託管層級便位於同一把金鑰之後，而當下一世代 Bonsai 問世、層級界線再次變動時，政策也只需維護在一個地方。

這該怎麼處理？

• 如果你在筆電或桌機上執行七月的 ternary 版本，請改用 Ternary Bonsai 2 27B。它在差不多的資源佔用下是更好的模型，而且它勝出的那些類別分數，正是代理式與指令遵循工作最關鍵的部分。

• 如果你在手機上執行的是七月 1-bit 版本——就繼續留著。它沒有後繼版本，而且 5.93 GB 的三值版本並不是 3.9 GB 版本的直接替代品。

• 如果你是第一次評估這個系列——先決定尺寸規格，再決定世代。你需要的變體會決定你該在哪個發行版本中選購，而這個順序與這次升級通常被描述的方式相反。

• 如果你是以基準測試作為選擇依據——請把 95% 和 98.2% 視為兩項不同的量測結果，而不是同一條線上的兩個點；並且在針對九月模型出現獨立評估之前，把兩者中的每一個數字都當作廠商自己的說法。那份評估才是值得關注的重點，因為它將是第一個能在共同基礎上比較這兩個世代的評估。