Unable to download a model

A user reported that downloading the Qwen2.5-VL-7B-Instruct model from Hugging Face repeatedly stalls at around 90% across multiple networks and countries, with error logs pointing to a DNS issue. Hugging Face Xet team member jsulz suggested updating the huggingface_hub library and using diagnostic tools, while the user confirmed the issue persists with huggingface_hub version 0.34.4 and hf_xet 1.1.9.

Hi all, is now 3 days I’m trying to download “hf download Qwen/Qwen2.5-VL-7B-Instruct --local-dir,….” on different networks and different routers in two different countries with very different download speeds and connections type satellite vs fiber and different provider, with or without VPN, but the final result is always the same: around 90% it gets stuck. It is incredibly frustrating. Does anyone has a clue on what could be the problem? Thank you in advance Best regards Hmm, that’s strange. When I tried it, the download completed normally. Maybe the library has been updated. pip install -U huggingface hub hf xet hf download Qwen/Qwen2.5-VL-7B-Instruct jsulz https://discuss.huggingface.co/u/jsulz 3 Hi @acqsol23 /u/acqsol23 I work on the Xet team that supports most of the Hub storage and file transfers. Saw this and was just wondering a few things: - Could you provide an output of hf env from the HF CLI https://huggingface.co/docs/huggingface hub/en/guides/cli hf-env to see what you have installed locally for help in debugging? - What commands are you using to download? If you’re using hf-xet during the download, we have some diagnostic tools https://github.com/huggingface/xet-core?tab=readme-ov-file issues-diagnostics--debugging that can use to detect hangs or other issues. If this continues, read the instructions on how to use the tools and open an issue with the output provided by the scripts and we can investigate. Hi, the download finished but I can’t spend my time to take care of it and then, when it stuck, kill the process 3 or more times and monitor it during sleeping time . The command is the one listed in the original post hf download Qwen/Qwen2.5-VL-7B-Instruct --local-dir someDirHere as is or in background using nohup and &. - huggingface hub version: 0.34.4 - Platform: Linux-6.14.0-110029-tuxedo-x86 64-with-glibc2.39 - Python version: 3.12.3 - Running in iPython ?: No - Running in notebook ?: No - Running in Google Colab ?: No - Running in Google Colab Enterprise ?: No - Token path ?: /home/d/.cache/huggingface/token - Has saved token ?: True - Who am I ?: acqsol23 - Configured git credential helpers: - FastAI: N/A - Tensorflow: N/A - Torch: 2.6.0+cpu - 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.9 - ENDPOINT: https://huggingface.co https://huggingface.co - HF HUB CACHE: /home/d/.cache/huggingface/hub - HF ASSETS CACHE: /home/d/.cache/huggingface/assets - HF TOKEN PATH: /home/d/.cache/huggingface/token - HF STORED TOKENS PATH: /home/d/.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 Here also some error messages that seems to relate my problems to a DNS error. Note that I have partially deleted the keypair ID just because I don’t know if it is a sensitive information. Thank you in advance for your help on investigating this problem. 2025-09-14T17:45:23.510669Z WARN Reqwest reqwest::Error { kind: Request, url: “ https://transfer.xethub.hf.co/xorbs/default/de7695e5b78cfc92d59bc60c5df0d2c27c2eca2075a62c06b563436c9c08f48d?X-Xet-Signed-Range=bytes%3D0-57720426&X-Xet-Session-Id=01K54MZS5WYE83TRDKR89HY6WK&Expires=1757875197&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly90cmFuc2Zlci54ZXRodWIuaGYuY28veG9yYnMvZGVmYXVsdC9kZTc2OTVlNWI3OGNmYzkyZDU5YmM2MGM1ZGYwZDJjMjdjMmVjYTIwNzVhNjJjMDZiNTYzNDM2YzljMDhmNDhkP1gtWGV0LVNpZ25lZC1SYW5nZT1ieXRlcyUzRDAtNTc3MjA0MjYmWC1YZXQtU2Vzc2lvbi1JZD0wMUs1NE1aUzVXWUU4M1RSREtSODlIWTZXSyIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTc1Nzg3NTE5N319fV19&Signature=ZBjFjyovn4Vr-sc7ium~GwllSB87Q2DXrg~Ikxq5GN3mn5zLbmaD-87Z6yOMTvzyEfHRxbP99LjH3vufc~VczNsGpZhOGDna7XtelCHIjL7OVjA6d8HB~54JiqoYq5vYj90CWhmIKoIV3ILR-sTG6g07pcZnuji8pEeh-GWHHz8PVSqnA1lufJWNCKlsuyPNLYMq7iTKU9nsJy45jstglsWZp1v84zhPwUk34BjynrgO905cgHa9wfKzh-Qrv2Wiwe61yZZ0yKdMauTOY0SI6SST0v5KPMWF1ZrZIyNxGzuVHlRAygsWjQ0gSmC-jhzATZuEOWmGKgPHg8pqrWlyUg &Key-Pair-Id=K2L8F4GPSG1IFC” https://transfer.xethub.hf.co/xorbs/default/de7695e5b78cfc92d59bc60c5df0d2c27c2eca2075a62c06b563436c9c08f48d?X-Xet-Signed-Range=bytes%3D0-57720426&X-Xet-Session-Id=01K54MZS5WYE83TRDKR89HY6WK&Expires=1757875197&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly90cmFuc2Zlci54ZXRodWIuaGYuY28veG9yYnMvZGVmYXVsdC9kZTc2OTVlNWI3OGNmYzkyZDU5YmM2MGM1ZGYwZDJjMjdjMmVjYTIwNzVhNjJjMDZiNTYzNDM2YzljMDhmNDhkP1gtWGV0LVNpZ25lZC1SYW5nZT1ieXRlcyUzRDAtNTc3MjA0MjYmWC1YZXQtU2Vzc2lvbi1JZD0wMUs1NE1aUzVXWUU4M1RSREtSODlIWTZXSyIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTc1Nzg3NTE5N319fV19&Signature=ZBjFjyovn4Vr-sc7ium~GwllSB87Q2DXrg~Ikxq5GN3mn5zLbmaD-87Z6yOMTvzyEfHRxbP99LjH3vufc~VczNsGpZhOGDna7XtelCHIjL7OVjA6d8HB~54JiqoYq5vYj90CWhmIKoIV3ILR-sTG6g07pcZnuji8pEeh-GWHHz8PVSqnA1lufJWNCKlsuyPNLYMq7iTKU9nsJy45jstglsWZp1v84zhPwUk34BjynrgO905cgHa9wfKzh-Qrv2Wiwe61yZZ0yKdMauTOY0SI6SST0v5KPMWF1ZrZIyNxGzuVHlRAygsWjQ0gSmC-jhzATZuEOWmGKgPHg8pqrWlyUg &Key-Pair-Id=K2L8F4GPSG1IFC%E2%80%9D , source: hyper util::client::legacy::Error Connect, ConnectError “dns error”, Custom { kind: Uncategorized, error: “failed to lookup address information: Temporary failure in name resolution” } } . Retrying… at /home/runner/work/xet-core/xet-core/cas client/src/http client.rs:226 2025-09-14T17:45:23.510714Z WARN Retry attempt 3. Sleeping 18.352830586s before the next attempt at /root/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/reqwest-retry-0.7.0/src/middleware.rs:171 ^C 2025-09-14T17:45:26.504848Z WARN Reqwest reqwest::Error { kind: Request, url: “ https –deleted because of the link restriction— ://transfer.xethub.hf.co/xorbs/default/1cf1f31fad1881a99345cf56daf7b49aad7dd820003b2bfbb5197dd9052c8c74?X-Xet-Signed-Range=bytes%3D0-55133428&X-Xet-Session-Id=01K54MZRZKVG0HB9CH4WX95MG6&Expires=1757875197&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly90cmFuc2Zlci54ZXRodWIuaGYuY28veG9yYnMvZGVmYXVsdC8xY2YxZjMxZmFkMTg4MWE5OTM0NWNmNTZkYWY3YjQ5YWFkN2RkODIwMDAzYjJiZmJiNTE5N2RkOTA1MmM4Yzc0P1gtWGV0LVNpZ25lZC1SYW5nZT1ieXRlcyUzRDAtNTUxMzM0MjgmWC1YZXQtU2Vzc2lvbi1JZD0wMUs1NE1aUlpLVkcwSEI5Q0g0V1g5NU1HNiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTc1Nzg3NTE5N319fV19&Signature=uoMW83qBClV-6aZ~ZSdQ4kIZKbb1GLShXAeAHn0ArY~b4YZJbG1Wxpl0RNxL2vUuSoMuo5K3msHBXntjtAS8kNTrRlidn-ML6fXMNJ5qu7iPEx2yKBqep8ToQKJ9Ru5zjJWBJOzmf2JbMxJ9U27R1CXRsO6rFqtSlrBX5RloFi31UuJngxW~QbcKNiIEfKVOfUbSfl17EntBk8RYYWphmVUGgTEUs82Tczdy-w~VAXMsiF~FELmGBZWoQBuJkFqqtOOF-FkB7fcOL5COLIDrCHccrynA1U4AG-CZpUSTvDlC8~DzWeo-WLNetX1TNCOcDAW~UZxuSJHMT8gOG3NuhA &Key-Pair-Id=K2L8F4GPSG1IFC”, source: hyper util::client::legacy::Error Connect, ConnectError “dns error”, Custom { kind: Uncategorized, error: “failed to lookup address information: Temporary failure in name resolution” } } . Retrying… at /home/runner/work/xet-core/xet-core/cas client/src/http client.rs:226 2025-09-14T17:45:26.504926Z WARN Retry attempt 2. Sleeping 11.845732287s before the next attempt at /root/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/reqwest-retry-0.7.0/src/middleware.rs:171 jsulz https://discuss.huggingface.co/u/jsulz 5 Thanks for the update Glad the download finished. The errors listed here are sometimes present when exceeding the operating system’s limit on open file handles. Are you using any HF XET flags by chance i.e., HF XET HIGH PERFORMANCE ? . If you encounter those specific errors again, you can try to raise the soft limit on open file descriptors to something reasonably larbe by running ulimit -Sn 4096. The hangs are curious and difficult to diagnose without catching them in the middle of a download. I appreciate re-running the download again is not a great solution, but if you encounter this in the future, just follow the link I shared above and rerun the download with the diagnostic tools. These tools will run along with your process and so shouldn’t require you to monitor the download yourself. As you would have to rerun the download anyway, hopefully that is not overly burdensome. If you have any additional feedback when you use these tools, happy to help. Thank you Thank you very much for your answer. Not explicitly: I don’t know if they are set by default. Thank you for the advice, I’ll take a note for the future, and, if something arises I’ll continue the discussion here. Have a nice we. Hi, just to inform you that i solved as follow to minimize the impact of the disconnection. Instead of hf I use git as follow: Installation sudo apt install -y git git-lfs curl python3 python3-venv python3-pip git lfs install git config --global lfs.concurrenttransfers <number of parallel downloads In my case one 1 to minimize losses in case of resume git config --global core.parallel <number of parallel operations In my case eight 8 Run source ~/hf-venv/bin/activate huggingface-cli login git clone <URL to HF files <local download directory git clone h t t p s://huggingface.co/stabilityai/stable-diffusion-xl-base-1.0 ~/mnt/llm-local/models/original stable diffusion xl If it fails, to resume: cd <local download directory git lfs pull Best regards Sounds like a corrupted or incomplete download rather than your connection. Have you tried clearing the Hugging Face cache and starting the download again? That fixed a similar issue for me once.