How to describe interruptible GPU instances honestly

Three facts a buyer needs before the discount

An interruptible GPU instance, sold as spot, preemptible or community capacity, can be reclaimed by the provider while it runs. To describe one honestly, a pricing page should state how much warning the buyer gets before a reclaim, what happens to the running job and its disk, and how the rate is set. The discount is the reason to buy. Those three facts decide whether the buyer can use it.

Any answer can be built around. Ten seconds of warning, a deleted disk and a rate that moves hourly are all workable if they are written down. What cannot be worked around is finding them out mid-run.

A page that gives the discount prominently and the three facts nowhere, or only in documentation two clicks away, has it the wrong way round for a buyer deciding whether the product is usable at all. The facts belong next to the rate, and the documentation can carry the detail.

Reclaim notice, in seconds or minutes

State the notice as a duration and say how it is delivered: a signal to the instance, a metadata endpoint the job can poll, an email, or none. A job that checkpoints on a signal needs the signal. Told only that instances "may be interrupted", a reader has to assume there is no warning at all, and on that assumption the product may not look usable.

If the notice is not guaranteed, say that as well. "Usually two minutes, sometimes none" is a fair statement. The worst case can be planned for once it is known.

Say too whether the notice period differs by card or by region. Moving a job from one card to another should not mean rediscovering the warning.

If a reclaim can be avoided by paying more, as with a bid that can be raised, say how. A buyer halfway through a run may well pay to keep it.

What happens to the job and its disk

There are several honest answers and they lead to different products. The instance may be stopped with its disk kept, so the buyer restarts where they left off once capacity returns. It may be terminated with its disk deleted, so anything not saved elsewhere is gone. It may be restarted automatically on another machine. Say which.

Then say what the buyer pays for while it is not running. A stopped instance whose disk is kept may still be billed for storage, and a buyer who expected a reclaim to stop all charges will find out on the invoice.

Checkpointing is the buyer’s job, but the page can make it easier. Pointing to where a job should write its state, and whether that storage survives a reclaim, turns a risk into a procedure.

How the rate is set

Some providers set a fixed discount from the on-demand rate. Some run an auction or a bid, where the buyer names a maximum. Marketplaces may let each host set its own price; one marketplace’s own pricing page says prices are set by the market and not by the platform. Each model is legitimate and each makes the rate mean something different.

If the rate moves, the page should say how often it can change and whether a running instance is repriced or reclaimed when it does. A buyer reading a moving rate as fixed will treat the first change as a broken promise.

Take a consumer card as an example. The RTX 4090 has 24 GB of memory, and its own page compares on-demand rates: the count of sellers is 14 and the lowest listed hourly rate is $0.12. Interruptible rates for the same card sit outside that comparison, which is one more reason to label them where they appear.

Keep the interruptible rate out of the on-demand row

The worst description of an interruptible instance is no description: the rate shown in the same column as on-demand rates with nothing to tell them apart. It wins comparisons it should not, and the buyer who rents it expecting on-demand behaviour has a poor first run.

Give it its own row, the word "interruptible" or "spot" beside the figure, and a link to the three facts above. The GPU rate tables here compare listed on-demand rates, and a provider whose interruptible rate is clearly labelled is easy to keep out of a list it does not belong in.

Which jobs a buyer can put on an interruptible card

A page can help the buyer decide by saying what the product suits. Training that writes a checkpoint every few minutes to storage that survives a reclaim can lose only the minutes since the last write. Batch work broken into small pieces, such as running a model over a queue of documents, can retry the piece that was interrupted. Experiments and sweeps, where losing one run costs little, are the natural fit.

Serving a live application is the poor fit. A reclaimed instance behind a user-facing endpoint is an outage unless the buyer runs spare capacity elsewhere. So is a long training run with no checkpointing, where a single reclaim near the end loses the whole job.

Saying this on the pricing page may cost the provider a few buyers who would have been unhappy anyway, and it means the ones who stay chose the product knowing what it does.