← 返回列表

2026-09-22-Bucoid-heretic-ara无审查档部署报告.md

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 ~/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 s68.0 tok/s70%
数学推理（带思考，587 token）14.2 s43.1 tok/s78%
无审查对白（182 token）5.6 s35.1 tok/s52%

速度随任务波动（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 本机实测。

下载此文件