16GB 显卡跑 Qwen3.8-27B，只要 7 GB：三进制模型 Bonsai 2 部署手记与双格式实测

本文目录

第一步：获取 PrismML 的 llama.cpp fork
第二步：编译（Windows 两个坑）
第三步：下载模型
第四步：启动脚本的两处变化
速度：PQ2\0 完胜
能力：同一棵树的两个盒子
裁决

> Qwen3.8-27B 是个 27B 级别的新模型，FP16 要 54 GB 显存，正常人家里的显卡想都别想。而 PrismML 用三进制权重（每个权重只取 -1、0、+1）把它压到了 **7.21 GB**——一张 16GB 的 RTX 5060 Ti 不仅装得下，还能把 262K 上下文开满，智能保留官方宣称 98.2%。这棵树叫 Ternary-Bonsai-2-27B（盆栽二代，一代是 7 月基于 Qwen3.6-27B 的那棵）。这篇博客从零讲清楚它是什么、怎么装，并替大家在它的两种打包格式（PQ2\_0 / PTQ1\_0）之间做个了断。

主角介绍：7 GB 的 27B 是怎么炼成的

Ternary-Bonsai-2-27B 是 PrismML 在 2026 年 9 月放出的二代盆栽。它的核心卖点一句话就能说完：Qwen3.8-27B 的能力，1/9 的体积，消费级显卡本地跑。拆开看：

底座：Qwen3.8-27B，架构不变——混合注意力（约 75% 线性注意力 + 25% 全注意力）、64 层、262K 上下文、0.46B 视觉塔。
体重管理：三进制 g128 权重（每个权重 ∈ {-1, 0, +1}，每 128 个共享一个 FP16 缩放），真实位宽 1.72 bpw，理想体积 5.8 GB，约为 FP16 的 1/9.3。这次连 embedding 和 LM head 都是三进制，没有"高精度后门"。
新花样：Hadamard 旋转。权重在离线阶段做了分块 Hadamard 变换，运行时对激活值做匹配变换。模型卡里写得很硬气：运行时要么会做这个变换，要么拒绝加载——原版 llama.cpp 会直接拒载 PQ2_0/PTQ1_0，老 fork 装新模型则会"不报警地输出垃圾"。配套运行时不是可选项，是必需品。
脑子：官方 14 项 thinking 模式基准平均 84.78，保留 FP16 约 98.2% 的智能；数学 96.57 与全精度差不到半分，编码 89.42 与基线持平。作为对照，传统 IQ2_XXS 只有 72.59——低比特领域通常"位宽砍半、智商清零"，这棵树是个例外。
两种打包：PTQ1_0（密集三值，1.75 bpw，5.95 GB）和 PQ2_0（每个三值占一个 2-bit 槽位，2.13 bpw，7.21 GB）。同样的权重，不同的装盒方式——这就是本文后半场的两位选手。
证件：Apache 2.0，随便用。

安装：从编译到跑起来

第一步：获取 PrismML 的 llama.cpp fork

前面说过，原版 llama.cpp 不认识这种新格式，必须用官方 fork。新读者直接克隆：

git <span>clone</span> https://github.com/PrismML-Eng/llama.cpp

如果你像我一样装过一代时的旧版 fork，光 git pull 不够——7 月的旧版本源码里连 PQ2_0 四个字母都搜不到，README 里还写着"PQ2_0: planned future fork format, not supported anywhere yet"。三个月过去，未来已来，对齐到最新即可：

<span>cd</span> llama.cpp
git fetch origin
git reset --hard origin/prism   <span># 本地无改动，直接对齐上游最新（本文用的是 b10709）</span>

第二步：编译（Windows 两个坑）

编译用 VS 2022 BuildTools + CMake + Ninja。50 系显卡（Blackwell,sm_120）要显式指定 CMAKE_CUDA_ARCHITECTURES=120——漏了它编译不报错、运行才玄学。另外这次冒出两个新坑：

坑一：上游的测试文件在 Windows 上编译不过。 tests/test-dspark-forward.cpp 用了 POSIX 的 setenv/unsetenv，MSVC 直接甩一脸 error C3861。我们又不跑它的测试，跳过即可：

cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=120 -DLLAMA_BUILD_TESTS=OFF
cmake --build build -j 8

坑二：--flash-attn 必须带值。 它的现代写法是 --flash-attn on|off|auto。如果你不写值，参数解析器会把排在后面的参数（比如 --temp）抓过来当它的值吃掉，报一句莫名其妙的 unknown value for --flash-attn: '--temp'。老老实实写 on 就没事。

第三步：下载模型

<span># 主模型二选一（对比测试我两个都下了），mmproj 必下</span>
hf download prism-ml/Ternary-Bonsai-2-27B-gguf Ternary-Bonsai-2-27B-PQ2_0.gguf --local-dir .
hf download prism-ml/Ternary-Bonsai-2-27B-gguf Ternary-Bonsai-2-27B-mmproj-Q8_0.gguf --local-dir .

第四步：启动脚本的两处变化

启动脚本（start_server.bat）有两个点值得展开说说：

chat template 直接用模型内置的，不要外挂文件。 解释一下背景：llama-server 用 --jinja 渲染对话模板，模板可以来自 GGUF 内置，也可以用 --chat-template-file 指定外部文件。一代的内置模板有条铁律——system 消息必须排在最前，否则直接抛异常，而服务器生成工具调用解析器时免不了要试探各种渲染，两边一碰就 400，当时只能把模板导出成外部文件、改掉这两条"殉爆"规则才搞定。二代的内置模板已经成熟（还新增了 reasoning_effort 等参数），这些折腾都不需要了，直接 --jinja 读内置的，少一个维护点。
采样参数跟着模型卡走。 二代是默认开启思考的推理模型，官方推荐 thinking 模式用 temp 1.0 / top-p 0.95 / top-k 20（非思考模式才是 temp 0.7 / top-p 0.8），照抄即可。

llama-server.exe -m Ternary-Bonsai-2-27B-PQ2_0.gguf --mmproj Ternary-Bonsai-2-27B-mmproj-Q8_0.gguf ^
  -ngl 99 -c 0 --fit on --cache-type-k q4_0 --cache-type-v q4_0 --flash-attn on ^
  --temp 1.0 --top-p 0.95 --top-k 20 --jinja --host 0.0.0.0 --port 8080

服务器 10 秒完成加载，262144 上下文直接拉满。日志里有一条无害的警告值得知道：--fit on 本来负责按剩余显存自动调整参数，但你显式写了 -ngl 99（全部层上 GPU）之后它就罢工了（"n_gpu_layers already set by user, abort"）——模型本来就装得下，当它不存在即可。

正赛：PQ2_0 vs PTQ1_0

官方吞吐表里没有 5060 Ti，只说了"Blackwell 卡上 PQ2_0 更快，Ada 代和 L4 上 PTQ1_0 反超"。纸面不如实测，两个文件都下下来，同机同参数跑一轮。

速度：PQ2_0 完胜

环境：RTX 5060 Ti 16GB，fork b10709，-ngl 99 -fa on，llama-bench 默认测试：

指标	PQ2\_0 (7.21 GB)	PTQ1\_0 (5.95 GB)	差距
pp512（提示处理）	976.9 t/s	463.2 t/s	PQ2\_0 快 2.1 倍
tg128（文字生成）	47.9 t/s	43.7 t/s	PQ2\_0 快 9.6%
服务器实测生成	~45.8 t/s	~41.4 t/s	PQ2\_0 快约 11%
最大上下文	262144（拉满）	262144（拉满）	持平
权重显存占用	6.70 GiB	5.53 GiB	PTQ1\_0 省 1.2 GiB

生成阶段的差距（约 10%）符合"PTQ1_0 少搬 17% 权重数据、但解包更费指令"的官方解释——5060 Ti 的显存带宽还没穷到那份上，解包开销先显形了。而提示处理是纯粹的计算密集型活，PQ2_0 的 2-bit 槽位解包便宜，直接打出 2.1 倍的碾压局。长文档、多轮对话、挂 Claude Code 这种 prefill 大户，差距会非常直观。

能力：同一棵树的两个盒子

两者装的是同一套三值权重，理论上能力应该一致。用同一套题（相同采样参数，reasoning_effort=medium）各问一遍，覆盖六个领域：

题目	PQ2\_0	PTQ1\_0
数学：分部积分求 ∫₀^π x·sinx dx	正确得 π，步骤规范	正确得 π，步骤规范
逻辑：三个贴错标签的盒子	策略正确，推理完整	策略正确，推理完整
编程：O(1) LRU 缓存	哈希表+双向链表，可直接运行	哈希表+双向链表，可直接运行
科学：瑞利散射解释天空颜色	正确，"蓝光散射约 6 倍于红光"接近真实值	正确，但"十几倍甚至数十倍"偏大，一处 LaTeX 没闭合
写作：秋日黄昏的旧车站（散文）	意象凝练，885 tokens 完稿	通顺但略散，1208 tokens 完稿
知识：CRISPR-Cas9 原理+伦理	正确覆盖全流程	正确覆盖全流程

最说明问题的一个细节：两个模型都把"贺建奎"写成了"贺建轩"——同样的权重，同样的错字，连犯错都一模一样。写作和个别表述的差异属于采样随机性，不是能力差距。

顺带一个使用提示：这模型思考起来很舍得花 token，写作题给 700 max_tokens 时，两家都把预算全用在打草稿上、正文一个字没吐。调用时 max_tokens 要给思考留足余量，或者用 chat_template_kwargs: {"reasoning_effort": "medium"} 收敛一点。

裁决

5060 Ti（以及所有 Blackwell 卡）：无脑 PQ2_0。 生成快 10%，prefill 快一倍多，能力完全一样，16GB 显存两种都装得下、上下文都能开满——PTQ1_0 省的那 1.2 GB 在这张卡上毫无存在感。PTQ1_0 的主场是老架构和极端带宽受限的环境（官方数据里 4090、L4 上它反超），不在我家。测完我就把 PTQ1_0 删了，7 GB 也是 disk 空间。

结尾

从零部署的全部成本：一次编译（外加绕开一个 POSIX 测试文件）、一次下载、一个启动脚本；从一代升级更省，脚本只改两行。换来的是 98.2% 的 FP16 智能保留度和 47.9 t/s 的本地 27B。

二代目，正式上岗。

环境：RTX 5060 Ti 16GB / PrismML llama.cpp fork b10709 / Ternary-Bonsai-2-27B PQ2_0 + PTQ1_0 / Windows + CUDA (sm_120)

参考资料：Ternary-Bonsai-2-27B-gguf · PrismML llama.cpp fork · Bonsai-demo（官方运行指南）