Bonsai 27B：Bonsai 家族中的 27B 模型解析

Bonsai 27B 是 PrismML 的 Bonsai 系列中擁有 270 億參數的模型，而當人們輸入「bonsai 27b」時，指的就是它——但單憑這個名稱無法讓你找到正確的目標，因為有三個不同的東西都與相當接近的名稱有關。Bonsai 27B 是 Qwen3.6-27B 的低位元重建版本，依廠商自家公告的日期為 2026 年 7 月 14 日，並以同一模型的兩種套件形式發布：1-bit Bonsai 27B 將二元 {−1, +1} 權重儲存在約 3.9 GB 中，而 Ternary Bonsai 27B 則以每個權重 1.71 有效位元儲存三元 {−1, 0, +1} 權重——廠商主打數字為 5.9 GB，實際出貨套件則為 7.165 GB。它不是 Ternary Bonsai 2 27B，那是另外命名、以 Qwen3.8-27B 為基礎的第二代；也不是 PrismML 為 Snapdragon AR1 Gen 1 智慧眼鏡打造的 20 億參數視覺語言模型。Bonsai 27B 的兩種套件都具備 262,000 詞元的上下文、精簡的 4 位元視覺塔，以及 Apache 2.0 授權。這個模型就是 Bonsai 27B；接下來的決定是它的兩種套件中，哪一種符合你的記憶體預算。

本頁是該模型的參考資料。這並非公告：Bonsai 27B 自 2026 年 7 月起便已推出，而如今值得回答的問題，正是讀者帶著前來的那一些——它究竟是什麼、這個名稱區分了什麼，以及實際運行它需要多少成本。

哪一個是 27B

這裡的混淆是真實存在的，值得在處理其他任何事情之前先解決，因為一旦猜錯，你要嘛會被導向一個 20 億參數的模型，要嘛會被導向正確模型但錯誤的那一代。

• Bonsai——家族名稱，也是供應商對它的稱呼。單憑這個名稱，並不能指認出任何可下載的項目。PrismML 已推出 Bonsai 1.7B、Bonsai 4B、Bonsai 8B、Bonsai 27B 和 Bonsai Image，還有那個 20 億參數的眼鏡模型，以及一個 2026 年 4 月較早發布、針對較小產品線、名為 Ternary Bonsai 的版本。搜尋這個單獨的字詞，會隨機落在這整組結果中的某一項。

• Bonsai 27B——本頁的主題。27B 系列的第一代，衍生自 Qwen3.6-27B，日期為 2026 年 7 月 14 日。當頁面只寫「Bonsai 27B」，沒有其他限定詞，也沒有「2」時，指的就是這個模型，而這也正是應該使用的名稱。

• Ternary Bonsai 27B——不是另一個模型。它是 Bonsai 27B 中重視品質的版本：同一個 27B 模型、相同的架構與相同的基礎，只是以三元權重取代二元權重。該儲存庫名為 Ternary-Bonsai-27B-gguf，而其模型卡與二元版本的模型卡一樣，將 Qwen3.6-27B 列為基礎模型。這裡的「三元」是權重格式，不是版本。

• Ternary Bonsai 2 27B — 一款真正與眾不同的模型。27B 系列的第二代，以 Qwen3.8-27B 為基礎打造，於 2026 年 9 月 17 日發布，具備不同的參數分配與不同的品質主張。當中的「2」承載了全部的差異。

• 1-bit Bonsai 2B — 不同規模的另一位家族成員：一款為眼鏡等級硬體打造的 20 億參數視覺語言模型，而不是任何精度下的 27B 模型。

所以，如果你來這裡是想弄清楚這些之中哪一個是 27B 模型，答案是：上面第三行和第四行是同一個模型的兩種權重格式，而第五行則不是。實務上：稱它為 Bonsai 27B，並在必要時加上 pack。

規格，來自模型卡

本節中的每一項數據皆來自 PrismML 針對這兩個套件包所發布的模型卡，且是廠商對自家模型的陳述。若某個數字是宣稱而非實測，便會標示為宣稱。

• 參數 — 總計約 27.3B，而「27B」指的就是這整個總量。這個拆分值得了解，因為它說明了記憶體行為：大約 24.8B 位於橫跨 64 個區塊的語言骨幹中，約 2.5B 位於嵌入層與 LM head，約 0.46B 則位於一座 27 層的視覺塔中。低位元表示法從頭到尾一體套用——嵌入、注意力、MLP 與 LM head——語言網路中任何地方都沒有更高精度的退路。

• 脈絡 — 完整的 262,000 個詞元，沒有長脈絡變體，也沒有縮減脈絡的版本。這個視窗的成本是被管理而非全額支付：主幹是混合式的，因此其 64 層中只有 16 層保留完整的注意力快取，而該快取以近乎無損的 4 位元形式儲存。在完整的 262K 視窗下，壓縮後的高速快取能讓模型維持在大約 9.4 GB 以內（二進位套件）以及 12.8 GB 以內（三元套件）。

• 模態 — 文字與圖像，兩種套件皆適用。視覺塔以精簡的 4 位元形式（0.63 GB）出貨，並隨附一份 BF16 副本（0.93 GB）。視覺也是壓縮代價最高的部分，這點將於下文說明。

• 權重格式與大小 — 1-bit Bonsai 27B 使用帶有 FP16 分組縮放的二值 {−1, +1} 權重，以 GGUF Q1_0_g128 封裝，每個權重的真實有效位元數為 1.125 位元；隨附檔案為 3.803 GB，而模型卡將部署後的佔用空間取整為約 3.9 GB。Ternary Bonsai 27B 使用帶有相同分組縮放的三值 {−1, 0, +1} 權重；一個三值數值攜帶 log₂3 ≈ 1.585 位元的資訊，因此此表示法的下限為每個權重約 1.71 位元，換算下來理想值為 5.9 GB。已發布的三值封裝大於該理想值，因為現今的核心會將每個三值數值存放在 2 位元槽中——部署時每個權重為 2.125 位元——而隨附檔案為 7.165 GB。PrismML 同時公布這兩個數字，而非只提出好看的那個數字，而兩者之間的差距是核心限制，而非模型設計選擇。

• 授權條款 — 兩套套件包均為 Apache 2.0，兩個儲存庫與廠商公告皆如此載明。這是寬鬆授權，且無使用領域限制；在這樣的權重規模下，這一點比大多數情況更為重要。

• 基礎模型——兩者皆為 Qwen3.6-27B。這是對他人模型的重新壓縮，而非從零開始訓練的模型；其結果是，Bonsai 27B 的能力上限與更新節奏都跟隨上游的 27B 系列，而非 PrismML 的。

三元關係，僅陳述一次

這兩個套件是同一個模型，而誠實的總結是：三值換得品質，二值換得佔用空間，而兩者之間的差距比 3.9 GB 對 7.2 GB 的尺寸差異所暗示的還要小。

在 PrismML 自家的 15 項基準測試思考模式套件中，FP16 Qwen3.6-27B 基準得分為 85.07。Ternary Bonsai 27B 得分 80.49——保留率 94.6%，廠商四捨五入為約 95%。1-bit Bonsai 27B 得分 76.11——89.5%，四捨五入為約 90%。因此，以品質為導向的套件補回了二元套件與完整精度之間約一半的差距，代價是多出約 3.3 GB，而二元套件才是能塞進 12 GB 手機的那一個。同一套件顯示，同一基準的 4-bit Q4_K_XL 版本得分 84.99，即 99.9% 保留率，佔用 17.6 GB——這項比較說明了為何這兩個低位元套件根本會存在，因為它在品質上勝過它們，卻在所有能提供給模型的記憶體不到 18 GB 的裝置上落敗。

二元封裝讓步的地方並不平均，而分類拆分才是有用的部分。相較於 FP16 基準，它在數學上從 95.33 降到 91.66，在程式碼上從 88.74 降到 81.88，但在指令遵循上從 78.47 降到 65.74，在代理與工具呼叫工作上從 80.00 降到 66.03，在視覺上從 72.61 降到 59.57。如果你的工作負載是算術或程式碼補全，3.9 GB 幾乎等於免費。如果是工具呼叫代理或圖像理解，那才是真正在為壓縮付出代價的地方。

模型卡也公布了一項它稱為智慧密度的衍生指標——每 GB 的總合分數，並經過標準化，使滿分趨近於無限大。依此指標，1-bit Bonsai 27B 達到 0.530，Ternary Bonsai 27B 為 0.400，相較之下，同一基線的 2-bit IQ2_XXS 版本為 0.199，4-bit Q4_K_XL 版本為 0.155，而 FP16 模型為 0.051。這份清單中最有意思的數字是第一個比較：二值封裝在整體品質上擊敗傳統 2-bit 版本，而佔用空間不到後者一半，這正是該系列的核心論點，一句話道盡。

兩個套件之間的完整正面對決，以及各自數據的來源，都詳列於本部落格的 Bonsai vs Bonsai 27B 頁面，並與共享同一家族名稱的 20 億參數模型並列呈現。

隨這個模型而來的一個問題，只該得到一個事實性的答案，僅此而已。這些套件是同一底層模型的低位元編碼，而不是重新訓練的變體；而且這些儲存庫並未隨附發佈任何另行調校或無審查的檢查點——唯一有提供的全精度產物，是同一組權重的未打包 FP16 轉換，其發佈目的是讓你能在標準工具中，將壓縮套件與其自身基準進行比較。

權重與授權條款，來自儲存庫

Bonsai 27B 的權重發佈於 Hugging Face 上、掛在 prism-ml 組織名下，而檔案清單是這次發布中最具體的東西。二進位封包的儲存庫裝有模型本體，大小為 3.803 GB；作為對照，同一模型的 FP16 GGUF 為 53.808 GB；DSpark 推測解碼草稿模型在 4-bit 下為 1.787 GB、在 BF16 下為 7.292 GB；還有視覺塔，分別為 0.931 GB 與 0.629 GB。三值儲存庫則帶有自身 7.165 GB 的封包，外加第二份 7.585 GB 的打包，後者是 group-64 而非 group-128，且與上游相容而非最佳化，另外還有相同的草稿模型與視覺檔案。兩個儲存庫皆為 Apache 2.0，且都指名 Qwen3.6-27B 為基礎模型。

從那份清單可以得出兩件事。第一，53.808 GB 對上 3.803 GB，正是模型卡開頭主打的 14.2 倍比例，而且這是可以查核的，不是憑空宣稱——全精度檔案就在那裡。第二，這個發行版比模型本身更重：如果你把草稿模型和視覺塔也一併算進去（多模態路徑需要它們），你就是在一個 3.9 GB 的模型之上再加約 2.4 GB。3.9 GB 這個主打數字指的是語言權重，而不是部署。

下載量是這個以品質為導向組合唯一領先的地方：截至 2026 年 10 月，三值 GGUF 儲存庫的下載次數已突破 590,000 次，而二值組合僅略高於 400,000 次；至於兩者的 MLX 容器則各自都超過一百萬次。這樣的分布形態顯示，這款模型大多是在 Apple 硬體上運行，而非在伺服器上；也顯示下載它的人買的是多出來的那五個百分點保留率，而不是盡可能最小的檔案——這大致正是供應商設計這對組合時所設想的用途。

運行中

現在你能取得的是每包四種神器，而你想要哪一種，取決於你的執行環境，而非品質。

• 適用於 llama.cpp 的 GGUF — 這是主要途徑，也是低位元核心當初所針對撰寫的途徑。這兩套打包都是適用於 CUDA、Metal 與 CPU 的 llama.cpp 組建，但 1 位元與三元核心存在於 PrismML 自家的分支中，而非上游，因此原版 llama.cpp 尚無法正確載入它們。群組 64 三元封裝之所以存在，正是為了你需要上游相容性、且願意接受 7.585 GB 而非 7.165 GB 的情況。

• Apple silicon 版 MLX —— 分別隨附的容器：二進位套件為 5.129 GB，三值套件為 8.491 GB。請注意，MLX 二進位容器比 GGUF 二進位套件更大，這是容器額外負擔的差異，而非不同模型。

• 適用於伺服器框架的 AWQ 4 位元版本 — 針對期待 AWQ 檢查點的服務框架，為每個模型提供的 4 位元建置版本，分為九個分片，總計 18.70 GB，並附有多 GPU 配置指引。這不是低位元產物；這是同一個模型，以在機架上合理的精度呈現，卻捨棄了這個模型存在的全部理由。

• Unpacked FP16 safetensors — 完整的約 54 GB 模型，採用 Hugging Face 標準格式，特別針對尚未原生支援 1 位元權重的框架而發布。廠商表示，一旦低位元核心合併至上游，此產物便會退役。

根據模型卡本身的表格，二進位套件上實測的解碼吞吐量在 M5 Max 上為每秒 66.4 個 token，M5 Pro 上為 44.2，M4 Pro 上為 26.0，H100 上為 104.8；預填充則分別為每秒 874、421、133 和 2,755 個 token。公告頁面引用的是更高的峰值——M5 Max 上最高達每秒 87 個 token，RTX 5090 上則為 163——這些是廠商自身的最佳情況配置，而非該表格的數據。請將這兩組數據視為不同的量測條件，而非互相矛盾，並將兩者都視為廠商所報告的數據。峰值記憶體同樣取自該模型卡：在二進位套件上，4K 上下文時為 5.2 GB，10K 時為 5.6 GB，100K 時為 11.6 GB；在三元套件上則為 8.4、8.7 和 14.7 GB——但要注意，這些數字早於 4-bit KV 快取，而正是 4-bit KV 快取讓完整的 262K 視窗降到個位數 GB。

DSpark 草稿模型是選用的，而且在啟用它之前值得先了解，因為它完全不會改變輸出：它是一個六層的區塊平行 transformer，以從五個均勻間隔的目標層擷取出的隱藏狀態作為條件，在服務精度下會增加約 0.5 GB，並且會對照目標模型進行驗證，而不是自行取樣。這就是為什麼廠商能在 CUDA 上宣稱有 1.37 倍加速，卻又不影響品質數據。它在 Apple silicon 上預設不會啟用。

本地模型走到盡頭時，才是真正有趣的工程問題，而這是路由問題，不是模型問題。筆電上的 3.9 GB 模型能處理其上下文容得下的內容；其餘一切則必須有去處，而那個去處就是 API 後方的託管模型。OrcaRouter 就是那一層——一個端點橫跨 200 多個託管模型，對供應商定價 0% 加成，跨供應商自動容錯移轉，以及從本地層級升級至託管層級的升級規則以設定表達，而非手動拼裝。它是本地模型之上的一層，而非其替代品。

比較索引

Bonsai 27B 身處一個家族，其中每個相鄰成員各自回答不同的問題，而這些頁面分別承接每一個問題——這裡不會再重新論證其中任何一個。

• Bonsai 與 Bonsai 27B — 二十億參數的眼鏡模型對上這一個：參數多達十六倍，上下文長度多達兩百五十六倍，以及為何家族名稱完全無法透露你下載的究竟是什麼。這裡的頁面是一篇部落格文章，而不是託管的模型，這個區別在這個家族裡值得弄清楚。

• Bonsai 27B 對上 Qwen3.8-27B — 這是此模型與它所未採用的較新基礎模型之間的正面對決。本批次中有一頁專門頁面承載該比較，而且由於這兩個模型名稱相似、僅相隔一個世代，值得以其自身的角度來閱讀，而非視為本規格的延伸。

• Bonsai vs Ternary Bonsai 2 27B——跨世代的躍進，以及這兩次發布各自以不同的標尺來呈報其品質：一個是相對於基線的保留率，另一個則是比較性的宣稱。

• Ternary Bonsai 2 27B — 第二代獨立成篇，採用 Qwen3.8-27B，適合已決定想要較新模型、而非此版本的讀者。

什麼尚未確定？

本頁上的每一項品質數據都出自 PrismML，是在 PrismML 自家的 15 項基準測試套件上測得的，而公司外部沒有任何單位發表過重現結果。這是目前對 Bonsai 27B 的已知資訊中最大的單一缺口：其壓縮相關的主張異常具體、也異常容易驗證，卻始終未經第三方查核。廠商也明確表示，代理式編碼——長時間跨度、多檔案、執行與修復的工作流程——並非本次發布的重點目標，而針對此用途調校的變體是路線圖上的下一項工作；這與上文類別拆分的工具呼叫與指令遵循表現落差相符。在出現獨立評估之前，無論是保留率數字還是密度排名，都應解讀為廠商的立場，而非已確立的結果。

已經確定下來的部分比較小，卻更有用：權重確實存在，大小可以對照檔案清單查核，授權條款是 Apache 2.0，而這兩個套件相差約 3.3 GB，換來的是大約五個百分點的保留品質。這樣就足以在兩者之間做出選擇。哪一個適合你，取決於你的工作負載看起來更像算術，還是更像工具呼叫；而上述的分類數字，是今天做這項決定時所能取得的最佳證據。