Bonsai 與 Bonsai 27B：同一個家族名稱，十六倍的參數量

任何只憑名稱選購這個系列的人，都會買到錯誤的模型，原因在於單獨的「Bonsai」這個名稱並不是一個模型。它是一個系列，而截至本週，這個系列包含一個可在智慧眼鏡上運行的 20 億參數視覺語言模型，以及一個可在手機、筆電或桌機上運行的 270 億參數模型。第一個是 2026 年 9 月 23 日發表的 1-bit Bonsai 2B 視覺語言模型——由一個 1.7B 的 1-bit 語言模型加上一個 0.3B 的 4-bit 視覺編碼器組成，具備 1,024 token 上下文，建構於 Bonsai 1.7B 之上。第二個是 Bonsai 27B，於 2026 年 7 月 14 日以 Apache 2.0 釋出，建構於 Qwen3.6-27B，具備 262,000 token 上下文，並可選擇 5.9 GB 的三值版本或 3.9 GB 的二值版本。它們共享一個名稱、一個廠商、一種壓縮理念，除此之外幾乎別無共同點。十六倍的參數、兩百五十六倍的上下文，以及兩種截然不同的裝置。

這個頁面是為那種搜尋了其中一個，結果卻來到另一個的人準備的。

命名問題，直白地說

PrismML 的模型選單目前列出 Bonsai 2 27B、Bonsai 27B、Bonsai 8B、Bonsai 4B、Bonsai 1.7B 與 Bonsai Image。眼鏡產品發表則在 Bonsai 1.7B 系列之上，新增了一個 20 億參數的視覺語言模型。因此，單說「Bonsai」可能指至少四種參數級別中的任一種，以及兩個世代，而大小後綴是唯一能區分它們的東西。這不是對命名的批評——這是模型家族的常態——但這確實意味著家族名稱完全沒有透露你正在下載什麼。

有用的分野不在於世代，而在於裝置等級。27B 系列中的一切，都假設你有介於 4 GB 到 8 GB 的記憶體可以分配給語言模型，而且願意花掉它。1.7B 系列中的一切，則假設你只有幾百 MB，不會更多。這個單一事實會在任何基準測試之前，就決定這個系列中哪一半與你有關。

每一個實際上是什麼

• 參數 — 眼鏡模型中的 1.7B 1-bit LLM 加上 0.3B 4-bit 視覺編碼器，對比 Bonsai 27B 中衍生自 Qwen3.6-27B 的 27B 等級模型。

• 上下文 —— 在眼鏡模型上為 1,024 個 token，對比 Bonsai 27B 上完整的 262,000-token 上下文。

• 語言模型權重 — 1 位元 1.7B 為 0.43 GB，相較於三值 Bonsai 27B 的 5.9 GB，以及其 1 位元版本的 3.9 GB。

• 表示法 — 二元 {−1, +1} 權重，兩者皆採用 FP16 分組式縮放，這是該系列所圍繞打造的 1-bit 配方；Bonsai 27B 另提供三值 {−1, 0, +1} 版本，每權重有效位元數為 1.71。

• 目標晶片 —— Snapdragon AR1 Gen 1 眼鏡平台上的 Qualcomm Hexagon NPU，透過具備 1 位元核心支援的 QNN SDK 編譯，對比透過 MLX 的 Apple 晶片與透過 CUDA 的 NVIDIA，以運行 Bonsai 27B。

• 解碼吞吐量 — 眼鏡模型在 4 GB AR1 Gen 1 測試平台上為每秒 15.36 個 token，對比 iPhone 17 Pro 上約每秒 11 個 token；而 1-bit Bonsai 27B 在 Apple M5 Max 上為 87、在 RTX 5090 上為 163。

那些數字全都是廠商提供的，而這兩組數據是在不同的硬體上、對照不同的基準所測得，因此它們描述的是兩款產品，而不是同一條曲線上的兩個點。

Bonsai 27B 勝出之處，而且絕非險勝

上下文是首要考量，而差距絕非細微末節。一個 262,000 個詞元的視窗能容納一座程式碼庫、一份長文件、一份逐字稿，或一場運作中的代理工作階段，而且還綽綽有餘。一個 1,024 個詞元的視窗只能容納一則簡短指令和一張影像。如果你的工作負載涉及閱讀任何超過一頁的內容，Bonsai 27B 是這兩者中唯一還做得到這件事的模型；而在眼鏡模型上，再怎麼巧妙的提示都無法彌補這個差距，因為限制在於保留給鍵值狀態的記憶體，而非權重的大小。

能力是第二位。據報導，Bonsai 27B 的三值版本在涵蓋 15 項基準測試的思考模式套件中，保留了其全精度基準約 95% 的表現，而它的 1 位元版本約 90%，最大損失出現在視覺與工具使用方面。那些是廠商在自家套件上得出的數據，而且它們仍然與一個 20 億參數模型屬於不同層次的事——該模型唯一公布的品質聲明，是它對上 4 位元 Qwen 3 1.7B 時達到了「可比較的基準測試結果」。眼鏡模型並沒有被其自家開發商拿來與 27B 模型相比，因為這種比較不會有用。

生態系是第三。Bonsai 27B 以 GGUF、MLX 與 AWQ 封裝形式推出，並附有已文件化的執行環境，因此有一條途徑能在你已擁有的硬體上執行它。眼鏡模型存在於 Qualcomm NPU 工具鏈中。

2B 勝出之處，而這正是整個重點所在

一個 0.43 GB 的語言模型能進得去的地方，5.9 GB 的模型根本去不了，而眼鏡平台正是其中之一。這就是全部的論點，而且它比規格對比聽起來更有力，因為這些裝置別無選擇：一副只有 4 GB 共享平台記憶體的眼鏡，無論哪個版本都裝不下 Bonsai 27B；而手機若要裝下三值版本，就得放棄手機大部分的用途。

還有第二項較少受到關注的優勢：1 位元表示法在這類裝置上並非妥協，而是讓一切得以實現的關鍵技巧。PrismML 自己的說法是，1 位元路徑所帶來的智慧大致相當於同一模型在 4 位元精度下的表現，同時只用約四分之一的記憶體，並以超過兩倍的速度生成 token。對於每一毫瓦與每一 MB 都要斤斤計較的常開裝置而言，這項取捨就是產品本身。

所以這兩個模型並不是在互相競爭。2B 是在沒有其他地方可執行時所執行的模型；27B 則是在有其他地方可執行時所執行的模型。

層級界線才是真正的決策

幾乎沒有人會在這兩者之間做選擇。實際的部署會同時採用兩者：裝置上有一個小型、常時運作的模型，負責處理能放進 1,024 個 token 的請求；其後則有更大的模型，處理其他所有情況。一旦你接受了這樣的形態，工程問題就不再是「該選哪個 Bonsai」，而是「界線在哪裡，以及由誰來執行這條界線」。

在應用程式碼中強制執行時，那條界線會變成一個分支，每當裝置端模型改變上下文長度或能力時就必須改寫——而從過去三個月的實證來看，這大約是每月一次。若改以路由原則來強制執行，它就會變成一條關於上下文預算與所需能力的規則，而本機層級也會繼續只是一個層級，而不是變成貫穿整個用戶端、深植其中的假設。這正是 OrcaRouter 所運作的層級：在 200 多個代管模型前方的一個端點，具備容錯移轉，以及以設定表達的升級原則。兩款 Bonsai 都不會在此被路由——兩者都是讓你在自己的硬體上執行的下載項目——因此誠實的說法是，路由層涵蓋的是本機層級之上的那一層，而對於一個 1,024 權杖的本機模型來說，大多數流量都會落在那一層。

如果你必須選一個

• 你正在為眼鏡、穿戴式裝置或任何常時開啟的裝置開發——這裡唯一的選擇就是 1-bit Bonsai 2B 視覺語言模型，而 1,024 個 token 的上下文是你必須圍繞其設計的既定限制，而非與之對抗的對象。

• 你正在為手機打造——3.9 GB 的 1-bit Bonsai 27B 是這個系列中最大的模型，能符合 iPhone 等級的記憶體預算，而且它還能為你帶來 262K 上下文，這是眼鏡模型無法企及的。

• 你如果是為筆記型電腦或桌上型電腦而建置，ternary Bonsai 27B 版本是這個系列中重視品質的選擇，而 1-bit 版本換來的是速度，而非能力。

• 你正在打造一套混合架構——先決定升級規則，再決定模型。模型可以換；但界線一旦進了用戶端，就換不了。

值得觀察的是，讓這款眼鏡得以推出的 NPU 路徑是否能向上延伸。若行動加速器上的 1-bit 核心能夠通用，1.7B 系列就會變得更大，而在手機上採用 27B 模型的主張也會更有力。在那之前，這個家族的兩半仍會依裝置類別清楚區隔，這使得選擇比共用名稱所暗示的更容易。