← 返回列表

GPU机LMStudio模型清单-2026-09-13.md

GPU 机 LM Studio 模型清单与体积核查（2026-09-13）

核查对象：GPU 机 192.168.31.31（zywpc）上的 LM Studio / llmster 模型库 核查动机：确认「是否存在一个 11 GB 出头的 Qwen3.8-27B 档」 核查方式：lms ls / lms ls --json + find ~/.lmstudio/models -type f -printf '%s' 逐文件字节数核对 + hf-mirror 上游仓库 API 全量化档比对 ⚠️ 2026-09-13 更正（同日二次核查，推翻本文档初版两处结论）：

  1. 初版称「本机没有 11 GB 的 27B」——错误。~/Downloads 里存在未导入 LM Studio 的游离 GGUF：Qwen3.8-27B-Ridge-3.7bpw.gguf（11.73 GiB）、RVN-Q3_K_S-multilingual-mtp.gguf（11.67 GiB）等，且 Ridge 已于 2026-08-27 用 llama.cpp 完整 benchmark（128K + MTP ≈ 50 tok/s，视觉已验证）。详见 Qwen3.8-27B-Ridge混合量化部署实测-补录2026-09-13.md。
  2. 初版称「全部模型无视觉能力」——仅对 LM Studio 注册表成立。GPU 机 ~/Downloads 已有 27B 的 mmproj（0.87 GiB）且实测可用，基础模型 Qwen3.8-27B 本身即 image-text-to-text。

结论速览（修正后）：LM Studio 注册表内 11 个模型最小 27B 为 12.24 GiB、且全为纯文本；但磁盘上另有一批未注册的低比特混合量化模型，其中 Ridge 3.7bpw 是目前该机上综合最优的 27B 方案。

1. 当前运行状态

项值
已加载模型qwen3.8-9b-heretic-uncensored-nvfp4（256K 上下文，PARALLEL 4，IDLE）
显存占用13300 MiB / 16311 MiB（约 13.0 GiB）
HTTP 服务运行中：http://192.168.31.31:1234（OpenAI 兼容，bind 0.0.0.0）
服务启动方式lms server start --bind 0.0.0.0 --port 1234（daemon 重启后必须手动补这一步）
模型库总占用~/.lmstudio/models = 118 GiB；~/.lmstudio 全目录 = 120 GiB
磁盘/dev/sda5 1.2T，已用 965G，剩余 123G（89%）
已装模型数11（10 个 LLM + 1 个 embedding），lms ls 报 126.08 GB

⚠️ 两套体积口径必须分清（本文档同时给出）：

  • GiB（1024³，磁盘真实占用）＝ find -printf %s / 1073741824
  • GB（1000³，lms ls 显示口径）＝ GiB × 1.0737

换算关系：lms ls 显示的 13.15 GB ⇔ 磁盘上 12.24 GiB。这是「11 GB 档」记忆混淆的主要来源。

2. 本机已装模型全表（11 个）

2.1 LLM（10 个，按体积升序）

模型 key（API 标识）磁盘 GiBlms ls GB量化显存/速度实测备注
qwen2.5-1.5b-instruct1.041.12Q4_K_M~205 tok/s老小模型，现基本闲置
qwen3.8-9b-heretic-uncensored-nvfp44.825.18NVFP4+Q4_K_M13.0 GiB / ~70 tok/s256K 上下文全 GPU；无 MTP head
qwen3.8-27b@q3_k_xl12.2413.15UD-Q3_K_XL15.3 GiB / 29.9 tok/s官方版推荐默认，16K 上下文
huihui-qwen3.8-27b-abliterated@q3_k_xl12.4113.33UD-Q3_K_XL15.8 GiB / ~30 tok/s无审核快速版，上限 21504（21K）
qwen3.8-27b@iq4_xs13.2714.25UD-IQ4_XS~28.8 tok/s质量略好于 Q3_K_XL，8K 上下文
qwen3.8-27b-heretic-ara-16gb-vram-xs-mtp13.3514.33IQ4_XS+MTP未实测带 MTP（推测解码），注意 MTP 会额外吃显存
qwen3.8-27b-fable-distill-heretic-ara-i114.2615.31IQ4_XS未实测Fable 蒸馏 heretic 版
qwen3.8-27b-nvfp414.9616.06NVFP49.1 tok/s不推荐：llama.cpp FP4 内核不成熟
qwen3.8-27b@q4_k_m15.3316.46UD-Q4_K_M~5.5 tok/s必须部分卸载（--gpu 0.70），慢 5 倍
huihui-qwen3.8-27b-abliterated@q4_k15.6616.81Q4_K~5 tok/s旧慢档，保留备用

2.2 Embedding（1 个）

模型 key体积位置用途
text-embedding-nomic-embed-text-v1.584.11 MB~/.lmstudio/.internal/bundled-models/nomic-ai/（LM Studio 自带，非 models 目录）Open WebUI 的 RAG 嵌入

2.3 磁盘文件路径明细（~/.lmstudio/models/）

unsloth/Qwen3.8-27B-GGUF/                        41G
  ├─ Qwen3.8-27B-UD-Q3_K_XL.gguf                 12.24 GiB
  ├─ Qwen3.8-27B-UD-IQ4_XS.gguf                  13.27 GiB
  └─ Qwen3.8-27B-UD-Q4_K_M.gguf                  15.33 GiB
huihui-ai/Huihui-Qwen3.8-27B-abliterated-GGUF/   29G
  ├─ Huihui-Qwen3.8-27B-abliterated-UD-Q3_K_XL.gguf   12.41 GiB
  └─ Huihui-Qwen3.8-27B-abliterated-Q4_K.gguf         15.66 GiB
mradermacher/Qwen3.8-27B-Fable-Distill-Heretic-ara-i1/  15G
  └─ mradermacher_iq4xs.gguf                     14.26 GiB
williamliao/Qwen3.8-27B-NVFP4-GGUF/              15G
  └─ Qwen3.8-27B-NVFP4-Quality-v2.gguf           14.96 GiB
Bucoid/Qwen3.8-27B-Heretic-Ara-16GB-VRAM-IQ4-XS-MTP/    14G
  └─ bucoid_3.0_mtp.gguf                         13.35 GiB
Noobito45/Qwen3.8-9B-heretic-uncensored-NVFP4-GGUF/     4.9G
  └─ Qwen3.8-9B-distill-heretic_nvfp4_q4_k_m.gguf      4.82 GiB
Qwen/Qwen2.5-1.5B-Instruct-GGUF/                 1.1G
  └─ qwen2.5-1.5b-instruct-q4_k_m.gguf           1.04 GiB

3. 「11 GB 的 27B」到底是什么

答案有两层，初版只答对了第一层：

第一层（LM Studio 注册表内）：UD-IQ3_S 量化档 —— 上游有、LM Studio 里没有。逐字节核对注册的 8 个 27B GGUF 文件，最小 12.24 GiB。⚠️ 但初版由此推出的「不存在有文件但未注册的情况」是错的 —— 我当时的全盘扫描命令输出被截断（只看到了体积最小的一批文件），漏掉了 ~/Downloads 下的大文件。

第二层（真实答案）：用户记忆中的 11 GB 档就在 GPU 机上，是 Empero 的 Ridge 混合量化：

文件体积状态
/home/zyw/Downloads/Qwen3.8-27B-Ridge-3.7bpw.gguf11.73 GiB✅ 2026-08-27 已 benchmark
/home/zyw/Downloads/RVN-Q3_K_S-multilingual-mtp.gguf11.67 GiB❌ 未测
/home/zyw/Downloads/RVN-Q3_K_M-multilingual-mtp.gguf12.81 GiB❌ 未测

这三份都游离在 ~/.lmstudio/models 之外，从未被 lms import 导入，因此 lms ls 完全看不到 —— 这正是初版误判的根因。详见 Ridge 专项报告。

3.1 上游全部 11 GB 档（hf-mirror API 实查）

仓库文件名体积本机
unsloth（官方）Qwen3.8-27B-UD-IQ3_S.gguf11.21 GiB❌ 未下载
huihui（无审核）Huihui-Qwen3.8-27B-abliterated-UD-IQ3_S.gguf11.13 GiB❌ 未下载
huihui（无审核+GSQ-RCO）Huihui-...-GSQ-RCO-IQ3_S.gguf10.96 GiB❌ 未下载
huihui（无审核+MTP）Huihui-...-GSQ-RCO-IQ3_S-mtp.gguf11.29 GiB❌ 未下载

3.2 为什么容易记成 11 GB

  1. 口径混淆：本机已装的 UD-Q3_K_XL 磁盘 12.24 GiB，而 lms ls 显示 13.15 GB；反过来 IQ3_S 的 11.21 GiB 在 lms 口径下是 12.0 GB。任一口径在两个档之间来回看，就会得到「11 GB 多」的印象。
  2. LM Studio 内置模型目录会直接列出 IQ3_S 的 11.2 GiB 下载项，即使从没下过也会留下印象。

3.3 结论：不建议下载 IQ3_S

对比项已装 UD-Q3_K_XL上游 UD-IQ3_S
体积12.24 GiB11.21 GiB（仅小 1.03 GiB）
质量Q3_K 系（较好）IQ3 系（明显更低，IQ 系对 27B 压到 3-bit 损伤更大）
满配可行性已验证 --gpu max --context-length 16384，15.3 GiB / 16.3 GiB，29.9 tok/s可省约 1 GiB 换更长上下文

省下的 1 GB 换不来质变：16 GB 卡上 Q3_K_XL 已经能全 GPU + 16K 上下文。除非明确目标是「必须腾出 1 GB 去跑 32K 上下文」，否则下了没有体感提升。真要更小，UD-IQ3_XXS（10.18 GiB）同理不推荐。

3.4 附：官方 27B 上游全量化档（供以后选型）

46.55 GiB  BF16               22.53 GiB  UD-Q6_K_L        16.34 GiB  Q4_1
29.30 GiB  UD-Q8_K_XL         21.50 GiB  UD-Q6_K_M        15.33 GiB  UD-Q4_K_M  ← 已装
27.05 GiB  Q8_0               20.47 GiB  UD-Q6_K          14.95 GiB  Q4_0
26.12 GiB  UD-Q8_K_L          19.44 GiB  UD-Q5_K_XL       14.30 GiB  UD-Q4_K_S
23.56 GiB  UD-Q6_K_XL         18.41 GiB  UD-Q5_K_M        13.27 GiB  UD-IQ4_XS  ← 已装
                              17.38 GiB  UD-Q5_K_S        12.24 GiB  UD-Q3_K_XL ← 已装
                              16.35 GiB  UD-Q4_K_XL       11.21 GiB  UD-IQ3_S
                                                          10.18 GiB  UD-IQ3_XXS
                                                           9.15 GiB  UD-Q2_K_XL
                                                           7.80 GiB  UD-IQ2_S
                                                           6.77 GiB  UD-IQ2_XXS
                                                           6.27 GiB  UD-IQ1_M
                                                           5.77 GiB  UD-IQ1_S

无审核 huihui 仓库的小档（供参考）：UD-IQ2_S 7.85 / UD-Q2_K_XL 9.32 / GSQ-RCO-IQ3_XXS 9.40 / Q2_K 10.12 / UD-IQ3_XXS 10.26 / UD-IQ3_S 11.13 / GSQ-RCO-IQ3_S-mtp 11.29 GiB。

4. 关于「纯文本模型收到图片报 400」的完整结论

报错原文（Trae 等客户端发图给 qwen3.8-9b-heretic-uncensored-nvfp4 时）：

{"error":{"message":"The provided messages contain images, but
 qwen3.8-9b-heretic-uncensored-nvfp4 does not support image inputs.",
 "type":"invalid_request_error","param":"messages","code":"invalid_value"}}

对照实验（2026-09-13 实测，同一端点同一模型）：

请求结果
纯文本消息HTTP 200，正常返回
含 image_url 内容块HTTP 400，报错与上文字字一致

结论：服务端健康、网络正常、模型加载正常 —— 这是模型能力边界。LM Studio 注册表内的 11 个模型全部为纯文本（该目录下 find -iname "*mmproj*" 无结果，也未装 ollama），服务端收到图像内容块即拒绝；重试、改温度、调 max_tokens 均无效。

⚠️ 但「这台机器不能看图」是错的：GPU 机 ~/Downloads 里已备好 27B 的 mmproj-Qwen3.8-27B-BF16.gguf（0.87 GiB），配对 Ridge 模型后 2026-08-27 实测 loaded multimodal model 成功，且 128K 上下文下带视觉仍有 51.64 tok/s（几乎不降速）。基础模型 Qwen3.8-27B 官方即为 image-text-to-text 多模态。详见 Ridge 专项报告。

处置：客户端里删掉图片附件重发纯文本即可。若确实需要看图，走第 6 节方案。

附带坑：该 9B 为思考型模型，实测 133 个生成 token 中 129 个是 reasoning。客户端 max_tokens 若设得过小（<200）会表现为「回复为空/只转圈」，易误判为模型故障，建议 ≥1500。

5. 可选的「让模型能看图」三条路（均未执行，供决策）

方案成本优点缺点
A. 补下 mmproj（第 6 节）0.86 GiB，约 1 分钟同一个 9B 直接变多模态，Trae 里可原生发图heretic 蒸馏后视觉能力是否保留未验证
B. 两步走：vision-identify 技能（DeepSeek-V4-Flash-Vision-Exp 官方 API）把图转文字，再喂给 9B0（本机已有）识图质量最好，不下载、不占显存，立即可用需人工搬一次文字
C. 独立本地视觉模型：本机已有 ~/Downloads/vlm-models/（Qwen2.5-VL-3B Q4_K_M 1.8G + mmproj-F16 1.3G，llama.cpp vlm-env/vlm_server.py）0（已存在，未运行）完全本地、免费3B 精细识别弱于官方 API

6. 【重要】可解锁图片输入的上游 mmproj 文件

核查上游仓库时发现，两个已装模型的仓库都提供视觉投影文件 —— 下载后放入同一模型目录，LM Studio 会将该模型识别为多模态：

目标模型需补文件体积来源仓库
qwen3.8-9b-heretic-uncensored-nvfp4mmproj-BF16.gguf0.858 GiBNoobito45/Qwen3.8-9B-heretic-uncensored-NVFP4-GGUF
huihui-qwen3.8-27b-abliteratedmmproj-model-bf16.gguf0.87 GiBhuihui-ai/Huihui-Qwen3.8-27B-abliterated-GGUF

⚠️ 更正（09-13 二次核查）：27B 的 mmproj 早就下载好了，无需再补 —— /home/zyw/Downloads/mmproj-Qwen3.8-27B-BF16.gguf（0.87 GiB，08-27）与 mmproj-Qwen3.8-27B-F16.gguf（0.86 GiB），且实测 loaded multimodal model 成功。下表 9B 那行仍成立（其 mmproj 确未下载），但更优的看图方案是直接用 Ridge 27B + 已备好的 mmproj（11.73 + 0.87 GiB 完全塞得进 16GB，且带 128K 上下文）。

意义：这是「用同一个模型看图」的路径，可彻底消除第 4 节的 400 报错。9B 的成本仅 0.86 GiB，风险点是蒸馏版是否保留视觉能力 —— 装完发一张图即可验证。Ridge 27B 的视觉能力则已实测验证。

另注：9B 仓库还有 ..._nvfp4_q8_0.gguf（5.654 GiB）质量档，比现用的 q4_k_m（4.82 GiB）高，需要质量时可换（显存仍有余量）。

7. 运维要点速查（含本次踩坑）

# 启动 daemon + 服务（GPU 机；手动模式，不开机自启）
echo yueling408 | sudo -S systemctl start lmstudio
lms server start --bind 0.0.0.0 --port 1234   # daemon 重启后必须补这一步才恢复 API

# 模型列表 / 已加载
lms ls          # 注意：显示十进制 GB，比磁盘 GiB 大 7.4%
lms ps

# 9B 满配加载（推荐直接用现成脚本）
bash ~/switch-heretic-9b.sh    # = lms load ... --gpu max --context-length 262144 -y
lms unload --all               # 释放显存（用 ComfyUI 前必须执行）

坑速记：

  1. lms ls 的 GB ≠ GiB：12.24 GiB 显示为 13.15 GB，反向换算易造成「11 GB 档」这类记忆偏差。
  2. 换配置前必须先 lms unload --all，否则瞬时 OOM（报 kv cache / pp buffers 分配失败）。
  3. lms load 手动加载的模型不受 Auto-Evict 管理，会钉住显存导致后续 JIT 切换失败；单模型场景下用脚本显式加载反而更快（满配 31 tok/s vs JIT 慢加载 8 tok/s）。
  4. 9B 无 MTP：--speculative-draft-mtp 会直接报错（无捆绑 MTP head）；带 MTP 的是 qwen3.8-27b-heretic-ara-16gb-vram-xs-mtp。
  5. 与 ComfyUI 显存互斥：9B 满配占 13.0 GiB，27B 档占 15.3+ GiB，出图/出视频前务必 lms unload --all。
  6. 本机访问必须加 --noproxy '*'（DSH 机 ALL_PROXY=socks5h 会把局域网请求拐走）。
  7. hf-mirror 可用（实测 HTTP 200 / 0.45s），HF 官方域名在本网不可达；下载走 hf-mirror。

8. 核查命令（可复现）

# 1. 注册表（十进制 GB）
lms ls; lms ls --json

# 2. 磁盘真实字节数（GiB）—— 识别"未注册文件"的关键
find ~/.lmstudio/models -type f -iname "*.gguf*" -printf "%s\t%p\n" | sort -rn

# 3. 视觉投影文件核查（本次结论：全部为纯文本）
find ~/.lmstudio -iname "*mmproj*"

# 4. 上游量化档全表
curl -s "https://hf-mirror.com/api/models/unsloth/Qwen3.8-27B-GGUF?blobs=true" \
 | python3 -c "import sys,json;[print('%8.2f GiB  %s'%((s.get('size') or 0)/1073741824,s['rfilename'])) for s in json.load(sys.stdin)['siblings'] if s['rfilename'].endswith('.gguf')]"

核查人：DSH 会话 · 核查时间：2026-09-13 03:45 · 环境：llmster（LM Studio 0.4.21 无头版），CLI commit 71bd99c

下载此文件