GPU VPS vs Cloud GPU: What You Rent and What It Costs

GPU VPS vs Cloud GPU: The Contract You Rent Decides the Cost, Not the Hourly Rate

TL;DR: GPU VPS vs cloud GPU is mostly a billing question. “GPU VPS” names four different contracts, and Vultr, DigitalOcean and Akamai keep billing a powered-off GPU instance. For one RTX PRO 6000, a $959.20 flat plan on a 24-month term is cheaper than a $3.00-per-hour plan above 10.49 useful hours a day, counting ten billed setup minutes, before egress.

Illustrative scenario: A developer needs a 96 GB GPU for evening fine-tuning and a private inference endpoint. One provider sells a “GPU VPS” for a flat monthly fee, another a “cloud GPU” by the hour. Both pages show a similar card, and neither says what happens to the bill on idle nights.

Thesis: In the GPU VPS vs cloud GPU debate the labels tell a buyer almost nothing, because both cover virtual machines with a whole GPU, virtual machines with a slice, containers and dedicated servers. The monthly cost is decided by how many hours per day the GPU does useful work and by whether the provider keeps billing it when you stop. On that basis a 24-month flat plan is cheaper above 10.49 useful hours per day for the two plans we priced, and keeping a stopped hourly instance costs as much as running it all month.

Conventions: GB means 10^9 bytes, and card sizes are the vendors’ nominal figures. Prices are USD list prices read from provider pages on November 6, 2026, and they change without notice. A “useful hour” is an hour in which the GPU runs your workload.

GPU VPS vs cloud GPU: four contracts sell under two labels

A VPS is a virtual machine with its own operating system, so a “GPU VPS” should be a virtual machine with a GPU attached. That holds for some products and fails for others. Contabo sells a “GPU VPS” with a full RTX PRO 6000 passed through and says there is no vGPU slicing. Vultr sells “Cloud GPU” machines, but its documentation marks the A100, A40 and A16 plans as vGPU, a shared physical card, and the L40S as passthrough.

Container platforms differ. RunPod pods and Vast.ai instances are Docker containers, and Vast.ai states that each instance gets exclusive access to its GPU. Hetzner’s GPU line is neither: its pages list dedicated servers rented monthly with a setup fee. A GPU VPS vs cloud GPU comparison across two sites therefore compares isolation and billing models, not prices for the same thing.

NVIDIA’s documentation supplies the vocabulary. In passthrough an entire physical GPU is assigned to one virtual machine. A time-sliced vGPU shares the GPU engines with other vGPUs, and their processes are scheduled one after another. A MIG-backed vGPU that fills a whole GPU instance has exclusive access to that instance’s engines. On a time-sliced card a neighbor changes your latency; on passthrough there is none.

Table 1. Four contracts behind “GPU VPS” and “cloud GPU”, examples read on November 6, 2026
ContractWhat you getGPU shared with other tenants?Examples on provider pages
VM with passthroughA virtual machine that owns one whole GPUNoVultr L40S; Contabo GPU VPS; GPU Mart
VM with a vGPU sliceA virtual machine with a fraction of a GPUYesVultr A100, A40 and A16 plans
Container on a GPUA Docker container on a hostExclusive by contract on Vast.aiRunPod pods; Vast.ai instances
Dedicated serverA whole machine rented by the monthNoHetzner GEX line

Source: Vultr documentation, Contabo and GPU Mart pages (vendor claims), RunPod and Vast.ai documentation, Hetzner server matrix; retrieved November 6, 2026. Takeaway: ask which row a plan belongs to before comparing its price with another plan.

A few nvidia-smi queries separate a slice from a whole card

A buyer need not trust the product page. NVIDIA documents commands that show how a GPU is presented to the operating system, and a renter can run them minutes after boot. The documentation has gaps, so we separate what it states from what it leaves out.

The nvidia-smi documentation says nvidia-smi -L lists each GPU with its UUID and nvidia-smi -q reports MIG mode. NVIDIA’s NVML reference defines five virtualization modes: bare metal, passthrough, a vGPU in a virtual machine, and two hypervisor-side modes. The vGPU quick-start guide shows a licensed guest printing a virtualization mode of VGPU and a product name that is a vGPU profile.

nvidia-smi -L
nvidia-smi -q | grep -i -A2 "virtualization"
nvidia-smi --query-gpu=pci.bus_id,mig.mode.current --format=csv

We did not run these on a paid instance, so we show no output. The documents leave three gaps: the nvidia-smi manual does not describe the “Virtualization Mode” field of -q, the printed strings for each mode are undocumented, and no document we read gives a command that tells a container from bare metal on the GPU side.

Table 2. What NVIDIA documentation says each signal means
SignalDocumented meaningWhat it tells a renter
NVML mode PASSTHROUGHDevice assigned to a virtual machine by passthroughYou own the whole card
NVML mode VGPUA vGPU inside a virtual machineYou have a slice; ask if it is time-sliced or MIG-backed
NVML mode NONEA bare-metal GPUA dedicated server or a container host
MIG mode EnabledCard partitioned into isolated instancesIsolated memory paths, but not your whole card

Source: NVIDIA nvidia-smi documentation, NVML enums, MIG User Guide and vGPU Quick Start, retrieved November 6, 2026. Takeaway: a MIG slice has no virtualization mode of its own, so read MIG mode and the device list too.

Hardware limits what a provider can sell. The MIG guide lists seven instances for the H100 and four for the RTX PRO 6000 Blackwell Server Edition, and NVIDIA’s L40S page lists MIG as unsupported. NVIDIA’s GPU Operator documentation says Kubernetes time-slicing has no memory or fault isolation between replicas. A time-sliced vGPU in a virtual machine differs: each vGPU has its own framebuffer, but the engines are shared and scheduled in series. Because the L40S does not support MIG, an L40S slice can only be time-sliced.

Virtualization also has a latency cost. Reported by HLRS Stuttgart (April 2026, preliminary, A100 80 GB): time to first token was 1.9% to 18.2% slower in a virtual machine; GPU decode time was nearly identical. Two-GPU NCCL all_reduce reached 14 GB/s on bare metal and 1.2 GB/s in the virtual machine, which the authors attribute to missing peer-to-peer access. The slides do not say whether the machine used passthrough or vGPU, and they tested inference only; the interconnect result bears on multi-GPU training, which was not tested.

A powered-off GPU still bills at Vultr, DigitalOcean and Akamai

Idle billing is the clause that most affects a part-time user in any GPU VPS vs cloud GPU choice, and providers state it in their documentation. “Stop” means different things on different platforms, so a habit learned on one costs money on another.

Vultr’s FAQ says a stopped Cloud GPU instance bills like a running one and that destroying it is the only way to stop charges. DigitalOcean says powered-off GPU Droplets bill until destroyed, and Akamai’s pricing page says the same. The container platforms split the cost. RunPod does not bill the erased container disk of a stopped pod but charges $0.20 per GB-month for its volume disk, against $0.10 while the pod runs. Vast.ai keeps accruing storage charges until you delete the instance.

Account limits add a second hidden step: AWS sets the default On-Demand quota for P instances and for G and VT instances at 0 vCPUs, against 5 for the standard families, so a first GPU launch starts with a quota request.

Table 3. What each provider’s documentation says about a stopped GPU instance
ProviderStopped or powered-off state
Vultr Cloud GPUBilled the same as running; destroy to stop
DigitalOcean GPU DropletsBilled until destroyed
Akamai GPU plansPowered-off VM still billed
RunPod podsContainer disk erased; volume disk $0.20 per GB-month
Vast.ai instancesStorage charges continue until deletion

Source: Vultr, DigitalOcean, Akamai, RunPod and Vast.ai documentation, retrieved November 6, 2026. Takeaway: on a virtual machine platform the only way to stop paying for the GPU is to destroy the instance, which also destroys the setup you built.

Destroying the instance after every session repays boot, driver check and model download each time, and the cost model below prices those minutes. For hourly list prices see the site’s GPU cloud pricing comparison.

VRAM sets the floor: a 32B model in BF16 leaves an 80 GB card almost no room for a 32K session

Price is irrelevant if the model does not fit. Weights take parameters times bytes per parameter, and the KV cache grows with context length and concurrent sequences. The site’s KV cache memory article derives the formula, applied here to cards providers list.

Qwen3-32B has 64 layers, 8 KV heads and a head dimension of 128 on Hugging Face, and its BF16 weights occupy 65.52 GB. At a 32,768-token context one sequence needs 8.59 GB of KV cache. An H100 has 80 GB, and vLLM’s documented default memory utilization is 0.92 for the standard allocator, so we left 8% of the card out of the budget. On the nominal 80 GB that leaves 8.08 GB, short of one 32K sequence, so by this budget the card serves none; the memory a driver reports differs from the nominal size, so read zero as marginal. A 141 GB H200 leaves 64.20 GB and serves seven.

Llama 3.1 70B is larger: its BF16 weights are 141.11 GB, more than the 141 GB of an H200, so the model does not fit that card under vLLM’s default limit. A 192 GB card leaves 35.53 GB and serves three 32K sequences. DigitalOcean lists the H200 at $4.47 per GPU-hour and a 192 GB MI300X at $2.59, so the card that fits the 70B model is also cheaper per hour, with a different software stack.

Table 4. Concurrent 32K-token sequences after weights and an 8% reserve, BF16 weights and BF16 KV cache
ModelWeights (GB)Card memory, nominal (GB)KV per 32K sequence (GB)Concurrent sequences
Qwen3-32B65.52808.590 (marginal)
Qwen3-32B65.521418.597
Llama 3.1 70B141.1114110.740 (weights do not fit)
Llama 3.1 70B141.1119210.743

Source: model configurations on Hugging Face and the Llama 3 paper (arXiv 2407.21783); derived by GPU Insights with calc_kv_cache.py, November 6, 2026. Takeaway: the memory class you rent decides whether a model serves any session, before price enters; nominal sizes understate real capacity a little, which can add one sequence.

Quantization changes the answer. OpenAI’s model card says gpt-oss-120b fits one 80 GB GPU, with 65.25 GB of MXFP4 weights. The model also alternates sliding-window and full-attention layers, so the naive KV formula overstates its cache, and we computed no sequence count for it.

A rented H100 beats Together’s price only at a relaxed latency target and high utilization

Fit says a model can run; whether renting pays depends on how busy the card is: hourly price divided by tokens per second times 3,600 times utilization, times one million.

Editorial estimate: the inputs are DigitalOcean’s H100 at $4.41 per GPU-hour and two points of the SemiAnalysis InferenceX ladder for gpt-oss-120b on one H100 (FP4, vLLM, 8K tokens in and 1K out, runs from March 27 to May 17, 2026): 8,973 tokens per second per GPU at 50 tokens per second per user, and 5,863 at 100. That is Tier 2 data at two interactivity targets, not the throughput of an average rented instance. The page quotes a cost of $0.055 per million tokens at $1.17 per GPU-hour for the second point, which reproduces only if the figure counts input and output tokens together, so we read it that way.

Reported by Together AI, Fireworks and Groq on November 6, 2026: gpt-oss-120b costs $0.15 per million input tokens and $0.60 per million output tokens. Reported by DeepInfra the same day: $0.037 and $0.17. At the benchmark’s eight input tokens per output token, the Together price is $0.20 per million total tokens and DeepInfra’s is $0.0518.

Table 5. Editorial estimate: H100 rental cost per million total tokens, gpt-oss-120b, FP4, vLLM, 8K in and 1K out
Utilization of billed timeAt 50 tokens/s per user (8,973 tokens/s)At 100 tokens/s per user (5,863 tokens/s)
10%$1.37$2.09
30%$0.46$0.70
50%$0.27$0.42
100%$0.14$0.21

Source: GPU Insights calculation from DigitalOcean pricing and SemiAnalysis InferenceX (Tier 2), November 6, 2026. Takeaway: at the 50 tokens/s target the rented H100 matches Together’s $0.20 above 68.3% utilization; at 100 tokens/s it would need 104.5%; DeepInfra’s $0.0518 needs 263.7% and 403.5%, so it is out of reach at both.

The latency target is the lever: a slower per-user rate packs more users on the card, and cost per token falls by a third. Per million output tokens, multiply by nine: the 100 tokens/s point at 30% utilization costs $6.27. That split assumes input and output tokens cost the same to process, which is a convention, not a measurement. The reliable input is your own measured throughput on your own prompts at your own latency target.

The realistic risks are the shared kernel and your own open port

Containers share the host kernel, and the NVIDIA Container Toolkit has had serious escapes: CVE-2025-23266 carries a CVSS score of 9.0 supplied by NVIDIA and lists toolkit versions up to 1.17.7 as affected in the NVD record, and CVE-2024-0132 affects 1.16.1 and earlier. Wiz argues that containers are not a strong isolation barrier in multi-tenant GPU hosting. We did not check which toolkit versions any provider runs; check your version against NVIDIA’s bulletin.

The larger exposure is the service you start. Ollama binds to 127.0.0.1 on port 11434 by default and its local API needs no authentication. In a Shodan survey published in September 2025, Cisco found 1,139 vulnerable Ollama servers exposed, about 19% of them actively serving models. vLLM’s --api-key protects only the /v1, /v2, /inference and /cohere paths, so other endpoints stay open with a key set. Its --host option has no default in the documentation, and the source code sets it to None, so do not assume a local-only bind and set it explicitly.

One licensing detail for a buyer’s checklist: clause 2.8 of the GeForce licence, version of February 25, 2025, says the driver software is not licensed for datacenter deployment. That is a question for providers renting GeForce cards, not a finding about any provider.

One RTX PRO 6000 costs less on a flat plan above 10.49 hours a day

To price the GPU VPS vs cloud GPU contract, take one GPU sold both ways: the RTX PRO 6000 Blackwell with 96 GB. Akamai lists it at $3.00 per instance-hour on its GPU pricing page, with 1,024 GB of storage and access by request; some GPU models require a contract. Contabo shows $959.20 per month as the effective rate for a 24-month subscription, with taxes included, and passes the full card through. The page says monthly billing is available with a one-month minimum but prints no month-to-month price. We treat the struck-through $1,199.00 as the probable monthly price, which is an inference.

We computed three patterns over a 30-day month. Pattern A destroys the hourly instance after each session and bills ten setup minutes. Pattern B stops the instance between sessions, which Akamai still bills. Pattern C is the flat plan.

Line chart of monthly cost for hourly, stopped-but-billed and flat plans of one RTX PRO 6000 Blackwell GPU as useful hours per day rise from 2 to 24
Figure 1. Monthly cost of one RTX PRO 6000 Blackwell 96 GB by useful hours per day. Source: GPU Insights calculation from Akamai and Contabo pricing pages; prices as of November 6, 2026

Editorial estimate — Methodology: pattern A = days × (hours + setup minutes ÷ 60) × hourly price; pattern B = 30 days × 24 hours × hourly price; pattern C = flat price. Computed with rent_model.py on November 6, 2026. The calculator below runs the same formulas.

Table 6. Assumptions behind the model
AssumptionValueBasis
Hourly price$3.00 per hourAkamai GPU pricing page
Flat price$959.20 per month (24-month term), $1,199.00 listContabo GPU VPS page
Days in month, setup30 days, 10 billed minutes per sessionEditorial choice
Storage, egress, taxAkamai: 1,024 GB of disk lost on destroy, 0 TB of transfer, overage $0.005 per GB, tax treatment not stated. Contabo: 900 GB, unlimited fair-use traffic, taxes included. Storage and egress left outAkamai and Contabo pages

Source: Akamai and Contabo product pages; month length and setup are editorial choices. Takeaway: leaving out storage and egress understates the hourly plan and lowers the true break-even, while Contabo’s included taxes push the other way; the idle-billing rule moves the bill by more than a thousand dollars.

Pattern B costs $2,160.00 a month regardless of use, 2.25 times the flat plan. Pattern A at 4 useful hours a day costs $375.00, or $3.13 per useful hour, against $7.99 for the flat plan at that usage. At 12 hours the flat plan is already cheaper per useful hour, $2.66 against $3.04.

Table 7. Monthly cost by useful hours per day, one RTX PRO 6000 Blackwell 96 GB
Useful hours per dayA: hourly, destroyed after useFlat plan, 24-month termA per useful hourFlat per useful hour
2$195.00$959.20$3.25$15.99
4$375.00$959.20$3.13$7.99
8$735.00$959.20$3.06$4.00
12$1,095.00$959.20$3.04$2.66
16$1,455.00$959.20$3.03$2.00
24$2,175.00$959.20$3.02$1.33

Source: GPU Insights calculation from Akamai and Contabo pages, November 6, 2026. Takeaway: for these two plans the flat plan is cheaper from 12 hours a day, before egress and with a 24-month commitment; break-even is 10.49 hours, or 13.16 at a $1,199.00 monthly price.

Enter your own quotes below.

GPU rental cost calculator

Defaults as of November 6, 2026. Defaults: one RTX PRO 6000 at $3.00 per hour against a $959.20 flat plan on a 24-month term, and an H100 at $4.41 per hour at the 100 tokens/s per user point, per output token against Together blended price. Replace them with your quotes.

Session
Hourly price and extras
Flat monthly plan
Tokens
Monthly cost by billing pattern
PatternMonthly costPer useful GPU-hour
A. Hourly, destroyed after each session––
B. Hourly, stopped but still billed––
C. Flat monthly plan––

Worked example

Take a developer using 4 useful hours a day, 30 days a month, on the contracts above.

  1. Billed hours per day: 4 hours plus 10 setup minutes is 4.17 hours.
  2. Pattern A: 30 days × 4.17 hours × $3.00 = $375.00.
  3. Pattern B: 30 days × 24 hours × $3.00 = $2,160.00, because the stopped instance still bills.
  4. Pattern C: $959.20 from the 24-month term.
  5. Break-even: $959.20 ÷ (30 × $3.00) − 10 ÷ 60 = 10.49 hours per day.

At 4 hours a day the hourly, destroyed pattern is $584.20 cheaper than the flat plan, and at 8 hours it is $224.20 cheaper. At 12 hours the order reverses. Whether this developer will hold 12 hours a day for 24 months is a demand forecast, not a price comparison.

The counterargument: if an API costs less per token, renting any GPU is wasted money

The strongest objection comes from Table 5. DeepInfra’s price is out of reach for a rented H100 at both latency targets, and Together’s needs 68.3% utilization even at the relaxed one. A buyer who only wants gpt-oss-120b tokens should use the API.

The response is narrower. An API sells the models its provider hosts under its context limits and logging terms. A rented card runs your own fine-tuned weights and your own quantization, serves workloads that are not token-shaped, such as image generation, and keeps prompts on a machine you control. Table 5 does not price those reasons.

What this analysis can’t tell you

The main limitation is that every price is a list price read from a page on one day, through text extraction that can misalign table rows. Providers changed rates during 2026, and Lambda’s new price book starts on November 16, so the figures decay quickly. The two plans in the cost model also differ in commitment, egress and tax treatment.

The second is that no workload ran on a rented instance. The nvidia-smi signals are what the documents state, not what a provider’s machine prints, the InferenceX token definition is inferred from its quoted cost, and the HLRS figures are preliminary and cover one card. Smaller gaps: Contabo’s page does not label a monthly price or state its price after the first 24 months, Contabo’s own chart prices the Akamai plan at $2.50 per hour against $3.00 on Akamai’s page, and the vLLM documentation prints no default bind address, so we relied on its source code.

Decision framework by role: what to decide and what to measure

ML engineer. If you can get hourly access, rent hourly and destroy after each session while you average under 10.49 useful hours a day, the break-even in Table 7, which assumes you accept a 24-month commitment on the flat side; a $1,199.00 monthly price would put it at 13.16 hours, and Akamai grants access by request. Measure your real useful hours for two weeks before signing a term.

DevOps or SRE. Put the stopped-instance rule from Table 3 in the runbook: on Vultr, DigitalOcean and Akamai, destroy, do not stop. Script boot, driver check and model download to shrink the ten setup minutes, and run the Table 2 queries first.

FinOps. In a GPU VPS vs cloud GPU review, track cost per useful GPU hour, not the hourly rate. Pattern B costs 2.25 times the flat plan, and it appears when nobody owns the stop-versus-destroy decision. Compare against an API only after measuring your own throughput and input-to-output ratio, because Table 5 moves from no match to a 68.3% break-even with the latency target alone.

Security lead. Bind inference servers explicitly to 127.0.0.1 behind an authenticated proxy, require a patched Container Toolkit on container platforms, and ask any provider renting GeForce cards about licence clause 2.8.

FAQ: edge cases when comparing a GPU VPS with a cloud GPU

Does stopping a GPU instance stop the bill?

Not on Vultr, DigitalOcean or Akamai, which bill until you destroy the instance. A stopped RunPod pod bills only its volume disk, and Vast.ai bills storage until deletion.

Is a GPU VPS the same as a dedicated GPU server?

No. Hetzner’s GPU line is dedicated servers billed monthly with a setup fee, while a GPU VPS is a virtual machine. Contabo and GPU Mart say their plans use passthrough, a vendor claim the Table 2 queries can check.

Can a GPU VPS run a 70B model?

Only if the card holds the weights: Table 4 shows 141.11 GB of BF16 weights do not fit a 141 GB card, while a 192 GB card leaves room for three 32K sessions.

Is it safe to expose Ollama on a public address?

No. Its local API needs no authentication, and a Cisco survey published in September 2025 found 1,139 vulnerable servers exposed. Keep the 127.0.0.1 binding and use an SSH tunnel or an authenticated proxy.

Sources & further reading

Related reading

Updated: November 2026. This article is independent engineering analysis for educational and informational purposes, not legal, financial, or investment advice. Prices and specifications are reported from provider pages read on November 6, 2026; break-even hours, memory fits and cost per million tokens are computed by GPU Insights. This article contains no affiliate links and no sponsored content.

Iovanny Olguín Ávila
Author: Iovanny Olguín Ávila

Computer Systems Engineer with an MSc in Computer Science. I apply quantitative analysis and data-driven methodologies to evaluate financial instruments, investment vehicles, and emerging technologies. My technical background allows me to cut through marketing language and analyze the actual mechanics of financial products — from HELOC structures to Medicare Advantage plan design to business credit card reward algorithms.

Leave a Comment