model cleanup

apb commented

2026-09-02 21:42:33 +01:00

Owner

Fixing models

mistral-medium
qwen-coder-next

Fixing models * mistral-medium * qwen-coder-next

apb commented

2026-09-03 10:41:07 +01:00

Author

Owner

Investigation complete. Here's the report:

Model files
~/.lmstudio/models (228G, mostly real files)
Model File Size
empero-ai/Qwythos-9B-Claude-Mythos-5-1M-GGUF Qwythos-9B-…-MTP-Q8_0.gguf + mmproj-f16 9.8G + 918M
LiquidAI/LFM2.5-VL-450M-GGUF Q8_0 + mmproj-F32 379M + 377M
lmstudio-community/gemma-4-12B-it-QAT Q4_0 + mmproj-BF16 7.0G + 175M
lmstudio-community/gemma-4-26B-A4B-it Q4_K_M + mmproj-BF16 16.8G + 1.2G
lmstudio-community/gemma-4-E4B-it Q4_K_M + mmproj-BF16 5.3G + 992M
lmstudio-community/GLM-4.7-Flash-GGUF Q8_0 (single file) 31.8G
lmstudio-community/mine/ Qwen3.5-27B-Claude-4.6-Opus-Distilled.i1-Q6_K 22.1G
lmstudio-community/Qwen3.6-27B Q8_0 + mmproj-BF16 28.6G + 931M
lmstudio-community/Qwen3.6-35B-A3B Q4_K_M + mmproj-BF16 21.2G + 903M
lmstudio-community/Qwen3-Coder-Next Q4_K_M (single file) 48.5G
lmstudio-community/Qwen3-VL-30B-A3B-Instruct Q4_K_M + mmproj-F16 18.6G + 1.1G
openbmb/MiniCPM-V-4-gguf ggml-model-Q4_K_S + mmproj-f16 symlinks
ggml-org/MiniCPM-V-4.6-GGUF Q4_K_M + mmproj-Q8_0 symlinks
tashfene/Ornith-1.0-35B-MTP-Q4_K_M ornith-1.0-35b-MTP-graft-Q4_K_M 21.7G
tencent/Youtu-VL-4B-Instruct Q8_0 + mmproj-BF16 5.2G + 893M
unsloth/MiniMax-M2.7-GGUF/UD-IQ4_XS 4-part split GGUF symlink to dir, 8.2M + 49.6G + 49.6G + 9.2G (≈109G)
unsloth/MiniMax-M2.7-GGUF/UD-IQ3_XXS 3-part split GGUF symlink to dir, 8.2M + 50.0G + 30.1G (≈88G)
unsloth/Mistral-Medium-3.5-128B-GGUF/Q4_K_M 2-part split GGUF ⚠️ broken — see below
~/.cache/huggingface/hub (291G)

Standard HF layout: blobs/ (real content-addressed data) ← snapshots// symlinks.

unsloth/MiniMax-M2.7-GGUF — 176G; both split sets intact
unsloth/Mistral-Medium-3.5-128B-GGUF — 75G (24G + 47G blobs + 5.1G mmproj-BF16 + 7.6M)
unsloth/Muse-Glimmer-30B-GGUF — Muse-Glimmer-30B-UD-Q4_K_XL (15.9G) + mmproj-Q8_0 (2.1G)
deepreinforce-ai/Ornith-1.0-35B-GGUF — ornith-1.0-35b-Q4_K_M (21.2G)
ggml-org/MiniCPM-V-4.6-GGUF (1.2G), openbmb/MiniCPM-V-4-gguf (2.9G)

Findings

⚠️ Broken: Mistral-Medium-3.5-128B Q4_K_M (most important)

~/.lmstudio/models/unsloth/Mistral-Medium-3.5-128B-GGUF/Q4_K_M → snapshot dir …/snapshots/c8f5b1…/Q4_K_M, which is empty (mtime Aug 10 12:30).
The actual data is still there as orphan blobs: 24G (3f4ddc…) + 47G (839639…) ≈ 72G, consistent with a 2-part Q4_K_M of a 128B model. The snapshot symlinks to them were deleted, so llama.cpp/LM Studio sees no files under that path. The mmproj (mmproj-BF16.gguf, 5.1G) still resolves fine.
No .incomplete/.part/.tmp files anywhere, and no broken symlinks elsewhere — so the blobs are almost certainly complete downloads, just unlinked. Fixable cheaply: recreate symlinks in the snapshot dir (e.g. Mistral-Medium-3.5-128B-Q4_K_M-00001-of-00002.gguf → ../../blobs/3f4ddc… and -00002-… → ../../blobs/839639…), or re-run the HF download to re-link.

Symlinks (all healthy, by design)

7 symlinks under ~/.lmstudio/models pointing into the HF cache — this is how LM Studio registers HF-downloaded models without duplicating ~300G. Two of them (MiniMax UD-IQ4_XS / UD-IQ3_XXS) point at subdirectories of split GGUFs, so the model entry is a folder, not a file.
The HF cache itself uses the standard blob→snapshot symlink scheme; all resolve.

Orphaned / unlinked cache models

deepreinforce-ai/Ornith-1.0-35B-GGUF and unsloth/Muse-Glimmer-30B-GGUF exist in the HF cache (38G total) but have no corresponding entry under ~/.lmstudio/models. Note tashfene/Ornith-1.0-35B-MTP-Q4_K_M is a different file (MTP graft, 21.7G real file). If these two cache models aren't referenced by path from your llama.cpp containers, the 38G is reclaimable.

Odd file: ~/.lmstudio/models/glmmods — a plain 1.8KB ASCII text file (LM Studio "lmstudio" spec format: FROM hf.co/unsloth/GLM-4.7-Flash-GGUF:Q6_K + manual TEMPLATE for Cline tool behavior) sitting directly in the models root, not in a model directory. It references a Q6_K that isn't present locally (you have GLM-4.7-Flash Q8_0 in lmstudio-community). Worth confirming it's meant to be a model spec LM Studio parses vs. a leftover note.

Nothing else of concern: no partial downloads, no zero-byte files, disk usage fine (629G free, 65% used).

Investigation complete. Here's the report: 1. Model files ~/.lmstudio/models (228G, mostly real files) Model File Size empero-ai/Qwythos-9B-Claude-Mythos-5-1M-GGUF Qwythos-9B-…-MTP-Q8_0.gguf + mmproj-f16 9.8G + 918M LiquidAI/LFM2.5-VL-450M-GGUF Q8_0 + mmproj-F32 379M + 377M lmstudio-community/gemma-4-12B-it-QAT Q4_0 + mmproj-BF16 7.0G + 175M lmstudio-community/gemma-4-26B-A4B-it Q4_K_M + mmproj-BF16 16.8G + 1.2G lmstudio-community/gemma-4-E4B-it Q4_K_M + mmproj-BF16 5.3G + 992M lmstudio-community/GLM-4.7-Flash-GGUF Q8_0 (single file) 31.8G lmstudio-community/mine/ Qwen3.5-27B-Claude-4.6-Opus-Distilled.i1-Q6_K 22.1G lmstudio-community/Qwen3.6-27B Q8_0 + mmproj-BF16 28.6G + 931M lmstudio-community/Qwen3.6-35B-A3B Q4_K_M + mmproj-BF16 21.2G + 903M lmstudio-community/Qwen3-Coder-Next Q4_K_M (single file) 48.5G lmstudio-community/Qwen3-VL-30B-A3B-Instruct Q4_K_M + mmproj-F16 18.6G + 1.1G openbmb/MiniCPM-V-4-gguf ggml-model-Q4_K_S + mmproj-f16 symlinks ggml-org/MiniCPM-V-4.6-GGUF Q4_K_M + mmproj-Q8_0 symlinks tashfene/Ornith-1.0-35B-MTP-Q4_K_M ornith-1.0-35b-MTP-graft-Q4_K_M 21.7G tencent/Youtu-VL-4B-Instruct Q8_0 + mmproj-BF16 5.2G + 893M unsloth/MiniMax-M2.7-GGUF/UD-IQ4_XS 4-part split GGUF symlink to dir, 8.2M + 49.6G + 49.6G + 9.2G (≈109G) unsloth/MiniMax-M2.7-GGUF/UD-IQ3_XXS 3-part split GGUF symlink to dir, 8.2M + 50.0G + 30.1G (≈88G) unsloth/Mistral-Medium-3.5-128B-GGUF/Q4_K_M 2-part split GGUF ⚠️ broken — see below ~/.cache/huggingface/hub (291G) Standard HF layout: blobs/ (real content-addressed data) ← snapshots/<rev>/<file> symlinks. unsloth/MiniMax-M2.7-GGUF — 176G; both split sets intact unsloth/Mistral-Medium-3.5-128B-GGUF — 75G (24G + 47G blobs + 5.1G mmproj-BF16 + 7.6M) unsloth/Muse-Glimmer-30B-GGUF — Muse-Glimmer-30B-UD-Q4_K_XL (15.9G) + mmproj-Q8_0 (2.1G) deepreinforce-ai/Ornith-1.0-35B-GGUF — ornith-1.0-35b-Q4_K_M (21.2G) ggml-org/MiniCPM-V-4.6-GGUF (1.2G), openbmb/MiniCPM-V-4-gguf (2.9G) 2. Findings ⚠️ Broken: Mistral-Medium-3.5-128B Q4_K_M (most important) ~/.lmstudio/models/unsloth/Mistral-Medium-3.5-128B-GGUF/Q4_K_M → snapshot dir …/snapshots/c8f5b1…/Q4_K_M, which is empty (mtime Aug 10 12:30). The actual data is still there as orphan blobs: 24G (3f4ddc…) + 47G (839639…) ≈ 72G, consistent with a 2-part Q4_K_M of a 128B model. The snapshot symlinks to them were deleted, so llama.cpp/LM Studio sees no files under that path. The mmproj (mmproj-BF16.gguf, 5.1G) still resolves fine. No .incomplete/.part/.tmp files anywhere, and no broken symlinks elsewhere — so the blobs are almost certainly complete downloads, just unlinked. Fixable cheaply: recreate symlinks in the snapshot dir (e.g. Mistral-Medium-3.5-128B-Q4_K_M-00001-of-00002.gguf → ../../blobs/3f4ddc… and -00002-… → ../../blobs/839639…), or re-run the HF download to re-link. Symlinks (all healthy, by design) 7 symlinks under ~/.lmstudio/models pointing into the HF cache — this is how LM Studio registers HF-downloaded models without duplicating ~300G. Two of them (MiniMax UD-IQ4_XS / UD-IQ3_XXS) point at subdirectories of split GGUFs, so the model entry is a folder, not a file. The HF cache itself uses the standard blob→snapshot symlink scheme; all resolve. Orphaned / unlinked cache models deepreinforce-ai/Ornith-1.0-35B-GGUF and unsloth/Muse-Glimmer-30B-GGUF exist in the HF cache (38G total) but have no corresponding entry under ~/.lmstudio/models. Note tashfene/Ornith-1.0-35B-MTP-Q4_K_M is a different file (MTP graft, 21.7G real file). If these two cache models aren't referenced by path from your llama.cpp containers, the 38G is reclaimable. Odd file: ~/.lmstudio/models/glmmods — a plain 1.8KB ASCII text file (LM Studio "lmstudio" spec format: FROM hf.co/unsloth/GLM-4.7-Flash-GGUF:Q6_K + manual TEMPLATE for Cline tool behavior) sitting directly in the models root, not in a model directory. It references a Q6_K that isn't present locally (you have GLM-4.7-Flash Q8_0 in lmstudio-community). Worth confirming it's meant to be a model spec LM Studio parses vs. a leftover note. Nothing else of concern: no partial downloads, no zero-byte files, disk usage fine (629G free, 65% used).

apb commented

2026-09-03 11:40:12 +01:00

Author

Owner

Updated the [Mistral-Medium-3.5-128B] entry:

[Mistral-Medium-3.5-128B]
model =
/hf-cache/models--unsloth--Mistral-Medium-3.5-128B-GGUF/snapshots/c8f5b1477e1b22cd2d819157d450f001f7047298/Q4_K_M/Mist
ral-Medium-3.5-128B-Q4_K_M-00001-of-00003.gguf

Key points:

First shard only — llama.cpp detects the -00001-of-00003 naming and automatically loads parts 2 and 3 from the same
directory (7.6M + 47G + 24G ≈ 72G total).
Why not the /models/unsloth/... path: your old entry pointed at the symlinked dir under ~/.lmstudio/models, but
those LM Studio symlinks are absolute host paths (/home/andy/.cache/…) — broken inside the container, where the
cache lives at /hf-cache. The snapshot-internal symlinks are relative (../../blobs/…), so the /hf-cache path
resolves correctly in the container.
Optional, only if you want vision on this model (it's text-only as configured):

 mmproj =
/hf-cache/models--unsloth--Mistral-Medium-3.5-128B-GGUF/snapshots/c8f5b1477e1b22cd2d819157d450f001f7047298/mmproj-BF
16.gguf

Updated the [Mistral-Medium-3.5-128B] entry: ```ini [Mistral-Medium-3.5-128B] model = /hf-cache/models--unsloth--Mistral-Medium-3.5-128B-GGUF/snapshots/c8f5b1477e1b22cd2d819157d450f001f7047298/Q4_K_M/Mist ral-Medium-3.5-128B-Q4_K_M-00001-of-00003.gguf ``` Key points: - First shard only — llama.cpp detects the -00001-of-00003 naming and automatically loads parts 2 and 3 from the same directory (7.6M + 47G + 24G ≈ 72G total). - Why not the /models/unsloth/... path: your old entry pointed at the symlinked dir under ~/.lmstudio/models, but those LM Studio symlinks are absolute host paths (/home/andy/.cache/…) — broken inside the container, where the cache lives at /hf-cache. The snapshot-internal symlinks are relative (../../blobs/…), so the /hf-cache path resolves correctly in the container. - Optional, only if you want vision on this model (it's text-only as configured): ```ini mmproj = /hf-cache/models--unsloth--Mistral-Medium-3.5-128B-GGUF/snapshots/c8f5b1477e1b22cd2d819157d450f001f7047298/mmproj-BF 16.gguf ```

apb commented

2026-09-03 15:52:44 +01:00

Author

Owner

hf download unsloth/Mistral-Medium-3.5-128B-GGUF \
    --local-dir unsloth/Mistral-Medium-3.5-128B-GGUF \
    --include "*UD-Q4_K_XL*"

``` hf download unsloth/Mistral-Medium-3.5-128B-GGUF \ --local-dir unsloth/Mistral-Medium-3.5-128B-GGUF \ --include "*UD-Q4_K_XL*" ```

Rows
Columns

model cleanup #8