# Qwen3.8-27B Bucoid heretic-ara（无审查 IQ4_XS）部署报告

> 部署日期：2026-09-22 ｜ 硬件：GPU 机 RTX 5060 Ti 16GB
> 模型：`Bucoid/Qwen3.8-27B-Heretic-Ara-16GB-VRAM-IQ4-XS-MTP`（`bucoid_3.0_mtp.gguf`，13.35 GB）
> 配置：**MTP 加速 + 64K 上下文 + q4_0 KV + 无视觉**（按用户指定）

---

## 0. 一句话结论

**已上线。MTP 生效（接受率 52–78%），64K 上下文，显存 15.6 GiB，通过完整生成验证。**

```bash
bash ~/switch-llm.sh bucoid     # 别名 heretic / ara
```

API：`http://192.168.31.31:8080/v1`，模型名 **`bucoid-heretic-27b`**。

---

## 1. 最终配置

| 项 | 值 |
|---|---|
| 模型 | `bucoid_3.0_mtp.gguf`（IQ4_XS，自带 MTP 层 `blocks=65 / nextn=1`）|
| 模型路径 | `~/models/bucoid-heretic-27b/` → **符号链接**到 LM Studio 注册表（未复制，省 13.35 GB）|
| 上下文 | **65,536（64K）** |
| KV | `-ctk q4_0 -ctv q4_0` |
| 投机解码 | `--spec-type draft-mtp,ngram-map-k4v --spec-draft-n-max 1` |
| 视觉 | **未加载 mmproj**（纯文本；日志中 mmproj/vision 提及 0 次）|
| 显存实测 | **15,566–15,694 MiB**（16,311 MiB 总量，余量约 600 MiB）|
| 单元 | `llama-bucoid-heretic`（`disabled` 不自启）|

---

## 2. ⚠️ 本次最重要的发现：`73728`（72K）能加载但**一生成就崩**

### 踩坑经过

第一版按"探最大上下文"的思路部署到 **73728**：服务启动正常、`/health` 返回 ok、显存 15,790 MiB —— **一切看起来都对**。

但第一个真实请求（300 token 的普通生成）直接让进程 **SIGABRT core dump**：

```
llama_decode → ... → Main process exited, code=dumped, status=6/ABRT
```

**根因**：我最初的探测方法只验证了"服务能启动"（`/health`），**没有验证"能出字"**。加载时的显存占用 ≠ 生成时的峰值（CUDA 计算缓冲在 decode 阶段才分配）。余量 520 MiB 不够生成开销。

### 重做探测：每个候选必须真跑一次生成

| 配置 | 加载 | **生成** | 结论 |
|---|:--:|:--:|---|
| 无 MTP @ 122880 | ❌ | — | 超限 |
| 无 MTP @ 114688（112K）| ✅ | 未验证 | 加载通过（未做生成验证）|
| MTP @ 81920 | ❌ | — | 超限 |
| **MTP @ 73728（72K）** | ✅ | **❌ SIGABRT** | **不可用** |
| MTP @ 69632（68K）| ✅ | 未验证 | 加载通过 |
| **MTP @ 65536（64K）** | ✅ | **✅ 通过** | **已采用** |
| MTP @ 114688 + `-ub 256` | ❌ | — | 缩 micro-batch 也救不回 |

**→ 结论：MTP 档的可用上限是 64K（不是 72K）。**

> **方法论教训（值得写进备忘）**：
> llama.cpp 服务"起得来"不代表"能用"。凡是逼近显存上限的配置，
> **必须补一次真实生成请求并确认进程存活**，否则会在用户第一次提问时崩溃。

---

## 3. 另一个必需参数：`--fit off`

不加这个参数，llama.cpp 的自动 fit 估算会**在加载阶段直接拒绝启动**：

```
W common_fit_params: failed to fit params to free device memory:
  n_gpu_layers already set by user to 99, abort
```

实测**在任何上下文下都秒失败**（连 64K 都不行），因为它的估算偏保守。你现有的 `llama-ko-ridge` 单元里也有 `--fit off`，是同一个原因。

---

## 4. 实测性能（64K + MTP）

| 任务 | 耗时 | 速度 | MTP 接受率 |
|---|---:|---:|---:|
| 高重复长 prompt（约 3000 token 输入）| 6.0 s | **68.0 tok/s** | 70% |
| 数学推理（带思考，587 token）| 14.2 s | 43.1 tok/s | 78% |
| 无审查对白（182 token）| 5.6 s | 35.1 tok/s | 52% |

> 速度随任务波动（35–68 tok/s），与 MTP 接受率正相关 —— 这是投机解码的常态。

---

## 5. 上下文 / MTP 的取舍（本机实测边界）

| 想要 | 配置 | 状态 |
|---|---|---|
| **MTP 加速** | 64K + `draft-mtp` | ✅ 已部署 |
| **最大上下文** | 112K + 仅 ngram（关 MTP）| ✅ 加载通过（生成未验证）|

要切到 112K：把单元里 `-c 65536` 改成 `-c 114688`、`--spec-type` 去掉 `draft-mtp`，
**但务必补一次生成验证**（按 §2 的教训）。

---

## 6. 功能验收

| 测试 | 结果 |
|---|---|
| 服务启动 | ✅ 6 s |
| **生成可用性**（长 prompt 300 token）| ✅ 进程存活 |
| **生成可用性**（思考模式 587 token）| ✅ 进程存活 |
| MTP 生效 | ✅ 日志 `creating MTP draft context`，`draft_n` 有值 |
| 无视觉 | ✅ 未加载 mmproj |
| 无审查特性 | ✅ 虚构创作场景正常产出，无回避 |
| 别名切换 | ✅ `switch-llm.sh bucoid` / `heretic` / `ara` |

---

## 7. 与其它无审查档的定位

| 档 | 体积 | 上下文 | MTP | 视觉 | 精度 |
|---|---:|---:|:--:|:--:|---|
| **bucoid-heretic（本次）** | 13.35 GB | 64K | ✅ 自带 | ❌ | IQ4_XS |
| CRACK（Bonsai 2 三值）| 6.71 GB | 192K / 256K | 嫁接 | ✅ | 2.13bpw 三值 |
| KO-Ridge（huihui）| 11.73 GB | 128K | ✅ 自带 + DFlash2 | ✅ | 3.7bpw 混合 |

**这次的目标是"比 CRACK 少一层损失"**：CRACK 同时承受极限压缩 + 权重级去审；Bucoid 只有去审一层，位宽 IQ4_XS 高得多。

---

*本报告数字均来自 2026-09-22 本机实测。*