Skip to main content
Vast.ai offers three instance types with different priority levels and pricing models to match your workload requirements and budget.

Overview

On-demand

High Priority Fixed pricing, guaranteed resources

Reserved

High Priority Discounted rates with pre-payment

Interruptible

Low Priority Lowest cost, may be paused
In the create interface, you’ll see a selector for “on-demand” or “interruptible”. Once an instance is rented, you cannot change its type. However, you can convert on-demand instances to reserved for discounts.

On-demand Instances

Best for: Production workloads, continuous training, time-sensitive tasks On-demand instances provide:
  • Exclusive GPU control with high priority
  • Guaranteed resources for the contract duration
  • Fixed pricing set by the host
  • Maximum duration shown on offer cards
  • Data persistence even when stopped

Key Considerations

  • Check the maximum duration before renting (shown on offer cards)
  • For long-running jobs (days/weeks), verify host reliability scores
  • When contracts expire, hosts may renew or stop the instance
  • Data remains accessible when instances are stopped
Expired Instance Deletion: Expired instances may be deleted 48 hours after expiration. Retrieve your data before then. Expired instances cannot restart while expired.

Reserved Instances

Best for: Long-term projects, predictable workloads, cost optimization Reserved instances are on-demand instances with pre-paid discounts:
  • Up to 50% discount based on commitment length
  • Same high priority as on-demand
  • Convert anytime from existing on-demand instances
  • Credits locked to the specific instance
  • Partial refunds available if cancelled early
To create a reserved instance, first rent on-demand, then convert using the discount badge on your instance card.
For detailed instructions on creating and managing reserved instances, see Reserved Instances.

Interruptible Instances

Best for: Batch processing, fault-tolerant workloads, development/testing Interruptible instances use a bidding system:
  • Lowest cost (often 50%+ cheaper than on-demand)
  • Bidding priority - higher bids get priority
  • May be paused if outbid or if on-demand requested
  • Data preserved when paused but instance not functional
  • Resume automatically when priority returns

Working with Interruptible Instances

When using interruptible instances:
  • Save work frequently to disk
  • Use cloud storage for important outputs
  • Implement checkpointing in your code
  • Expect interruptions and plan accordingly
Priority rules:
  1. On-demand instances always have highest priority
  2. Among interruptible instances, highest bid wins
  3. Paused instances resume when they regain priority

Choosing the Right Type

Use CaseRecommended TypeWhy
Production inferenceOn-demandNeed guaranteed availability
Multi-day trainingReservedLong-term discount with reliability
Hyperparameter searchInterruptibleCan handle interruptions, cost matters
Data preprocessingInterruptibleCan resume where left off
Time-critical jobsOn-demandCannot afford interruptions
Development/testingInterruptibleShort sessions, cost-sensitive
Steady workloadsReservedPredictable usage, want discounts

Quick Reference

Switching Between Types

  • On-demand → Reserved: ✅ Yes, anytime via discount badge
  • On-demand → Interruptible: ❌ No, must create new instance
  • Interruptible → On-demand: ❌ No, must create new instance
  • Reserved → On-demand: ⚠️ Lose remaining discount

Priority Levels

  1. On-demand/Reserved: High priority, never interrupted
  2. Interruptible (high bid): Runs when resources available
  3. Interruptible (low bid): Paused until higher bids complete

Next Steps

I