Thanks for the catch! You're right — for VLMs where initial_files = [text_model, mmproj], keeping the base GGUF and then calling reverse() would place text_model at the end instead of mmproj, breaking downstream code at line 2146 that expects mmproj as the last element.

Fixed in the latest push by swapping base_gguf past mmproj before reversal when it's a VLM (len(initial_files) > 1). Verified all 4 scenarios:

Thanks for the fix! I'm going to push a couple of commits to address a few items.

Nice catch on the root cause. The preservation logic is correct for the common case, but two edges gave me pause so I pushed follow-ups (feel free to revert if you disagree):

316af41a — use is_vlm instead of len(initial_files) > 1

convert_to_gguf extends initial_files with shard files when max_shard_size splits a large non-VLM model. The length check would then fire the VLM-only reorder for a sharded text-only model and scramble the shard list. is_vlm (already set from convert_to_gguf's return) is the semantic flag we actually want.

c9666917 — handle sharded VLMs in the reorder

For a sharded VLM, initial_files = [text_shard1, text_shard2, …, mmproj]. insert(1, pop(0)) only moves one text element, leaving mmproj mid-list after reverse() — which breaks the all_file_locations[-1] mmproj assumption at save.py:2145. Rebuilt the list explicitly so any number of text shards is handled.

Thanks for the thorough review and the follow-up commits! Both fixes make total sense:

• Using is_vlm is clearly the right call over the length check — I didn't account for sharded non-VLM models.
• The explicit list rebuild for sharded VLMs is the correct approach too, pop(0)/insert(1) was only moving one shard.

Appreciate you catching these edge cases. Happy with the changes, let's merge whenever you're ready.

Follow-up from E2E testing on unsloth/gemma-3-27b-it (sharded VLM, 2 text shards + mmproj). Exposed a pre-existing bug in the cleanup delete branch that the fix 2 work adjacent to it did not address.

6bcb02f5 — delete all text intermediates, not just base_gguf

When first_conversion is not in quantization_method, the old code did:

all_saved_locations.remove(base_gguf)
Path(base_gguf).unlink(missing_ok = True)

base_gguf = initial_files[0]. For a sharded output, that's only shard 1 — shards 2..N are left orphaned on disk AND still in the returned list, which breaks the all_file_locations[-1] == mmproj invariant consumed at save.py:2145.

Observed with quantization_method=["q4_k_m"] on gemma-3-27b-it:

• initial_files = [BF16-00001-of-00002, BF16-00002-of-00002, BF16-mmproj]
• Returned list: [Q4_K_M, BF16-mmproj, BF16-00002-of-00002] ← shard 2 stray, mmproj not at [-1]
• On disk: shard 1 gone, shard 2 (3.9G) still there as garbage

The fix iterates initial_files[:n_text] so every text part is both removed from the list and unlinked from disk. n_text excludes mmproj for VLMs so the existing mmproj preservation is untouched. Backwards compatible with the non-sharded single-file case (n_text=1, loop runs once, same behavior as before).

This is pre-existing — it was broken before this PR opened. Scoping it in because the PR is already the cleanup-logic PR and the gemma sharded test made it loud.