{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigx2shu5trghhqrxpatzqctvq727gn4xtpeb3vdrjrjqm5x7ozqqy",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mlk7hifa6lg2"
  },
  "path": "/t/upload-speeds-extremely-slow-stalling-since-april-1st/174910#post_8",
  "publishedAt": "2026-05-11T02:09:19.000Z",
  "site": "https://discuss.huggingface.co",
  "textContent": "I just hit identical stalling on a 7.7 GB safetensors upload from a Linux/aarch64 box (huggingface_hub 1.14.0 + hf-xet 1.5.0). After a couple of failed attempts I dug into the source and found something I hadn’t seen called out in any tutorial:\n\n**`HF_HUB_ENABLE_HF_TRANSFER=1` is a silent no-op for uploads in v1.x.** The `hf_transfer` Rust library has been removed from the upload path entirely, replaced by `hf-xet`. The new “high performance” flag is `HF_XET_HIGH_PERFORMANCE=1`. From `huggingface_hub/constants.py`\n\nI tested all the workarounds suggested earlier in this thread, plus the documented HP flag. Throughput I observed for the same 7.7 GB file:\n\n  * No flags (default Xet, standard perf): sustained ~6 Mbps, eventually stalls in CLOSE-WAIT\n  * HF_HUB_ENABLE_HF_TRANSFER=1 (the old advice): sustained ~6 Mbps — identical to no flags, because the flag is a no-op\n  * HF_XET_HIGH_PERFORMANCE=1: ~21–42 Mbps initial burst, then stalls at ~1.3 GB cumulative (matches xet-core #800 / huggingface_hub #3726)\n  * HF_HUB_DISABLE_XET=1 (the HTTP-fallback workaround): ~3 Mbps single-stream LFS — slow but stable\n  * HF_XET_FIXED_UPLOAD_CONCURRENCY=1 (the bypass-adaptive-controller workaround): ~2.7 Mbps sustained, stable, no CLOSE-WAIT — but functionally equivalent to HF_HUB_DISABLE_XET=1 in throughput\n\n\n\nSo both workarounds in this thread effectively trade “fast but stalls” for “stable but slow” — which still leaves multi-GB uploads at multi-hour ETAs on residential connections. There’s currently no fast + stable upload path for first-time large content uploads where Xet has nothing to dedup against.\n\nHow to confirm which path is active during your upload — run ss -tnp and look at the destination IPs:\n\n  * 34.107.x.x / 34.149.x.x / 160.79.x.x → Xet\n  * *.cloudfront.net → vanilla LFS\n\n\n\nTwo doc/UX changes that would have saved me hours:\n\n  1. Mention HF_XET_HIGH_PERFORMANCE=1 in the basic hf upload quickstart, not just buried in the “Tips and tricks for large uploads” section.\n  2. Make the deprecation warning fire whenever HF_HUB_ENABLE_HF_TRANSFER=1 is set, not only when both flags are set together.\n\n\n\nI’ll open a separate issue on huggingface_hub for the warning + docs visibility. The actual stalling bug for HP mode looks like it’s already tracked under xet-core #800.",
  "title": "Upload speeds extremely slow / stalling since April 1st"
}