# 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](https://github.com/ggml-org/llama.cpp/pull/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 机开机即可执行）

```bash
# ── 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](https://huggingface.co/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](https://github.com/PrismML-Eng/Bonsai-demo) | README / AGENTS.md / MODEL-FORMATS.md（运行方式与调参） |
| fork 发布页 | [releases/tag/prism-b10709-9a9394a](https://github.com/PrismML-Eng/llama.cpp/releases/tag/prism-b10709-9a9394a) | 平台包清单 |
| fork 二进制（实测） | linux-cuda-12.8-x64.tar.gz | 扫出 `sm_120`/`compute_120` + 内核存在性 |
| 第三方拆解 | [orcarouter.ai/blog/ternary-bonsai-2-27b](https://www.orcarouter.ai/blog/ternary-bonsai-2-27b) | bpw 四口径、分项得失、20 项 suite、abliteration 技术 |
| 官方公告 | [prismml.com/news](https://prismml.com/news/prismml-launches-bonsai-2-27b) | 发布时间 |
| 历史 issue | [ggml-org/llama.cpp#25727](https://github.com/ggml-org/llama.cpp/issues/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 会话生成；所有"已核实"项均附核实命令/来源，所有"估算"项已显式标注。