BONSAI 2（27B 三值模型）项目评估与本机适配分析

⚠️ 本文已有 3 处结论被后续实测推翻，请以实测篇为准

实测与部署报告：2026-09-19-Bonsai2-27B实测与部署报告.md（同目录）

本文原说法	实测结果
Bonsai 2 支持 dspark 投机解码（1.8–2.4×）	❌ Bonsai 2 没有 drafter，该能力属上一代 Ternary-Bonsai 27B
"建议两个 packing 都压一次再定"	✅ PQ2_0 明确更优：提示处理快 2.16×、生成快 10%，代价 +1.1 GiB
"C 数学推理答案截断"	❌ 答案完整正确，是我读文件时的截断失误

本文保留其价值在于：厂商口径核实、第三方争议、bpw 四口径辨析、坑清单 —— 这些未被推翻。

评估日期：2026-09-19 ｜ 评估对象：Prism ML Bonsai 2 27B（2026-09-17 发布） 目标环境：GPU 机 192.168.31.31（RTX 5060 Ti 16GB，sm_120，CUDA 13.x 体系） 本报告所有"已核实"项都注明核实方式；所有"估算"项都显式标注，未实测的部分不冒充实测。

---

0. 一句话结论

Bonsai 2 27B 是把「你正在用的 Qwen3.8-27B」（Ridge / KO-Ridge 的同一个底座）用三值量化 + 量化感知训练压到 5.95 GB 的模型，厂商自报保留 98.2% 能力。

对你三件最有价值的事：

1. 质量档位 ≈ 你现在的 Ridge（实测：5 组中文题 4 好 1 差，与 Ridge 完全同型），体积只有一半（6.71 GiB vs 11.73 GiB）。
2. 16GB 卡上能开到 262K 满上下文（实测显存 13.5 GiB），而你现在的 Ridge-long 是 128K / 15.5 GiB。
3. ⚠️ LM Studio 跑不了它，必须用它家 fork 的 llama.cpp —— 这恰好跟你 Ridge 的「systemd + 裸 llama.cpp」那套路子一致。

我已实测核实的关键一点：官方预编译 CUDA 包就是给 Blackwell sm_120 编的（架构清单里只有 sm_120/compute_120），你的 5060 Ti 属于原生支持，不需要自己编译。

建议（已实测修正）：可以部署，已部署为 llama-bonsai2 服务（262K / PQ2_0）。实测 tg128 49.69 tok/s、pp512 1000.92 tok/s、显存 13.5 GiB；质量与 Ridge 基本无差距。但不建议立刻替换 Ridge —— Ridge 靠 MTP 峰值更快（56.6 vs 48）。建议作为"长上下文 / 省显存"的第二档。详见实测篇。

---

1. 项目是什么

项	内容
发布方	Prism ML（prismml.com），2026-09-17 发布
底座	Qwen3.8-27B（混合注意力：约 75% 线性 + 25% 全注意力，SwiGLU / RoPE / RMSNorm）——架构完全未改
做了什么	只替换语言模型矩阵权重的数值表示（非重新训练底座），并配套写了低比特内核
权重表示	三值 g128：每个权重取 {−1, 0, +1}，每 128 个权重共享一个 FP16 scale
关键机制	权重存储在 Hadamard（Walsh–Hadamard 块 1024）旋转基下，运行时对激活做匹配变换；旋转声明在文件元数据里，运行时不做匹配变换就拒绝加载
参数	27.36B = 24.35B 语言主干（64 层）+ 2.54B embedding/LM head + 0.46B 视觉塔（27 层）
上下文	262,144 token
多模态	是，视觉塔是未量化的原厂 Qwen 塔，单独打包（mmproj）
许可	Apache 2.0
运行库	llama.cpp fork（CUDA/Metal）、MLX fork（Apple）、mlx-swift（iOS）
热度（HF API 实测）	下载 1,516,960 次 / likes 1,045

为什么必须用它的 fork：Hadamard 激活变换还没进上游（PR ggml-org/llama.cpp#27779 仍 open）。

---

2. 硬指标核实（我独立查的，不是抄宣传）

用 HuggingFace API（prism-ml/Ternary-Bonsai-2-27B-gguf）核到的真实文件与体积：

文件	HF API 实测	说明
Ternary-Bonsai-2-27B-F16.gguf	53.808 GB	FP16 参考
Ternary-Bonsai-2-27B-PQ2_0.gguf	7.206 GB	2bit 槽位 packing，prompt 处理更快（demo 默认下载这个）
Ternary-Bonsai-2-27B-PTQ1_0.gguf	5.947 GB	三值密集 packing，最小
Ternary-Bonsai-2-27B-mmproj-Q8_0.gguf	0.629 GB	视觉投影器（要图才加载）
Ternary-Bonsai-2-27B-mmproj-BF16.gguf	0.931 GB	视觉投影器参考版

• 实测压缩比：53.808 / 5.947 = 9.05×（与厂商"约 9 倍"吻合；体积是事实，可核实）
• 换算成 GiB（lms ls 那种十进制口径的坑你已经在 07 目录踩过）：PTQ1_0 = 5.54 GiB、PQ2_0 = 6.71 GiB、mmproj-Q8_0 = 0.586 GiB

⚠️ 四个 bpw 口径，别混用（第三方拆解得很清楚）

数字	含义	是否有对应文件
1.585	一个三值符号的信息量 log₂3	格式属性，无文件
1.71	只算三值张量（+ scale 摊销）	无文件
1.72	全语言模型（含 0.0976% 保持高精度的张量），理想 5.80 GB	目标值，非文件
1.76	实际出货的 PTQ1_0 GGUF（5.93–5.95 GB）	✅ 就是你下的文件

（模型卡写 1.75/5.95 GB，白皮书写 1.76/5.93 GB，是同一文件的不同精度表述，不是矛盾。）

---

3. 质量怎么读：98.2% 这个数字的真实含义

3.1 厂商口径（14 项 thinking 模式，EvalScope + vLLM on H100）

变体	真实 bpw	体积	平均分	vs FP16
Qwen3.8-27B FP16	16.0	54 GB	86.32	100%
Qwen3.8-27B UD-Q4_K_XL（"4bit"）	5.2	17.6 GB	85.18	98.7%
Qwen3.8-27B IQ2_XXS（"2bit"）	2.8	9.4 GB	72.59	84.1%
Bonsai 2 27B	1.72	5.9 GB	84.78	98.2%

3.2 形状比平均值重要（分项得失）

类别	FP16	Bonsai 2	差
指令跟随	81.25	82.66	+1.41 ✅ 唯一反超
数学	97.06	96.57	−0.49（基本持平）
编码	89.07	89.42	+0.35（持平）
知识 & 推理	85.55	79.86	−5.69 ⚠️
视觉	71.36	66.19	−5.17 ⚠️ 单项最大跌幅
Agent / 工具调用	76.74	74.92	−1.82

3.3 必须知道的三条保留意见

1. 长程工程能力是真短板（厂商自己承认）：Terminal-Bench 2.1 52.8 vs 69.7、SWE-bench Verified 60.8 vs 80.6 —— 都只有全精度的约 3/4。聚合的 98.2% 掩盖了这一点。
2. 所有数字都是厂商在自家 suite、自家 harness 上测的，第三方尚未复现。第三方分析原话大意：能独立核实的是"文件 5.947 GB"，"98.2%"是厂商测量值，不是关于模型的事实。
3. 视觉塔本身没被量化，掉分掉在"读视觉输出的语言模型"这一侧。

3.4 最有说服力的一点：它确实打赢了传统低比特量化

	bpw	体积	平均
Bonsai 2 27B	1.76	5.93 GB	84.78
Qwen3.8-27B IQ2_XXS	2.8	9.4 GB	72.59

更小且更强（小 1.23×、高 12 分）。而且 IQ2_XXS 的崩坏是选择性的：MMLU-Redux 还有 88.93 看着没事，AIME26 掉到 57.5、LiveCodeBench 掉到 56.4 —— 这解释了为什么"我随便聊了聊感觉还行"不能当证据。

3.5 对你的用途意味着什么

你的实际场景（小说创作、报告/文档写作、视频提示词、合同审查、日常问答、识图）大多是中短程语言 + 推理任务：

• 吃不到短板：长程 agentic（SWE-bench / Terminal-Bench）和视觉细节（OCR）基本用不上
• 吃到强项：数学/编码/指令跟随与 Q4 档持平
• 结论：在你的用法下，它大概率表现得比那个 84.78 的平均分看起来更好

---

4. 能不能在你机器上跑（关键核实）

4.1 ✅ 预编译包 = sm_120 专用（我已下载实测）

我把 llama-prism-b10709-9a9394a-bin-linux-cuda-12.8-x64.tar.gz（167 MB，43 秒下完）拉下来扫了 libggml-cuda.so：

=== GPU 架构清单 ===
compute_120 sm_120          ← 只有这两个，没有 sm_89/sm_90

• ✅ 你的 RTX 5060 Ti（Blackwell GB206 = sm_120）是原生目标架构，不用自己编译
• 二进制版本：0.2.0-dev (build 10709, commit 9a9394a89)，GNU 11.4.0 / Linux x86_64
• ✅ fork 专属内核都在：PTQ1_0、PQ2_0、hadamard(37 处)、dspark(145 处)（投机解码）
• ✅ 工具齐全：llama-cli / llama-server / llama-bench / llama-mtmd-cli（多模态）/ llama-speculative-simple
• ⚠️ 不自带 CUDA 运行时，依赖系统提供对应大版本的 .so（详见下一节两个包的实测对比）

4.2 两个官方 CUDA 包我都下载实测了，结果不同

	CUDA 12.8 版（159.5 MB）	CUDA 13.3 版（139.6 MB）
内含 GPU 架构（strings 实测）	仅 sm_120 + compute_120	sm_86 / sm_89 / sm_120 / sm_121 + compute_121
你的 5060 Ti（sm_120）	✅ 原生专用	✅ 支持
需要的系统 CUDA 运行时	libcudart.so.12、libcublas.so.12	libcudart.so.13、libcublas.so.13
在 DSH 机上的解析结果	✅ 解析到 /lib/x86_64-linux-gnu/libcudart.so.12	❌ not found（本机只有 12.x 运行时）
版本	0.2.0-dev build 10709 commit 9a9394a	同

两个包都不自带 CUDA 运行时，都要系统提供对应大版本的 .so。

4.2.1 推荐跑法（按推荐度）

方案	优点	缺点/前置
① CUDA 13.3 预编译包	✅ 已验证含 sm_120；架构覆盖面广；匹配你 GPU 机的 CUDA 13.x 体系	需要 libcudart.so.13/libcublas.so.13。你机器上 torch 是 cu130，其 venv 里自带一份 nvidia/cu13/lib —— 用你 H3 项目里那套 LD_LIBRARY_PATH 注入即可（restart_comfy.sh 里已有现成写法）
② CUDA 12.8 预编译包	✅ 已验证 sm_120 且是唯一为 Blackwell 专门编译的包（只有 sm_120，理论上最快/最纯）	需要 .so.12；GPU 机是 CUDA 13 体系，可能要额外装 CUDA 12 runtime
③ 自己编译 fork	完全匹配本机、无运行时怪问题；你已经编过两次（Ridge 用旧构建、KO 用 ~/llama.cpp-new），约 7 分钟	最慢；官方脚本检测到 <16GB 显存会自动降 -j 2

实操建议：先试 ①，起不来再换 ②。两个包我都已备好（见附录），可直接 scp 到 GPU 机，省掉 GitHub 下载与代理折腾。

4.3 16GB 显存预算表（我按官方 KV 口径算的）

官方口径：FP16 KV = 64 KiB/token；4bit KV（BONSAI_KV4=1）≈ 18 KiB/token；固定开销 ≈ 1.2 GiB。

配置	权重	KV	开销	合计	16GB 卡（可用≈15.4 GiB）
PTQ1_0 + 4bit KV + 262K 满上下文	5.54	4.5	1.2	11.2 GiB	✅ 宽裕
PQ2_0 + 4bit KV + 262K 满上下文	6.71	4.5	1.2	12.4 GiB	✅ 可行
PTQ1_0 + 4bit KV + 128K + 视觉投影器	5.54	2.2	1.2+0.59	9.5 GiB	✅ 宽裕
PTQ1_0 + FP16 KV + 128K	5.54	8.0	1.2	14.7 GiB	⚠️ 极限，建议配 4bit KV
PQ2_0 + FP16 KV + 100K	6.71	6.25	1.2	14.2 GiB	⚠️ 极限

对照现状：Ridge-long = 128K + 视觉在 CPU = 15.5 GiB。 → Bonsai 2 用一半显存就能开到 2 倍上下文，这是它对你最实在的价值。

4.4 速度预估（⚠️ 纯估算，必须实测）

依据 fork 官方 llama-bench 表：RTX 4090（1008 GB/s）PTQ1_0 91.1 / PQ2_0 81.2 tok/s。 5060 Ti 16GB 带宽 448 GB/s ≈ 4090 的 44%；batch-1 decode 是带宽瓶颈，按带宽线性缩放：

• PTQ1_0 ≈ 36–40 tok/s、PQ2_0 ≈ 32–36 tok/s（估算）
• ⚠️ 开 dspark 投机解码（CUDA 上 L40S 实测 1.8–2.4×）→ 有望 60–90 tok/s 【已更正】Bonsai 2 没有配套 drafter，此路不通，实测 45–50 tok/s 即上限（见实测篇）
• 对照：你 Ridge 现在是 53.9 tok/s（实测）

⚠️ 注意一个反直觉点：官方表里 Blackwell / Hopper 上 PQ2_0 反超 PTQ1_0（5090：129.9 vs 120.5），而 PTQ1_0 只在 Ada/L4 上更快。你是 Blackwell → PQ2_0 可能反而更快，但 PTQ1_0 省 1.3 GB。【已实测更正】PQ2_0 确认更优：pp512 1000.9 vs 464.2 t/s（2.16×）、tg128 49.69 vs 45.12 t/s（+10%），代价 +1.1 GiB 显存 —— 结论：用 PQ2_0。

---

5. 它和你现有栈的关系（最关键的一节）

	Ridge（现役）	KO-Ridge（无审核）	Bonsai 2 PTQ1_0	Bonsai 2 PQ2_0
底座	Qwen3.8-27B	Qwen3.8-27B	Qwen3.8-27B（同源！）	同
体积（磁盘）	11.73 GiB	11.73 GiB	5.54 GiB	6.71 GiB
量化	Ridge 3.7bpw 混合	KO 3.7bpw abliterated	三值 1.76bpw	三值 2.16bpw
实测质量	PPL 7.82（BF16 7.15，差 9.3%）	同源	厂商称 ≈ Q4_K_XL	同
上下文	64K / 128K	128K	262K	262K
视觉	✅（long 档 CPU 编码 26.7s）	❌（作者档 --no-mmproj）	✅（mmproj 0.59 GiB）	✅
投机解码	MTP（接受率 0.78）	DFlash2（接受率 0.31）	❌ 无（官方未发布 drafter）【已更正】	同
运行框架	旧 llama.cpp 构建	~/llama.cpp-new	fork 专用（第三套）	同
端口	8080	8080	需另开（如 8081）	同
自启	disabled	disabled	建议同策略	同

定位建议

1. 最有价值的角色 = "小显存 + 超长上下文"的备选档：显存占用砍半，上下文从 128K 抬到 262K，且保留视觉。适合长文档分析、整库代码阅读、超长对话。
2. 不建议立刻替换 Ridge：Ridge 的 53.9 tok/s、视觉 8.34s、MTP 接受率都是你实测过的；Bonsai 2 全是纸面数字。
3. 值得花 20–30 分钟实测一次：如果实测站得住，它就是你 16GB 卡上最划算的 27B（质量≈Q4 档、体积 1/3、上下文 2×）。
4. KO-Ridge 的"无审核"定位，官方 Bonsai 2 替代不了。但 OrcaRouter 已发布运行时 abliteration 版（不改权重、α 可调、129 个干预点、自称 AdvBench 拒答 99%→6%），技术路线值得关注——不过它自己也声明"删掉拒绝方向不等于输出安全/正确"，且方向是从 BF16 底座估的，跨量化迁移未完全验证。

---

6. 落地路径（等 GPU 机开机即可执行）

# ── GPU 机 192.168.31.31 ──────────────────────────────
mkdir -p ~/bonsai2 && cd ~/bonsai2

# 1) 取 fork 二进制（推荐 CUDA 13.3 版，匹配本机 CUDA 13 体系）
curl -LO https://github.com/PrismML-Eng/llama.cpp/releases/download/prism-b10709-9a9394a/\
llama-prism-b10709-9a9394a-bin-linux-cuda-13.3-x64.tar.gz
tar xzf llama-prism-b10709-9a9394a-bin-linux-cuda-13.3-x64.tar.gz
mv llama-prism-b10709-9a9394a bin

# 2) 下模型（HF 官方域名不通，走镜像）
export HF_ENDPOINT=https://hf-mirror.com
#   二选一：PTQ1_0（5.95GB，最小）或 PQ2_0（7.21GB，prompt 更快）
#   + mmproj 0.63GB（要视觉才下）

# 3) 起服务（换端口 8081，避开 ridge 的 8080；KV 压 4bit 才能吃满 262K）
~/bonsai2/bin/llama-server \
  -m ~/bonsai2/models/Ternary-Bonsai-2-27B-PQ2_0.gguf \
  --mmproj ~/bonsai2/models/Ternary-Bonsai-2-27B-mmproj-Q8_0.gguf \
  -ngl 99 -fa on -c 262144 -ctk q4_0 -ctv q4_0 \
  --jinja --host 0.0.0.0 --port 8081

# 4) 压速度（两个 packing 都测，再决定）
~/bonsai2/bin/llama-bench -m .../PTQ1_0.gguf -ngl 99 -fa on -p 512 -n 128
~/bonsai2/bin/llama-bench -m .../PQ2_0.gguf  -ngl 99 -fa on -p 512 -n 128

采样参数（模型卡推荐，已写进 GGUF 元数据）：thinking 模式 temp=1.0, top_p=0.95, top_k=20；非 thinking temp=0.7, top_p=0.80, top_k=20, presence_penalty=1.5。 思考档位：默认 xhigh；low 不被支持（选了也接近 xhigh）；要短回答用 medium 或 --reasoning-budget N。

---

7. 坑清单（按踩到概率排序）

1. 🔴 LM Studio 跑不了 Bonsai 2。它需要 fork 的 Hadamard 激活变换，上游 PR #27779 还没合。LM Studio 自带自己那份 llama.cpp runtime → 你这套「lms load + 注册表 + JIT」机制完全用不上，必须起独立 llama-server。（你 Ridge/KO 已经是这个模式，不算新负担。）
2. 🔴 千万别喂给 stock llama.cpp。PTQ1_0/PQ2_0 会被拒（安全失败）；但 Q2_0 那档不报错、直接输出流利乱码（危险失败）。所以别下 Ternary-Bonsai-2-27B-gguf-dev 仓库里那个 Q2_0-prism-fork-required.gguf。
3. CUDA 运行时错配：12.8 版包要 libcublas.so.12，你 GPU 机是 CUDA 13.x → 用 13.3 版包（或补 12.x 运行时）。
4. 端口冲突：ridge/ko-ridge 都占 8080；新服务用 8081，并纳入你 switch-llm.sh 那套互斥逻辑。
5. 别用 -c 0：那会用满 262K 训练上下文直接 OOM（官方 FAQ 明确点过）。显式给数字。
6. 它是思考模型，默认思考链很长（跟 KO-Ridge 一个坑）→ 客户端 max_tokens 要留够，否则返回空正文；或 --reasoning-budget 2048。
7. 两个 packing 不是简单优劣：Ada/L4 上 PTQ1_0 快，Hopper/Blackwell 上 PQ2_0 快。你是 Blackwell → 【已实测更正】PQ2_0 快 2.16×（pp512）/ +10%（tg128），选 PQ2_0。
8. dspark 投机解码有反作用：会关闭跨请求前缀缓存并强制 -np 1 【已更正】Bonsai 2 无 drafter，该条不适用（上一代 Ternary-Bonsai 27B 才有此权衡）。
9. 磁盘：GPU 机已 ~89% 满、~/Downloads 还有 ~30 GiB 重复 GGUF；这次至少再占 6–7 GB。
10. MLX 包在 N 卡上没用：Ternary-Bonsai-2-27B-mlx-2bit 是 Apple Silicon 专用，其量化 matmul 没有 CUDA 实现，别下错。

---

8. 本次未做 / 待办

【2026-09-19 23:00 更新】下列待办已全部完成，结果见同目录 2026-09-19-Bonsai2-27B实测与部署报告.md。

• ✅ 本机零实测 → 已在 GPU 机实测（当时 22:00 探测为关机，后用户开机）
• ✅ 用 llama-bench 实测两个 packing → PTQ1_0 45.12 / PQ2_0 49.69 tok/s；pp512 464 / 1001 t/s
• ✅ 实测 262K + 4bit KV 显存 → PTQ1_0 12.4 GiB / PQ2_0 13.5 GiB（我原先估算的 11.2 GiB 偏乐观）
• ✅ 同提示词对比 Ridge → 质量基本无差距；唯一共性问题（D 指令跟随）三者全失败，与量化无关
• ⛔ 实测 dspark 加速比 → 不适用，Bonsai 2 无 drafter
• ✅ mmproj 在 GPU 上工作正常（视觉通路已验证）
• ✅ 已部署为 llama-bonsai2 systemd 服务（PQ2_0 / 262K / 端口 8080，纳入 switch-llm.sh）
• 两个预编译包已归档到同目录 fork-binaries/

---

附录：来源与核实方式

来源	链接	用途
HF 模型卡	prism-ml/Ternary-Bonsai-2-27B-gguf	规格、17 项基准、采样参数
HF API（实测）	hf-mirror.com/api/models/prism-ml/Ternary-Bonsai-2-27B-gguf	文件体积、下载量
Bonsai-demo	PrismML-Eng/Bonsai-demo	README / AGENTS.md / MODEL-FORMATS.md（运行方式与调参）
fork 发布页	releases/tag/prism-b10709-9a9394a	平台包清单
fork 二进制（实测）	linux-cuda-12.8-x64.tar.gz	扫出 sm_120/compute_120 + 内核存在性
第三方拆解	orcarouter.ai/blog/ternary-bonsai-2-27b	bpw 四口径、分项得失、20 项 suite、abliteration 技术
官方公告	prismml.com/news	发布时间
历史 issue	ggml-org/llama.cpp#25727	上一代在 LM Studio/CUDA 的坑（已闭）

本次归档的本地文件（均在 45-Bonsai2模型评估/ 下）

文件	说明
fork-binaries/llama-cuda128.tar.gz	fork 预编译包 CUDA 12.8 x64（159.5 MB）——实测仅含 sm_120，需系统 .so.12
fork-binaries/llama-cuda133.tar.gz	fork 预编译包 CUDA 13.3 x64（139.6 MB）——实测含 sm_86/89/120/121，需系统 .so.13
fork-binaries/模型卡-README.md	官方 HF 模型卡原文
fork-binaries/Bonsai-demo-README.md	官方 demo 说明（运行/显存表/FAQ）
fork-binaries/官方AGENTS调参指南.md	官方给 agent 的硬件调参指南（部署时最该先读的一份）
fork-binaries/MODEL-FORMATS.md	三种 packing 格式辨析（避免下错文件的权威依据）

本报告由 DSH 会话生成；所有"已核实"项均附核实命令/来源，所有"估算"项已显式标注。