Why is uploading to bucket so slow?

Beginners
1

Im trying to upload my model which is in “pkl” format but its taking forever to upload, my internet speed is normally 8-9Megabytes per second, but its uploading with the speed of 39..4kbps , its just a 87.5mb file. lol i just feel like giving up.
appreciate any help!!

2

Hmm… That speed drop is so extreme that I would not treat it as a normal cap or a generic “server/network is slow” situation:

Short answer

For an 87.5 MB file, 39 KB/s is unusually slow.

The first thing I would clarify is the upload method:

Was this uploaded through the web UI / browser, or through the CLI?

That matters because a browser Bucket upload, hf buckets cp, and a normal hf upload may not use exactly the same transfer path.

If you prefer to stay in the web UI only, I would try the browser-side workarounds below first. If those do not help, then the CLI tests are the best next step because they give clearer logs and separate the browser path from the lower-level transfer path.

GUI-only things to try first

If you uploaded through the web UI, I would try these before assuming the whole service is slow.

Try this in the browser/UI Why it helps
Retry in a fresh private/incognito window Removes extension/session/cached-state effects
Try a different browser Separates browser-specific upload behavior
Disable browser extensions temporarily Ad blockers, privacy tools, script blockers, antivirus extensions, and download/upload helpers can interfere
Turn off VPN/proxy if possible Checks whether the route to HF transfer endpoints is bad
Try a different network, such as phone tethering Quickly separates local network/ISP route from HF-side behavior
Re-login to Hugging Face and reopen the Bucket page Clears stale auth/session state
Try renaming the file to a simple ASCII filename Avoids edge cases around path/filename handling
Try uploading a same-size dummy file through the UI Checks whether the problem is file-specific or transfer-path-specific
Try uploading at a different time Useful if the problem is temporary route or backend degradation
Watch the browser DevTools Network tab HTTP errors, retries, stalled requests, 401/403/5xx, or very long pending requests are useful clues

A same-size dummy file can be created without changing the original file:

python - <<'PY'
from pathlib import Path
import os

Path("test-90mb.bin").write_bytes(os.urandom(90 * 1024 * 1024))
PY

If you do not want to use CLI at all, just create any roughly 90 MB test file locally and try uploading it through the same web UI.

Interpretation:

Browser-only result What it suggests
Incognito/different browser is much faster Browser session, extension, or local browser state
Different network is much faster Route, VPN, proxy, ISP, or corporate network issue
Same-size dummy file is also ~39 KB/s Not specific to .pkl; transfer path is more likely
Same-size dummy file is fast, original file is slow File-specific or local inspection behavior becomes more plausible
DevTools shows repeated retries / 5xx / long pending requests Useful evidence for HF maintainers
DevTools shows 401/403 Auth/session/permission issue
DevTools shows no real network activity but UI says uploading Browser/UI progress reporting may be misleading

Best practical workaround: use the Bucket CLI as a baseline

If GUI-only attempts do not help, the most useful next test is the Bucket CLI:

hf buckets cp ./model.pkl hf://buckets/<namespace>/<bucket>/model.pkl

This is not just a workaround. It is also a diagnostic split:

Result What it suggests
Web UI is slow, hf buckets cp is fast Browser/UI/session path is likely the problem
Web UI and hf buckets cp are both slow Lower-level transfer path, route, Xet/CAS, proxy/VPN, or client path
CLI gives a clear error Much more actionable than a browser progress bar

Docs:

If you already used CLI, try Xet high-performance mode

HF_XET_HIGH_PERFORMANCE=1 \
hf buckets cp ./model.pkl hf://buckets/<namespace>/<bucket>/model.pkl

For a normal Hub repo upload instead of a Bucket upload:

HF_XET_HIGH_PERFORMANCE=1 \
hf upload <namespace>/<repo> ./model.pkl model.pkl

The current huggingface_hub docs describe HF_XET_HIGH_PERFORMANCE=1 as the high-performance mode for Xet transfers.

Docs:

If you are uploading to a normal Hub repo, try disabling Xet as a diagnostic

HF_HUB_DISABLE_XET=1 \
hf upload <namespace>/<repo> ./model.pkl model.pkl

I would treat this as a diagnostic, not necessarily the best long-term mode.

Result What it suggests
HF_HUB_DISABLE_XET=1 is much faster Xet/CAS transfer path is suspicious
HF_HUB_DISABLE_XET=1 is slower but completes Xet path may be problematic, but fallback is not optimized
No change Browser path, route, proxy/VPN, auth, or something else may be the issue

Docs:

Important: if you are testing through Python code, set environment variables before importing huggingface_hub, datasets, transformers, or anything that may import them.

First split: which upload path is slow?

If you used… Try next… Why
Web UI / browser upload GUI-only checks, then hf buckets cp Separates browser path from CLI path
hf buckets cp already HF_XET_HIGH_PERFORMANCE=1 hf buckets cp ... Checks whether Xet high-performance mode helps
hf upload to a repo HF_XET_HIGH_PERFORMANCE=1 and HF_HUB_DISABLE_XET=1 variants Checks whether Xet/CAS is involved
Unsure Start by identifying whether it was web UI or CLI The next useful test depends on that

Why I do not think this is a normal cap

A rough scale check:

Speed Approx. time for 87.5 MB
39 KB/s ~37 minutes
100 KB/s ~15 minutes
1 MB/s ~1.5 minutes
8 MB/s ~11 seconds

So this is not just “a bit slow”. If your usual upload speed is around 8–9 MB/s, then 39 KB/s is a very large drop.

A normal bandwidth cap, rate limit, or temporary server slowdown would not be my first guess. I would instead suspect that the upload is technically still alive, but the transfer stack has entered a bad low-throughput / retry / backoff state.

Why the transfer path matters

Modern Hugging Face uploads are not always just one simple HTTP upload.

Hugging Face has been moving Hub storage from Git LFS-era storage toward Xet-backed storage:

In simple terms, the path may look more like this:

your file
  -> browser or hf CLI
  -> huggingface_hub
  -> hf-xet
  -> chunking / hashing / local transfer work
  -> CAS / xorb transfer endpoint
  -> backend object storage
  -> final Hub or Bucket metadata update

So “uploading to a bucket is slow” can mean several different things.

Layer Possible issue
Browser upload Web UI, session, extensions, progress display, signed upload path
CLI path Local client, auth, version, config
Xet path Transfer mode, cache, concurrency, timeout
CAS/xorb path Transfer endpoint issue
Network route Bad route to the HF transfer endpoint
Proxy/VPN/corporate network TLS inspection or traffic shaping
Backend storage Possible, but not the first thing I would assume

Similar failure class

This exact case may be new, but the general failure shape is not new.

There are recent Hugging Face / Xet-era reports where upload or transfer performance becomes extremely slow or stalls:

The point is not that your case is definitely one of those exact issues. The point is that Xet/CAS/xorb transfer behavior is a real layer to test, especially when the symptom is “very slow but not cleanly failed”.

There are also older object-storage-client issues outside Hugging Face with similar “still alive but barely progressing” behavior:

So I would not think of this as simply “the internet is slow”. I would think of it as a transfer-path issue until proven otherwise.

Minimal info to post back

If you want others or HF maintainers to help, I would post these results:

Upload method:
- Web UI / browser Bucket upload?
- hf buckets cp?
- hf upload?
- something else?

GUI-only checks:
- Incognito/private window result
- Different browser result
- Extensions disabled result
- Different network result
- Same-size test file result
- Browser DevTools Network errors, if any

Environment, if CLI is used:
- OS
- hf --version
- output of hf env
- huggingface_hub version
- hf_xet version
- logged in or anonymous?
- VPN/proxy/corporate network?

CLI tests, if possible:
- hf buckets cp speed
- HF_XET_HIGH_PERFORMANCE=1 result
- HF_HUB_DISABLE_XET=1 result, if using normal Hub upload
- same-size test-90mb.bin result

Logs:
- any CAS / xorb / hf_xet / timeout / retry / 401 / 403 / 5xx messages

You can collect CLI version info with:

hf --version
hf env
hf auth whoami

python - <<'PY'
import os
import platform

print("python:", platform.python_version())
print("platform:", platform.platform())
print("HF_TOKEN present:", bool(os.environ.get("HF_TOKEN")))

try:
    import huggingface_hub
    print("huggingface_hub:", huggingface_hub.__version__)
except Exception as e:
    print("huggingface_hub unavailable:", repr(e))

try:
    import hf_xet
    print("hf_xet:", getattr(hf_xet, "__version__", "unknown"))
except Exception as e:
    print("hf_xet unavailable:", repr(e))
PY

My practical guess

My practical guess is:

not a normal bandwidth cap
not generic "the server is slow"
probably an unhealthy upload transfer path
possibly browser Bucket upload, Xet/CAS/xorb, or the route to those endpoints

If you want to stay GUI-only first, I would try:

private window
different browser
extensions disabled
VPN/proxy off
different network
same-size dummy file
browser DevTools Network tab

If those do not change anything, then the most useful next baseline is:

hf buckets cp ./model.pkl hf://buckets/<namespace>/<bucket>/model.pkl

And if CLI is already being used, I would compare:

HF_XET_HIGH_PERFORMANCE=1 \
hf buckets cp ./model.pkl hf://buckets/<namespace>/<bucket>/model.pkl

Those comparisons should quickly tell whether this is a browser-only issue, a Bucket-specific issue, or a lower-level Xet/CAS transfer-path issue.