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, down 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 down 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 down 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-down 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 down 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.