gpu vps
AI inference and fine-tuning
A whole GPU, passed through, on a commitment that makes the maths work.
What we would deploy
€287/mo
€410−30% annual
Time-sliced vGPUs make benchmarking meaningless and make memory-bound inference unpredictable. FUSION passes the entire physical card through over PCIe Gen5, so the device you see is the device you have: full memory, full clocks, direct driver access, no scheduler between your kernels and the silicon.
Why this configuration
Start on an RTX 4090 for models up to about thirty billion parameters quantised, move to L40S for forty-eight gigabytes of memory, or take an H100 NVL when you need the bandwidth. On the annual cycle a 4090 lands near the cost of two months of on-demand capacity elsewhere, which is what makes long fine-tuning runs affordable at all.
What we would deploy
Sizing
Weights plus KV cache, then round up to a real card. Weights are parameters times bytes per parameter: 8B at fp16 is 16 GB, 70B at 4-bit about 40 GB. KV cache is the part people forget — it scales with batch times context. So: 8B fp16 on an RTX 4090 (24 GB), 70B quantised on an L40S (48 GB), 70B at fp8 with long context and real batching on an H100 NVL (94 GB). RTX 4000 Ada suits embeddings and small vision models.
Passthrough, not vGPU
FUSION hands the whole PCIe device to your VM through IOMMU. The card appears in lspci, nvidia-smi reports it directly, and you install whatever driver and CUDA version your stack needs. Nothing is time-sliced with another tenant and no licence server sits between you and the hardware. vGPU is the opposite arrangement: the hypervisor partitions the card, schedules slices between guests, and pins you to the driver branch the host runs. For inference that matters twice over — MPS and CUDA graphs behave predictably, and VRAM is genuinely yours rather than a quota that another guest's allocation can pressure.
Throughput is a batching problem
A single request leaves most of a modern GPU idle. Decode is memory-bandwidth bound, so tokens per second for one stream is set by VRAM bandwidth and barely moves with more compute. Concurrency is where the silicon earns out. Continuous batching in vLLM or TensorRT-LLM pushes aggregate throughput up several times over naive serving, at the cost of VRAM for the growing KV cache. That is the real sizing tension: every gigabyte you spend on weights is a gigabyte unavailable for concurrency. Quantising a 70B to 4-bit is often faster in aggregate than fp16, purely because it leaves room to batch.
What goes wrong
- Sizing on weights alone. KV cache grows linearly with batch and context, so an 8B model that loads in 16 GB will OOM at 32k context and batch 16. Compute the cache before you pick the card.
- Assuming consumer cards scale out. The 4090 has no NVLink and peer-to-peer over PCIe is disabled, so tensor parallel across two of them is slow. Use one bigger card, not two smaller ones.
- Expecting fp8 everywhere. fp8 needs Ada or Hopper. Quantising to fp8 on older silicon falls back to emulation and runs slower than the fp16 path you replaced.
Tune the machine
- Storage and encryption — ZFS with hourly snapshots · €7
- Addressing and transit — Uplink upgrade to 10 Gbps · €19
- Everything else — Second-resolution metrics + alerting · €5
More
Built for specific jobs
Game server hosting
Tick rate is a single-thread problem. Everything else is noise.
Trading and low-latency VPS
Distance to the matching engine, and nothing between you and the wire.
Private VPN and proxy endpoints
Your own exit, in a jurisdiction you picked on purpose.
Seedboxes and bulk storage
Terabytes that stay cheap and a port that stays open.
Kubernetes worker nodes
Cheap per core, dense, and identical every time.
Hosting resellers
Your brand on the panel, our hardware underneath.