Ternary Bonsai 2 27B：5.9 GB 能裝下什麼，以及 98.2% 沒告訴你的事

Ternary Bonsai 2 27B 是 Prism ML 於 2026 年 9 月 17 日發表的 273.6 億參數多模態語言模型，而關於它，必須理解的一點是：其語言權重只會取三個數值中的其中一個。它的基礎模型是 Qwen3.8 27B——一個 27B 混合注意力模型——而 Bonsai 保留了那套架構、那套訓練與那個形態，並將語言模型的矩陣權重替換為三元表示。出貨的檔案為 5.93 GB。全精度參考版本為 53.81 GB。廠商主打的宣稱是，它保留了原始版本基準平均的 98.2%。

從多數報導都會略過的部分說起：那個 98.2% 是 Prism ML 自家的數字，是在 Prism ML 自家的 20 項基準測試套件上、用 Prism ML 自家的測試框架測出來的，公司以外沒有任何單位重現過。這不是指控——這只是發布隔天的正常狀態，而這也正是你應該賦予它的地位。今天你能獨立驗證的是檔案：Hugging Face API 列出Ternary-Bonsai-2-27B-PTQ1_0.gguf為 5.947 GB，對照 FP16 參考版本的 53.808 GB，縮減了 9.05 倍，與廠商所稱的「約 9 倍」相符，完全不需要信任任何人。檔案大小是事實。品質保留率是廠商的量測數據。真正有意思的內容在兩者之間——類別細分，它精確顯示出壓縮在哪些地方是免費的，哪些地方不是。

這個發布還有另一面。9 月 18 日，也就是公告發布後隔天，OrcaRouter 發布了同一款模型的執行階段去抑制（runtime-abliterated）變體——OrcaRouter Ternary Bonsai 2 27B Uncensored——它在推論時移除學習到的拒絕方向，並讓權重保持位元完全相同。它會在下方自己的章節中說明，因為這項技術才是有趣的部分，也因為其限制與其結果一樣具有啟發性。

它是壓縮過的 Qwen3.8 27B，不是新訓練的模型

這個區別，就是解釋這次發布與照抄新聞稿之間的差別。Prism ML 並沒有從零開始訓練一個 27B 模型，也沒有採用全新的預訓練配方。它所做的是拿來 Qwen3.8 27B，並改變其權重儲存與運算所用的數值表示方式。

架構維持不變，而且就是基礎模型的架構：一種混合注意力設計，大約 75% 是線性注意力、25% 是全注意力，並搭配 SwiGLU MLP 區塊、RoPE 與 RMSNorm。這個混合主幹也正是為什麼 262K token 的脈絡被描述為具備完整脈絡能力，而不僅僅是支援——以線性注意力為主，才能讓長脈絡在裝置上仍維持可負擔的成本。該模型是視覺語言模型：它同時接受圖像與文字，而視覺塔是原封不動、未量化的 Qwen 塔，並另外單獨封裝。

Prism ML 貢獻了兩件事。第一是三元表示本身，加上讓它得以存活的量化感知訓練。第二是核心——針對 Apple Silicon 與 CUDA 上那個混合注意力堆疊的自訂低位元核心，這些核心直接對打包權重進行運算，而不是將它們解包成 FP16 再相乘。少了第二項貢獻，第一項就只是一種儲存格式，無法以高速使用。

Prism ML 自家的白皮書將參數拆分報告為：語言主幹中 24.35B，分布於 64 個區塊；嵌入與 LM head 中 2.54B；以及 27 個區塊的視覺塔中 0.47B，總計 27.36B。視覺塔是真正屬於另一種產物的部分：GGUF 發行版將其打包為約 0.63 GB 的 4-bit mmproj 檔案，只有在影像實際送達時才載入，因此純文字服務永遠不會攜帶它。

這是同一實驗室的第二代 Bonsai；第一代 Bonsai 27B 於 2026 年 7 月問世，大約早了兩個月，而兩代之間的比較是個合理的問題——我們會在與 Bonsai 27B 的正面對決中處理這個問題，而不是在這裡重複。

「ternary g128」具體而言是什麼意思？

如果你之前沒有接觸過三值權重，這段話會讓其他所有內容都變得清楚易懂，所以這裡就不用任何簡寫來說明。

神經網路中的普通權重是 16 位元浮點數——在實用範圍內約有 65,536 個可區分的值，每個值儲存起來要耗費 16 位元。三元權重並不是一個小浮點數。它是在三個符號之間的選擇：−1、0 或 +1。那就是全部的詞彙。若樸素地儲存一個這樣的符號，每個權重就會耗費兩個位元，因為兩個位元能提供四種狀態，而你只需要三種。

單就它本身而言，那會造成表達能力的災難性損失，這也是為什麼該格式從來不僅僅是符號本身。每 128 個連續權重構成一組，共用一個 FP16 縮放因子，而實際的權重值就是三元符號乘以該縮放因子：

• w = ssub>g/sub> · t，其中 t ∈ {−1, 0, +1} 且 ssub>g/sub> 是 128 這一組共用的一個 FP16 縮放係數

所以模型仍然能表示很廣泛的量值範圍——只是它以粗略的、分組的方式來表示，而不是逐個權重表示。0 不是捨入造成的假象；它是真正的第三種狀態，而正因為有它，一組 128 個權重才能在需要時大多保持靜默。

旋轉後的基底是讓人驚訝的部分。在三元分配發生之前，每個權重矩陣都會以區塊為單位，透過正交旋轉進行轉換——一個 Walsh–Hadamard 矩陣結合固定的 ±1 正負號對角線，區塊大小為 1024——而三元值就是在該旋轉空間中選定的。旋轉會在準備階段被摺疊進所儲存的權重中，因此不會增加額外的位元，也不會增加額外的權重傳輸量。在推論時，執行環境改為對激活值套用相應的轉換，而封裝後的模型會在其中介資料中宣告其旋轉方式，因此執行環境不是套用相應的轉換，就是拒絕載入該檔案。

何必費這個功夫？因為 Hadamard 旋轉能把權重矩陣的能量更均勻地分散到各個座標上，這使得後續的三階量化相較於在原始、尖峰般的分布上進行時，破壞性小得多。這個旋轉不是裝飾；它正是三元模型還能在某種程度上保住母模型品質的原因。代價是這個轉換在批次大小為 1 時，位於每一個投影的關鍵路徑上，這是個真實的工程問題——Prism ML 在 Metal 上把符號翻轉融合進轉換的載入路徑，並在 CUDA 上把它平行化到整個執行緒區塊上，以免它主導解碼過程。

這些數字，請仔細看：1.585、1.71、1.72、1.76

這次發布有四組位元寬度數字在流傳，它們全都正確，而且衡量的是四件不同的事。把它們混為一談，是這則報導中最容易犯的錯誤。以下分別說明每一組，以及它實際涵蓋的內容。

• 每權重 1.585 位元——一個三元符號的資訊內容，log₂3。這是格式本身的性質，而非任何檔案的性質。沒有任何已出貨的項目以每權重 1.585 位元運行。

• 每權重 1.71 位元 — 僅限三值張量。將 16 位元 FP16 群組縮放係數分攤到 128 個權重後，就會得到 log₂3 + 16/128 ≈ 1.71。這仍不是實際出貨的數字；它只是單獨的三值張量。

• 每個權重 1.72 位元 — 語言模型中的每一個參數，包括那一小部分維持在低位元表示之上的參數。Prism ML 以較高精度保留 26,238,464 個參數——佔語言模型的 0.0976%，在 bf16 下約 52 MB——主要是線性注意力層的循環狀態路徑，以及正規化權重。這些張量既未經旋轉，也未經量化，而正是它們使這個數字從 1.71 變成 1.72。在 1.72 之下，理想化佔用空間為 5.80 GB，約減少 9.3 倍。這是 Prism ML 的「True Ternary」列，而它是目標，而不是你下載的檔案。

• 每個權重 1.76 位元——實際出貨的 GGUF。高效能核心需要一種封裝格式，而 Prism ML 的 PTQ1_0 會將三進位數值密集封裝，達到每權重 1.76 位元、5.93 GB，約 9.1 倍。這正是公告所引用的「5.9 GB」與「縮小 9 倍」背後的檔案，也是上述測量所證實的那個檔案。

第二種打包方式是PQ2_0，它把每個三元值存放在 2 位元的槽位中，而非以密集方式儲存。它以更多空間換取更便宜的解包：在 7.25 GB 中為每位權重 2.16 位元，約 7.4 倍。兩種打包方式都不是全面更快——PTQ1_0 每步搬移的權重資料約少 18%，但得付出運算代價來解開密集三元值，因此它在記憶體成為瓶頸的 Ada 世代顯示卡與 L4 上勝出，卻在單一批次解碼受制於指令吞吐量而非記憶體的 Hopper、Blackwell 與 Apple 晶片上落敗。提示處理則在所有情況下都偏好 PQ2_0，因為它受運算限制。

給任何要拿這些去核對原始資料的人兩點補充說明。首先，Prism ML 自家的文件在數值進位上略有不同——白皮書的儲存表把 PTQ1_0 列為 1.76 位元/權重、5.93 GB，而 Hugging Face 上的 GGUF 模型卡則給出 1.75 與 5.95 GB，實測檔案則是 5.947 GB。這些是同一個檔案以不同精度描述，並非實質上的分歧。其次，所宣稱的「超過 9 倍」縮減是廠商自己的說法；以實際檔案測量則是 53.808 / 5.947 = 9.05 倍，兩者一致。

基準圖像：不是平均值，而是形狀

這個頭條數字是平均 83.9，對比 Qwen3.8 27B FP16 基準的 85.4，也就是 98.2%。平均是其中最不有趣的部分。底下的分布形狀才是真正資訊所在，而它並不均勻。

• 指令遵循 — 82.66 對 81.25。 這是壓縮模型勝過其全精度母模型的唯一一個類別。這不是任何人能隨口解釋掉的雜訊；這是在廠商自家測試套件上的一項類別勝利。

• 數學 —— 96.57 對 97.06，程式設計 —— 81.58 對 82.17。兩者基本上旗鼓相當：在分類平均上分別相差半分與零點六分。對於一個足跡僅九分之一的模型來說，這正是整套技術被拿來爭論的成果。

• 知識與推理 — 83.95 對 86.66。 下降了 2.7 分，而總平均少掉的 1.8 分中，有相當一部分就落在這裡。

• 視覺 — 78.59 對 81.64。 下降 3.05 分，是單一類別中最大的跌幅。值得注意的是，視覺塔本身並非被壓縮的部分；讀取其輸出的語言模型才是。

• 代理式與工具呼叫 — 77.57 對 79.74。此類別平均涵蓋 τ 2-Bench 的 80.22 與 BFCL v3 的 74.92。

個別結果值得了解，因為它們並非全都指向同一方向。在 Terminal-Bench 2.1 上，該模型得分為 52.8，而全精度為 69.7——大約四分之三——在 SWE-bench Verified 上得分為 60.8，而全精度為 80.6，同樣約為四分之三。這是該模型家族首次在 Terminal-Bench 上進行評估，而 Prism ML 明確表示，其在第一版 Bonsai 發佈時所承諾的長時程軟體工程進展是部分的，而非完整的。與此相對：τ 2-Bench 從上一版的 73.6 上升至 80.2，BFCL v3 維持在 74.9，AA-LCR 則為 77.0，與全精度相差不到一分。AIME26 達到 95.83，LiveCodeBench 則為 90.07。

該信什麼、不該信什麼。在數學、程式編寫與指令遵循方面，可以相信這份結果的樣貌——這些類別中，該技術確實做到它所宣稱的事，而且它們是與基線在同一套測試工具上測得的。至於長時程的代理式工作則要謹慎：真正對持續性工具驅動工程構成壓力的兩項基準——Terminal-Bench 2.1 與 SWE-bench Verified——所顯示的差距遠大於總體數字所暗示的程度，而廠商自己也這麼說，並未加以掩飾。此外，在其他人實際跑過之前，應把整張表視為單一實驗室、單一套測試工具的測量結果。這項但書在這裡並非形式上的客套——它正是「這個模型保有 98.2%」與「這個模型的廠商在廠商自選的測試套件上測得 98.2%」之間的差別。兩者都為真；但只有一項是關於這個模型的事實。

為什麼這會勝過同一基礎模型的 IQ2_XXS 版本

這值得獨立成一節，而不是一行，因為這正是量化感知三元訓練優於訓練後量化的全部論據。

讓 Qwen3.8 27B 變小的傳統做法，是在訓練後將其量化。白皮書的比較基準，是同一基礎模型的 IQ2_XXS GGUF 版本：

• Ternary Bonsai 2 27B — 每權重 1.76 位元，5.93 GB，20 項基準平均 83.9

• Qwen3.8 27B IQ2_XXS — 每權重 2.2 位元、7.3 GB、20 項基準測試平均 75.2

經訓練壓縮的模型既更小又更好。它比傳統低位元版本小 1.23 倍，得分則高出 8.7 分。這種組合不是四捨五入造成的巧合；它要主張的是，訓練期間所選定的表示法，其價值遠高於事後才套用相同名目位元預算的表示法。

更具啟發性的部分在於為何傳統建構會失敗，因為這種失敗具有選擇性且容易遭到忽略。IQ2_XXS 並非均勻地退化。它在表面知識上表現穩固——MMLU-Redux 上為 85.79——卻在需要持續推理鏈的任務上崩潰：AIME26 上為 78.6，LiveCodeBench 上為 70.05，GPQA Diamond 上為 65.45。Bonsai 2 在這同樣三項上分別得分 95.83、90.07 和 85.76。隨意的聊天測試會覺得 IQ2_XXS 建構完全堪用，永遠不會顯現出這種崩潰；損害正好存在於長時間推理與程式碼生成發生的地方。這種不對稱正是為什麼「我試用時感覺沒問題」不能作為量化模型的證據。

Prism ML 把同樣的論點濃縮成一個它稱為智慧密度的單一衍生數字——大致上是每 GB 的基準測試能力。在 20 項基準測試套件上，它回報 Bonsai 2 為每 GB 0.444，IQ2_XXS 版本為 0.276，FP16 為 0.051。這項指標是廠商自行建構的，其加權方式是一種設計選擇，而非定律；但它產生的排序與原始表格產生的排序相同，因此它增添的是詮釋，而非證據。

關於這項比較，再補一則誠實的說明。Prism ML 的 GGUF 模型卡另外報告了一組範圍較窄的評估——一套 14 項基準的思考模式測試組——同樣的保留率數字在其中再度出現，為 84.78 對 86.32，而 IQ2_XXS 則為 72.59。兩套不同的測試組卻得出同樣的 98.2%，這對「總體宣稱並非單一基準選擇所造成的假象」提供了些許佐證。但這兩套仍舊是同一個實驗室、在同一套測試框架上跑出來的。我們對這場對決更完整的細部分析，包括打包格式的問題，收錄在與 Qwen3.8 27B GGUF 各版本的比較之中。

實際運作需要什麼

吞吐量數據，取自白皮書中在批次大小為 1、排除視覺塔的標準化 tg128 測量：

• Apple M5 Max — 46.8 tok/s 解碼，765 tok/s 提示處理

• Apple M5 Pro — 解碼 27.7 tok/s；另一次使用較長視窗的 PQ2_0 套件測試測得持續 27.0 tok/s，GPU 供電軌耗電 27.0 W，CPU 與 GPU 合計耗電 32.8 W

• Apple M4 Pro — 解碼 18.0 tok/s，而提示處理約 125 tok/s，在極長上下文中成為主要限制

• NVIDIA RTX 5090 — 在 PQ2_0 套件上以每 token 0.582 mWh 達到 142.5 tok/s 解碼

Prism ML 提出的實際主張並非加速比，而是一種「不存在」：53.8 GB 的 FP16 基準根本無法放入 16 GB 的筆電，因此有意義的說法是，27B 等級的模型如今已能在日常硬體上互動運行。在 M5 Pro 上，測得的解碼會以約 201 GB/s 串流權重，證實了低位元表示法旨在利用的、以記憶體頻寬為主的特性。

然後是邊界情況，它們比峰值數字更重要。

你不能使用原版 llama.cpp。三元混合注意力核心位於 Prism ML 自家的 llama.cpp 分支中。原版 llama.cpp 會將 PTQ1_0 和 PQ2_0 類型視為未知而拒絕，而且——更危險的是——會在沒有任何警告的情況下載入較舊的 Q2_0 三元格式並產生垃圾輸出，因為它沒有 Hadamard 激活執行環境。如果你在未套用相符旋轉的二進位檔上執行此模型，你不會得到錯誤；你會得到看似流暢的胡言亂語。這是這個版本最可能讓你白白浪費一個下午的方式。

MLX 套件沒有 CUDA 路徑。 MLX 版本（prism-ml/Ternary-Bonsai-2-27B-mlx-2bit）鎖定 Apple Silicon，在該平台上，它於 Python 與 Swift 執行環境中皆具備針對此混合堆疊的自訂核心。其量化矩陣乘法有 Metal 與 CPU 核心，但沒有 CUDA 實作，因此在 NVIDIA 機器上，該特定套件完全無法獲得 GPU 加速。CPU 推論可以運作，但在 CPU 上進行 27B 前向傳遞可能耗時數分鐘——這使得 Linux CPU 路徑對實作測試與可重現性而言很有用，但對提供服務而言則毫無用處。

這兩種套件是真正的取捨，而非排名。如果你使用的是 Ada 世代的顯示卡或 L4，或者記憶體是關鍵限制，那麼 PTQ1_0 是 5.93 GB 的首選。如果你使用的是 Hopper、Blackwell 或 5090，PQ2_0 能以 1.3 GB 換得解碼速度。如果你使用的是 Apple silicon，請注意上方 M5 Pro 的數據是在 PQ2_0 上測得的，而這也是示範設定預設下載的套件。

關於 MLX 封裝本身帳目計算的說明，因為這是一個常見的混淆來源。MLX 容器是一種仿射 2 位元格式，其區塊會為每 128 個權重儲存一個 FP16 縮放值 與一個 FP16 偏誤。Bonsai 的三元權重只需要縮放值——層級僅由縮放值本身得出——因此偏誤是多餘的負擔，而每 128 個權重的區塊成本為 36 位元組，而非 34。這使得 MLX 封裝的封裝位元率達到 2.250 位元/權重，既不是 1.72，也不是 1.76。它是裝載相同三元值的不同容器，其在 Hugging Face 上測得的檔案為 8.005 GiB。

執行階段解除限制的變體

9月18日，OrcaRouter 發布了 OrcaRouter Ternary Bonsai 2 27B Uncensored；這款模型完全在執行階段對自身套用拒絕方向消融。這個工程構想比產品本身更值得關注，所以先談這個構想。

傳統的 abliteration 會直接修改權重。它會在激活空間中找到一個對應於拒答行為的方向，然後把寫入殘差流的權重矩陣對該方向正交化：W ← W − r(rᵀW)。在普通的 FP16 模型上，這沒問題——編輯後的矩陣仍然是稠密浮點矩陣，所以把它存起來就能繼續。但在三元打包上，這是一條死路，而且這條死路的原因，正是這整個模型存在的理由。對三元矩陣做正交化，會產生一個稠密的全精度矩陣。要把它存回三元打包裡，你就必須重新量化——而重新量化編輯過的權重，並不會重現當初產生原始權重的量化感知訓練。你會把當初付出代價換來的東西，就這樣白白丟掉。

所以投影改到推論時進行。與其改變 W，不如改變它的輸出：

• y ← y − α · dot(y, r) · r，以 float32 計算，其中 y 是殘差貢獻，而 r 是正規化的拒絕方向

在 α = 1 時，每個殘差寫入中與拒答方向平行的分量會被移除。在 α = 0 時，模型維持不變。α 大於 1 會過度投影，可能導致品質下降。由於 α 是執行階段參數，而非檢查點屬性，同一個套件可以在同一行程中與自身進行 A/B 測試——這正是 OrcaRouter 的評估所做的事。原始 Bonsai 套件維持位元完全一致：零個權重被修改、零次重新量化、零額外的權重量化誤差。

有兩個實作細節，正是這種做法的樸素版本會失敗的地方。

129 個干預點，不是 16 個。每個能寫入殘差流的模組都必須被包覆，而在這個混合架構中，這包括 64 個 mlp.down_proj 區塊、48 個 linear_attn.out_proj 層、16 個 self_attn.o_proj 層，以及 model.embed_tokens——總共 129 個。只包覆 self_attn.o_proj 是顯而易見的錯誤，只涵蓋了其中 16 個，讓其餘 113 個寫入未被投影。自我檢查腳本會測量沿拒絕方向的殘餘分量是否被壓到約殘差範數的 1e-6，若未偵測到全部 129 個點就會提出警告。

請勿重新旋轉該方向。三元封裝會將其投影保持在旋轉基底上，該基底是沿著它們的輸入維度，並在激活端進行補償。拒絕投影運作於輸出，而這些輸出屬於那些投影，且已經回到一般的隱藏基底——因此拒絕方向是一個普通的 5120 維向量，對它套用額外的 Hadamard 旋轉會完全投影到錯誤的基底上。

OrcaRouter 所測量到的——我們自家的數據，而非獨立數據

這些是 OrcaRouter 自身的規則式量測，也應如此解讀：一個規則式的開頭語句分類器，而非 LLM 評審，思考功能關閉、貪婪解碼、64 個 token 的預算，且 base 與 ablated 是同一程序中、相同權重，以 α = 0 對比 α = 1。這些結果僅具指示性，未達可發表等級，也不構成對 Prism ML 任何宣稱的驗證。

關於拒絕，以收到拒絕的提示詞所占比例衡量：

• AdvBench（n=100）—— 基礎 99.0%，消融 6.0%，其中 56.0% 有回答但以免責聲明包裝

• JailbreakBench（n=100）— 96.0% 基準、4.0% 消融、52.0% 附帶但書

• StrongREJECT（n=150）—— 99.3% 基礎，3.3% 消融，45.3% 有但書

• HarmBench（n=150）—— 基礎 98.7%、消融 7.3%、有附帶條件 48.0%

• MaliciousInstruct（n=100）— 97.0% 基礎、0.0% 消融、52.0% 附帶警告

• ForbiddenQuestions（n=150）—— 基礎 75.3%，消融 5.3%，附帶條件 42.7%

• SimpleSafetyTests（n=50）—— 基礎 96.0%、消融後 18.0%、附警示語 60.0% —— 而這個數字其實被低估了。該資料集多為自傷相關的提示，而模型會以危機轉介的開頭「I am deeply sorry to hear…」來回應，這正是分類器的精確片語清單所遗漏的，因此被評判為遵從。該資料集上真正的殘餘拒答率高於 18.0%。分類器刻意維持原狀，以便這些數字能與 OrcaRouter 的其他模型卡保持可比性。

任何集合中的回覆都沒有用完其 token 預算，因此這些比率都沒有因截斷而被高估。在良性提示上，同樣的投影也消除了過度拒絕：XSTest-safe 的拒絕率從 5.2% 降至 0.4%，而 JailbreakBench 的良性子集則從 25.0% 降至 0.0%。已發布的 pack 拒絕了該基準中四分之一的良性提示；經消融後，它一個也不拒絕。

在能力方面，權重位元完全相同意味著不需要為重新量化付出代價，而量測結果也與此一致：

• MMLU（n=300）— 76.7% 基礎、77.7% 消融、+1.0

• GSM8K（n=150）— 87.3% 基準、86.0% 消融後、−1.3

• CMMLU（n=500）—— 76.2% 基礎、75.6% 消融後、−0.6

在這些樣本數下，每一次變動都落在雜訊範圍內；一題 GSM8K 就值 0.7 分。MMLU-Pro 予以排除而非報告：其提示要求在答案之前先進行推理，而雙方各有 63–64% 的回覆並未在 token 預算內得出答案，因此任何準確率數字都會是預算所設定的下限，而不是一項測量。

最重要的注意事項

拒絕方向是從 Bonsai 套件訓練時所依據的 BF16 基礎模型估計而來。架構與隱藏基底完全相同，因此幾何結構吻合。但該方向經過量化感知訓練後能保留得多好，尚未被充分測量。

執行階段能以數學方式、精確到大約 1e-6 證明，它會從每個殘差寫入中移除所提供的方向。但單憑這一點，它無法證明該方向在量化模型中仍捕捉到與其在稠密模型中所捕捉到的相同行為特徵。這些是不同的主張，而只有第一項已獲確立。任何閱讀上方安全表的人，在閱讀時都應知道：這項干預的有效程度正好等同於方向轉移假設的有效程度，而那個假設正是懸而未決的問題。

OrcaRouter 對這次發布本身還加上了務實的定位框架，這點值得照樣重申，而不是用改寫把它淡化掉：移除一個學得的拒絕方向，可能導致模型回應原本會拒絕的請求。這是一種研究與推論控制機制，並不證明任何由此產生的輸出是安全、正確或適當的，而使用它的部署應套用自身的存取控制與政策執行。移除拒絕並不是沒有代價的改進，本文也不是以它彷彿是那種改進的方式寫成的。

還有三點實用提醒，給任何要重現它的人。這個 pack 必須用它自己隨附的 runtime 來載入——一般的 MLX 載入器可能看似成功載入，實際上卻默默算錯東西，所以如果在還沒啟用 ablation 之前輸出就看起來不對，請先檢查載入路徑。系統支援逐層選擇性的 ablation，因此干預不必是全有或全無。此外，ablation 評估是在 pack 展開後的 FP16 版本上執行，而不是讓 pack 驅動自己的 kernel，因為打包後的量化 matmul 沒有 CUDA 實作，而 CPU 後端每次前向傳遞需要數分鐘；那個展開版本精確承載了 pack 的三元值，並在抽查中重現 pack 自身的下一個詞元分布到小數點後三位，但這是容器上的變更，值得留意。程式碼與完整表格都在 OrcaRouter Ternary Bonsai 2 27B Uncensored 這個 repository 中。另一份比較涵蓋了經 ablation 處理的 MLX 版本與未修改的 Qwen3.8 27B MLX 路徑，對 runtime 的具體細節有更深入的探討。

這會走向何方，以及還有什麼仍未獲得證實

一個大約六 GB、近乎無損的 27B 模型，對本地代理帶來的改變，主要就在於哪些東西能常駐。一個能在 16 GB 筆電上與真實上下文視窗並存的語言模型，可以在代理處理其他工作時保持載入——讀取檔案、呼叫工具、跨多輪對話維持計畫——而不是每次請求才被換入，或被推送到伺服器。這就是「你會試用一下的本地模型」與「你會讓它一直跑著的本地模型」之間的差別，而這正是 τ 2-Bench 的 80.2 與 BFCL v3 的 74.9 這些代理式數字所要佐證的特定特性。

未經證實的清單，比那份公告所暗示的還要長。

• 沒有獨立重現。本文中的每一項品質數據——83.9、98.2%、各類別平均值——都是 Prism ML 以自家測試套件所做的自家量測。這不是該發布版本的缺陷；這不過是剛誕生一天時會有的樣貌。這也是最先會改變的一點。

• 長時程代理式工作是廠商自家表格中最弱的一環，而非最強的部分。Terminal-Bench 2.1 為 52.8，對比 69.7，這是真實的差距，而廠商表示該能力僅屬部分。

• 你尚未試過的提示。低位元模型的失效情況具有選擇性，而 IQ2_XXS 在 AIME26 與 LiveCodeBench 上崩潰、卻在 MMLU-Redux 上維持 85.79，是現有最清楚的證據，說明基準平均分數無法告訴你實際工作負載上會發生什麼事。Bonsai 2 在那兩項基準上並未出現這種崩潰，這令人鼓舞，但並不等同於保證。

• 上文所述 abliterated 變體中的方向轉移問題，該問題在構造上即無法解決。

• 核心是否能隨著執行環境演進而經得起考驗。目前這個模型需要一個分支；原版 llama.cpp 會拒絕三種格式中的兩種，並默默地弄亂第三種。在那些核心合併至上游之前，「llama.cpp 能運行的地方它就能運行」對這個模型來說尚未成真。

這次發布本身並無疑問。一個 27B 級別的多模態模型，大小為 5.93 GB，佔其壓縮來源模型足跡的九分之一，數學與程式能力與母模型相當，指令遵循則略勝一籌，這對本地推論而言是真正不同的運作點。在 2026 年 9 月 18 日，合理的態度是：將檔案大小視為事實，將保留率數字視為供應商一天前在其自行選擇的測試套件上做出的審慎聲明，並對自身工作負載保留判斷，直到你實際用它跑過為止。

執行階段消融程式碼、拒答方向與完整評估表皆由OrcaRouter發布，並連同該團隊所建置的路由平台一併公開。