Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.vast.ai/llms.txt

Use this file to discover all available pages before exploring further.

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 rental period
  • 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 the rental contract ends, hosts may extend the rental 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