GPU server rental: which tasks need one and how to choose the card
A server with a graphics card makes sense when the work splits into thousands of parallel threads: the matrix operations of neural networks, rendering frames, encoding video. A CPU handles this kind of job many times slower, while buying your own data-centre card costs as much as a car and leaves it idle between jobs. The table above lists cloud and VPS plans with a GPU from hosts in Europe, the USA and Asia; the switch above it also shows dedicated servers with a graphics card.
Why people rent a GPU and when a CPU is enough
- Neural network inference. A language model with 7–70 billion parameters, speech recognition, embeddings for document search. On a GPU an answer arrives in seconds, and one server can serve many users at once.
- Fine-tuning. Fine-tuning and LoRA adapters on your own data need noticeably more video memory than running the same model: besides the weights, gradients and optimizer state also live in memory.
- Image generation. Stable Diffusion, Flux and similar models produce an image in seconds on an RTX-class card and in minutes on a CPU.
- Rendering. Blender Cycles, Redshift, Octane: renting for a few hours before a deadline is cheaper than buying a workstation for one project.
- Video transcoding. The NVENC/NVDEC hardware codecs encode a stream into several qualities at once and take the load off the processor.
- Scientific computing. Molecular dynamics, simulations, image processing: anything written for CUDA or OpenCL.
You do not always need a graphics card. Small language models in compressed form run on an ordinary processor too: slower, but at the flat price of a regular VPS. For an internal bot or document processing without strict speed requirements, start with the VPS for Ollama selection and move to a GPU once response time becomes the bottleneck.
Cloud GPU or a dedicated server with a card
A cloud GPU or GPU VPS suits short and unpredictable jobs. Many plans are billed by the hour: start the server, run the training or the render, delete it, and pay only for the time used. In such plans the card is either passed through to the virtual machine whole (passthrough) or shared between customers via vGPU, where you get a slice of memory and compute units. Check which one you get: a slice is fine for inference of small models, but not for training.
A dedicated server with a graphics card belongs to one customer: no virtualization between you and the card, consistent performance and usually more disk and memory. It pays off under steady load, when a model answers users around the clock or the render queue never empties. If you need a powerful machine but not a GPU, see the general catalog of dedicated servers.
How to read a GPU plan
- Card model and generation. Consumer RTX 3090 and 4090 cards give a lot of compute for the money and are good for image generation and inference. Professional A2000 and L4-class cards are power-efficient and fit inference and video. A100 and H100 are for training large models: more memory, a fast link between cards and support for formats such as BF16 and FP8.
- Video memory. This is the main limit: a model that does not fit into VRAM either will not start or runs several times slower. A rough rule: at full FP16 precision a billion parameters takes about 2 GB, with 4-bit quantization several times less, plus headroom for context. For training, multiply by several times again.
- Number of cards. Two cards are not one card with double the memory: the model has to be split between them, and the link speed between cards (NVLink or PCIe) affects the result.
- CPU and RAM next to the card. A weak CPU cannot feed data fast enough, and an expensive card sits idle. System memory should ideally be at least as large as video memory.
- NVMe disk. Datasets, checkpoints and model weights take tens to hundreds of gigabytes; a slow disk stretches every load.
- Bandwidth and traffic. Weights of a large model are downloaded in gigabytes. Check port speed and the traffic limit so the first download does not eat the monthly quota.
- Ready images. An image with the NVIDIA driver, CUDA, PyTorch or GPU-enabled Docker saves an hour of setup. Check the versions: an old driver will not run a recent framework.
- Hourly or monthly price. Compare by real usage: a few hours a day favours an hourly plan, round-the-clock work favours a monthly one.
What to check before paying
- A test hour. Rent the server for an hour, run your own job and look at the nvidia-smi output: card model, memory size, driver version and utilization under load.
- Card availability. Popular models are often sold out, and a plan in the list does not guarantee a free card in the location you want. Ask how long delivery takes and whether a server can be reserved.
- Data location. If the model processes personal data of people in the EU, GDPR applies to you as the controller, and a data centre inside the EU makes transfers easier to document. Otherwise location mostly affects how fast datasets download.
- Persistent storage. Deleting an hourly server usually wipes its disk. Check whether there is a persistent volume or snapshots so you do not download the weights again on every start.
- Payment. Hourly plans charge a prepaid balance, and the server is stopped when the balance hits zero. Most hosts accept cards, many take PayPal and business customers can usually pay by invoice; the table shows the methods for each plan.
If the card is needed for only part of a project, move the rest to a regular server from the VPS catalog: the web interface and the database live there, and the GPU server is switched on only for compute.