
Bonsai 2 對比 Ternary Bonsai 2 27B:這個家族名稱正身兼二職
- Orca新Orca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 每百萬 tokens · 61 tok/s
- Orca新Orca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 每百萬 tokens · 74 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2952智能
- anthropicAnthropic: Claude Sonnet 5.52026-09-2856智能
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 每百萬 tokens · 724 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2238智能
- OpenAIOpenAI: GPT-6 Sol2026-09-2248智能
- AnthropicAnthropic: Claude Opus 5.52026-09-2258智能
- xAIGrok 4.72026-09-2146智能
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 每百萬 tokens · 36 tok/s
- OrcaOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 每百萬 tokens · 821 tok/s
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-09-1040智能
- OpenAIOpenAI: GPT-6 Astra2026-09-0453智能77程式
- GoogleGoogle: Gemini 3.8 Flash2026-09-0241智能76程式
- AlibabaQwen: Qwen3.8 Max (0902)2026-09-0245智能76程式
- AnthropicAnthropic: Claude Fable 5.12026-09-0153智能82程式
- TencentTencent: Hy4 preview2026-08-28$0.83 / $2.50 每百萬 tokens · 52 tok/s
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 每百萬 tokens · 109 tok/s
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642智能72程式
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 每百萬 tokens · 184 tok/s
搜尋Bonsai 2,你會找到大約五種不同的產物,其足跡橫跨一個數量級,而且單從名稱根本看不出某篇文章講的是哪一個。Ternary Bonsai 2 27B才是特定的那一個——一個以 Qwen3.8-27B 為基礎打造的單一 27B 級 ternary 模型,於 2026 年 9 月 17 日發布,並以 5.95 GB 的 dense-trit 封裝或 7.21 GB 的 2-bit-slot 封裝出貨。單獨的 Bonsai 2則是總稱:同一個名稱涵蓋Ternary Bonsai 2 2B、Ternary Bonsai 2 4B與Ternary Bonsai 2 9B這三個小得多的模型,它們以 Qwen3.5 為基礎打造,於 2026 年 10 月 15 日發布;而如今它也涵蓋了一個 Ollama 函式庫項目,在單一 tag 家族下提供全部四種尺寸。
所以這不是常見的正面對決。其中一方是另一方的子集,而真正有用的問題不是哪個更好,而是把「Bonsai 2」輸入搜尋框的讀者實際上想要其中哪一個。答案取決於命名所掩蓋的一件事:這個家族其實是兩個家族,依基礎模型區分,而這道分界並不在尺寸數字所暗示的地方。
兩個家族共用一個名號
讀取已發佈檔案的 GGUF 標頭,那道接縫就明明白白地藏在中繼資料欄位裡。每一個 Bonsai 2 產物——2B、4B、9B 與 27B 皆然——都回報 general.architecture = qwen35。這個字串是 Qwen3.5 混合注意力骨幹,而對三個小模型來說完全正確:模型卡將 Qwen3.5-2B、Qwen3.5-4B 與 Qwen3.5-9B 列為基礎模型,架構維持不變。27B 則是另一回事。它的基礎是 Qwen3.8-27B,一個更新、更強的 27B 混合注意力模型,而它恰好共用同一個架構字串,因為 Qwen3.8 沿用同一系列的骨幹。
廠商自己的發行說明,若並排對照閱讀,會讓這個分歧顯而易見;若單獨閱讀其中任一份,則完全看不出來。10 月 15 日針對小型模型的那篇文章說它們「基於 Qwen3.5」,並描述它們加入 Bonsai 2 27B 的行列——而後者被準確地定位為另一回事。9 月 17 日關於 27B 的文章則說 Qwen3.8-27B。兩篇公告、兩個基礎模型、一個家族名稱,而一篇第三方文章說「Bonsai 2 基於 Qwen3.5」,它在 27B 這點上錯了,卻看起來來源十分可靠。
這很重要,因為基礎模型世代在這裡不是細節。它設定了能力上限,也設定了保留百分比是哪些東西的百分比,而且這意味著小型模型的基準測試數字和 27B 的基準測試數字不是同一條曲線上的兩個點——它們是兩份各自對照不同基準的獨立報告。對於任何把它們排在同一欄的表格,都要抱持懷疑。

數字,並排
所有數據皆由 Prism ML 自行呈報;未經獨立驗證。
• 基礎模型 — Ternary Bonsai 2 2B / 4B / 9B:分別為 Qwen3.5-2B、-4B、-9B;Ternary Bonsai 2 27B:Qwen3.8-27B
• 宣布 — 小型三款為 2026 年 10 月 15 日;27B 為 2026 年 9 月 17 日
• 最小的語言模型套件——2B 時為 0.429 GB PTQ1_0;9B 時為 1.997 GB PTQ1_0;27B 時為 5.947 GB PTQ1_0
• 預設套件 —— 全部皆為 PQ2_0:分別為 0.517 GB、1.146 GB、2.417 GB 和 7.206 GB
• 每權重位元數 — 2B 時約 1.83,4B 時約 1.81,9B 時約 1.78,27B 時理想 1.72 / 打包 1.75
• 上下文 — 整個系列皆為 262,144 個 token,繼承自 Qwen 骨幹
• 視覺 — 每種大小都有獨立的 mmproj 套件,僅在圖片出現時載入
• 授權 — 全程採用 Apache 2.0
• 如報告所述的保留率 — 27B:在 14 項基準測試中,達到 Qwen3.8-27B FP16 的 98.2%;小型模型:涵蓋六個技能領域的 19 項基準測試,以相對於各自 Qwen3.5 基準的各類別保留率來報告
那份清單中的其中一行,就是 27B 佔用 5.95 GB、而 9B 佔用 2.00 GB 的原因,而且這不只是參數數量的問題。27B 被描述為在嵌入、注意力投影、MLP 投影與 LM 頭部上「端到端三元」,其中有一個決定性細節:一小組張量——線性注意力層的遞迴狀態路徑,加上正規化權重,約 2,620 萬個參數,佔語言模型的 0.0976%——維持在較高精度,而正是這剩下的部分,讓主要數字從每權重 1.71 位元變成 1.72 位元。在 9B 上,同樣的機制得到約 1.78。較大的模型在每個權重上更有效率,而非更低,因為固定的高精度額外負擔會被分攤到十倍多的參數上。如果你正根據每權重位元數表來推斷該選哪個尺寸,那就是這張表所指向的唯一方向。

小型模型真正勝出的地方
不是在品質上——而是在這項宣稱的形態上。這次小型模型發布是這個系列中唯一發布冗長度聲明的,也是兩份公告中所包含最可查證的事:Prism ML 報告指出,9B 在標準指令遵循與日常數學任務上使用的 token 約少了 40%。這是關於輸出長度、而非能力的陳述,你可以在一個下午內用你自己的提示詞加以驗證。同一篇文章把避免重複迴圈與控制冗長度列為明確的開發優先事項,而這正是當你的上一代有問題時,你會寫出來的那種東西。
這也是唯一一個在多個類別上報告保留率超過 100% 的版本——2B 在指令遵循上為 121.5%、數學為 107.8%、程式碼為 115.0%,相對於全精度 Qwen3.5 基準。那些是廠商自家測試套件上的自家數字,而壓縮模型在精挑細選的基準上得分高於其來源模型,這既是關於三元算術的說法,至少也同樣是關於訓練與測試框架的說法。27B 的報告則較為保守——84.78 對 86.32,數學為 96.57 對 97.06,程式碼水準為 89.42 對 89.07,且損失集中在知識/推理與視覺——這正是 1.7 位元表示法應該產生的樣貌。當一份報告的損失正好落在理論預測的位置,而另一份的增益落在廠商選擇大力宣傳的類別上時,這種不對稱本身就是資訊。
封裝:27B 的低調優勢
自 2026 年 10 月 17 日起,四種尺寸全部都可從 Ollama 以 bonsai-2:2b、:4b、:9b 與 :27b 拉取——總共九個標籤,每個尺寸也各帶有一個 -q2_0 別名。這是近期的事,供應商並未公告,而且值得了解它實際上提供什麼。Ollama 的標籤解析到 Q2_0 封裝,那是上游 llama.cpp 唯一能載入的封裝。密集三值 PTQ1_0 封裝——該系列中最小的檔案——完全不在登錄庫上。所以,方便的路徑與小巧的路徑是不同的路徑,對四種尺寸皆然。
27B 的不同之處在於它不隨附什麼。4B 和 9B 各自隨附兩個選用的推測解碼草稿模型:一個內建於 2-bit 槽位套件中的 MTP 頭,以及一個 DFlash2 區塊草稿模型;後者對複製密集型工作有幫助,但在一般聊天上比單純解碼更慢。2B 則刻意不隨附草稿模型——廠商說明指出,在那個規模下,解碼步驟本身已經很便宜,而掃掠深度草擬在日常提示上的實測結果比單純解碼更慢。27B 這一代捨棄了其第一代前身所搭載的對等草稿模型。
那是不同尺寸之間真正的能力差異,而且它完全沒有出現在 Ollama 頁面上。

決定,以及該如何處理答案
27B 是當工作負載屬於長時程推理時的首選:程式碼、數學、代理式工具鏈,以及置於 262K 脈絡中的長文件。它是該家族中唯一採用 Qwen3.8 世代基礎模型的規模,而廠商的類別細分指出,壓縮在數學與程式設計方面幾乎沒有讓它付出代價,卻在知識回憶與視覺方面造成損耗。
9B 是當限制在於記憶體而非難度時該選擇的型號:筆電常駐助理、手機部署,以及任何 2 GB 與 6 GB 之差就是能否出貨的關鍵的場景。它公開的效能概況,恰好最強於 27B 相對基準最弱之處——指令遵循與冗長度控制——而這正是小型本地助理實際花費其 token 的地方。2B 與 4B 則是為更緊縮的預算而存在,而在這些規模下,保留率數字已變得夠嘈雜,以至於你自己的提示詞會比廠商的表格更具參考價值。
關於大多數讀者實際上會做的比較,也就是與託管模型相比,而非彼此比較,這點值得說明。Bonsai 2 的兩種尺寸都不是透過 OrcaRouter 提供服務,本文也並非暗示如此——它們是你下載的權重。但「2 GB 的本機模型對這項任務夠不夠好」這個問題,得靠與某個基準比較才能回答,而 OrcaRouter以一個 API 串接 200 多個託管模型,且收取 0% 加價,並原樣傳遞供應商定價,還能在供應商之間自動容錯移轉,並提供路由 DSL 將多個模型組合成單次呼叫。先用託管模型建立基準,再測試本機模型能否在你的硬體上跨越這個門檻。這樣的順序可省下人們浪費在調校一個根本不可能夠用的下載項目上的數週時間。
從這篇文章帶走的一項告誡。兩份發布都報告了保留率百分比,兩者都是由廠商以自家測試工具測量,而且截至今日,沒有任何第三方重現過其中任何一個。唯一你能親自驗證的是產物——檔案大小、封裝方式、GGUF 中繼資料、授權條款,以及在你自己的機器上的吞吐量。這就是著手的地方,也是這兩份公告不再彼此相似的地方:27B 的獨立套件大小在 Hugging Face 上按檔案逐一公佈,而小模型口耳相傳的 0.43 GB、0.95 GB 和 2 GB 足跡,指的是排除視覺塔之後的語言模型本身。要在相同基準上比較它們,否則 9B 會看起來像是輸掉了一場它從未參與的爭論。
這些都不是假設:像這次發布這類版本背後那些有紀錄的 AI 失效與代理事件,全都收錄在OrcaRouter AI Incident Archive,其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。
