# Model download freezing at exact percentage

> Source: <https://discuss.huggingface.co/t/model-download-freezing-at-exact-percentage/177785#post_5>
> Published: 2026-07-13 23:54:12+00:00

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 downloading the same `model.safetensors`

from [ juiceb0xc0de/bella-bartender-gemma-e4b](https://huggingface.co/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](https://github.com/huggingface/xet-core/issues/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](https://huggingface.co/docs/huggingface_hub/package_reference/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](https://github.com/huggingface/xet-core/issues/896) a fairly concrete starting point.