什麼!?Qwen3.8 27B 居然被壓到 5.9GB，跑起來能力居然有無損模型的 98.2%

前言

真空壓縮袋可以把一床冬被壓到剩十分之一厚，塞進衣櫃最上層。要蓋的時候拿出來拍一拍、等它膨起來，一樣暖。省下的是櫃子，付出去的是每次拿出來那一下。

PrismML 的 Ternary Bonsai 2 對 Qwen3.8-27B 做的就是這件事：FP16 原本 54GB，壓完最小那包 5.95GB，官方說分數還有 FP16 的 98.2%。#14 我用兩張 2080 Ti 跑 Q8_0 的同一顆模型，那是這台機器當時的主力。這篇想知道的是：壓成三值塞進一張卡，還剩多少？

答案是 140 題差一題。前半段是能照抄的做法，外加兩個會卡住你的設定；我怎麼量、哪裡量錯過、試過但沒用的路，收在後面的進階區。

Ternary Bonsai 2 是什麼：權重幾乎只剩 -1、0、+1

模型的權重，就是它訓練完學到的那一大堆數字，27B 就是 270 億個。原版每個數字用 16 位元存(FP16)，一般的量化是壓成 8 位元、4 位元。Bonsai 2 更狠：幾乎每個數字只能是 -1、0、+1 三種值，每 128 個再共用一個縮放係數，平均每個權重只佔 1.72 位元，檔案從 54GB 縮到 5.95GB。(線性注意力的狀態路徑和 normalization 權重約占語言模型的 0.1%，留在較高精度，這 1.72 已經算進去。)

它還多一個步驟：存檔前先把權重做一次 Hadamard 轉換(每 1024 個一塊，一種只用 +1、-1 的旋轉)。這個細節只要記住兩件事：跑的時候，每一層的輸入也要照樣轉一次，上游 llama.cpp 不會做這一步，所以跑不了 Bonsai；而且這一步每吐一個字都要做，後面「越小越慢」也跟它有關。

官方給兩種打包，存的是同一組三值權重：

• PTQ1_0：把三值擠得很密，1.75 位元，5.95GB。標題的 5.9GB 就是這包。
• PQ2_0：每個三值佔一個 2 位元的格子，2.13 位元，7.21GB。浪費一點空間，換解包比較省事。

官方的分數是在 H100 上用 EvalScope + vLLM 量的，thinking 模式、14 項測驗取平均。這表看最後一欄：同樣是兩位元等級，傳統的 IQ2_XXS 掉到 84.1%，Bonsai 2 留在 98.2%。

版本	大小	14 項平均	對 FP16
Qwen3.8-27B FP16	54 GB	86.32	100%
UD-Q4_K_XL	17.6 GB	85.18	98.7%
IQ2_XXS	9.4 GB	72.59	84.1%
Bonsai 2 27B	5.9 GB	84.78	98.2%

這是他們的數字，不是我量的。我量的在下一節。

我量到的：一張卡 130 題，兩張卡的 Q8_0 是 131 題

題目 140 題：GSM8K 50、MATH-500 30、MuSR 20、HumanEval+ 40，用固定種子從各題庫抽。兩邊同一份題目、同一套評分，thinking 開著，取樣照 Qwen 官方建議(temperature 1.0、top_p 0.95、top_k 20)，每題上限 8192 token，一次只送一題。

看第一列和最後一列：

組態	卡	權重	140 題	吐字中位數
Bonsai 2 PQ2_0,effort medium	1	7.2 GB	130	36.85 tok/s
Bonsai 2 PQ2_0，effort xhigh(預設)	1	7.2 GB	116	35.38 tok/s
Qwen3.8-27B Q8_0(去審查版)+ MTP，llama.cpp	2	29 GB	131	66.04 tok/s

差一題，在雜訊內。分項看，數學兩邊都是 30/30；MuSR 這種多步推理 Bonsai 反而多對兩題(15 對 13)；輸在 HumanEval+(36 對 38)和 GSM8K 一題。

換算下來是 Q8_0 的 99.2%。這跟官方的 98.2% 不是同一把尺：他們比的是 FP16、14 項、H100，我比的是 Q8_0、4 項、140 題。另外兩件事先講清楚：

• 我跑 140 題的是 7.2GB 的 PQ2_0，不是標題那包 5.9GB 的 PTQ1_0。兩包存的是同一組三值權重，能力應該一樣，但 PTQ1_0 我只量了速度。
• 這是兩套完整設定的比較。Q8_0 那邊開著 MTP、跑兩張卡，差距不能全算在量化頭上。

代價在最後一欄：一張卡的 Bonsai 吐字大約是兩張卡 Q8_0 的一半多一點。

2080 Ti 選 PQ2_0：大 1.2GB，decode 快兩成

直覺是檔案越小、要搬的資料越少、跑越快。在 2080 Ti 上不是這樣。同一支 fork、同一張卡、llama-bench 的結果，看 tg128(吐字速度)那一欄：

權重	檔案	pp512(讀 prompt)	tg128(吐字)	整卡 VRAM
PTQ1_0	5.95 GB	435 tok/s	32.71 tok/s	6,670 MiB
PQ2_0	7.21 GB	691 tok/s	39.12 tok/s	7,818 MiB
Q4_K(同底模)	15.66 GiB	634 tok/s	28.68 tok/s	16,330 MiB

(VRAM 是整張卡的讀數，含卡上 ComfyUI 佔的 346 MiB。)

最小的 PTQ1_0 最慢。PQ2_0 比它大 1.2GB，吐字快 19.6%；跟一般的 Q4_K 比，快 36%，VRAM 用不到一半。

為什麼更小反而更慢？把吐字速度乘上檔案大小，就是每秒實際從 VRAM 讀了多少資料，再除以 2080 Ti 的理論頻寬 616 GB/s:

Q4_K 把頻寬吃到 78%，它是被記憶體卡住的，所以檔案越小越快這條對它成立。Bonsai 兩包都遠遠沒吃滿，卡的是別的東西：每吐一個字，都要把三值解開、再對輸入做那道 Hadamard 轉換，這些是運算，不是搬資料。PTQ1_0 擠得越密，解包越費工，省下來的 17% 資料量抵不過多出來的解包工作。

官方模型卡自己也寫了同一件事：PTQ1_0 在 Ada 世代和 L4 上比較快(那些卡頻寬緊)，在 H100、A100 和 Blackwell 上輸給 PQ2_0，因為在這些卡上，batch 1 的 decode 卡在指令吞吐量和 kernel launch overhead(也就是運算本身，不是搬資料)。2080 Ti 屬於後面那一種。簡單講：Q4_K 是資料搬不完，Bonsai 是資料搬完了，還得花時間拆包。

#12 講過這張卡的另一面：低位元量化省的是 VRAM，不一定省時間。

怎麼跑：編 PrismML 的 fork，加一個 --reasoning-effort medium

你需要：

• 一張改裝 2080 Ti 22G。 短 context 峰值不到 8GB，原廠 11G 的卡推算也塞得下，但我沒測。
• PrismML 的 llama.cpp fork，branch prism。我用的是 commit 01041db，CUDA 12.4。
• 權重 Ternary-Bonsai-2-27B-PQ2_0.gguf，7.21GB。

編譯。重點是 CMAKE_CUDA_ARCHITECTURES=75，PQ2_0 和 PTQ1_0 的 kernel 在 sm_75 上編得過：

git clone --branch prism https://github.com/PrismML-Eng/llama.cpp prismml-llama.cpp
cd prismml-llama.cpp
cmake -B build-cuda75 -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=75 -DCMAKE_BUILD_TYPE=Release
cmake --build build-cuda75 -j 20 --target llama-server llama-bench
./build-cuda75/bin/llama-server --version   # fork 的 llama-bench 沒有 --version,要看 server

下載權重：

hf download prism-ml/Ternary-Bonsai-2-27B-gguf Ternary-Bonsai-2-27B-PQ2_0.gguf --local-dir ~/models/bonsai2

啟動。這就是跑出 130 題的那一行：

./build-cuda75/bin/llama-server \
  -m ~/models/bonsai2/Ternary-Bonsai-2-27B-PQ2_0.gguf \
  -ngl 99 -c 16384 -np 1 -fa on --jinja \
  --reasoning-effort medium \
  --host 0.0.0.0 --port 8080

取樣參數我是在每個請求裡帶(temperature 1.0、top_p 0.95、top_k 20、min_p 0)；官方說 GGUF 的 metadata 也存了同一組預設值。

會卡住你的兩件事：

1. 上游 llama.cpp 跑不了。 它不認得 PQ2_0 和 PTQ1_0，直接拒載。一定要用 fork。
2. reasoning effort 預設是 xhigh。 不改的話，140 題裡有 21 題想到 8192 token 用完還沒給答案，總分掉到 116。改 medium 截斷剩 1 題。官方模型卡也寫了 low 不支援，選了會跟 xhigh 差不多。

還有一件不是坑，但會浪費時間：有兩張卡也別想拆開跑。張量平行(-sm tensor)一載入就 assert，能跑的分層切法(-sm layer)只多 6~7%，原因在進階區。

還能更快：社群的 MTP 版，n=2 快 15–43%

官方的 Bonsai 2 沒有 MTP 頭(MTP 是 Qwen3.8 內建的草稿產生器，一次先猜幾個字、主模型一次驗完，猜中的就省下來)。GGUF 裡少了原版那組 nextn 張量，官方下載腳本也寫明沒有草稿模型。

社群有人把 MTP 頭接回去了：BoldingBuilds 的去審查 PQ2_0-MTP 版。同一張卡、temp 0、每種題目跑三發取中位數：

組態	寫程式	數學	散文
不開投機	38.9	38.2	37.8
MTP n=2	44.8	54.6	47.3
MTP n=3	40.3	53.1	41.8

看第二列：n=2 最快，n 再加上去反而變慢。啟動多加 --spec-type draft-mtp --spec-draft-n-max 2 就好，但 fork 要先上一個 15 行的 patch，不然 MTP 那條路跑不起來。patch 內容在進階區。

這一版的能力是 128/140，比原版少兩題，在雜訊內(MATH-500 少 3 題、MuSR 多 1 題)。它是去審查(abliterated)版。

262K context 一張卡塞得下，但 KV 要量化

Qwen3.8-27B 64 層裡有 48 層是線性注意力，狀態大小固定，不隨 context 變長。只有 16 層全注意力會存 KV，所以 262K 塞得進一張 22G。

./build-cuda75/bin/llama-server -m <PQ2_0-MTP.gguf> -ngl 99 \
  -c 262144 -ctk q8_0 -ctv q8_0 -np 1 -fa on --jinja \
  --spec-type draft-mtp --spec-draft-n-max 2

實際灌一段 15 萬 token 的輸入(去審查的 PQ2_0-MTP 版):

	prefill	decode	峰值 VRAM
不開投機	315.5 tok/s	13.1 tok/s	17,336 MiB
MTP n=2	297.3 tok/s	21.1 tok/s	19,432 MiB

塞得下，也跑得動，只是不快：15 萬 token 讀一次要 8 分鐘左右。KV 用 fp16 會爆(推算要 24GB 左右)，一定要 q8_0。長 context 下開 MTP,decode 從 13.1 拉到 21.1，多了 61%。

進階：除錯與實驗紀錄

不讀這節不影響使用。這裡是量測的細節、判錯過的地方、以及試過但沒採用的路，寫給想深追的人和 AI。

effort 那一刀：116 → 122 → 130

第一輪用 fork 的預設值(xhigh)跑，116/140。24 題失敗裡 21 題是 finish_reason=length:MuSR 15 題、HumanEval+ 4 題、MATH-500 2 題。MuSR 那 15 題全部是想到上限還沒寫答案。

第一個假設是上限太小。把那 21 題用 16384 token 重跑，只救回 6 題：

題庫	重跑	救回	16k 仍截斷	答錯
MATH-500	2	2	0	0
HumanEval+	4	2	2	0
MuSR	15	2	9	4

合起來是 122/140。截斷的推理不是鬼打牆(最後 5000 字沒有重複片段)，是想太多：兩選一的謀殺推理題，它在找段落首字母有沒有藏頭。

第二個假設是 effort。模型卡建議 medium，整份 140 題重跑，130/140，截斷從 21 題掉到 1 題。

bench	N	xhigh / 8192	medium / 8192	Q8_0 雙卡
GSM8K	50	49	49	50
MATH-500	30	28	30	30
MuSR	20	5	15	13
HumanEval+	40	34	36	38
合計	140	116	130	131

組別	截斷	輸出 token 中位數	p90	吐字中位數
xhigh / 8192	21	447	8192	35.38
medium / 8192	1	512	2326	36.85
Q8_0 雙卡	0	522	2437	66.04

中位數幾乎一樣，拉開的是 p90:xhigh 有一成的題目一路想到底。

怎麼確認 --reasoning-effort 真的有吃進去？ server log 沒有對應的那一行，/props 也沒有欄位。能用的指紋是 prompt 的 token 數：同一題 gsm8k/895，xhigh 算出 prompt_n=135，medium 是 prompt_n=93。這個旗標是餵給 chat template 的，整趟只有它會動到 prompt 的組法，少掉的 42 個 token 只能是它。

(同一題的推理長度三組是 286、209、270 字元，temperature 1.0 下單題取樣是雜訊，不能拿來當佐證。)

配對分歧(medium 對 Q8_0 雙卡)：都對 126、只有 Bonsai 對 4(musr/34、musr/212、musr/0、HumanEval/76)、只有 Q8_0 對 5(gsm8k/1059、musr/20、HumanEval/145、HumanEval/97、HumanEval/151)、都錯 5。

評分細節：GSM8K 取最後一個 Answer: 後面的數值；MATH-500 取最後一個完整的 \boxed{}，用 math_verify 0.9.0 判；MuSR 取最後的選項字母；HumanEval+ 用 evalplus 0.3.1，base 和 plus 測試都過才算對，每題外層 20 秒 timeout。抽樣種子 random.Random(20260920)。finish_reason=length 一律算錯，不重跑。

更小更慢：頻寬用量怎麼算，以及我量錯過的一次

換算方法：decode tok/s × 權重檔大小 = 每秒從 VRAM 讀出的資料量(每吐一個字，全部權重要讀一遍)；除以 2080 Ti 的理論頻寬(352-bit × 14 Gbps = 616 GB/s)。

權重	檔案	tg128	讀取量	佔峰值
Q4_K	16.8 GB	28.68	482 GB/s	78%
Bonsai PQ2_0	7.21 GB	39.12	282 GB/s	46%
Bonsai PTQ1_0	5.95 GB	32.71	195 GB/s	32%

(Q4_K 的 15.66 GiB 換成 GB 是 16.8。)

還有兩個獨立的證據指向同一邊：

• 投機解碼越開越慢。 DFlash2 在 Bonsai 上 n=3 → 5 → 8，吐字 46.3 → 42.5 → 34.7(寫程式那題)。8 月我把 Qwen3.8-27B 自己的 DFlash2 草稿配一般的 Q4 跑過同樣的掃描，n=2 到 n=5 一路往上爬(53.77 → 59.73)才持平。權重讀取本來就不是瓶頸，一次驗 n 個字，就要多做將近 n 倍的運算。
• 8 月那次的 Q4 對 Q8 對照(同底模、同一台機器)：純 decode，Q4 比 Q8 快 36%(37.79 對 27.80)。一般的 4 位元量化在這張卡上仍然被頻寬卡住，所以越小越快。

判錯過的一次。 我一開始想用「讀 prompt 速度 ÷ 吐字速度」當判斷依據，量出 Bonsai 讀 prompt 只有 21.2 tok/s，比吐字還慢，差點把它當成算力受限的鐵證寫進來。回頭看量測腳本才發現：我對同一段 4060 token 的提示連打三發取中位數，第二、第三發命中 prompt cache，只剩幾個 token 要算，每秒 token 數被固定開銷拖到很低，中位數剛好落在那兩發。反證很直接：server 啟動加三發請求 20 秒內就結束，真的是 21.2 tok/s 的話光一發就要 191 秒；llama-bench 的 pp512 是 691,15 萬 token 的長輸入也有 315。

如果你也要量 prefill:每一發換不同的輸入，或是關掉 cache。另外，這個比值本身也分不出 decode 卡在哪：prefill 是一次處理一大批 token，本來就偏吃算力，Bonsai 正確的 pp512 ÷ tg128 是 17.7 倍，照那個診斷，結論會是頻寬受限，跟上面三條證據相反。

DFlash2 在 Bonsai 上：跑得起來，只比 MTP 快 3–8%

ProCreations 做了 Bonsai 2 專用的 DFlash2 草稿(2.06GB 的 Q8_0 GGUF)。PrismML 的 fork 載不動它：

done_getting_tensors: wrong number of tensors; expected 81, got 58

這份草稿是新一代的 DFlash2，帶 conv 和 selector 模組，fork 的架構表裡沒有 DFLASH_ATTN_CONV_BASE/PROJ、DFLASH_FFN_CONV_BASE/PROJ、DFLASH_SELECTOR_HIDDEN/NEXT/PREV 這幾組。我也編過上游 llama.cpp 兩個 DFlash2 PR 的版本，更早就倒下了：上游不認得 PQ2_0。

能跑的是 ProCreations repo 裡附的 runtime 原始碼(runtime/prism-dflash2-source.tar.gz，已經上好 patch):

cmake -S <src>/llama -B <src>/llama/build -G "Unix Makefiles" \
  -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=75 -DCMAKE_BUILD_TYPE=Release \
  -DLLAMA_CURL=OFF -DLLAMA_BUILD_TESTS=OFF -DLLAMA_BUILD_EXAMPLES=OFF
cmake --build <src>/llama/build -j 12 --target llama-server llama-quantize

他們寫 CUDA 13.3，但 find_package(CUDAToolkit) 沒鎖版本，12.4 一樣編得過。沒有 ninja 就用 Unix Makefiles。

同一支 binary、同一張卡、temp 0、-c 16384，三種題目各跑三發取中位數(去審查版):

組態	寫程式	數學	散文	接受率	峰值 VRAM
MTP n=2	42.8	50.4	45.4	60.9%	9.3 GB
DFlash2 n=3	46.3	52.4	46.8	63.3%	11.5 GB
DFlash2 n=5	42.5	50.2	44.1	50.3%	11.8 GB
DFlash2 n=8	34.7	46.9	36.8	39.9%	12.3 GB
原版(非去審查)DFlash2 n=5	47.3	49.0	40.9	50.7%	11.8 GB

最好的 n=3 只比內建 MTP 快 3–8%，還要多 2.2GB VRAM 和一份外掛草稿。去審查對接受率幾乎沒影響(n=5 時 50.3% 對 50.7%)。我最後沒採用。

同一系列的 DFlash2 草稿，放在雙卡 FP8 的 Qwen3.8-27B 上結果完全不一樣，那是下一篇。差別就在上一節：那邊的權重是 29GB 的 FP8，真的被頻寬卡住。

兩張卡為什麼不能用 -sm tensor:Hadamard 區塊被切斷

先撞到的是：

llama_params_fit is not implemented for SPLIT_MODE_TENSOR

加 --fit off 繞過之後，撞上真正的那一個：

ggml-backend-meta.cpp:1086: GGML_ASSERT(split_state.ne[j] % div == 0) failed

我原本以為是混合注意力的問題，但 #14 那顆 Q8_0 跟 Bonsai 2 的 MTP 版架構完全相同(都是 qwen35、866 個張量、SSM 參數一字不差)，它就切得開。差別只在 Bonsai 的 GGUF 多了一組 metadata:

prism.hadamard.block_size    = 1024
prism.hadamard.transform     = normalized-sylvester-walsh-hadamard
prism.hadamard.axis          = input-last-dimension
prism.hadamard.weight_names  = 401 個權重

Hadamard 沿輸入的最後一維，每 1024 個切一塊來轉。隱藏層寬度 5120，切兩張卡各 2560，而 2560 ÷ 1024 = 2.5，等於把一塊從中間切開。split_state 是張量平行自己的記帳結構，它要求每張卡分到的寬度能被區塊整除。MTP 和 DFlash2 兩條路都擋，跟投機方式無關。

能跑的 -sm layer 是分層切：一張卡算前半層、另一張算後半層，同一時間只有一張在算。實測 DFlash2 n=3 是 49.0 / 55.4 / 50.1，MTP n=2 是 46.0 / 53.7 / 48.6，比單卡快 6–7%。多的是容量，不是算力。

MTP 版要上的 patch

fork 在 commit 01041db 的主計算圖會在查 embedding 之後把 Hadamard 轉回來，但 MTP 那張計算圖有自己的 embedding 查表，漏了這一步，於是 llama_verify_hadamard_graph 檢查不過，context 建不起來。補在 src/models/qwen35.cpp:

#include "llama-impl.h"   // llama_mul_mat_hadamard

// graph_mtp 裡，tok_embd = ggml_get_rows(...) 之後：
        // a Hadamard-latent embedding table stores rotated rows; restore the
        // primal basis right after the lookup: h = s * (H z). The main graph does
        // this in llm_graph_context::build_inp_embd(); this graph has its own lookup
        // and must do the same or llama_verify_hadamard_graph rejects the context.
        if (hadamard_inverses) {
            const auto it = hadamard_inverses->find(tok_embd_w);
            if (it != hadamard_inverses->end()) {
                tok_embd = llama_mul_mat_hadamard(ctx0, tok_embd, it->second.rot);
                if (it->second.signs) {
                    tok_embd = ggml_mul(ctx0, tok_embd, it->second.signs);
                }
            }
        }

打完照原本的方式編，--version 還是顯示 commit 01041db99，記得自己分清楚哪一支有上 patch。

上一代 Bonsai v1 的 dspark 草稿：中文反而變慢

Bonsai 2 沒有草稿模型，上一代 Ternary-Bonsai-27B(v1)有一個 dspark 草稿(DFlash 家族，上游 llama.cpp 2026-07-28 已合併)。bf16 7.29GB，轉檔去掉共用張量、量化成 Q4_0 後剩 632MB。同 server 同卡、temp 0、三發中位數：

題目	不開投機	dspark	倍數	接受率
英文 quicksort	41.8	53.3	1.28×	0.57
繁中 300 字說明	41.2	36.9	0.90×	0.31
英文追車算術	40.7	63.9	1.57×	0.74

官方寫「無損 1.34 倍」，我三題平均 1.25 倍，中文是負的。另外 temp 0 下開不開投機的推理在約 600 token 處分岔(批次驗證的數值差讓 argmax 翻面)，在 llama.cpp 的實作上「無損」不是逐字相同。免草稿的 ngram-simple 也試了：三題正式請求一次都沒有提出草稿，1.00 倍，思考中的散文沒有重複片段可以抓。

還沒做的

• 5.95GB 的 PTQ1_0 沒跑 140 題。照理跟 PQ2_0 同分，但沒量就是沒量。
• 原廠 11G 的 2080 Ti 沒測。
• 視覺(mmproj)沒測。
• 早期冒煙測試裡，繁中回答漏了一個簡體字、推理全是簡體。要拿同一題打未量化的 Qwen3.8-27B 才能判斷是不是量化造成的，還沒做。

---

同系列：#14 兩張改裝 2080 Ti 玩 tensor parallel · #12 為什麼 4-bit 在 2080 Ti 上快不起來 · #20 FastLLM + DFlash2 雙卡