GPU VPS vs dedicated GPU server: what you actually get

GPU VPS vs dedicated GPU server: the short answer

A GPU VPS is a virtual machine with access to a GPU, and that access can be anything from a time-sliced share of one card to several whole cards passed through to your VM. A dedicated GPU server gives you whole GPUs that nobody else uses, with CPU, RAM and storage reserved for you. What you actually get depends less on the label than on three facts: whether the GPU is shared in turns, cut into a fixed slice or whole; how much of its memory is yours; and whether your GPUs are linked by NVLink.

“VPS” sometimes means a slice because a provider can then sell one data-center GPU to several customers who each need less than a whole card; NVIDIA’s MIG and vGPU exist for exactly that. On 19 October 2026, AWS listed G6f instances with as little as one-eighth of an NVIDIA L4 and 3 GB of GPU memory (AWS), and Azure’s NVadsA10 v5 virtual machines started at one-sixth of an NVIDIA A10 with 4 GiB (Azure). Others use the word for whole cards: Cloudzy says the GPUs in its “GPU VPS” are “dedicated passthrough, not vGPU, not MIG, not shared” (Cloudzy). A quick test: if a listing’s GPU memory is less than the card’s full memory, it is a slice.

In practice, there are four kinds of offer:

1. Shared, time-sliced GPU: several tenants take turns on one card.
2. Fractional GPU: a fixed slice of one card, a MIG instance or a vGPU profile.
3. Whole GPUs in a VM: full cards passed through to your virtual machine.
4. Whole server: the physical machine and all its GPUs, with NVLink or NVSwitch where the board has them.

Shared, sliced or whole: the comparison

Six questions separate them; sources follow in the next sections.

Shared and time-sliced GPUs

A shared GPU is the opposite of a dedicated one: several workloads take turns on the same card. NVIDIA’s GPU Operator for Kubernetes can advertise one card as several “replicas” whose workloads interleave, and “the GPU simply provides an equal share of time to all GPU processes, across all of the pods”. NVIDIA is clear about the cost: “Unlike Multi-Instance GPU (MIG), there is no memory or fault-isolation between replicas,” and asking for more than one time-sliced GPU does not guarantee a proportional share of compute (NVIDIA GPU Operator).

Your job then runs as fast as the other tenants allow, and one of them can take memory your job expected to have. This kind of sharing serves containers, and NVIDIA’s container tools “take care of mounting the appropriate NVIDIA Drivers” from the host (NVIDIA): you run on the host’s driver, whatever you install in the image. Time-slicing suits notebooks, development and light inference, not work that needs a known amount of memory or steady latency.

Fractional GPUs: MIG slices and vGPU profiles

MIG: a hardware partition

Multi-Instance GPU (MIG) splits one GPU into up to seven instances. Each gets “separate and isolated paths through the entire memory system”, so that a workload runs “with predictable throughput and latency” even when the others saturate their own memory; NVIDIA describes the result as a defined quality of service with fault isolation (MIG user guide). NVIDIA lists MIG for the A100, A30, H100, H200, B200 and RTX PRO 6000 Blackwell Server Edition, among others (supported GPUs). GeForce cards are not on that list, and the L40S spec sheet says “No” (NVIDIA L40S).

A slice is a fixed fraction of the card. On an 80 GB H100, the smallest profile, 1g.10gb, gets one-eighth of the memory and L2 cache and one-seventh of the streaming multiprocessors, and seven of them fit on one GPU. The smallest profile is 1g.18gb on the H200 and 1g.23gb on the B200, and the RTX PRO 6000 Server Edition splits into at most four 1g.24gb instances (MIG profiles). Two limits matter for AI work: “NCCL is currently not supported with MIG”, and peer-to-peer transfers work only between MIG instances of the same GPU (MIG considerations). A slice is for single-device jobs. AMD’s MI355X can likewise be split into 1, 2, 4 or 8 isolated compute partitions, of 36 GB each in the eight-way mode (AMD ROCm).

vGPU: fixed memory, shared engines

NVIDIA vGPU lets several virtual machines use one physical GPU at once (vGPU user guide). Each vGPU type has a fixed amount of memory: on an H100 SXM5 80 GB, NVIDIA’s compute types range from H100XM-4C, with 4 GB and up to 20 per GPU, to H100XM-80C, which takes the whole card (H100 vGPU types). Cards without MIG can be split too: the smallest L40S profile has 1 GB, up to 32 per card (vGPU types).

The memory is yours; the engines are not. With time-sliced vGPUs, “the GPU performs the work for each VM serially”, and the default best-effort scheduler “allows a vGPU to use GPU processing cycles that are not being used by other vGPUs” (vGPU scheduling), so your speed follows your neighbors’ load. Equal-share and fixed-share schedulers exist, but the host chooses.

The guest driver must be a release compatible with the host’s vGPU Manager, or “the NVIDIA vGPU fails to load” (release notes). CUDA developer tools and unified memory are disabled by default and enabled per vGPU on the hypervisor side, by whoever runs the host (vGPU configuration). And NVLink peer-to-peer transfers work only on time-sliced vGPUs that hold all of a GPU’s memory, not on vGPUs that sit on MIG instances (P2P support).

Whole GPUs in a VM: passthrough

In NVIDIA’s words, “GPU pass-through is used to directly assign an entire physical GPU to one VM.” Only the NVIDIA driver inside that VM accesses the card, the card is not shared among VMs, and several GPUs can be assigned to the same VM (NVIDIA). You get each card’s full memory and all its engines, and you install the NVIDIA driver you want. The hypervisor, the host kernel and the hardware around your VM remain the provider’s.

Multi-GPU VMs need one more check on NVSwitch boards such as HGX H100 or B200. According to NVIDIA’s Fabric Manager guide, full passthrough gives 2- and 4-GPU VMs reduced NVLink bandwidth, and 4-GPU VMs on H100-class systems asymmetric bandwidth, while the shared NVSwitch model, the one NVIDIA recommends, gives them complete bandwidth (Fabric Manager guide). Two offers that both say “4× H100” can therefore scale differently on the same hardware.

A whole server: all the GPUs, NVLink and NVSwitch

At the far end, you rent the whole machine. On an 8-GPU SXM board every GPU reaches every other one over NVLink: NVIDIA’s HGX B200 and B300 link eight GPUs through NVLink 5 switches at 1.8 TB/s per GPU (NVIDIA HGX), and the H100 SXM is rated 900 GB/s of NVLink against 128 GB/s for its PCIe Gen5 link (NVIDIA H100). On NVSwitch boards, the Fabric Manager service builds that fabric; on a bare-metal server it runs on your own host (Fabric Manager), next to a kernel and driver that are yours to choose.

PCIe cards have no such fabric. NVIDIA lists no NVLink for the L40S or the GeForce RTX 5090 (L40S, RTX 5090), and the RTX PRO 6000 Server Edition is a PCIe card too, so their GPUs exchange data over PCIe. That suits data-parallel training and one model per GPU; tensor parallelism, which exchanges data at every layer, gains most from NVLink. Our multi-GPU guide shows how to read and measure the topology.

Questions to ask before you rent

• Is the GPU shared or time-sliced? If it is, ask what stops a neighbor from using your memory: plain time-slicing does not.
• Is it a MIG slice or a vGPU profile? Ask for the exact profile name, such as 1g.10gb or H100XM-20C: it gives the memory and the share of the GPU.
• How much GPU memory, exactly? In GB per GPU, not “up to”.
• NVLink between my GPUs? Ask for the nvidia-smi topo -m output of the same configuration. On NVSwitch boards, ask whether 2- and 4-GPU machines get full NVLink bandwidth.
• Root access? Root inside a container is not root on the server: the driver and kernel stay the host’s.
• Can I install my own driver? Yes with passthrough or a whole server; on a vGPU, only releases compatible with the host’s vGPU Manager; in a container, no.
• How is it billed? By the second, the hour or the month, and what happens to your data when you stop.

Once you have access, two commands confirm most answers (nvidia-smi, MIG device names):

nvidia-smi -L        # each GPU and its UUID; MIG slices are listed as "MIG 1g.10gb Device 0"
nvidia-smi topo -m   # NV# = NVLink between two GPUs; PIX, PXB, PHB, NODE, SYS = PCIe paths

Where CryptGPU fits

CryptGPU rents whole GPUs only. Here are its answers to the questions above:

That suits work that keeps whole GPUs busy most of the month: models served around the clock, long fine-tunes, multi-GPU training. For an H100, a month at CryptGPU costs less than the median on-demand hourly price once the GPU runs more than about 16.8 hours a day; below that, hourly billing is cheaper (see the break-even for every GPU).

It is not the right choice for a notebook or a small model that fits in a slice, a few hours of compute, or several servers joined by InfiniBand: a fractional or hourly instance fits those better. Otherwise, see every GPU we rent, prices by server size, RTX PRO 6000 vs RTX 5090 for 96 GB or 32 GB per card, why we rent by the month and the FAQ, or configure a server.

GPU VPS and dedicated GPU server FAQ

What is a GPU VPS?

A virtual private server with access to a GPU: a time-sliced share of a card, a fixed slice (a MIG instance or a vGPU profile) or whole cards passed through to the VM, depending on the provider. If the listed GPU memory is less than the card’s full memory, it is a slice.

vGPU or passthrough: what is the difference?

Passthrough gives one VM a whole physical GPU, driven by the VM’s own NVIDIA driver. vGPU shares one GPU between several VMs, each with a fixed amount of memory and, unless its profile takes the whole card, a time-sliced share of the engines.

Is a MIG slice slower than a full GPU?

It has less of everything: a 1g.10gb slice of an H100 gets one-seventh of the streaming multiprocessors and one-eighth of the memory and L2 cache. In exchange, it keeps the same cache and memory bandwidth whatever the other slices do.

Can a GPU slice run an LLM?

A small one. By our sizing rule, which counts 92% of memory as usable, a 10 GB slice holds a model of about 7B parameters in FP8, or 14B in 4-bit; a 70B model needs about 84 GB in FP8. The sizing helper lists the configurations that fit a given model.

Can I train across several GPUs on a GPU VPS?

Only with whole GPUs: NCCL is not supported with MIG, and NVLink peer-to-peer on vGPU needs whole-GPU profiles. With whole GPUs in a VM, ask how the NVLink fabric is partitioned.