CAS Bridge not working for large files

[nicoboss]

Describe the bug

The Xet client allows larger files to be uploaded then can be downloaded over the CAS Bridge.

The increase of the per-file upload limit from 50 GB to 500 GB is highly appreciated as it finally allows us to upload GGUF quants of large models without splitting them heavily improving the user experience. It unfortunately turned out that such files can be only downloaded using the Xet Client but not over the HuggingFace website or any other download method that relays on the CAS Bridge. Please fix the CAS Bridge so it works with files up to the new 500 GB per-file limit.

The CAS Bridge simply errors with status code 400 when encountering such a file. This issue affects all recently created mradermacher quants of large models.

Reproduction

HuggingFace Website downloads fails using 400 Bad Request:

• https://huggingface.co/mradermacher/Mistral-Large-3-675B-Instruct-2512-i1-GGUF/blob/main/Mistral-Large-3-675B-Instruct-2512.i1-Q2_K.gguf
• https://huggingface.co/mradermacher/Mistral-Large-3-675B-Instruct-2512-i1-GGUF/blob/main/Mistral-Large-3-675B-Instruct-2512.i1-IQ3_M.gguf
• https://huggingface.co/mradermacher/Kimi-K2-Thinking-GGUF/blob/main/Kimi-K2-Thinking.Q6_K.gguf.part1of2

git clone https://huggingface.co/mradermacher/Mistral-Large-3-675B-Instruct-2512-i1-GGUF fails using Smudge error: Error downloading Mistral-Large-3-675B-Instruct-2512.i1-IQ3_M.gguf

XET client works: hf download mradermacher/Mistral-Large-3-675B-Instruct-2512-i1-GGUF --include= Mistral-Large-3-675B-Instruct-2512.i1-Q2_K.gguf --local-dir=/GGUFs

Files only slightly exceeding the old 50 GB limit work as intended:

• https://huggingface.co/mradermacher/shisa-v2.1-llama3.3-70b-i1-GGUF/blob/main/shisa-v2.1-llama3.3-70b.i1-Q6_K.gguf

System info

Version used to upload the quants but should not matter:

- huggingface_hub version: 0.35.3
- Platform: Linux-6.17.2-2-pve-x86_64-with-glibc2.41
- Python version: 3.10.18
- Running in iPython ?: No
- Running in notebook ?: No
- Running in Google Colab ?: No
- Running in Google Colab Enterprise ?: No
- Token path ?: /root/.cache/huggingface/token
- Has saved token ?: True
- Who am I ?: mradermacher
- Configured git credential helpers: 
- FastAI: N/A
- Tensorflow: N/A
- Torch: 2.6.0+cu124
- Jinja2: 3.1.6
- Graphviz: N/A
- keras: N/A
- Pydot: N/A
- Pillow: 11.3.0
- hf_transfer: N/A
- gradio: N/A
- tensorboard: N/A
- numpy: 1.26.4
- pydantic: 2.11.7
- aiohttp: N/A
- hf_xet: 1.1.10
- ENDPOINT: https://huggingface.co
- HF_HUB_CACHE: /root/.cache/huggingface/hub
- HF_ASSETS_CACHE: /root/.cache/huggingface/assets
- HF_TOKEN_PATH: /root/.cache/huggingface/token
- HF_STORED_TOKENS_PATH: /root/.cache/huggingface/stored_tokens
- HF_HUB_OFFLINE: False
- HF_HUB_DISABLE_TELEMETRY: False
- HF_HUB_DISABLE_PROGRESS_BARS: None
- HF_HUB_DISABLE_SYMLINKS_WARNING: False
- HF_HUB_DISABLE_EXPERIMENTAL_WARNING: False
- HF_HUB_DISABLE_IMPLICIT_TOKEN: False
- HF_HUB_DISABLE_XET: False
- HF_HUB_ENABLE_HF_TRANSFER: False
- HF_HUB_ETAG_TIMEOUT: 10
- HF_HUB_DOWNLOAD_TIMEOUT: 10

[rajatarya]

Hi @nicoboss - There is no reliable way to serve files larger than 50GB over a single HTTP connection (if you have ideas I would welcome them) - typically one HTTP connection cannot survive for the time necessary to download such large files.

Can you tell me more about the use case for downloading such large files over HTTP?

[seanses]

Also, you want to avoid git clone a repo with super large files directly, due to a long lasting issue that git smudge process buffers the entire file content in memory before updating the working tree. See git-lfs/git-lfs#6132

[nicoboss]

There is no reliable way to serve files larger than 50GB over a single HTTP connection (if you have ideas I would welcome them) - typically one HTTP connection cannot survive for the time necessary to download such large files.

Every modern web browser supports resuming failed downloads. When you retry a failed download, it continues where it stopped using a new HTTP connection if supported by the web server. The HuggingFace CAS bridge does support resuming failed downloads so there is no need for a single HTTP connection to survive for the entire period of the download. No action is required for your side other than to fix the CAS Bridge, so it works for large files.

Can you tell me more about the use case for downloading such large files over HTTP?

With massive LLMs such as Mistral-Large-3-675B-Instruct-2512 a single GGUF quant can be massive. Until recently HuggingFace had a 50 GB per-file upload limit which forced us to split large GGUFs into multiple smaller files. This requires the user to concatenate them after downloading. This adds an additional step for the user and with most file systems not supporting zero copy concatenation all data to be copied making it take time and requiring twice the available local storage. With the 50 GB per-file upload limit being lifted all this hassle can be avoided by simply uploading the quant as a single file. There are unfortunately many casual users that still use the HuggingFace website to download our GGUFs instead of huggingface-cli this especially considering the less tech-savvy GGUF userbase.

The CAS bridge not working for large files leaves us with no choice than to either accept HuggingFace website downloads being broken for large quants and try to educate our users to use huggingface-cli instead or to revert to splitting large files causing an inconvenience for advanced users. By making the CAS Bridge work with large files we could offer the best possible user experience for everyone.

Also, you want to avoid git clone a repo with super large files directly

I only showed git clone to prove that this is an issue with the CAS Bridge and not the HuggingFace website. No one would ever git clone one of our repositories as they contain quants in different precisions with users only wanting to download the ones that best fit their local inference setup.

[rajatarya]

@nicoboss Thanks for sharing more details about the use case. Yes, you are correct, the download experience from the Hub website is limited to 50GB files or less due to the CAS Bridge.

Do your users typically succeed with XL (~50GB) file downloads through the Hub website today? Meaning, do their browsers automatically retry failed downloads and resume them? Do your users mind having to retry manually in the browser?

(I ask because whenever I've tried to download large files - maybe 4GB ISO images over the browser I often have to manually babysit the download to have it succeed.)

We will work on improving the scalability of the CAS Bridge so it can handle larger file sizes. As things are currently architected it isn't as easy as changing a file-size limit, so it will take some time for us to improve things.

Would something like using uvx hf download be a reasonable workaround until we increase the file size CAS Bridge can handle?

For your users the steps would something like:

# Install uv, https://docs.astral.sh/uv/getting-started/installation/
curl -LsSf https://astral.sh/uv/install.sh | sh

uvx hf download mradermacher/Mistral-Large-3-675B-Instruct-2512-i1-GGUF Mistral-Large-3-675B-Instruct-2512.i1-IQ3_M.gguf

I will keep this issue open and update it as we make progress on it.