GPU Server Hosting

What is a GPU server and how is it different from a CPU server?

A GPU server uses a graphics card with thousands of small cores to perform huge numbers of simple calculations in parallel; the matrix multiplications at the heart of AI models are ideally suited to this parallelism. A CPU does sequential work quickly with a few powerful cores, while a GPU applies the same operation to millions of numbers at once. That is why a language model generating an answer or an image model drawing a picture is many times faster on a GPU than on a CPU.

The second critical component of a GPU is VRAM, the card's own memory. Model weights, intermediate results and, for language models, the context cache (KV cache) must sit in this memory; if a model does not fit in VRAM it either will not run at all or spills into system memory and slows down dramatically. When choosing a GPU, the amount of VRAM usually matters more than raw compute.

What is a GPU server used for?

A GPU server is used for any workload that needs parallel compute, from running large language models to 3D rendering. The most common scenarios are:

• LLM inference: running open-weight models such as Llama, Qwen, Mistral and Gemma on your own server to provide an internal chat assistant or API. Details: LLM server hosting.
• RAG applications: loading company documents into a vector database so the model answers from those documents.
• Fine-tuning: adapting a model to your own data with LoRA or QLoRA.
• Image generation: running Stable Diffusion, SDXL and Flux models through ComfyUI or Automatic1111.
• 3D rendering and video: Blender Cycles (OptiX/CUDA), video encoding (NVENC) and effects processing; see GPU render server.
• Speech and vision: transcription with Whisper, object detection and OCR.

Which graphics cards are used?

LIONFIN GPU servers use NVIDIA's professional workstation RTX A series cards (Ampere architecture); the plan table shows which card and how much VRAM each plan has. Unlike gaming cards, this series is designed to run under sustained load in data center and workstation environments.

Key Ampere features for AI work:

• Tensor cores: accelerate matrix operations in FP16, BF16 and TF32 precision; PyTorch uses them automatically.
• RT cores: accelerate ray tracing in Blender and other render engines.
• NVENC/NVDEC: perform video encoding and decoding on the card.
• CUDA compatibility: supported by PyTorch, TensorFlow, JAX, vLLM, llama.cpp and the rest of the ecosystem.

The graphics card is reserved for you; no other customer's workload shares your VRAM or compute units. This makes time estimates reliable, especially for long training jobs.

How much VRAM does a model need?

A language model's VRAM requirement is roughly its parameter count multiplied by the bytes per parameter, plus headroom for the context cache. The calculation works like this:

For example, an 8-billion-parameter model needs about 16 GB for the weights alone in FP16, and about 5 GB with 4-bit quantisation. The context cache comes on top: as the context window and the number of concurrent users grow, the KV cache can grow from a few gigabytes to much more. So do not plan VRAM to the limit; leave 20–30% headroom.

For image models, resolution and batch size are decisive; for fine-tuning, the method is: full fine-tuning needs several times the memory of inference, while QLoRA reduces this considerably. Each plan's VRAM is listed in the plan table.

What does the CUDA-ready image give you, and how do you set up the software stack?

The CUDA-ready image is an operating system image delivered with the NVIDIA driver and the CUDA toolkit already installed; when you connect, nvidia-smi sees the card and you can install libraries such as PyTorch straight away. Mismatches between driver and CUDA versions are the biggest time sink on GPU servers; the ready image lets you skip that step.

nvidia-smi
python3 -m venv ~/ai && source ~/ai/bin/activate
pip install torch
python3 -c "import torch; print(torch.cuda.is_available())"

If the last command returns True, the stack works. Commonly used tools:

• Ollama or llama.cpp: download and run a model with a single command.
• vLLM: a multi-user, OpenAI-compatible API server.
• Docker + NVIDIA Container Toolkit: expose the graphics card to containers.

You are free to update the driver yourself or install a different CUDA version.

What are the benefits of running an LLM on your own server?

The main benefit of running an LLM on your own GPU server is that you keep control of your data: prompts and documents are not sent to a third-party API provider. For organisations that process personal data or work with client contracts, health or financial data, this simplifies data-protection compliance and privacy assessments.

Other benefits:

• Predictable cost: a fixed monthly fee instead of paying per token; the difference grows with heavy use.
• Model freedom: run any open-weight model with the quantisation and settings you choose.
• Customisation: deploy a model fine-tuned on your own data.
• No rate limits: API providers' request quotas do not apply to you.

The downside is that model updates, security and monitoring are your responsibility, and you cannot always match the quality of the largest closed models.

Dedicated GPU server or hourly cloud GPU?

A monthly GPU server is usually more economical for continuous or daily workloads, and hourly cloud GPUs for occasional short experiments. Consider these criteria:

An API server, an internal chat assistant or an always-on image pipeline uses the card for most of the month; in that case a fixed-price server wins on both cost and availability. With the hourly model, rebuilding the environment, re-downloading the model and moving data every session creates a hidden time cost, repeated every time on services that wipe the disk when the instance stops. If you are experimenting and use a GPU a few hours a week, hourly may make sense; once you reach production, a fixed server stands out for both cost and ease of operation. A detailed comparison is on the dedicated GPU server vs cloud GPU page.

What network and data center infrastructure do the GPU servers use?

GPU servers run on the LIONFIN network with 600 Gbit/s of total upstream capacity, in data center racks where the cold aisle is kept between 18 and 24 °C. Graphics cards produce a lot of heat under heavy load; stable cooling prevents the card from lowering its clock speed due to temperature (thermal throttling) and helps keep performance steady during long training jobs.

The large upstream capacity saves time when downloading big model files from repositories such as Hugging Face and transferring datasets to the server; weight files of tens of gigabytes are common. All traffic passes through the RouteFence firewall layer, and volumetric DDoS attacks are filtered at the network level.

The infrastructure is monitored 24/7 by NOC and SOC teams; our uptime target is 99.99%, which is a target, not a guarantee. For long training jobs, make a habit of saving regular checkpoints so you do not have to start over after an interruption.

How do you publish your model API securely?

The most important rule when exposing a model server to the internet is never to open the inference port directly, but to put an authenticated reverse proxy in front of it. Tools such as Ollama, vLLM and ComfyUI have no or limited authentication by default; an open endpoint lets strangers use your graphics card for free.

1. Start the model service so that it listens only on 127.0.0.1.
2. Put Nginx or Caddy in front and enable HTTPS with Let's Encrypt.
3. Add an API key or basic authentication; restrict access to specific IPs if possible.
4. Define request size and rate limits; very long prompts can exhaust VRAM.
5. Leave only ports 22 and 443 open in the firewall.

Use keys rather than passwords for SSH, and apply UFW firewall rules on day one. Weight files and fine-tuning results are the product of your work; keep backups of them off the server.

How is a GPU server used for rendering and video?

For rendering and video work, a GPU server lets you finish long jobs in the data center without tying up your local workstation: you upload the scene, start the render from the command line and download the result. Blender supports headless (no UI) operation for this:

blender -b scene.blend -E CYCLES -o //output/frame_#### -a -- --cycles-device OPTIX

This command renders every frame of the scene with the Cycles engine using the RTX card's OptiX acceleration. Points to watch:

• Scene memory: textures and geometry must fit in VRAM; for scenes that do not fit, lower texture resolution or split the scene into layers.
• File transfer: transfer large project folders with rsync so only changed files are resent.
• Video encoding: FFmpeg's h264_nvenc and hevc_nvenc encoders encode on the card without loading the CPU.
• Long jobs: run them inside tmux or screen so they continue even if the SSH connection drops.

For multi-card needs such as a render farm, you can connect several servers to the same job queue.

How do you back up model files and datasets?

The assets to back up on a GPU server are not the models you downloaded but what you produced: fine-tuning results (LoRA adapters), training checkpoints, cleaned datasets, the vector database and configuration files. Open-weight base models can be downloaded again when needed; but if the output of a training run that took days is lost, reproducing it takes just as long.

• Save checkpoints at set steps in your training script and keep the last few.
• Regularly copy adapters and datasets to storage outside the server with restic or rclone.
• Record your Python environment with requirements.txt or a Dockerfile, so you can rebuild the same environment on another server in minutes.
• Use the vector database's own export tool; copying a running database folder can produce an inconsistent backup.

This routine also makes it easier to move to a plan with more VRAM or to another server later.

How do you choose the right GPU server plan?

Choose a GPU server plan by VRAM first, then system memory and disk, and CPU cores last. The order works like this:

1. VRAM: the weights of the largest model you will run at your chosen precision + context cache + headroom. If the model does not fit, nothing else matters.
2. System memory: models are loaded into system memory before the card; data preprocessing and the vector database also run here. A good rule is for system memory to be no smaller than VRAM.
3. Disk: several model versions, datasets, checkpoints and Docker images fill space fast; NVMe shortens loading times for large weight files.
4. CPU: matters for data loading, tokenisation and preprocessing, but is not the bottleneck in most scenarios.

Each plan's graphics card, VRAM, CPU, memory and disk values are kept current in the table on this page. Small models that run on CPU only and embedding services may not need a graphics card at all; in that case a VDS server is the more economical option.