Bonsai 2 27B —— 本机实测与部署报告

实测日期：2026-09-19 ｜硬件：GPU 机 192.168.31.31 / RTX 5060 Ti 16GB (sm_120, CUDA 13.1) 本报告是实测与部署报告；项目背景、厂商口径核实、第三方争议见同目录 2026-09-19-Bonsai2-27B项目评估与适配分析.md（那篇是本篇之前写的，其中 3 处结论已被实测修正，见本文第 7 节）。原始数据（bench 输出、5 组提示词全文、服务日志、脚本）在同目录 实测原始数据/。

1. 结论速览

Bonsai 2 27B 在本机可用，质量与你现役 Ridge 基本无差距，而显存少 2 GiB 且上下文大一倍；PQ2_0 是 5060 Ti 上的正确选择。

维度	Bonsai 2 (PQ2_0)	Ridge 3.7bpw（现役）	谁更优
生成速度（tg128）	49.69 tok/s	53.9 tok/s（历史实测）	Ridge 略快
提示处理（pp512）	1000.92 tok/s	未实测	—
显存占用	13.5 GiB	15.5 GiB	✅ Bonsai 2
最大上下文	262,144	131,072	✅ Bonsai 2（2×）
磁盘体积	6.71 GiB	11.73 GiB	✅ Bonsai 2
视觉	✅ GPU 编码	✅ CPU 编码（26.7s）	✅ Bonsai 2
投机解码	❌ 官方未发布 drafter	✅ MTP（接受率 0.78）	Ridge
质量（5 组中文题）	4 好 1 差	4 好 1 差	平手

明确结论：可以部署、可以日常用；但不建议立刻替换 Ridge —— Ridge 靠 MTP 投机解码在峰值速度上仍占优（56.6 tok/s vs 48），且它的长上下文表现是你实测过的。建议定位为"长上下文/省显存"的第二档，用 switch-llm.sh bonsai2 按需切换。

2. 已部署（生产可用）

项	值
服务单元	`llama-bonsai2.service`（disabled 不自启，与其它 4 个单元一致）
端口	`8080`（与 ridge / ko-ridge 互斥，5 选 1）
模型名（API）	`bonsai2-27b`
端地址	`http://192.168.31.31:8080/v1`
上下文	262,144
二进制	`/home/zyw/llama.cpp-bonsai/bin/llama-server`（PrismML fork，build 10709）
模型目录	`/home/zyw/models/ternary-bonsai-2-27b/`
实测显存	13,802 / 16,311 MiB

启停

bash ~/switch-llm.sh bonsai2         # 默认档：关思考（秒回），别名 bonsai
bash ~/switch-llm.sh bonsai2-think   # 思考档：预算 4096，别名 think
bash ~/stop-ridge.sh                 # 停全部
bash ~/ridge-status.sh               # 状态速查（现为 6 个单元）

⚠️ 本节配置已于同日深夜修订（关闭默认无限思考、拆分两档），详见下面的 §2.5。

冒烟测试结果（全部通过）

测试	结果
本机文本请求	✅ `45.7 tok/s`
局域网请求（DSH 机 → GPU 机）	✅ `42.9 tok/s`，返回"收到"
视觉（发图问内容）	✅ 正确描述图像内容，prefill 0.8s
API 能力声明	`capabilities: ["completion","multimodal"]`

systemd 单元要点

Environment=LD_LIBRARY_PATH=/usr/local/cuda-13.1/lib64   # fork 二进制不带 CUDA 运行时
ExecStart=/home/zyw/llama.cpp-bonsai/bin/llama-server \
  -m  .../Ternary-Bonsai-2-27B-PQ2_0.gguf \
  --mmproj .../Ternary-Bonsai-2-27B-mmproj-Q8_0.gguf \
  -ngl 99 -fa on -c 262144 -ctk q4_0 -ctv q4_0 -np 1 \
  --jinja --metrics --warmup --no-context-shift \
  --temp 1.0 --top-p 0.95 --top-k 20 --repeat-penalty 1.0 \
  --threads 8 --threads-batch 16 --host 0.0.0.0 --port 8080 --alias bonsai2-27b

2.5 ⚠️ 重要修订（同日深夜）：默认档的"无限思考"已关闭

现象（用户实测反馈）

Trae 调用：一直处于思考状态，半小时不出结果
Cherry Studio：一句"你好"想了 3 分钟

服务端日志证据

eval time =  570548.46 ms / 16000 tokens (28.04 t/s)   ← 提示仅 4 个 token
eval time =     186.05 ms /     4 tokens
eval time =  570411.36 ms / 16000 tokens
eval time =     186.51 ms /     4 tokens
eval time =  571436.94 ms / 16000 tokens
eval time =     186.77 ms /     4 tokens
eval time =  323484.00 ms /  9259 tokens

三次都正好 16000 token —— 这是客户端设的 max_tokens。也就是说：模型从未输出 EOS，一直在思考区里出不来，直到被客户端上限截断，一个字的正文都没给。

根因

Qwen3.8-27B 底座默认 reasoning effort = xhigh 且思考预算无限。我第一版单元只照抄了模型卡的采样参数推荐，没有设置任何思考档位 —— 等于把这个行为完全交给客户端自律，而多数聊天/Agent 客户端不会主动关思考。

为什么我自己的复现测试全都正常

用同样 4-token 的"你好"测试，模型 39 token 就正常停了。我逐个排除了：

测试	结果
基线（只给 max_tokens）	✅ 45 token 停
Cherry 风格 `temp 0.7 / top_p 0.9`	✅ 37 token 停
流式 `stream: true`	✅ 正常结束
带工具定义 `tools`	✅ 44 token 停
`frequency_penalty / presence_penalty = 1.0`	✅ 94 token 停
`reasoning_effort: low / medium`	✅ 停（`high` 则 HTTP 500）
长上下文（5,718 token）+ 你好	✅ 46 token 停

客户端究竟传了什么导致 16000 token，我没能定位（见下方"若复发"）。所以我没有继续猜，改为在服务端加结构性护栏。

修复（已上线）

两层护栏，第二层专防客户端覆盖：

默认档 --reasoning off —— 模型不进入思考区，结构上不可能再"想不完"
同时 --reasoning-budget 512 —— 实测即使客户端用 chat_template_kwargs: {"enable_thinking": true} 强行覆盖，思考也被封顶在 512 token

三个档位（取代原来的单档）

单元	思考设置	采样参数	用途
`llama-bonsai2`	`--reasoning on --reasoning-budget -1`（无限制）	`temp 1.0 / top_p 0.95`	模型默认行为；当前运行档（用户要求）
`llama-bonsai2-think`	`--reasoning on --reasoning-budget 4096`	`temp 1.0 / top_p 0.95`	有界思考
`llama-bonsai2-nothink`	`--reasoning off --reasoning-budget 512`	`temp 0.7 / top_p 0.80 / presence_penalty 1.5`	秒回（聊天/Agent）

bash ~/switch-llm.sh bonsai2           # 无限制思考
bash ~/switch-llm.sh bonsai2-think     # 预算 4096
bash ~/switch-llm.sh bonsai2-nothink   # 关思考，秒回

状态说明（2026-09-19 收尾）：加固版验证通过后，用户要求恢复无限制思考再自行测试，故 llama-bonsai2 当前为 --reasoning-budget -1；有界/秒回两档保留备用。 ⚠️ 无限制档下，客户端自身的 max_tokens 成为唯一的约束——若 Cherry/Trae 仍设 16000，之前的 9.5 分钟思考仍会重现（服务端日志里的 16000 就是客户端上限，不是服务端限制）。

注意：模型卡对"思考档 / 指令档"给的采样参数不同。我第一版在关思考的情况下仍用着思考档的 temp 1.0 / top_p 0.95，属于配置错配，已一并修正。

修复后实测

场景	修复前	修复后
"你好"（Cherry 场景）	3 分钟 / ~8,600 token	0.8 秒 / 27 token
模拟 Trae（2,882 token 提示 + 2 个工具定义）	半小时不出结果	3.4 秒 / 13 token
客户端强推 `enable_thinking: true`	无上限	9.4 秒（思考封顶 512）
思考档 + 数学题	—	✅ 正常（预算内思考后给答案）

若复发怎么办

说明客户端绕过了这两层护栏。把出问题的那次请求告诉我，我会在 8080 前面挂一个记录请求体的反向代理，抓出客户端到底传了什么参数 —— 这比继续猜有效。

教训

部署"思考型模型"时，必须显式设定思考档位，不能依赖客户端自觉。 模型卡给的采样参数推荐只管"怎么采样"，不管"想多久"。这个坑对你现有的 llama-ko-ridge 同样成立（它是 --reasoning-budget -1，即无限制）。

2.6 MTP 与加速路径实测（含 n-gram 投机解码的意外收获）

❌ MTP（Multi-Token Prediction）不支持

底座 Qwen3.8-27B 原本带 MTP 层（你现役 Ridge 正是靠 --spec-type draft-mtp --spec-draft-n-max 3 跑到 56.6 tok/s、接受率 0.78），但三值转换版把 MTP 层丢掉了。用 Bonsai 2 实测直接报错：

I common_speculative_init_result: creating MTP draft context against the target model 'Ternary-Bonsai-2-27B-PQ2_0.gguf'
W llama_init_from_model: context type MTP requested but model doesn't contain MTP layers
E common_speculative_init_result: failed to create MTP context
E srv    load_model: failed to create MTP context

→ --spec-type draft-mtp 对 Bonsai 2 完全不可用，连服务都起不来。

❌ dspark 草稿模型也未发布

官方 download_models.sh 第 144 行注释明说：Bonsai 2 has no dspark drafter；HF 仓库文件清单里也没有任何 drafter 文件。

→ 官方设计的两条投机解码路线（MTP / dspark），Bonsai 2 一条都走不了。

✅ 意外收获：n-gram 投机解码（`ngram-*`）可用，且效果显著

该 fork 的 --spec-type 支持一批既不需要草稿模型、也不需要 MTP 层的类型：

none, draft-simple, draft-eagle3, draft-mtp, draft-dflash, draft-dspark,
ngram-simple, ngram-map-k, ngram-map-k4v, ngram-mod, ngram-cache

实测（PQ2_0 / RTX 5060 Ti / 16K ctx / 关思考 / --spec-draft-n-max 8）：

任务类型	基线 tok/s	ngram-map-k4v	加速比	接受率
逐句抄录（高重复）	47.7	126.2	2.65×	85%
提取数字（中重复）	47.9	76.4	1.60×	72%
摘要	47.9	46.9	~1.0	未触发
自由创作	47.9	47.5	~1.0	未触发
数学推理	47.9	46.5	0.97×	0%（约 3% 开销）

机制：从已有上下文里匹配 n-gram 词串来投机，命中才生效 → 对"近乎逐字复用上下文"的任务爆发，对其余场景几乎零成本。

已启用：三个 bonsai2 单元均加入 --spec-type ngram-map-k4v --spec-draft-n-max 8（生产服务上复测：抄录 127.1 tok/s、提取数字 76.4 tok/s）。

最适合你的场景：合同审查、OCR 整理、报告改写、RAG 引用、代码编辑 —— 这类输出大量复用输入词串的工作。

加速手段全景（本机实测）

手段	状态	效果
PQ2_0 而非 PTQ1_0	✅ 已用	预处理 2.16×、生成 +10% —— 本次最大的单项收益
Flash attention + Q4 KV	✅ 已用	262K 上下文塞进 13.8 GiB
n-gram 投机解码	✅ 已用	高重复任务 2.65×，其余零成本
`draft-simple` + 同词表小模型	🔬 未试	通用投机解码（对所有文本有效，不限重复），但需一个词表与 Qwen3.8-27B 完全一致的小模型做草稿；本机没有，需另下
`draft-eagle3`	❌ 无模型	需 EAGLE3 草稿头，官方未发布
`-ub` 预处理微批调优	🔬 未试	可能小幅提升 pp512（当前 1001 t/s）
等官方补 drafter	⏳ 观察	若 PrismML 补发 dspark/MTP drafter，速度上限有望再翻倍

3. 两个 packing 的实测对比（本次最有价值的发现）

llama-bench（CUDA, ngl 99, fa on, 3 次重复）：

指标	PTQ1_0（1.75 bpw）	PQ2_0（2.13 bpw）	差异
文件	5.53 GiB	6.70 GiB	+1.17 GiB
tg128 生成	45.12 ± 0.10	49.69 ± 0.10	+10.1%
pp512 提示处理	464.19 ± 5.24	1000.92 ± 20.35	+115.6%（2.16×）
pp4096	464.16 ± 0.01	1006.12 ± 1.47	+116.7%
服务端显存（262K+Q4_0 KV+视觉）	12,658 MiB	13,802 MiB	+1,144 MiB
服务加载耗时	4 s	5 s	—

厂商的说法被实测证实：官方表里 PTQ1_0 只在 Ada/L4 上更快，Blackwell 上 PQ2_0 反超。这与机制吻合 —— PTQ1_0 每步少搬 17% 权重但要多花算术解包密集三值；5060 Ti 的 batch-1 解码不是带宽瓶颈（45.12 tok/s × 5.53 GiB = 267 GB/s，仅峰值的 60%），而是指令吞吐受限。

选择建议：用 PQ2_0。多花 1.1 GiB 换 2.16× 的提示处理速度，长文档/长对话/大 prompt 场景收益远大于生成速度那 10%。已部署的就是 PQ2_0。

4. 质量对比（同提示词、同参数、n=1）

固定 temperature=0.7, top_p=0.9, top_k=20, seed=42, max_tokens=2048；A–D 关思考，E 开思考。

测试	Bonsai 2 PTQ1_0	Bonsai 2 PQ2_0	Ridge 3.7bpw	判定
A 中文创作（雨夜钟表匠，300 字，克制）	✅ 克制、有画面感	✅ 同	✅ 同样好，风格更华丽	平手
B 文档改写（三值量化 → 5 条要点）	✅ 5 条	✅ 5 条	✅ 5 条	Ridge 略优
↳ 细节	"每百多个参数"（不精确）	同	"每 128 个参数"（精确）
C 数学推理（水管问题，关思考）	✅ 完整 4h48m	✅ 完整 4h48m	✅ 完整 4h48m	平手
D 指令跟随（恰好 5 条 bullet，硬约束）	❌ 只给 3 条	❌ 3 条	❌ 3 条，且无 bullet	双双失败
E 数学推理（同题，开思考）	✅ 完整 4h48m	✅ 完整 4h48m	✅ 完整 4h48m	平手

关键判读

D 的失败与量化无关。三个配置全都没做到"恰好 5 条"，Ridge 甚至比 Bonsai 更差（连 bullet 格式都没用）。这是 Qwen3.8-27B 家族 + 关思考模式下的通病，不是三值量化的损失。→ 这正说明没有基线就无法定性。
数学能力没退化。C/E 的推理链（含最小公倍数通分 → 5/24 → 24/5）与 Ridge 一致且完整。
A 创作质量主观上肉眼分不出高下，两者都在水准之上。
唯一可辨识的差距是 B 题的数值精确度（"每 128 个参数" vs "每百多个参数"），属轻微信息失真，不影响可用性。
⚠️ 样本量警告：n=1/题。上述"平手"是未发现差异，不等于"证明无差异"。要更强结论需按题多次采样。

速度对照（同一次质量测试内）

配置	A	B	C	D	E	特征
Bonsai 2 PTQ1_0	43.7	43.6	43.6	42.7	43.7	极稳
Bonsai 2 PQ2_0	47.9	47.9	48.0	46.4	48.0	极稳
Ridge 3.7bpw	33.3	42.0	56.6	39.0	54.9	波动大（MTP 接受率随内容变）

Bonsai 2 没有投机解码，所以速度极其稳定；Ridge 靠 MTP 投机解码，峰值更高（56.6）但低谷也低（33.3）。

5. 上下文与显存实测

服务端 -c 262144 -ctk q4_0 -ctv q4_0 -fa on -np 1 + mmproj：

配置	显存	上下文	备注
Bonsai 2 PTQ1_0	12,658 MiB（12.4 GiB）	262,144	余量 ~3.6 GiB
Bonsai 2 PQ2_0	13,802 MiB（13.5 GiB）	262,144	余量 ~2.5 GiB
Ridge 3.7bpw（现役）	15,532 MiB（15.2 GiB）	131,072	视觉在 CPU

262K 满上下文在 16GB 卡上确认可行，llama.cpp 在启动时即预分配 KV，所以 13.5 GiB 就是稳态占用。（注：官方公布的 KV 口径为 FP16 64 KiB/token、4bit ≈18 KiB/token，我按此估算的 11.2 GiB 偏乐观，实测 13.5 GiB —— 差额来自计算缓冲与视觉投影器。）

6. 部署与运维踩坑

#	坑	现象	处置
1	残留 server 占显存	新服务启动即 `failed to create context`（其实是 OOM），`systemctl` 只报 exit 1	起服务前 `pkill -x llama-server` 确认显存归零（本次就踩了：旧的测试 server 占 7.5 GiB）
2	fork 二进制不带 CUDA 运行时	`libcudart.so.13: cannot open shared object file`	单元里 `Environment=LD_LIBRARY_PATH=/usr/local/cuda-13.1/lib64`（CUDA 12.8 版包则要 `.so.12`）
3	LM Studio 跑不了	需 fork 的 Hadamard 激活变换，上游 PR 未合并	只能裸起 `llama-server`；与 Ridge 同模式，不是额外负担
4	别用 stock llama.cpp	`PTQ1_0/PQ2_0` 被拒（安全）；`Q2_0` 不报错直接出乱码（危险）	只用 fork 二进制；别下 `*-gguf-dev` 仓库
5	无投机解码	Bonsai 2 没有配套 dspark drafter（官方 `download_models.sh` 注释明说）	43.7–49.7 tok/s 即真实上限
6	端口冲突	7 个单元都占 8080	用 `switch-llm.sh` 互斥切换，别手工并行起
7	思考链长	默认 xhigh 且预算无限，单次可吃几千甚至上万 token	必须显式设思考档位（见 §2.5）；客户端 `max_tokens` 只是被动截断
8	视觉投影器	占 0.59 GiB 显存	纯文本场景可 `--no-mmproj` 省显存
9	客户端不认自定义模型名	Cherry Studio 显示「该模型不支持网络搜索」，网络搜索开关置灰	服务端没问题（实测 `supports_tools/tool_calls/parallel_tool_calls` 全 true，工具调用 3.5s 成功）。Cherry 按模型名查内置能力库，`bonsai2-27b` 不在库里 → 需手动勾选能力标签：模型设置里勾「函数调用/工具」+「思考」+「视觉」。另一条路是配 Cherry 自带的搜索服务商（Tavily 等），那条路径不依赖模型能力，任何模型可用
10	起服务时别用 pkill	单元由 systemd 托管，`pkill -x llama-server` 会让 systemd 判定主进程死亡 → 单元变 `inactive`（本次踩过）	用 `systemctl stop` → `reset-failed` → `start`；pkill 只用于清理非托管的临时 server

7. ⚠️ 对前一版报告的 3 处更正

前一版（2026-09-19-Bonsai2-27B项目评估与适配分析.md）在拿到实测前写的，以下 3 点被实测推翻：

#	前一版说法	实测结果	性质
1	"Bonsai 2 支持 dspark 投机解码（CUDA 1.8–2.4×）"	❌ Bonsai 2 没有 drafter，官方脚本注释：`Bonsai 2 has no dspark drafter`。只有上一代 Ternary-Bonsai 27B 有	我的错误（把上一代能力张冠李戴）
2	"建议两个 packing 都压一次再定"（倾向不定）	✅ PQ2_0 明确更优：pp 快 2.16×，生成快 10%，代价 +1.1 GiB	实测给出确定答案
3	"C 数学推理：Bonsai 答案截断 ⚠️"	❌ 答案完整正确（"4.8 小时 / 4 小时 48 分钟"，在文件第 64 行）。是我用 `head -50` 读取时自己截断的	我的错误（读文件失误，不是模型问题）

8. 下载链路实测（顺带记录）

方式	实测速度	结论
GPU 机 `curl` 直连 hf-mirror	2.8 MB/s	单连接被限速，5.9 GB 要 35 分钟
DSH 机迅雷	31.6 MB/s（PTQ1_0）；5.07 MB/s（PQ2_0 并行时）	✅ 快 11 倍
局域网 scp（DSH → GPU）	96–101 MB/s	6.9 GB 约 68 秒

正确姿势：DSH 机迅雷下载 → sha256 校验 → 局域网 scp 到 GPU 机 → .new + 原子 mv 替换。哈希：三个文件 sha256 均与 HF 官方值逐字节一致。

其它踩坑：

迅雷任务下载完成后会从任务列表消失，用 task_id 轮询会一直 NOT_FOUND → 改按文件字节数精确比对
.xltd 是预分配文件，大小 ≠ 进度，不能用它测速
GitHub 从 GPU 机只有 ~50 KB/s（fork 二进制包必须走局域网中转）
~/Downloads/scp_exec.sh 里目标 IP 还是废弃的 192.168.31.25，已修为 .31

9. 原始数据索引（同目录 `实测原始数据/`）

文件	内容
`llama-bench-PTQ1_0.txt` / `llama-bench-PQ2_0.txt`	两个 packing 的 bench 原始输出
`quality-PTQ1_0/`、`quality-PQ2_0/`、`quality-ridge-long/`	三配置 × 5 题的完整正文 + 指标 + 思考链
`ptq1-c-refrag.log`	C 题 seed=42 重跑（验证确定性：两次均 782 tokens）
`server-*.log`	llama-server 启动日志（含 KV/上下文实际分配）
`watcher.log` / `watcher2.log`	自动化测试流水线日志
`quality_test.py` / `bench.sh` / `watcher.sh` / `deploy_bonsai2.sh`	本次使用的全部脚本（可复现）
`ridge_compare.log`	Ridge 对照实验日志

10. 建议的后续（未做）

多题多次采样才能把"质量平手"从"未发现差异"升级为结论（现为 n=1/题）
长上下文实测：262K 是真的能跑到，还是只有分配成功？建议喂 15 万 token 文档实测
视觉交叉核对：本次只验证通路正常（描述具体可信），未用第二个模型核对准确度
中文长文创作 A/B：用你真实的创作提示词盲比 Ridge vs Bonsai 2，这是最有实际意义的验证
若 PrismML 后续发布 Bonsai 2 的 dspark drafter，值得重测速度上限

本报告全部数字来自 2026-09-19 在 RTX 5060 Ti 上的实测；厂商口径与第三方争议见同目录评估篇。

2026-09-19-Bonsai2-27B实测与部署报告.md