Why can't we download by torrent?

Hugging Face Hub does not officially support torrent downloads, a forum respondent said, because all files are served from the platform's CDN and its native git-based hosting does not work with torrent swarms. The respondent told a user in Kyrgyzstan that the `hf` CLI and `huggingface_hub` should resume interrupted downloads automatically via `hf_hub_download` or `snapshot_download`, and suggested `aria2c`, `hf-torrent`, or LlamaTor as stopgaps; the user reported direct downloads of 50 KB/s to 3 Mbps and an `hf download` attempt that failed after 75 MB. The respondent attributed the failure to the Xet chunked transfer backend opening many parallel connections that throttled ISPs choke on, and recommended setting `HF_HUB_DISABLE_XET=1` to force the single-connection HTTP path or capping `aria2c`/`hfd` concurrency to 1-2 connections.

d351r3d https://discuss.huggingface.co/u/d351r3d 1 I’m from the US, but I live in Kyrgyzstan, and I’m not paying $200 for home internet. For the last four months, downloading anything over 5 GB has basically been impossible. If I try to download a model and the download fails four times because of some random issue, I’ve just wasted the time and bandwidth of downloading that model four times. That’s exactly the problem. If you had torrents available for the models, or even an option to “make this a torrent”, this wouldn’t happen. My downloads wouldn’t randomly fail for no reason, and I wouldn’t be stuck downloading at 50 KB/s when I can torrent at 5 MB/s. The frustrating part is that I can download 40 GB torrents of X, Y, and Z within a day. So the bandwidth clearly exists; the problem is the reliability and speed of the direct downloads. I’d really like an answer on this, because you already allow people to download these models for free. Adding torrent support would solve what is probably the biggest, or only, practical problem for users in developing countries with unreliable or expensive internet. It would make large model downloads much more accessible without requiring you to provide faster or more expensive hosting. Torrents aren’t officially supported on the Hub all files are served straight from their CDN, and native git-based hosting doesn’t play well with torrent swarms , so I wouldn’t expect that to land as a built-in feature. That said, downloads should actually resume automatically if a transfer drops: the hf CLI / huggingface hub via hf hub download or snapshot download keeps the partial file in the cache with a temp name and continues from there next time you run the same command, so you shouldn’t be re-downloading from zero on a failed attempt. If it’s still restarting for you, try hf download <repo --local-dir ./model again after a failure same command, don’t clear the cache and see if it picks up where it stopped. On flaky connections aria2c with the HF URL, or the community hf-torrent /LlamaTor projects, also work as a stopgap if you specifically want swarm-style downloading in the meantime. d351r3d https://discuss.huggingface.co/u/d351r3d 3 I attempted the hf download CLI and Direct download is 50kb - 3mbps HF download CLI is like 25 - 110kbps and failed after 75mb Not sure why but it just did. I tried to resune and it failed. I’m not blaming HF. I do suspect its the internet in Kyrgyzstan throttling something. Sounds like Xet the new chunked transfer backend not playing nice with your route, since hf transfer/Xet tend to open many parallel connections which throttled/unstable ISPs choke on much worse than a single-stream direct download. Worth trying HF HUB DISABLE XET=1 before the hf download command, that forces the old single-connection HTTP path which is slower on paper but often way more stable on bad links, and resumes properly since it’s plain range requests. If it’s still crawling/dying, aria2c or the hfd script curl+aria2c wrapper let you cap concurrency to 1-2 connections, which tends to survive ISP throttling much better than either the direct link or the default CLI.