Interruptible GPU prices: risk and reward

An interruptible price is the platform renting out idle GPU capacity well below the standard hourly rate. In return, the platform reserves the right to stop you with short notice when it needs the capacity for standard tenants.

The model is the same as “spot/preemptible instances” in cloud computing: the discount is flexibility bought with interruption risk.

An idle GPU earns the platform nothing while electricity and depreciation keep running. Filling that capacity at a low price is pure gain for every hour above marginal cost.

The price itself fluctuates with supply and demand: it rises in busy periods and can drop to half the standard rate or lower when capacity is abundant.

Interruptions are typically triggered by rising demand: as customers renting at the standard rate start filling capacity, interruptible tenants are reclaimed first, in priority order. The notice window is short and the GPU is taken back immediately; persistent disk data is usually kept, so you can resume where you left off.

For the interruptible tenant the real question is not “will I be interrupted?” but “what do I lose when I am?”

A simple example: with a standard rate of $1.20/h and an interruptible rate of $0.45/h, the saving is 60% per hour. But every interruption adds a restart and warm-up cost: if your workload loses an average of 20 minutes per interruption, the effective cost gap shrinks significantly for a workload interrupted every 4 hours.

The correct formula is: expected cost = hourly rate × (hours used + hours spent on restarts). Measure the interruption frequency with a few days of testing before committing a long-term project.

• Save checkpoints regularly; with persistent disk, an interruption is only lost time.
• Prefer stateless, deterministic work: rendering, simulation, hyperparameter sweeps, data preprocessing.
• Split work into small chunks run from a queue; when a device is interrupted, the queue moves to other capacity.
• A design that can run in parallel across multiple devices/regions spreads interruption probability.

Training jobs that progress sequentially on a single GPU, carry a high checkpoint cost, and have hard deadlines are not suitable for the interruptible model; they should run on standard rentals. The rule is simple: is an interruption a delay or a data loss? If it is a delay, interruptible is an option; if it is a loss, never.