LLM fine-tuning GPU Europe work usually comes with one extra requirement: the training data should not leave the EU. Cloudj does not make compliance promises, but it gives you the tool that matters most for this, a Country field on the GPU deploy page that restricts the live list of host machines to the countries you choose. This article is a run sheet for a LoRA or QLoRA fine-tune on an EU-listed host, from sizing VRAM to deleting the instance when the job ends, with checkpoints kept in EU storage you control throughout.
For all European codes, start with the GPU cloud in Europe guide. For the policy side, the EU data location guide goes deeper.
Before the run: size the GPU
LoRA trains small adapter matrices while the base model stays frozen. QLoRA does the same on a base model loaded in 4-bit, which cuts memory sharply. Rough, hedged starting points:
| Base model (approx.) | Method | Card class to try |
|---|---|---|
| 7B to 9B | QLoRA | 24 GB consumer card, or RTX A6000 for longer sequences |
| 7B to 9B | LoRA in 16-bit | 48 GB card such as the RTX A6000, or an A100 PCIe with a modest batch |
| 13B to 14B | QLoRA | RTX A6000 or A100 PCIe |
| 30B to 35B | QLoRA | 48 GB card, sequence length permitting |
| 70B class | QLoRA | H100 SXM with 80 GB, or a multi-GPU machine |
Sequence length, batch size, gradient checkpointing and optimizer choice all move these numbers. Run a few hundred steps first and read peak memory from nvidia-smi before committing to a long job. Workstation and datacenter cards such as the A6000, A100 and H100 need a higher account level; the console tells you if a choice is not available.
Before the run: search EU hosts only
Open the deploy page with the A100 PCIe, or change the model, and enter only EU codes:
DE, NL, FR, SEAdd other EU or EEA codes your policy allows. Each row shows the country reported by the machine, at country level only. Stock changes during the day; if no machine fits, add more allowed codes, try a sibling card with similar VRAM, or check later. Do not widen beyond your allowed list just to start sooner.
When you pick a row, check two columns beyond price:
- Max duration and "available until": the run plus a margin must fit before the date, because the instance and its disk are removed then.
- Download speed: you will pull the base model and push checkpoints out.
Before the run: prepare storage you control
Checkpoints should leave the GPU host as they are written. The simplest EU destination is a server you already run, such as a VPS in Germany in Frankfurt with enough disk, or your own object storage in an EU region. Create a dedicated directory and an SSH key that only allows writing there.
The VPS backup strategy guide covers retention and versioning for that destination.
During the run
Connect with the SSH command from the instance's Connection tab, then:
- Run
nvidia-smito confirm the GPU and memory. - Start training inside
tmuxso a dropped connection does not stop it. - Save checkpoints at a fixed interval and push each one out as soon as it is complete:
rsync -avP --remove-source-files -e "ssh -p 22" /workspace/out/checkpoint-*/ backup@<eu-vps>:/data/ft-run-01/Run this from the GPU instance on a timer, or after each save. --remove-source-files frees disk on the GPU host; skip it if you want a local copy too. Bandwidth for uploads is charged per GB at the machine's listed rate, so save adapters rather than full merged weights where you can. LoRA adapters are small compared with the base model.
If the host goes offline, billing pauses while it is offline, but there is no automatic move to another machine. That is exactly why checkpoints must already be off the host.
After the run: delete with discipline
When the final adapter is safely in your EU storage, clean up in this order:
- Verify the files on the destination, for example with checksums.
- Delete datasets and checkpoints from the instance disk.
- Destroy the instance. Destroy deletes the instance and its disk permanently and stops charges. Stopping is not enough, because a stopped instance keeps its disk.
- Note the run in your own records: host country, dates, what data was used.
After destruction, the unused part of your deposit returns to your balance, which can take up to 72 hours while final bandwidth charges settle.
What Cloudj does and does not promise
The Country field lets you keep work on hosts in chosen countries. Location is reported by the machine at country level. Machines are independent hosts with no hardware SLA. Cloudj does not claim that any host meets GDPR or any other data law. Check your own legal obligations, and ask your legal team whether this setup fits your data. For data that cannot leave your own infrastructure, a rented GPU may not be appropriate at all.
For more on finding A100s in Europe, see the A100 cloud in Europe guide.
FAQ
Is a QLoRA fine-tune possible on a consumer card?
For 7B to 9B models, often yes on a 24 GB card. Larger models need 48 GB or more.
Can I keep the disk after training to resume later?
You can stop the instance, which keeps the disk at storage cost, but the GPU is released. For EU discipline, copy checkpoints out and destroy instead.
Does Cloudj guarantee my data stays in the EU?
No. You choose hosts by country with the filter. Keep source data and backups in your own EU storage and review your obligations.
Where are prices?
Live on GPU cloud and each model page.
Plan your run
Open the deploy page, restrict the Country field to your allowed EU codes, and test memory with a short run. Push checkpoints to your own EU storage as they are written, and destroy the instance when the job is done.