Nice. I also ran a small Colab experiment on my end:
Using a fresh Colab Free runtime, I could reproduce a no-progress state while down the same model.safetensors
from juiceb0xc0de/bella-bartender-gemma-e4b.
The most useful result was not just that it stalled again, but that the same file passed the reported 2 GB region when I explicitly disabled Xet.
| Test branch | Observed result |
|---|---|
Public GPT-2 control with hf-xet 1.5.1 |
|
| Completed normally | |
Target with hf-xet 1.5.1 , default settings |
|
| Stopped making progress | |
| Target with sequential reconstruction writes | Still stopped making progress |
Target with hf-xet 1.5.2rc0 |
|
| Failed explicitly with a response-body decoding error instead of silently hanging | |
| Target with Xet disabled | Passed 2.5 GB before I intentionally stopped the test |
This makes a simple explanation such as “the model file is physically truncated at 2 GB” much less likely.
My current reading is:
The problem appears to be specific to the Xet-aware fetch/reconstruction path, or to an interaction that this path triggers, rather than a universally unreadable byte range in the backing file.
That is still a black-box inference, not a confirmed internal root cause.
The xet-core issue you opened, #896, looks like the right place to continue. It now has a useful combination of:
For someone who only needs to retrieve the file, the most direct diagnostic fallback is:
HF_HUB_DISABLE_XET=1 \
hf download juiceb0xc0de/bella-bartender-gemma-e4b \
model.safetensors \
--repo-type model \
--local-dir ./bella-bartender-gemma-e4b
Hugging Face documents HF_HUB_DISABLE_XET
as the switch that disables hf-xet
even when the package is installed. The documentation also explicitly asks users who need to disable Xet to file an issue with diagnostics, which you have already done: Hugging Face Hub environment variables.
I would treat this as a temporary workaround and a path-isolation test, not as a final fix:
AccessDenied
reports in the same time window.One important distinction: I would currently keep the direct-download AccessDenied
problem and this Xet reconstruction stall as separate observations. They may share a broader incident context, but my Xet run did not show the same bridge XML 403
as its immediate failure.
This now looks narrower than a generic network or corrupt-file problem:
1.5.2rc0
exposes an explicit response-body decoding failure instead of the same silent wait;I would therefore treat the exact stopping region as a reproducible clue, while treating “2 GB buffer bug” as unconfirmed. The best-supported working description is an Xet-aware fetch/reconstruction failure, potentially involving incomplete range responses and a task that does not complete cleanly in 1.5.1
.
The existing diagnostic bundle plus this control/fallback comparison should give xet-core #896 a fairly concrete starting point.