# GPU server disk size: how much to choose before you deploy

URL: https://cloudj.net/blog/choose-gpu-disk-size
Published: 2026-11-12 · Updated: 2026-11-12

> Pick the right GPU server disk size before deploy: add up image, weights, data, outputs and headroom, since disk cannot be resized and is billed while stopped.

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](https://cloudj.net/blog/estimate-gpu-cloud-cost) 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](https://cloudj.net/blog/resize-vps-cpu-ram-disk) for that case.

## The GPU server disk size worksheet

Add up five lines:

```text
disk = container image or template
     + model weights (every model you will load)
     + datasets (raw and processed)
     + outputs (checkpoints, generated files, logs)
     + headroom
```

### 1. 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](https://cloudj.net/blog/text-to-video-gpu-cloud) 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](https://cloudj.net/blog/comfyui-gpu-europe).

## Checking usage while you work

Once the instance runs, keep an eye on space:

```bash
df -h /workspace
du -sh /workspace/* | sort -h
```

If 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](https://app.cloudj.net/deploy/gpu) before comparing machines, and check live prices on [GPU cloud](https://cloudj.net/gpu-cloud).