# 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](https://huggingface.co/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](https://huggingface.co/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 失败轮次及原因（重要）

```text
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 三条可复用的结论

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

---

## 4. 复现命令（llama.cpp）

```bash
# 二进制位置（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. 遗留与建议

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

---

**核查人**：DSH 会话 · **原始实测**：2026-08-27 · **补录**：2026-09-13
**参考**：[Empero Ridge 模型卡](https://huggingface.co/empero-ai/Qwen3.8-27B-Ridge-GGUF) · [无审核 KO-Ridge 版](https://huggingface.co/caiyi/Huihui-Qwen3.8-27B-abliterated-KO-Ridge-3.7bpw-GGUF) · [Ridge 量化科普（第三方）](https://www.mindstudio.ai/blog/qwen3-8-27b-ridge-quantization-local)