The short answer: a spot or preemptible GPU rate is not a discount on the same product you get with on-demand pricing — it's a lower price for a different, riskier product. Spot and preemptible instances in India's GPU cloud market are typically listed well below the equivalent on-demand rate for the same GPU, but that gap exists because the provider can reclaim the instance with little or no warning when it needs the capacity elsewhere. Before comparing a spot rate to an on-demand rate as if they were interchangeable, it's worth working out whether your workload can actually absorb what that lower price is compensating for.
What "spot" and "preemptible" actually mean
Both terms describe the same underlying trade: the provider sells you access to otherwise-idle capacity at a reduced rate, on the condition that it can take the instance back — usually with a short notice window, sometimes none at all — if a full-price customer needs it. "Spot" is the more common term among GPU-specific and global marketplaces; "preemptible" is more common terminology carried over from general-purpose cloud computing. Functionally, for GPU rental, treat the two as describing the same risk profile unless a specific provider's terms say otherwise.
The discount is pricing a real risk, not a marketing gimmick
It's tempting to read a lower spot price purely as savings. A more accurate read is that the price difference is what the provider is paying you, in effect, to accept two things: your job might stop mid-run without warning, and you might not be able to get a replacement instance immediately if demand for that GPU model spikes. For workloads that can genuinely tolerate both of those, spot pricing can be a legitimate way to lower cost per completed unit of work. For workloads that can't, comparing only the headline ₹/hour number and picking the cheaper one is comparing the wrong things.
Workloads that can actually absorb interruption
- Batch training with frequent checkpointing. If your training loop saves model state every few minutes (or better, supports resuming from the last checkpoint automatically), an interruption costs you at most the work since the last save — not the whole run.
- Embarrassingly parallel jobs. Hyperparameter sweeps, batch inference over a large offline dataset, or rendering/data-processing jobs split across many independent workers can lose one worker without the whole job failing — you just requeue that chunk.
- Non-time-critical experimentation. Exploratory runs where an interruption just means restarting later, with no user or deadline waiting on the result.
Workloads that can't
- Live inference serving. An interrupted instance behind a production endpoint is a production outage, not a resumed job. Spot capacity is a poor fit for anything user-facing unless it sits behind a fallback pool of on-demand capacity.
- Long single-shot training runs with no checkpointing. If a run takes 10 hours and only saves state at the end, an interruption at hour 9 destroys the entire run's cost, not just the marginal hour.
- Multi-GPU distributed jobs with tight synchronization. Losing one node in a synchronized multi-GPU training job can stall or crash the whole job, not just that node's share of the work — the blast radius of one interruption is larger than it looks from the per-GPU price.
What to actually check before renting spot capacity
- Notice period. Ask specifically how much warning (if any) you get before reclamation, and confirm the mechanism your workload uses to react to it — a signal your job needs to catch, or none at all.
- Interruption frequency for the specific GPU model and region. This varies by how contested that GPU model's capacity is, and providers don't always publish it — ask directly rather than assuming a uniform rate across GPU types.
- Checkpoint overhead. Frequent checkpointing to keep interruption cost low has its own storage and I/O cost, and factors into the real total, not just the headline hourly rate.
- What happens to storage on reclamation. Confirm whether local (attached) storage survives an interruption or is wiped along with the instance — this determines whether you need to checkpoint to durable storage separately.
- Replacement availability. If your workload needs to resume promptly after an interruption, check whether the provider makes it easy to re-request spot capacity for the same GPU model, or whether you're competing for it again from scratch.
Billing model and tax treatment don't change with spot pricing
Spot or preemptible pricing is a billing-model question, not a tax or compliance one — the same GST treatment and, where relevant, DPDP data-residency considerations that apply to on-demand capacity from a given provider apply equally to that provider's spot capacity. An India-incorporated provider offering spot pricing still issues a standard GST invoice on the amount actually billed; a foreign marketplace's spot rate is still subject to Reverse Charge Mechanism self-assessment for a GST-registered Indian buyer, the same as its on-demand rate. See our GST invoicing guide for the mechanics. What changes with spot pricing is availability and interruption risk, not who's responsible for the tax.
A practical framework
Before choosing spot over on-demand for a specific job, work through three questions in order: can this workload checkpoint or restart cheaply if interrupted; is there a real deadline or SLA that an unplanned pause would break; and does the theoretical savings still hold once you've priced in checkpoint overhead and the realistic chance of needing to re-queue. If the answer to the first question is no, the discount isn't worth evaluating further — the workload doesn't fit the product. If it is yes, spot capacity is worth pricing against on-demand for the specific job at hand, using current listings rather than a number from an old comparison, since spot availability and pricing move independently of on-demand rates.
Frequently asked questions
Is spot GPU pricing always cheaper than on-demand?
The listed rate almost always is, but "cheaper" only holds once you factor in the realistic cost of interruption for your specific workload — lost compute time, checkpoint overhead, and the time cost of requeuing. For a workload that can't tolerate interruption, the effective cost of a failed or restarted run can erase the headline discount entirely.
Does using spot capacity change GST or DPDP compliance obligations?
No. Billing model (spot vs. on-demand vs. reserved) is independent of tax treatment and data-residency obligations — both follow from the provider's incorporation and where the workload's data is actually processed, not from which pricing tier you chose. Check the provider's compliance posture the same way regardless of billing model.
How do I compare current spot rates across providers?
Use the compare tool for current listings and the cost calculator to model total cost for your expected usage pattern, including realistic assumptions about interruption frequency for your workload rather than treating the headline rate as the full cost.
This is a general framework for evaluating spot and preemptible GPU pricing, not a ranking of specific providers or a claim about current spot rates for any one listing. Spot availability and pricing move independently of on-demand rates and change frequently — check the compare tool for live, dated figures before making a purchasing decision.