# 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
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 单元要点

```ini
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，我没能定位**（见下方"若复发"）。所以我没有继续猜，**改为在服务端加结构性护栏**。

### 修复（已上线）

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

1. 默认档 `--reasoning off` —— 模型**不进入思考区**，结构上不可能再"想不完"
2. 同时 `--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
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 | **平手** |

### 关键判读

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

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

---

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