Open text-to-video models are among the heaviest workloads you can run on a rented GPU. They need far more memory than image generation, their checkpoints take up a lot of disk, and every clip you generate has to be downloaded. That changes the order in which you should make decisions. For text to video GPU cloud work, choose VRAM first, disk second and region third, and keep an eye on bandwidth price throughout. This guide takes the decisions in that order.
For the general method of choosing where to rent, see the GPU cloud by location guide.
Decision 1: VRAM tier for text to video GPU cloud work
Video models generate many frames together, and memory use grows with resolution, clip length and model size. Requirements differ widely between models and versions, so read each model's own documentation. As a rough planning guide:
| VRAM tier | Example card | What it tends to allow |
|---|---|---|
| 24 GB | RTX 4090 | Smaller video models, short low-resolution clips, heavy use of memory-saving options |
| 32 GB | RTX 5090 | More headroom for mid-size models and somewhat longer or sharper clips |
| 80 GB | H100 SXM | Larger models at higher resolution with fewer compromises |
| 96 GB | RTX PRO 6000 Workstation | A large single-card memory pool for the biggest open models and long clips |
These are hedged ranges, not benchmarks. Memory-saving techniques (offloading parts of the model to system RAM, tiled decoding, lower precision) let smaller cards run bigger models, but slower. If a model's documentation says it needs a certain amount of memory for the settings you want, start there.
Workstation and datacenter cards, including the RTX PRO 6000 and H100, need a higher account level than new accounts have. The RTX 5090 is a consumer card. If the console says "This GPU class is not available at your account level", contact Cloudj support from the console. The RTX PRO 6000 cloud guide covers the 96 GB card in detail.
The RTX 5090 is a Blackwell card. Make sure your PyTorch build and CUDA version support it; recent releases do, older images may not.
Decision 2: disk size
Disk is where video projects run out of room. You choose the size at deploy, within the template minimum and the machine maximum, and it cannot be resized later. Count:
- the container image or template environment;
- the video model checkpoint, plus text encoders and VAEs, which can add up to tens of GB per model;
- any second model you want to compare;
- generated clips and intermediate frames, which pile up quickly during experiments;
- headroom, so a long batch does not fail at the end.
Running price includes the disk, and a stopped instance still pays storage, so oversizing has a cost too. The GPU disk sizing guide gives a worked method.
Decision 3: region
Generation itself does not care where the GPU is. Region matters for two other things:
- Moving files. You download every finished clip and may upload reference images or videos. A host closer to you makes those transfers quicker.
- Interactive tools. If you drive the model through a web UI over an SSH tunnel, a nearby host feels more responsive.
On Cloudj, location is a country filter over a live list of independent host machines. Open the RTX 5090 deploy page and enter the code nearest you: US for the Americas, DE for Europe, SG for Southeast Asia. If a machine with the VRAM you need is listed, deploy it. If not, add neighbouring codes, switch to another card in the same tier, or clear the Country field for a pure batch run. Stock changes during the day, so check again later rather than assuming.
Because VRAM is the hard requirement and region is the soft one, it is usually better to take the right card in a farther country than the wrong card nearby.
Decision 4: bandwidth price
Video outputs are large, and bandwidth is charged per GB downloaded and uploaded, at each machine's own price per TB. Two listings with similar GPU prices can differ on bandwidth. When you compare results:
- look at the download and upload prices per TB on each listing;
- use the maximum bandwidth price filter if you expect to move a lot of data;
- encode outputs efficiently on the instance before downloading, for example with
ffmpeg:
ffmpeg -i raw_output.mp4 -c:v libx264 -crf 20 -preset slow final.mp4- download in batches with
rsync, and delete rejected takes on the server first.
The GPU cost estimation guide shows how to add GPU time, storage and bandwidth into one number.
Running headless
GPU instances on Cloudj have no graphical desktop. You work over SSH, run generation scripts directly, or reach a web UI through a tunnel from your own computer:
ssh -L 8188:localhost:8188 -p <port> root@<host>Video tools are installed by you over SSH or brought in a custom public Docker image; there is no ready-made video template. Respect the licence of each model, especially for commercial use.
Protect long renders
Every listing is an independent host with no hardware SLA. Each machine has an "available until" date, after which the instance and disk are removed, and if a host goes offline, billing pauses but the instance does not move. Download finished clips regularly instead of leaving a whole project on the instance.
FAQ
Is 24 GB enough for text-to-video?
For smaller models and short clips, often yes with memory-saving options. Larger open models are far more comfortable on 32 GB to 96 GB.
Can I increase the disk later?
No. Disk size is fixed at deploy. Size it for models, outputs and headroom.
Does region affect generation speed?
No. It affects file transfers and how responsive a remote UI feels.
Why is my bill higher than GPU time?
Downloads and uploads are charged per GB, and video files are large. Check bandwidth prices before you deploy.
Choose your video GPU
Open the RTX 5090 deploy page, set your disk size, and enter the country code nearest you. Compare all VRAM tiers and live prices on GPU cloud.