Model download freezing at exact percentage

A model download from Hugging Face freezes at a specific percentage due to a bug in the Xet-aware fetch/reconstruction path, as demonstrated by a Colab experiment. Disabling Xet with HF_HUB_DISABLE_XET=1 allows the download to proceed past the 2 GB region, indicating the issue is not a truncated file but a Xet-specific failure. The problem is tracked in xet-core issue #896.

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.