GPU Pricing Models Compared 2026: On-Demand vs Reserved vs Spot

GPU cloud pricing in 2026 comes in five structures: on-demand hourly, reserved/committed, spot/preemptible, per-token API, and bare metal. Each optimises for a different trade-off between cost, flexibility, and performance guarantee. This post breaks each model down mechanically so you can match the right structure to your workload without overpaying for flexibility you do not need or underpaying for reliability you cannot afford to lose.

The Five GPU Pricing Models

GPU cloud billing has five structural models. Most providers offer two or three; packet.ai offers all five. Understanding the mechanics of each model prevents the most common mistake: using on-demand rates for workloads that should be on reserved, or using reserved rates for workloads that should be on spot.

Model 1: On-Demand Hourly

What it is: You provision a GPU instance, the clock starts, you pay per hour (sometimes per minute or per second) until you stop it. No upfront cost, no commitment, no penalty for stopping early.

How it works on packet.ai: On-demand billing at packet.ai runs per hour. An A100 80GB at $1.43/GPU-hr means you are charged $1.43 for each hour the instance is running, whether or not your workload is using 100% of the GPU. Stopping the instance stops the billing.

When on-demand is the right model:

• Development and debugging - you need the GPU for a few hours, not days
• Experiments with uncertain runtime - you do not know in advance how long the run will take
• Variable load with natural start/stop cycles - your inference API has predictable off-hours
• Evaluation runs before committing to a longer job

When on-demand is the wrong model:

• Steady-state 24/7 inference - you are paying on-demand rates for capacity that will always be running
• Long training runs with a known endpoint - you are paying for the flexibility premium you are not using

On-demand rates on packet.ai - Dynamic tier. These are the prices for maximum flexibility. If your GPU runs fewer than 730 hours a month (i.e. it has planned downtime), on-demand is correct. If it runs 24/7, move to reserved or bare metal.

Model 2: Reserved / Committed Pricing

What it is: You commit to a GPU for a fixed period (typically 1 month or 1 year) in exchange for a lower hourly rate. The commitment is to pay for the period regardless of actual usage - you cannot stop and restart without cost.

How it works on packet.ai: packet.ai's Dedicated tier is available on monthly terms at a lower rate than hourly on-demand. Committing monthly locks in the rate for the billing period. On some providers, annual commits cut rates further - the trade-off is locking capital for 12 months.

When reserved is the right model:

• Steady-state 24/7 production inference - the GPU runs continuously, so you pay for every hour anyway
• Training runs with a known or estimable duration - if you know a run takes 3-4 weeks, commit monthly
• Cost predictability for budgeting - fixed monthly billing simplifies finance reporting

When reserved is the wrong model:

• Variable workloads with significant idle time - you pay for hours the GPU is not running
• Experiments with uncertain scope - committing to a month when you might be done in a week wastes the commitment premium

The break-even point between on-demand and monthly reserved is typically around 60-70% utilisation. If your GPU runs more than 15-18 days of a 30-day month, the monthly rate is cheaper. Below that, on-demand gives you more flexibility for the same or lower total cost.

Model 3: Dynamic / Spot / Preemptible

What it is: The cheapest GPU compute available, priced at a significant discount to on-demand, but the instance can be interrupted by the scheduler. On AWS and GCP, this is called "spot"; on packet.ai, it is the Dynamic tier.

Important distinction: packet.ai's Dynamic tier is not identical to AWS spot. AWS spot instances are interrupted when demand exceeds supply and the spot price rises above your bid. packet.ai's Dynamic capacity is scheduler-managed - the scheduler places workloads based on actual resource fingerprints (VRAM, bandwidth, SM utilisation) and can co-locate complementary workloads. The interruption model is different, but the key characteristic is the same: lower price, lower reliability guarantee than Dedicated.

When Dynamic/spot is the right model:

• Fault-tolerant training with frequent checkpoints - if interrupted at step 5,000, resume from step 4,800
• Batch inference pipelines - each item is independent, interruption loses the current batch, not the whole job
• Hyperparameter sweeps - losing one run is acceptable when you are running 50 in parallel
• Data preprocessing - idempotent jobs that restart cleanly

When Dynamic/spot is the wrong model:

• Production inference APIs with latency SLAs - an interruption during a user request is unacceptable
• Training runs that do not checkpoint - losing 48 hours of compute because a checkpoint was not saved is expensive in calendar time, not just money
• Stateful workloads that cannot resume - any job where restarting from scratch is not an option

The operational requirement for Dynamic/spot: your job must checkpoint. For PyTorch training, use torch.save() every N steps (N small enough that losing one checkpoint interval is acceptable). For vLLM batch inference, track completed item IDs and skip on restart.

Model 4: Per-Token and Per-Image API Billing

What it is: Instead of billing per GPU-hour, you pay per unit of output: per token for LLM inference, per image for image generation. No GPU provisioning, no idle cost, scale to zero between requests.

How it works on packet.ai: Token Factory bills per input and output token. Pixel Factory bills per generated image. In both cases, if you make zero requests, you pay zero. The GPU fleet is managed entirely by packet.ai - you interact only with an API endpoint.

When per-token/per-image billing is the right model:

• Variable or unpredictable demand - your inference API has traffic spikes and quiet periods
• Prototyping and early-stage products - you are not sure of your volume, and per-token billing lets you validate before committing to GPU capacity
• Teams without GPU infrastructure expertise - you want inference without managing CUDA, vLLM, and serving
• Low-volume workloads - at very low token volumes, per-token pricing is cheaper than keeping a GPU running for the occasional request

When per-token billing is the wrong model:

• High-volume, steady-state inference - once you cross a volume threshold, the per-GPU economics are significantly cheaper than per-token rates
• Custom models or fine-tuned weights - Token Factory serves specific models; if you need your own weights, you need a GPU instance
• Specific inference configuration - custom quantisation, context lengths, or serving settings require direct GPU access

The break-even between Token Factory and running your own GPU varies by model. A rough calculation for Llama 3.1 70B on an A100 at $1.43/GPU-hr: the GPU generates approximately 40 tokens/second at batch size 16. At 100% utilisation, that is 144,000 tokens per hour. Token Factory at $0.30/1M output tokens costs $0.043 per 144,000 tokens - significantly less than $1.43 per GPU-hour. However, most applications do not run at 100% GPU utilisation. At 20% utilisation (realistic for many production APIs with variable traffic), the GPU costs 5x more per token than Token Factory.

Model 5: Bare Metal

What it is: You rent the entire physical server - all GPUs, CPU, RAM, and NVMe - with no virtualisation layer. You get direct hardware access, no hypervisor overhead, and complete control over the software stack.

How it works: Bare metal is typically billed monthly. You are renting a specific server with defined hardware - not a virtual slice of it. This means predictable, consistent performance with no noisy-neighbour effects and no virtualisation overhead. packet.ai offers bare metal GPU servers on monthly terms.

When bare metal is the right model:

• Sustained pretraining or large-scale fine-tuning where every FLOP matters
• Custom kernel development that requires direct hardware access
• Inference fleets where virtualisation overhead (typically 2-5%) accumulates to a meaningful cost at scale
• Compliance or security requirements that mandate single-tenant physical hardware
• Teams that have already optimised their software stack and want to eliminate the last layer of abstraction

When bare metal is the wrong model:

• Variable workloads - you pay for the server whether it is running at 10% or 100%
• Short-duration work - monthly commitment does not make sense for a week-long job
• Teams without systems administration capacity - bare metal requires managing the full software stack with no managed layer

Matching Pricing Model to Workload

A decision framework for common workload types:

The Cost of Getting This Wrong

The most common mismatch: using on-demand pricing for a GPU that runs 24/7. An A100 at $1.43/GPU-hr on-demand runs to $1,044/month. The same GPU on a monthly reserved tier at a 40% discount is $626/month. Over 12 months, the difference is $5,016 per GPU - and most production inference deployments run multiple GPUs.

The second most common mismatch: using reserved pricing for a training run that finishes in 10 days but you committed monthly. If the run finishes early, you pay for 20 idle GPU-days at the reserved rate. On-demand with no commitment would have been cheaper if the run was shorter than the utilisation break-even.

The third mismatch: using per-GPU pricing for a low-volume inference workload. A GPU running at 5% utilisation (serving occasional requests) costs the same per hour as one running at 100%. Token Factory with per-token billing costs only for actual inference - at 5% GPU utilisation, Token Factory is 20x cheaper per token than self-hosted.

How packet.ai's Pricing Models Map to This Framework

packet.ai covers all five pricing models:

• On-demand hourly: Dynamic tier, per-hour billing, stop anytime
• Reserved: Dedicated tier, monthly billing commitment, pinned hardware
• Dynamic/scheduler-managed: Dynamic tier (the name reflects the model - scheduler places workloads based on resource fingerprints)
• Per-token: Token Factory - OpenAI-compatible API, $0.10/M input tokens, $0.30/M output tokens
• Per-image: Pixel Factory - image and video generation API, per-image billing
• Bare metal: Full server access, monthly terms

One structural note: packet.ai does not separate "Dynamic" and "Reserved" the way some providers separate "spot" and "on-demand". The Dynamic tier is scheduler-managed (lower price, lower guarantee) and the Dedicated tier is pinned (higher price, 99.99% SLA). Both bill hourly or monthly. The on-demand vs committed distinction exists within the Dedicated tier via hourly vs monthly billing.