Choosing a GPU server disk size feels like a minor setting on the deploy page, but it is one of the few choices you cannot undo. On Cloudj, the disk size of a GPU instance is set at deploy and cannot be resized later. Choose too small and a long job fails at the worst moment, or you redeploy and copy everything again. Choose too large and you pay for space you never use, both while the instance runs and while it is stopped. This guide gives you a simple worksheet to get it right the first time.
Disk is one of three cost components, alongside GPU time and bandwidth; the GPU cost estimation guide shows how they combine.
The rules that make sizing matter
- Fixed at deploy. You pick the disk size within the template's minimum and the machine's maximum. After deploy it cannot be changed. If you run out, the only fix is a new instance with a bigger disk.
- Machine maximums differ. Each host allows a different maximum disk. If you need a very large disk, that narrows which machines you can use.
- Part of the running price. Running price is GPU plus disk.
- Billed while stopped. A stopped instance still pays storage for its disk. Each listing shows its storage price per GB-month.
- Used in the search. The console's disk-size setting is used for the prices in the results, so set it before comparing machines.
This is different from a VPS, where resizing is a normal operation; see resizing a VPS's CPU, RAM and disk for that case.
The GPU server disk size worksheet
Add up five lines:
disk = container image or template
+ model weights (every model you will load)
+ datasets (raw and processed)
+ outputs (checkpoints, generated files, logs)
+ headroom1. Image or template
The base templates ("Ubuntu 22.04 + CUDA (SSH)", "PyTorch + JupyterLab") and most custom images with CUDA and a framework take several GB to a few tens of GB, depending on what is installed. Add anything you will pip install or apt install on top. If you use a custom image, check its size with docker image ls on your own machine.
2. Model weights
Rough sizes, as general guidance:
- weights in 16-bit precision take about 2 GB per billion parameters, so a 7B model is roughly 14-15 GB and a 70B model roughly 140 GB;
- 4-bit quantized weights take roughly a quarter of that;
- an SDXL checkpoint is several GB, plus any LoRAs, VAEs and ControlNets;
- video generation models, with their text encoders, can take tens of GB each.
Count every model you plan to try, not just the one you expect to keep. Model hubs also keep a download cache; downloading directly into your target folder avoids storing two copies.
3. Datasets
Count the raw data plus any processed copies: tokenized shards, resized images, extracted audio. Preprocessing often doubles the footprint for a while.
4. Outputs
This is the line people underestimate.
- Training checkpoints. A full checkpoint with optimizer state can be several times the size of the weights. Multiply by how many you keep on disk at once.
- Generated media. Images add up; video adds up quickly. The text-to-video guide explains why video projects need the largest disks.
- Logs and caches. Usually small, unless you log tensors or samples.
5. Headroom
Add 20-30% on top. Filesystems behave badly when full, and jobs often write temporary files you did not plan for.
Three worked examples
| Project | Image | Models | Data | Outputs | Headroom | Choose roughly |
|---|---|---|---|---|---|---|
| ComfyUI with SDXL and a few LoRAs | Template plus UI | One SDXL checkpoint, a few LoRAs and ControlNets | Reference images | A few thousand images | 25% | A modest disk, comfortably above the sum |
| LoRA fine-tune of a 7B model | PyTorch template | 7B in 16-bit | Instruction dataset | Adapters plus a few checkpoints | 25% | Medium |
| Serving a 70B model in 4-bit on 2 GPUs | Custom image with inference server | 70B 4-bit, roughly 40 GB | None | Logs | 25% | Medium to large |
Fill in your own numbers per line; the point is to write them down rather than guess. For the ComfyUI case specifically, see ComfyUI on a GPU in Europe.
Checking usage while you work
Once the instance runs, keep an eye on space:
df -h /workspace
du -sh /workspace/* | sort -hIf you are approaching the limit, delete old checkpoints after copying the ones you need off the machine, clear package caches (pip cache purge), and remove intermediate files. If that is not enough, deploy a new instance with a larger disk and copy your work across with rsync.
When to choose small on purpose
For a short test, a learning session or a CI run, choose the smallest disk that fits the template and your code. You will destroy the instance soon, and every extra GB adds to the running price. Stopped instances still pay for their disk, so for occasional work, destroying and redeploying can be cheaper than keeping a large stopped disk.
FAQ
Can I increase the disk after deploy?
No. Disk size is fixed at deploy. Deploy a new instance with a bigger disk and copy data across.
Do I pay for the disk while the instance is stopped?
Yes. A stopped instance pays storage for its disk at the machine's listed price.
Why can't I choose a very large disk on some machines?
Each machine has its own maximum disk size. If you need more, pick a machine whose maximum covers it.
How much headroom should I add?
Around 20-30% above your estimate is a sensible default.
Size it, then deploy
Fill in the worksheet, set the disk size on the GPU deploy page before comparing machines, and check live prices on GPU cloud.