Qwen3.8-27B-Ridge 混合量化部署实测（2026-08-27 实测 · 2026-09-13 补录）

背景：2026-09-13 用户回忆「Qwen3.8 27B 之前有个混合量化模型在 GPU 机上部署过，以 Q3 的大小达到 Q8 的精度」。 核查结论：记忆准确，且规模比记忆更大 —— 该模型 2026-08-27 在 GPU 机上用 llama.cpp 完整跑通过 32K→256K 上下文 × MTP × 视觉的扫描测试（30+ 个日志留存），但从未写入 dl-hub 任何记录，也从未导入 LM Studio（文件一直躺在 ~/Downloads/）。本文为补录。核查方式：GPU 机全盘 GGUF 字节级扫描 + 日志解析 + 上游仓库 README 比对。

1. 结论速览

项	事实
模型	`Qwen3.8-27B-Ridge-3.7bpw.gguf` — 出品方 Empero（empero-ai/Qwen3.8-27B-Ridge-GGUF）
体积	11.73 GiB / 12.59 GB（3.69 bpw）—— 就是用户记忆里的「11 GB 多一点」
位置	GPU 机 `/home/zyw/Downloads/Qwen3.8-27B-Ridge-3.7bpw.gguf`（未导入 LM Studio）
下载时间	2026-08-27 08:55–09:03（脚本 `~/Downloads/dl_ridge.sh`，hf-mirror + aria2c 16 线程）
测试时间	2026-08-27 09:05–09:57（30+ 个 `ridge_*.log`）
运行方式	llama.cpp（`llama.cpp-src/llama.cpp-master/build/bin/llama-server`，CUDA 构建），不是 LM Studio
实测最佳	128K 上下文 + MTP(draft-n-max 2~3) → ~50 tok/s，draft 接受率 0.81；提示词 ~147 tok/s
视觉	✅ 已验证可用：配 `mmproj-Qwen3.8-27B-BF16.gguf`（0.87 GiB）`loaded multimodal model`，且几乎不降速
记录状态	❌ dl-hub 全库无任何 Ridge 记录；AGENTS.md / 环境备忘亦未提及 → 本次补录

2. 「混合量化」的真相：不是 Q8 精度，是 Q8 通路

用户记忆里的「以 Q3 的大小达到 Q8 的精度」需要精确化，这也是 Ridge 方案的核心价值：

Qwen3.8 是 Gated-DeltaNet 混合架构：64 层 = 16 × (3 × GatedDeltaNet → FFN + 1 × GatedAttn → FFN)（即每 3 层线性注意力 + 1 层全注意力）。

Ridge 的量化策略（引 README）：

GDN state is disproportionately sensitive to low-bit quantization, so Ridge holds that path high and spends the saved bits by dropping mid-stack FFN. The Gated-DeltaNet state path is Q8_0. Mixers are Q4_K, not IQ2.

	做法
GDN 状态通路（`ssm_alpha` / `ssm_beta`）	保 Q8_0 ← 这就是「Q8」的来源
GDN mixers	Q4_K（不是 IQ2）
中间层 FFN	降位，用来抵消上面的开销
MTP draft head（`blk.64` / `nextn`）	保留，Q6_K（MTP 张量无 imatrix，IQ2/IQ3 会 abort）
视觉	独立 BF16 `mmproj`，不含在 GGUF 内

⚠️ 关键澄清：整体不是 Q8 精度

README 自己给出的实测 perplexity（同为 80 chunks × 512 token，llama-perplexity）：

候选	体积	BPW	Wiki PPL	vs BF16
BF16（官方 checkpoint 转换）	50.89 GiB	16.00	7.15 ± 0.12	—
Ridge-3.7bpw	11.73 GiB	3.69	7.82 ± 0.14	+9.3 %

所以准确表述是：整体质量比 BF16 差约 9.3%（大致落在 Q3~Q4 区间），但远好于同为 11.7 GiB 的平坦低比特方案 —— 因为它把最要命的 GDN 状态通路单独保到了 Q8_0。所谓「Q8 精度」指的是那条通路的精度，不是整模型。作者原文的定位是「the difference between this file and a flat 2-bit dump of the same model」。

同类思路的姊妹作（同为 3.69 bpw，专为 RTX 5060 Ti 16GB + DFlash2 投机解码调优）：caiyi/Huihui-Qwen3.8-27B-abliterated-KO-Ridge-3.7bpw-GGUF（无审核版，12.60 GB，未下载）。

3. 完整实测数据（2026-08-27，RTX 5060 Ti 16GB）

硬件：RTX 5060 Ti 16GB（16311 MiB）+ 32GB RAM；-ngl 99（全 GPU 卸载）；llama-server 本地 8081 端口。

3.1 上下文 × MTP 扫描（成功轮次）

日志	上下文	生成 tok/s	提示词 tok/s	draft 接受率	备注
`ridge_nomtp`	32K	30.28	160.70	—	无 MTP 基线
`ridge_mtp2`	32K	50.63	146.10	0.809
`ridge_mtp6`	32K	45.43	144.88	0.563	n-max 6 反而更慢
`ridge_96k_vis_mtp2`	96K	50.19	147.17	0.809	带视觉
`ridge_128k_mtp1`	128K	43.63	146.82	0.889
`ridge_128k_mtp2`	128K	50.16	148.43	0.809
`ridge_128k_mtp3`	128K	52.21	148.03	0.752	本轮最快
`ridge_128k_nomtp`	128K	30.89	180.14	—	MTP 增益 +62%
`ridge_128k_vis_mtp3`	128K	51.64	147.06	0.752	带视觉
`ridge_128k_vis_mtp4/5`	128K	48.04 / 50.15	~146	0.66 / 0.64	带视觉
`ridge_128k_vis_off`	128K	50.15	146.36	0.809	视觉关（对照）
`ridge_144k_mtp1/2`	144K	43.46 / 50.65	~148	0.89 / 0.81	全 GPU 上限
`ridge_192k_nkvo_mtp2`	192K	10.05	60.93	0.809	nkvo：KV 挪 CPU，掉速 5×
`ridge_210k_nkvo_mtp2`	210K	10.09	58.10	0.809
`ridge_256k_nkvo`	256K	8.59	88.81	—	理论最大上下文

3.2 失败轮次及原因（重要）

E ggml_backend_cuda_buffer_type_alloc_buffer: allocating 640.00 MiB on device 0: cudaMalloc failed: out of memory
E llama_init_from_model: failed to initialize the context: failed to allocate buffer for kv cache
E common_speculative_init_result: failed to create MTP context

失败档	原因
140K / 148K / 152K / 160K（含 `q4kv` 变体、`vis` 变体）	KV cache 显存不足 —— 全 GPU 卸载的硬上限在 144K 附近
192K / 210K / 224K / 256K（非 nkvo 版）	同上，必须加 nkvo 才能起
128K + `mtp6`（含 vis 版）	MTP n-max 6 的草稿上下文额外吃显存 → OOM

3.3 三条可复用的结论

MTP 是这台机器的性能关键：同上下文 30.3 → 50.6 tok/s（+67%），接受率 0.81，但 n-max 只能给 2~3，给 6 会在 128K 直接 OOM、在 32K 也反而变慢。
视觉几乎免费：加载 mmproj 后 128K 仍有 51.64 tok/s（对照 50.15），代价只有 0.87 GiB 模型体积。
144K 是「全 GPU 卸载」的实际天花板；要更长上下文必须 nkvo（KV cache 放 CPU），速度塌到 ~10 tok/s；256K 理论可达但仅 8.6 tok/s。

4. 复现命令（llama.cpp）

# 二进制位置（GPU 机，已编译好的 CUDA 版）
BIN=/home/zyw/Downloads/llama.cpp-src/llama.cpp-master/build/bin
M=/home/zyw/Downloads/Qwen3.8-27B-Ridge-3.7bpw.gguf

# 推荐配置：128K + MTP(n-max 2) —— 实测 ~50 tok/s
$BIN/llama-server -m $M -ngl 99 -c 131072 --port 8080 \
  --spec-type draft-mtp --spec-draft-n-max 2

# 加视觉（同一条服务，多挂 mmproj）
$BIN/llama-server -m $M -ngl 99 -c 131072 --port 8080 \
  --mmproj /home/zyw/Downloads/mmproj-Qwen3.8-27B-BF16.gguf \
  --spec-type draft-mtp --spec-draft-n-max 2 \
  --image-min-tokens 1024        # Qwen-VL 在 grounding 任务上需要 ≥1024 图像 token

# 超长上下文（>144K，KV 放 CPU，~10 tok/s）
$BIN/llama-server -m $M -ngl 99 -c 262144 --no-kv-offload --port 8080

采样参数（官方卡推荐）：thinking 开 --temp 1.0 --top-p 0.95 --top-k 20；instruct --temp 0.7 --top-p 0.80 --top-k 20 --presence-penalty 1.5。

5. 与当前在用的 LM Studio 方案对比

	Ridge-3.7bpw（已下载未用）	`qwen3.8-27b@q3_k_xl`（LM Studio 现役推荐）
体积	11.73 GiB	12.24 GiB
上下文	128K（实测）	16K
生成速度	~50 tok/s（MTP n-max 2）	29.9 tok/s
MTP 投机解码	✅ 原生 draft head	❌ 无
视觉/图片输入	✅（+0.87 GiB mmproj，已验证）	❌ 纯文本
运行环境	llama.cpp（llama-server）	LM Studio
记录状态	未记录、未接入任何客户端	已记录、已接入 WebUI/Cherry

Ridge 在每一项上都优于现役方案（更小、上下文 ×8、快 67%、多视觉与 MTP），却一直闲置。原因是它从未被导入 LM Studio（lms ls 里没有它），而 08-27 的测试全部走 llama.cpp 命令行，没有沉淀成常驻服务或脚本。

待决问题：LM Studio 侧能否复现这套配置（尤其 --spec-type draft-mtp 与 nkvo）尚未验证；若不能，建议以 llama-server 常驻方式使用 Ridge。

6. GPU 机 `~/Downloads` 游离模型清单（未导入 LM Studio）

文件	体积	下载时间	状态
`Qwen3.8-27B-Ridge-3.7bpw.gguf`	11.73 GiB	08-27 09:02	✅ 已 benchmark（本文）
`mmproj-Qwen3.8-27B-BF16.gguf`	0.87 GiB	08-27 09:03	✅ 视觉已验证
`mmproj-Qwen3.8-27B-F16.gguf`	0.86 GiB	08-27 08:41	未单独测试（F16 与 BF16 二选一即可）
`RVN-Q3_K_M-multilingual-mtp.gguf`	12.81 GiB	08-27 12:47	❌ 未测（无 rvn 日志）
`RVN-Q3_K_S-multilingual-mtp.gguf`	11.67 GiB	08-27 12:49	❌ 未测
`downloads/Qwen3.8-9B-distill-heretic_nvfp4_q4_k_m.gguf`	4.82 GiB	09-09 18:08	已导入 LM Studio（同 inode 副本）
配套脚本	—	08-26~27	`dl_ridge.sh` `dl_rvn.sh` `dl_nvidia.sh` `mtp_speedtest.sh`

注：~/Downloads（大写）与 ~/downloads（小写）是两个不同目录，9B 那份在小写目录里 —— 排查时容易漏。

7. 遗留与建议

补一次 LM Studio 可行性验证：把 Ridge 导入 LM Studio（lms import），测试 --speculative-draft-mtp 是否等价于 llama.cpp 的 draft-mtp，以及 128K 上下文能否达到同速。若不行则以 llama-server 常驻。
清理重复副本：~/Downloads 里 5 个 GGUF + ~/.lmstudio/models 里的导入副本存在同文件双份（Ridge 尚未双份，但 huihui Q4_K、UD-Q4_K_M 等都各存两份），约占 30+ GiB。磁盘已用 89%（剩 123G），清理前需确认服务不再引用。
RVN 两档待验证：Q3_K_M/Q3_K_S + multilingual imatrix + MTP，与 Ridge 同量级，未测过速度与质量。
无审核需求：可用 caiyi 的 KO-Ridge 3.7bpw 无审核版（12.60 GB，未下载）。

核查人：DSH 会话 · 原始实测：2026-08-27 · 补录：2026-09-13 参考：Empero Ridge 模型卡 · 无审核 KO-Ridge 版 · Ridge 量化科普（第三方）

Qwen3.8-27B-Ridge混合量化部署实测-补录2026-09-13.md