[Bug] Inconsistent model Cache naming causes duplicate downloads

[Sneakr]

Description:
Unsloth downloads models from HuggingFace using all lowercase names (e.g., meta-llama-3-70b-instruct), while Hugging Face Transformers uses the original casing (e.g., Meta-Llama-3-70B-Instruct).

Issue:

• This causes the same model to be downloaded twice.
• One version by Unsloth, another by AutoModel or other HF tools.

[github-actions]

Is this issue still important to you? Apologies in advance we might have missed this issue as well. For faster response times, please post on our Reddit server - https://www.reddit.com/r/unsloth or our Discord - https://discord.com/invite/unsloth

[mmathew23]

@danielhanchen Did HF ever get back to you on this one?

[Ki-Seki]

Background

Hi 😀, I'm also encountering this issue. I can confirm this isn't a problem with HF Hub. While it shouldn't be considered a bug, it's still quite important.

In HF Hub, repository names are case-sensitive by design, though different casing doesn't affect URL resolution. Different model names serve as different cache keys and are cached to different folders under the HF_HOME directory.

Issue

However, in Unsloth, for example, if the model precision is 4-bit, the following code automatically converts "unsloth/Qwen3-4B-Instruct-2507" to "unsloth/qwen3-4b-instruct-2507-bnb-4bit". NOTE: Not only does the model name change, but the casing changes as well!

This leads to duplicate downloads if I've already downloaded "unsloth/Qwen3-4B-Instruct-2507-bnb-4bit" (the capitalized version):

I believe this is a serious issue because all Unsloth notebooks are affected by this problem.

Solution

Remove the automatic lowercase conversion

[mmathew23]

Hi @Ki-Seki Thanks for the information! And sorry for the issue. If I'm remembering correctly there is a discrepancy in hf api. For instance if you load a model with from_pretrained you can pass any case and it will map to one name, ie from_pretrained is case insensitive.

Whereas on the save_pretrained side it is case sensitive. The save_pretrained logic is downstream of that.

From our POV we'd like HF to clarify if this is the intended behavior or not. I believe @danielhanchen will discuss or is already discussing with them.

[Ki-Seki]

Okay, I understand. Thank you for your efforts. 🤗

[lyesrock]

The issue persists even in 03/2026: the Unsloth Studio interface shows that the model is already downloaded, but when I click on it, it triggers a re-download using lowercase letters for the name. As a result, I end up with the exact same model twice on the HF Hub.

[aa956]

Bug still present as of c1685b9.

Selected the cached model from the chat UI and studio started download of the same repository and same model file with forced lowercase repository name.

Update: just in case, to replicate (on debian 13 but probably does not matter as long as OS uses case sensitive filenames):

cd ~/src && rm -rf unsloth && git clone https://github.com/unslothai/unsloth && cd unsloth && ./install.sh --local

Selected already downloaded ( using hf download owner/repo --include "*filter*") model (for example unsloth/Qwen3.5-4B-GGUF:Qwen3.5-4B-UD-Q4_K_XL.gguf):

Studio starts downloading a new copy of the model. Logs (left only interesting parts):

{"timestamp": "2026-04-03T10:53:57.419233Z", "level": "info", "event": "request_completed", "method": "GET", "path": "/api/models/gguf-variants", "status_code": 200, "process_time_ms": 198.68}
{"timestamp": "2026-04-03T10:54:24.979594Z", "level": "info", "event": "Detected remote GGUF repo 'unsloth/qwen3.5-4b-gguf', variant=UD-Q4_K_XL, vision=True"}
{"timestamp": "2026-04-03T10:54:24.979811Z", "level": "info", "event": "request_completed", "method": "POST", "path": "/api/inference/validate", "status_code": 200, "process_time_ms": 577.34}
{"timestamp": "2026-04-03T10:54:25.563141Z", "level": "info", "event": "Detected remote GGUF repo 'unsloth/qwen3.5-4b-gguf', variant=UD-Q4_K_XL, vision=True"}
{"timestamp": "2026-04-03T10:54:26.218725Z", "level": "info", "event": "GGUF download: 2.7 GB needed, 1401.2 GB free on disk"}
{"timestamp": "2026-04-03T10:54:26.218775Z", "level": "info", "event": "Resolving GGUF: unsloth/qwen3.5-4b-gguf/Qwen3.5-4B-UD-Q4_K_XL.gguf"}
Qwen3.5-4B-UD-Q4_K_XL.gguf:   2%|█▍                                                                                   | 47.9M/2.91G [00:19<06:59, 6.83MB/s]^C{"timestamp": "2026-04-03T10:54:53.813065Z", "level": "info", "event": "Graceful shutdown initiated \u2014 cleaning up subprocesses..."}
{"timestamp": "2026-04-03T10:54:53.813138Z", "level": "info", "event": "All subprocesses cleaned up"}

Shutting down...
INFO:     Shutting down
INFO:     Waiting for connections to close. (CTRL+C to force quit)
Cancellation requested; stopping current tasks.
Qwen3.5-4B-UD-Q4_K_XL.gguf:   2%|█▍                                                                                   | 47.9M/2.91G [00:27<27:08, 1.76MB/s]
{"timestamp": "2026-04-03T10:54:53.937550Z", "level": "error", "event": "request_failed", "path": "/api/inference/load", "method": "POST", "error": "No response returned.", "exc_info": true}
Exception in thread Thread-1 (_run):
^C^C^C^C

After that hf cache shows:

~/src/unsloth$ hf cache ls | grep -i qwen3.5-4b-gguf
model/bartowski/Qwen_Qwen3.5-4B-GGUF                                              5.2G 3 weeks ago   4 weeks ago   main          
model/unsloth/Qwen3.5-4B-GGUF                                                     2.9G 5 hours ago   4 hours ago   main          
model/unsloth/qwen3.5-4b-gguf                                                      0.0 1 minute ago  1 minute ago  main          

[Imagineer99]

Investigating

[aa956]

Investigating

Thank you, works for me after #4822

Thought that I've seen a regression but actually it was just updated model re-downloaded (one of the models I've tried this fix on was updated by the repository owner long after initial download).

[danielhanchen]

This issue should be fixed now - sorry on the delay - please update with uv pip install --upgrade unsloth unsloth_zoo --force-reinstall --no-cache-dir - if the issue is still there, please open another issue - appreciate it again!