Qwen3.8-27B-Ridge 部署报告（GPU 机 192.168.31.31）

部署时间：2026-09-13 目标：把 2026-08-27 就已下载并 benchmark 过、但一直闲置在 ~/Downloads 的 Ridge 混合量化模型，做成可长期使用的常驻服务结果：✅ 已部署为 systemd 服务，OpenAI 兼容 API 跑在 http://192.168.31.31:8080/v1，模型名 qwen3.8-27b-ridge 验收实测：文本 53.9 tok/s（500 token / 9.27s，128K 档 benchmark 为 52.2）、视觉识别 8.34s（准确识别红圆/蓝方/绿三角/文字 RIDGE-2026）、MTP 投机解码生效（接受率 0.47~0.78）

1. 部署架构

项	值
模型文件	`/home/zyw/models/qwen3.8-27b-ridge/Qwen3.8-27B-Ridge-3.7bpw.gguf`（11.73 GiB）
视觉投影	`/home/zyw/models/qwen3.8-27b-ridge/mmproj-Qwen3.8-27B-BF16.gguf`（0.87 GiB）
运行器	llama.cpp `llama-server`（`~/Downloads/llama.cpp-src/llama.cpp-master/build/bin/`，CUDA 版）
服务单元	`llama-ridge.service`（fast：64K + GPU 视觉，14878MiB）/ `llama-ridge-long.service`（long：128K + CPU 视觉，15532MiB）—— 当前运行 long 模式
监听	`0.0.0.0:8080`（局域网可访问；无 API key，与 LM Studio 1234 一致）
模型别名	`qwen3.8-27b-ridge`
自启	❌ 明确不做开机自启：两个单元均已 `systemctl disable`，实测 `is-enabled` = disabled；`Restart=no`。原因：与 LM Studio / ComfyUI 争抢 16GB 显存，必须手动切换
磁盘占用	零新增 —— 文件从 `~/Downloads` 同盘 `mv` 迁移（rename，瞬时无拷贝）；原下载脚本 `dl_ridge.sh` 仍在 `~/Downloads`

为什么用 systemd 而不是 nohup：本环境已记录过「nohup 进程组属于瞬态工具 shell，会被静默杀掉」的教训（见 dl-hub/05-下载服务维护/）。systemd 托管可保证进程独立于 SSH 会话存活。

1.1 文件迁移

为避免把生产模型留在 ~/Downloads（易被清理），已迁移到正式目录：

~/Downloads/Qwen3.8-27B-Ridge-3.7bpw.gguf   →  ~/models/qwen3.8-27b-ridge/
~/Downloads/mmproj-Qwen3.8-27B-BF16.gguf    →  ~/models/qwen3.8-27b-ridge/

（~/models 由 sudo 创建后 chown 给 zyw —— /home/zyw/models 此前是 root 属主，普通用户无法在其下建目录。）

2. 启停与切换（一键脚本）

# 启动（默认 long 模式：128K 上下文，视觉编码器在 CPU）——会先自动卸载 LM Studio 模型释放显存
bash ~/switch-ridge.sh

# 切到 fast 模式：64K 上下文，视觉编码器在 GPU（出图快 ~1s）
bash ~/switch-ridge.sh fast

# 停止，释放显存
bash ~/stop-ridge.sh

# 状态速查（服务/显存/API/MTP 接受率）
bash ~/ridge-status.sh

脚本内部：lms unload --all → 停另一个模式的单元 → systemctl start → 轮询 /health 直到就绪（约 8–15 秒）。

3. 显存取舍：为什么是 64K 而不是 128K

RTX 5060 Ti 只有 16GB（16311 MiB），11.73 GiB 的模型 + KV + MTP draft context + 视觉编码器必须挤在一起。实测矩阵：

配置	结果	显存	视觉编码	文本速度
64K + 视觉在 GPU（默认）	✅ 可用	14878 MiB	~3s（快）	53.9 tok/s
96K + 视觉在 GPU	❌ OOM 崩溃	—	—	—
120K + 视觉在 GPU	❌ OOM 崩溃	—	—	—
128K + 视觉在 CPU（`--no-mmproj-offload`）	✅ 可用	15538 MiB	~27s（慢）	54.0 tok/s
128K + 视觉在 GPU	❌ OOM 崩溃	—	—	—

失败点固定在视觉编码器的 888 MiB 连续显存分配（clip_model_loader::load_tensors → cudaMalloc failed）。64K 与 96K 之间是硬边界。

结论（按用户 2026-09-13 决定）：默认与当前运行模式 = long（128K） —— 长上下文优先，看图慢（~33s）但结果正确。需要频繁看图时再 bash ~/switch-ridge.sh fast 切到 64K + 秒级视觉。

4. 最终启动参数（逐项理由）

llama-server \
  -m ~/models/qwen3.8-27b-ridge/Qwen3.8-27B-Ridge-3.7bpw.gguf \
  --mmproj ~/models/qwen3.8-27b-ridge/mmproj-Qwen3.8-27B-BF16.gguf \
  --image-min-tokens 1024 \
  -ngl 99 -c 65536 \
  -ctk q4_0 -ctv q4_0 -fa on -np 1 \
  --spec-type draft-mtp --spec-draft-n-max 3 \
  --host 0.0.0.0 --port 8080 --alias qwen3.8-27b-ridge

参数	作用 / 为什么必须有
`-ngl 99`	全部层卸载到 GPU（27B 的 3.69bpw 才塞得下）
`-ctk q4_0 -ctv q4_0`	最关键 —— KV cache 量化到 4bit。不加则 128K 要 8192 MiB KV，必然 OOM；加后 ~2.6 GiB
`-fa on`	Flash Attention，配合 KV 量化使用
`-np 1`	单并发槽，避免多槽重复分配 KV
`--spec-type draft-mtp --spec-draft-n-max 3`	启用模型自带的 MTP 草稿头，文本提速 67%；n-max 给 6 会 OOM，2~3 最优
`--image-min-tokens 1024`	Qwen-VL 在 grounding 任务上的最低要求（llama.cpp 会警告）
`--host 0.0.0.0`	让局域网内的 Trae / Cherry / Open WebUI 能连
`--alias`	固定 API 里显示的模型名

5. 验收实测数据

5.1 文本（500 token 基准，与 08-27 同条件）

completion_tokens=500   elapsed=9.27s   e2e=53.9 tok/s
journal: n_gen=335, tg=55.14 t/s, draft acceptance=0.78076 (349/447), mean len=3.34

对比 08-27 原 benchmark（128K）：52.21 tok/s，接受率 0.752 —— 本次略优。无 MTP 时只有 30.9 tok/s，MTP 是本机性能关键。

5.2 视觉（自绘图，客观可验证）

测试图：白底 + 左上红圆 + 右上蓝方 + 中下绿三角 + 底部黑字 RIDGE-2026

elapsed 8.34s
回答：图中共有三个几何形状……
     1. 圆形 —— 左上，红色
     2. 正方形 —— 右上，蓝色
     3. 三角形 —— 中间偏下，绿色
     图上文字（黑色粗体，位于底部）写的是：RIDGE-2026

形状、位置、颜色、文字全部正确。/v1/models 的 capabilities 已报告 ["completion","multimodal"]。

5.3 图像编码耗时对比（同一张图）

mmproj 位置	prompt eval	端到端
CPU（long 模式，`--no-mmproj-offload`）	26695 ms / 1065 token（40 tok/s）	33.4s
GPU（fast 模式）	1077 ms / 371 token（344 tok/s）	8.34s

5.4 long 模式（128K）验收 —— 当前生效配置

切换后重跑同一套验收（2026-09-13）：

[1] 长文本基准（500 token）
    completion_tokens=500  elapsed=9.27s  e2e=53.9 tok/s      ← 与 fast 模式一致
[3] 视觉测试
    elapsed 33.66s                                            ← CPU 编码的代价
    answer: 圆形(左上/红)、正方形(右上/蓝)、三角形(中下/绿)、文字 RIDGE-2026  ← 全部正确

/v1/models 确认：n_ctx = 131072、n_ctx_train = 262144、n_params = 27.3B、size = 11.73 GiB。两单元状态：llama-ridge = inactive、llama-ridge-long = active、二者 is-enabled = disabled。

6. 客户端接入

# 从 DSH 机（192.168.31.76）调用 —— 注意 --noproxy
curl -s --noproxy '*' http://192.168.31.31:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen3.8-27b-ridge","messages":[{"role":"user","content":"你好"}],"max_tokens":800}'

Trae / Cherry：新增 OpenAI 兼容供应商 → Base URL http://192.168.31.31:8080/v1 → 模型名 qwen3.8-27b-ridge（API key 随便填，服务端不校验）
Open WebUI（192.168.31.76:3000）：可增加第二个连接指向同一 Base URL
⚠️ 与 LM Studio 互斥：Ridge 占用 14.9 GB 显存。switch-ridge.sh 会自动 lms unload --all；反过来要用 LM Studio 的模型（1234 端口）或 ComfyUI 出图前，先 bash ~/stop-ridge.sh
⚠️ 思考型模型：max_tokens 建议 ≥1000，否则可能全被思考链吃掉而返回空正文

7. 踩坑记录（本次新增，供以后复用）

KV cache 是第一个拦路虎：128K 上下文在 q4_0 KV 下要 8192 MiB，f16 KV 直接 OOM。先检查 -ctk/-ctv —— 这也是 08-27 那批成功日志与首次复现失败的唯一差别（线索来自 ~/Downloads/mtp_speedtest.sh 里的基础命令）。
视觉编码器要 888 MiB 连续显存，且分配发生在 KV 之前/附近；显存只剩 700 多 MiB 时会 GGML_ASSERT(buffer) failed 直接 abort（不是优雅报错）。取舍见第 3 节。
echo pass | sudo -S tee file <<EOF 会失败：heredoc 抢占了 stdin，sudo 读到的是脚本内容 → 三次密码错误。改为「先写到 ~/，再 sudo cp」。
SSH 长命令会丢输出/被中断：expect 封装的 ssh_exec.sh 对超过 ~30 秒的命令会丢结果，且远端进程会随会话结束被杀。需要长时间运行的排查脚本一律 setsid nohup ... > log 2>&1 < /dev/null &，再分次轮询日志；服务本体则交给 systemd。
~/Downloads（大写）与 ~/downloads（小写）是两个不同目录，9B 模型在小写目录里。
lms 的 -y 与 lms import 的坑、lms ls 十进制 GB 等既有坑见 GPU机LMStudio模型清单-2026-09-13.md。

8. 待办 / 可选优化

Open WebUI 接入：加第二个 OpenAI 连接到 192.168.31.31:8080/v1，网页端即可选用 Ridge。
中间档位试探：64K 与 96K 之间（如 80K）未逐点测试，若需更长上下文可试 81920。
RVN 两档未测：~/Downloads/RVN-Q3_K_{S,M}_multilingual-mtp.gguf（11.67 / 12.81 GiB）下载后从未 benchmark。
重复文件清理：~/Downloads 与 ~/.lmstudio/models 有大量同文件双份，约 30+ GiB；磁盘已用 89%（剩 123G）。
开机自启：如需长期常驻可 systemctl enable llama-ridge，但不建议 —— 会与 ComfyUI/LM Studio 抢显存。

9. 关于「Ridge 是不是无审查版」

结论：不是。 Ridge 是对官方对齐版的纯量化，安全对齐层完整保留。

证据：

来源	内容
模型卡	`base_model: Qwen/Qwen3.8-27B`、`base_model_relation: quantized`（只是量化，未做 abliteration/heretic 改写）
GGUF 元数据	`general.name = Qwen3.8 27B Bf16`、`general.basename = Qwen3.8`（官方基座命名，无 abliterated 痕迹）
实测行为	见下表 —— 创作类内容宽松，但这不等于无审查

9.1 拒答实测（2026-09-13，long 模式，128K）

探针	结果
暴力血腥创作（要求详细血腥细节）	完全照做，344 字详细血腥描写，`finish_reason: stop`，无任何拒答或说教
粗口对白（要求真实脏话、不许打星号）	完全照做，953 字，直接使用「他妈」等粗口
——	结论：在小说/剧本创作场景，Ridge 的表现与无审查版几乎没有差别

注：首次探针因 max_tokens=2000 全被思考链吃掉而返回空正文（该模型思考极长），加大到 4000 后才拿到结果 —— 这也是使用该模型时的通用注意点。

真正的差别在更硬的护栏上（政治敏感、色情等），对齐版会挡而 abliterated 不会。这类内容未做实测。

9.2 若确实需要真·无审查版，现成选项

选项	体积	位置	状态
`RVN-Q3_K_S-multilingual-mtp.gguf`	11.67 GiB	GPU 机 `~/Downloads/`（已在磁盘）	heretic + abliterated + uncensored + roleplay（`cole17e/Qwen3.8-27B-Heretic-Abliterated-Uncensored-GGUF`，GGUF 内名 `Qwen38 Ara v5`），带 MTP，从未测试
`RVN-Q3_K_M-multilingual-mtp.gguf`	12.81 GiB	同上	同上（Q3_K_M 档）
`huihui-qwen3.8-27b-abliterated@q3_k_xl`	12.41 GiB	LM Studio 已注册	abliterated，可立即用本报告同一套 llama.cpp 参数部署
`qwen3.8-27b-heretic-ara-16gb-vram-xs-mtp`	13.35 GiB	LM Studio 已注册	Ara v5 heretic，带 MTP，未实测性能
`qwen3.8-27b-fable-distill-heretic-ara-i1`	14.26 GiB	LM Studio 已注册	Fable 蒸馏 heretic，未实测
`qwen3.8-9b-heretic-uncensored-nvfp4`	4.82 GiB	LM Studio 已注册	Heretic，拒答率 100→22/100，70 tok/s
`caiyi/…Huihui-…abliterated-KO-Ridge-3.7bpw`	11.73 GiB	上游待下载	abliterated + 同款 Ridge 量化，体积与 Ridge 完全一致 → 性能可预期同级；仓库另附 `run-rtx5060ti.sh`。视觉需配 huihui 仓库的 `mmproj-model-bf16.gguf`（0.87 GiB）另测

推荐：要零下载就用已在本机的 RVN-Q3_K_S（带 MTP，最接近 Ridge 的形态）；要与 Ridge 完全同级的性能就下 caiyi 的 KO-Ridge 3.7bpw。

部署人：DSH 会话 · 部署与验收：2026-09-13 · 模型：empero-ai/Qwen3.8-27B-Ridge-GGUF（3.69 bpw，11.73 GiB） 相关文档：Qwen3.8-27B-Ridge混合量化部署实测-补录2026-09-13.md（08-27 原始 benchmark 与机制说明）· GPU机LMStudio模型清单-2026-09-13.md（全库清单）

Qwen3.8-27B-Ridge部署报告-2026-09-13.md