Studio: don't re-download updated GGUFs on load#7209
Conversation
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
for more information, see https://pre-commit.ci
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7ac0e2fb10
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
I reproduced the original issue and the main fix works. There are still a few cache/split and download-race edge cases in the inline reviews, but once those are addressed this looks good. Happy to retest. |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0ae9a76189
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 616746d30f
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@codex review |
|
Codex Review: Didn't find any major issues. Delightful! Reviewed commit: ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
|
@codex review |
|
Codex Review: Didn't find any major issues. 👍 Reviewed commit: ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
2 participants
When a GGUF repo is re-uploaded (as with the recent Gemma QAT quants), the next load of an already-downloaded model re-downloads the whole file. The load path resolves against the repo's current revision, counts the on-disk copy as "0.0 GB already cached", and starts a full fetch with no consent step. The Update button, which does ask first, never gets involved. Users reported this as "Unsloth is re-downloading a model I already have and I never gave it permission".
While that download runs, the hub download manager can start a second download of the same repo. Its registry cannot see the load path's downloader, so two writers hit the same cache blobs. The hub worker's cache preparation then purges partial blobs it does not own, which can stall the other transfer.
Fix
_download_ggufreuses a complete cached copy (any revision) before any sizing or fetch, online or offline. If a re-upload renamed the file, the variant label resolves against the local cache. Split sets are reused only when every shard is co-located.forcestill re-fetches). Snapshots iterate newest-first, so a load right after an update picks up the new files./api/hub/downloadreturns 409 for that repo while marked. Conversely,/loadreturns 409 when a hub download is active for the repo and no cached copy exists to reuse. A reuse-load proceeds since it never touches in-flight blobs. The guard and the load path share one probe (cached_gguf_for_load), so their verdicts cannot drift.Out of scope
Safetensors/transformers loads keep their existing behavior (separate worker, same race class). The hub worker still lacks the xet-stall HTTP fallback the load path has. Both are follow-ups.
Verification
New tests in
test_gguf_load_cache_reuse.pycover reuse after a revision bump, renamed files, force re-fetch, split sets, newest-snapshot preference, an mmproj snapshot sibling, the in-flight marker, the hub-side 409, and the shared probe behind the/loadguard.test_download_online_does_not_reuse_old_snapshotwas flipped to pin the new policy (nowtest_download_online_reuses_complete_cached_snapshot). The full gguf/download/llama_cpp/hub test sweep passes (1163 tests).