Bonsai 2 在任何人宣布它將推出之前，就已登陸 Ollama

2026年10月17日凌晨某時，Ollama 開始提供 Bonsai 2——一個涵蓋九個標籤的模型庫項目，包含 Ternary Bonsai 2 2B、Ternary Bonsai 2 4B、Ternary Bonsai 2 9B 以及 Bonsai 2 27B，每個都有兩種封裝，外加一個預設別名。Prism ML 對此隻字未提。供應商的新聞頁面上沒有貼文，10 月 15 日的小型模型公告中也沒有一行提及——那篇貼文將 llama.cpp 和 MLX 列為執行環境，並以託管主控台作為示範，卻完全沒有提到 Ollama。這個項目就這樣存在，全部九個標籤都被標上相同的「幾小時前」，這正是全新推送的樣子，而不是逐步推出的樣子。

所以，誠實的區分是這樣的。 現在可從登錄庫與檔案中得知的是： 這些標籤、它們的名稱、確切的位元組大小、其內容摘要，以及——因為 Ollama 以 GGUF 形式發布——權重本身內部的架構與中繼資料字串。 尚未確認： 是誰封裝了它們、為何廠商的公告略去了平台、這些三值核心究竟是 Ollama 自家引擎中的上游程式碼，還是外部引入的，以及廠商的任何數字是否經得起這趟考驗。這些都是各自獨立的問題，而本文將它們分開處理。

架上到底放了什麼

九個標籤、四種大小、三種相同權重的封裝。Ollama 的函式庫頁面列出了每個大小的預設別名，以及一個-q2_0 變體：

• bonsai-2:latest — 3.2 GB，解析為 9B（摘要 c8b5462f8688）

bonsai-2:2b 與 bonsai-2:2b-q2_0 — 911 MB，相同的 digest de2ccb4e7328

• bonsai-2:4b 與 bonsai-2:4b-q2_0 — 1.6 GB，相同摘要 93edd652c932

• bonsai-2:9b 與 bonsai-2:9b-q2_0 — 3.2 GB，相同的摘要 c8b5462f8688

• bonsai-2:27b 與 bonsai-2:27b-q2_0 — 8.3 GB，相同的 digest f3c4f4208659

這個命名背後的作用比表面上看起來更多。每個尺寸有兩個標籤共用同一個 digest，這並不是重複——而是在說明 Ollama 選用了哪一種封裝。拉取 bonsai-2:9b 的 manifest，模型層是 2.557 GB。那就是 Ternary Bonsai 2 9B 的 Q2_0 檔案，在 Hugging Face 上量測為 2.557 GB，位元組完全吻合。PQ2_0 封裝是 2.417 GB，而 PTQ1_0 封裝——最小的 1.997 GB——根本不在這裡。

那個選擇有個值得直說清楚的後果，因為這正是那種會演變成支援討論串的事情。在廠商的模型卡上，上游 llama.cpp 只執行三種封裝中的一種：Q2_0，「近期的 master，其中包含 Hadamard 活化執行階段」。它拒絕 PQ2_0 和 PTQ1_0，將它們視為未知類型，因為那些需要 Prism ML 的 llama.cpp 分支。Ollama 提供自家的引擎。Q2_0 是標準 GGUF 取用者有可能載入的封裝——而 Q2_0 正是 Ollama 出貨的封裝。Ollama 是自行開發了三元核心，還是導向某個內嵌的組建版本，登錄庫並不會告訴你。它確實告訴你的是：他們沒有出貨那個無法載入的檔案。

GGUF 中介資料透露的資訊比頁面還多

Ollama 的頁面會針對每個標籤顯示四項資訊：位元組大小、一個「256K」上下文標記、文字加圖片的輸入類型，以及相對時間戳記。其餘一切都在檔案裡。讀取每個模型層的 GGUF 標頭會得到以下內容，而它有值得一讀的特定理由：它是這段故事中唯一不是某人行銷宣稱的部分。

• general.architecture — qwen35 於全部四種尺寸

• general.name — Ternary-Bonsai-2-2B, -4B, -9B 用於小型三者；27B 層回報通用字串 Hf，且 general.basename = folded

• general.file_type — 全部四個皆為 41，且 general.quantization_version = 2

• general.size_label — 2B、4B、9B、27B，與標籤名稱相符

• 張量數量 — 2B 為 320，4B 為 426，9B 為 427，27B 為 851

架構字串才是耐人尋味的那個。qwen35 是 Qwen3.5 混合注意力主幹，而它從成品本身印證了模型卡以文字所說的內容：三個小模型分別是 Qwen3.5-2B、-4B 與 -9B，架構不變，權重則被替換。它也暴露出供應商自家發布說明所掩蓋的一道命名接縫。10 月 15 日的貼文說新模型「基於 Qwen3.5」。27B 則是完全不同的基底——Qwen3.8-27B，於 9 月 17 日發表。四個尺寸、一個系列名稱、兩種基底模型。任何你讀到關於「Bonsai 2」行為、且是在 27B 上測得的說法，都不會自動下移到 9B，而 GGUF 標頭正是你能看出原因的地方。

27B 的中繼資料也明顯比其餘的來得凌亂：general.name = Hf、general.basename = folded、general.version = v5，以及一個小型三者沒有的額外取樣鍵。這正是轉換流程的中間輸出在未經最後重新命名處理就被推送時的樣子。這不是缺陷——張量就是張量——但它是一枚指紋，暗示 27B 標籤是經由不同於小型三者的路徑而來的。

Ollama 數字不代表什麼

這裡正是大多數針對函式庫列表的報導出錯的地方，因此值得放慢腳步細看。Ollama 頁面上的位元組大小是容器大小，而且每一個大小都比裡面的模型檔案更大。2B 標籤顯示 911 MB，對應的是 0.547 GB 的模型層與 0.365 GB 的視覺投影器。27B 標籤顯示 8.3 GB，對應的是 7.626 GB 的模型層與 0.629 GB 的投影器。把授權與參數 blob 加進去，算術就對得上了：Ollama 引用的是整個被拉取的產物，包含視覺塔在內。

這表示 Ollama 頁面上 9B 版本所標示的 3.2 GB，無法與廠商針對同一模型所稱的「2GB」相提並論，而這個落差並不是需要回報的資料不一致——那其實是對兩種不同事物的兩種不同量測。Prism ML 的 0.43 GB / 0.95 GB / 2 GB 僅指語言模型本身。視覺塔會被卸載，只有在實際有影像送達時才會載入，因此純文字部署永遠不必為它付出代價，但 ollama pull 卻得要。如果你依據廠商的數字來評估裝置規格，然後又從 Ollama 拉取，那麼在你實際執行任何東西之前，就會超出預算 0.5 到 1 GB。

同樣的謹慎也適用於「256K」標章。其背後的脈絡是 262,144 個 token，繼承自 Qwen3.5 主幹——9B 上有 24 層線性注意力與 8 層完整注意力——而 Ollama 的標章為了顯示而將它向下取整。這個脈絡是真實的，而且是繼承而來的，並非 Ollama 額外加上的。並未在頁面上任何地方說明的是，長脈絡會耗費多少記憶體，而在一個混合注意力模型上，若僅部分層使用完整注意力快取，這可不是個小數字。Ollama 頁面上沒有任何內容告訴你，262K 是否真的能塞進你打算執行它的任何地方。

這是誰包裝的，這重要嗎？

未獲解答，而且應該標示為未解答，而不是用猜測的。有三種可能：Prism ML 推送了它、Ollama 在進行自身的目錄作業時從供應商公開的 GGUF 儲存庫拉取了它，或是第三方所為。註冊表無法告訴你是哪一種。

可以查核的是這件產物的出處，而它完全吻合。Ollama 自家的模型說明寫道：「來自 Prism ML 的 Bonsai 2 是一系列為三元權重（−1、0 或 +1）打造的視覺模型：大小約為標準 4 位元模型的一半，品質則接近全精度」，並連結到供應商的 Hugging Face 組織、Bonsai 2 27B 白皮書，以及 Apache 2.0。嵌在四個尺寸 manifest 中每一份的授權條款 blob，都是逐字不差的 Apache 2.0 文字。2B、4B 和 9B 的參數 blob 內容為 {"presence_penalty":1,"temperature":1,"top_k":20,"top_p":0.95}——這正是供應商推薦的思考模式取樣配方，出自模型卡；其中 min_p 的省略方式，完全如同 27B 模型卡所說 GGUF 檔案會省略它那樣。那不是有人憑空猜出來的；那是讀過模型卡後所做的轉換。

這點令人安心，卻仍然完全沒告訴你真正決定你體驗的關鍵：三元核心是否在你正在執行的引擎裡。誠實的立場是，成功拉取只證明該檔案是格式良好的 GGUF，如此而已。在你自己的硬體上驗證之後，再以它為基礎來建構。

廠商的主張，以及已查核的項目

這個系列所附帶的每一項品質數字都來自 Prism ML，且是在 Prism ML 自家的測試框架上取得，沒有任何一項經過獨立重現。這在這個階段是正常的，應該被明確說出來，而不是只用暗示的。10 月 15 日的文章報告了小模型在六個技能領域中的 19 項基準測試，並附上相對於全精度 Qwen3.5 基準的保留率：

• 2B — 代理能力 95.5%、數學 107.8%、指令遵循 121.5%、程式編寫 115.0%、知識 82.9%、視覺 89.0%

• 4B — 90.0% / 99.3% / 106.0% / 100.7% / 90.9% / 91.3%

• 9B — 92.4% / 98.2% / 100.0% / 100.1% / 93.0% / 92.5%

其中好幾項超過 100%，這不是筆誤，也不是四捨五入造成的假象——這代表三值模型在該類別上得分高於它所衍生自的全精度模型。2B 的指令遵循達到 121.5%，是最明顯的例子。請以它理應受到的懷疑來看待這件事：壓縮模型在供應商挑選的基準測試上擊敗自己的基線，這至少同樣說明了訓練與測試框架的狀況，而不只是表徵；而且小模型類別的成績遠比 27B 的雜訊更多。27B 的數字更保守，形態也更可信——84.78 對上 FP16 的 86.32，在 14 項思考模式基準測試中保留率為 98.2%，數學為 96.57 對上 97.06，程式設計等級為 89.42 對上 89.07，而損失集中在知識/推理與視覺。當一個模型家族在 1.7 位元表徵下放棄能力時，那正是你會預測到的特徵輪廓。

那篇小型模型文章中唯一一個不是基準測試的主張，才是最值得認真看待的：9B 模型「在標準指令遵循和日常數學任務上使用的 token 大約少了 40%」。那是關於冗長程度、而非能力的說法，而且這種事你可以用一個下午在自己的提示上驗證。它也與供應商自家模型卡上的警告相互呼應——思考模式可能在一個簡單問題上燒掉 3,000 多個 token，所以至少設定 8,192 個輸出 token，而且不要在開啟思考時執行貪婪解碼，因為它可能會卡在推理中。一個冗長程度少了 40%、卻仍需要 8,192 個 token 預算的模型，是在告訴你它在某個特定地方很囉嗦。

這對你意味著什麼

如果你已經在跑 Ollama，而且想在沒有資料中心 GPU 的筆電上試試 27B 等級的模型，這四個標籤就是目前存在的最短路徑：一次 pull、不用 fork、不用編譯核心。如果你需要的是真正最小的封裝，或是廠商為 4B 和 9B 提供的推測解碼草稿模型，Ollama 的清單裡並沒有這些——那得從 Hugging Face 下載，並使用 Prism ML 的 llama.cpp 建置版本，而且自 10 月 15 日起就是如此。

另一件值得知道的事是，本地端並不是使用低位元模型的唯一途徑，也不見得永遠是正確的選擇。OrcaRouter 提供單一 API，串接 200 多個託管模型，零加成——直接以供應商定價原樣傳遞——還能在供應商之間自動容錯移轉，因此你可以在真實工作負載上評估某個模型，再決定它是否值得在你筆電上佔有一席之地。目前 Bonsai 2 的所有尺寸都未透過 OrcaRouter 提供服務，本文也沒有這樣主張：這個系列是你自行下載執行的，而且在廠商發布端點之前都會維持如此。路由層能為你帶來的，是這個決定的另一半——那些你將用來與它比較的託管模型，全都只要一組金鑰就能取用，而當單一模型不敷使用時，還有模型融合與路由 DSL 可用。

接下來該關注什麼，依其改變整體局面的程度排序：某個 Ollama 標籤多出一個 ptq1_0 的同類項目，這將意味著 dense-trit 核心已進入上游；一篇承認該平台的廠商貼文，這將解答來源出處的問題；以及任何針對 9B 或 27B 的獨立基準測試，這是唯一能讓留存數據脫離廠商自報欄位的東西。在上述任何一項成真之前，這份清單只是個交付機制，而非新模型——而它所交付的模型自 10 月 15 日起就已公開。

這些都不是假設：像這次發布這類版本背後那些有紀錄的 AI 失效與代理事件，全都收錄在OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。