Transfer data to GPU server in another region: a practical guide

When you rent GPUs by country, your data and your GPU are often in different places. Your dataset sits on a laptop in Hanoi, the GPU is in Germany, and the results need to come back somewhere else again. Learning to transfer data to GPU server instances efficiently saves both time and money, because a GPU waiting for an upload is still billed. This guide covers the tools, the habits that make big transfers reliable, and how bandwidth charges work on Cloudj.

For how location filtering works in the first place, see the GPU cloud by location guide.

Rule one: do not upload what you can download

The biggest saving is not sending data at all. Public model weights and datasets should be downloaded on the GPU host directly from their source. The host's connection is usually much faster than your home or office uplink, and nothing crosses your own network.

For Hugging Face models:

pip install -U "huggingface_hub[cli]"
huggingface-cli login            # only for gated or private repos
huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir /workspace/models/qwen2.5-7b

Downloads resume if interrupted. The Hugging Face Hub download guide covers filtering files and cache locations. Use wget -c or curl -C - for other direct links, so a dropped connection continues instead of restarting.

Only your own data (private datasets, fine-tuned checkpoints, project files) should travel from your machine.

Know your connection details

Every Cloudj GPU instance is reached over SSH with a key. The Connection tab shows the host and the port, which is often not 22. Every tool below needs that port:

• ssh -p PORT
• scp -P PORT (capital P)
• rsync -e "ssh -p PORT"

If you are not yet comfortable with keys and ports, read how to SSH into a GPU instance first.

Use rsync for anything big

rsync is the right default. It shows progress, skips files already transferred and can resume partial files:

rsync -avP -e "ssh -p <port>" ./dataset/ root@<host>:/workspace/dataset/

-P keeps partial files and shows progress. If the connection drops, run the same command again and it continues. scp works for a single small file, but it cannot resume.

Compress and pack small files

Thousands of small files transfer slowly because each one has overhead. Pack them into one archive first:

tar -czf dataset.tar.gz dataset/
rsync -avP -e "ssh -p <port>" dataset.tar.gz root@<host>:/workspace/
ssh -p <port> root@<host> "cd /workspace && tar -xzf dataset.tar.gz"

Compression helps for text, CSV, JSON and logs. It does little for JPEG, PNG, MP4 or model weights, which are already compressed; for those, use tar -cf without -z and save the CPU time.

For video work, upload the source video and extract frames on the server rather than uploading frames.

Verify what arrived

For anything important, compare checksums at both ends:

sha256sum dataset.tar.gz
ssh -p <port> root@<host> "sha256sum /workspace/dataset.tar.gz"

The two hashes must match. This catches the rare corrupted transfer before you waste GPU hours training on bad data.

Speed up long-distance transfers

Over long international paths, a single TCP stream may not use your full bandwidth. Options:

• Split and run in parallel. Upload several archive parts with separate rsync processes.
• Upload once to a nearby VPS, then copy server to server. A Cloudj VPS close to the GPU can act as a staging point. Server-to-server copies between data centres are often much faster than a home upload.
• Schedule large uploads at night, when residential networks are quieter.
• Start the GPU after the data is close. Prepare data on a staging server, deploy the GPU, then pull from staging.

To copy from one instance or server to another, create a key on the source, add its public key to the destination's ~/.ssh/authorized_keys, and run rsync between them. The migrate a website to a new VPS article shows the same server-to-server pattern in another context.

Bandwidth charges

On Cloudj, each machine lists its own bandwidth price per TB for download and upload, and you are charged per GB at that machine's price. Both directions count: pulling a dataset onto the instance and sending results back out.

Practical consequences:

• When you compare machines for a data-heavy job, look at the bandwidth price as well as the hourly running price.
• Downloading a large model from its source onto the instance also counts as download traffic; it is still usually the quickest route.
• Bring back only what you need: final checkpoints and outputs, not caches.

A deposit held at deploy includes a bandwidth reserve; the unused part returns after you destroy the instance, and can take up to 72 hours while final bandwidth charges settle. The estimate GPU cloud cost article shows how to add transfer to your budget.

Getting results back before the end date

Each machine shows "available until" a date. After it, the instance and its disk are removed. Machines are independent hosts with no hardware SLA. So:

rsync -avP -e "ssh -p <port>" root@<host>:/workspace/outputs/ ./outputs/

Run it regularly during long jobs, not only at the end. Destroy the instance once everything is safe.

FAQ

Why does rsync say connection refused?

Usually the wrong port. Use the port from the Connection tab with -e "ssh -p PORT".

Should I compress model weights before uploading?

Rarely worth it; weights are already dense. Better still, download them on the host.

Are uploads into the instance charged?

Bandwidth is charged per GB in both directions at the machine's listed prices. Check them before moving large data.

What if my upload keeps failing?

Use rsync -P so it resumes, split large archives, or stage through a nearby VPS.

Plan your next transfer

When you pick a machine on the deploy page, look at download speed and bandwidth price along with the GPU. Live prices per model are on GPU cloud.