All insights

Compute & Cost

Reserved vs On-Demand for Government Workloads

· 9 minute read

On-demand is a price. Reservation is a date. If the workload has a gazette, buy the date. If it is a genuine experiment, rent the hour.

Cloud sales language treats on-demand as sophistication and reservation as an old habit. Government calendars disagree. Board exams, budget sessions, scholarship windows, disaster declarations and court-ordered deadlines do not flex because a GPU pool is busy. If your workload has a date that a minister can be asked about, on-demand is a bet, not a strategy.

This comparison is about capacity assurance, not about a frozen rupee. Reserved hours on IndiaAI or a commercial cloud, reserved racks in a colocation, and owned on-prem cards are three ways to buy a date. On-demand hours are a way to buy a maybe. Maybes are fine for evals, fine-tunes and curiosity. They are not fine for a gazetted service.

Pull live reservation terms from the portal or the MSA. We will not invent a discount percentage and call it IndiaAI policy. Public notes have described reserved SKUs and demand SKUs side by side on mission price lists; the spread moves. The method does not.

What you are actually buying

On-demand: a right to request a VM from a pool. You buy a price and a queue. The queue is the product feature nobody puts on the slide.

Reserved: a right to a capacity window — a month, a quarter, a named week — sometimes at a different unit price, always with a written expectation that the SKU will be there. Read the pre-emption clause. A reservation that can be withdrawn for a higher-priority mission user is a soft reservation. Write the word soft in the file if that is what you have.

Owned: a card in a cage you control. You buy the date absolutely, and you buy idle, power, AMC and the refresh question. Owned is the reservation that does not depend on a portal login remaining valid.

Pick the instrument from the calendar, then look at the rupee.
WorkloadDefault instrumentOn-demand is acceptable ifOwned is justified if
Gazetted citizen window (exams, schemes)Reserve or ownYou have a tested fallback that does not need the GPUAir-gap or a window that repeats every year
Standing inference, low concurrencyOwn a small card, or a cheap reservationOutage is an inconvenience, not a rights failureData cannot leave, or the meter would run all year
Annual training / eval weekReserve a burstThe week can slipYou already own idle cards and the extra would sleep 50 weeks
Curiosity, hackathon, thesisOn-demandAlmost alwaysAlmost never

Money, without a fake spread

Reserved cloud hours are often cheaper per hour than on-demand on commercial price lists, and sometimes structured differently on mission portals. That spread is a reason to ask, not a reason to type 30 percent into a DPR. On-demand is often cheaper in total if you would have reserved a month and used four days.

Do the two multiplications. (Reserved unit × reserved hours) versus (on-demand unit × expected hours × a slip factor). The slip factor is how you admit that a missed reservation is not free — it is a delayed scheme or a weekend of officers. If you cannot name the slip cost, you will always under-buy reservation.

Owned cards flip the arithmetic again. Their reservation cost is capex plus power plus idle. They win when the date repeats and the data is heavy. They lose when the date is once and the card would then heat a room.

Failure modes that are specific to our files

Eligibility clocks. A reservation on IndiaAI that depends on an annual approval can expire in the week you need it. Put the renewal on a calendar older than the exam. Shared mission priority. A national facility can be asked to prefer a foundation-model project over your district eval. Read whether your reservation is pre-emptible.

Payment and GeM timing. On-demand spend that overruns a sanction is not a cloud feature. It is an irregularity. Caps, alerts, and a hard stop belong in the architecture. Air-gap fantasy. You cannot reserve your way into an air-gap. If the file needs a gap, reservation is the wrong instrument.

Caps are architecture

An on-demand account without a rupee cap and a hard stop is not agile. It is an open sanction. Put the cap in the cloud IAM, not only in a Word file. Alert at 60 percent and 85 percent to the officer who owns the head, not only to the SI.

If the vendor cannot implement a stop, you do not have on-demand. You have a hose. Prefer a reserved block you understand to a hose you will explain to the PAC.

Objections you will hear — and what to do with them

These are the lines that stall the file. Answer them in the room, then put the answer in the note. A spoken answer without paper will be forgotten by the next officer.

On-demand is more agile, which government needs

Agility is the ability to serve the gazette. A queue is not agility. It is a vendor-owned calendar.

We own cards, so this article is irrelevant

Owned is a reservation. You still need a policy for the one week a year you need more. That week is this article.

The portal does not offer reservations for our class

Then write that constraint and choose owned or a commercial reserve, or change the workload's dependence on a date. Do not pretend on-demand is a reserve.

Finance will not pay for unused reserved hours

Show them the slip cost of a missed gazette. If they still prefer on-demand, write the risk in the note they initial.

A calendar-first choice

  1. Week 1: list the next twelve months of dates a minister could be asked about. Mark which need this GPU.
  2. Week 2: for each date, choose own / reserve / on-demand / fallback-without-GPU. Price the three multiplications. Read pre-emption and eligibility clocks.
  3. Week 3: put caps on any on-demand account. Put renewals on a circular calendar. Rehearse the fallback once.

How this shows up in the file

Subject: Capacity assurance for [workflow] through [period].

Dates that cannot slip: [list]. Instrument: [own / reserve / on-demand]. Pre-emption and eligibility notes: [portal / MSA references]. Unused-reservation risk accepted because [reason] / rejected in favour of [alternative]. On-demand accounts have a hard monthly cap of [amount].

This note is not a portal term sheet and not legal advice. A gazette is not an on-demand event.

This article is informational field guidance for Indian public institutions, not legal, procurement, tax, accounting, tariff or engineering advice. Confirm against the current Gazette, GFR, GeM term, SERC tariff order, IndiaAI portal rule, CAG mandate, DPDP text, departmental finance manual and your counsel before you file it. Figures are methods and order-of-magnitude illustrations, not a dataset of real deployments and not a substitute for a live quote.

How to put this in the finance note

A P1 CIO/CTO searching “reserved capacity AI government” needs a number a CFO can defend, not a GPU brand. “Reserved vs On-Demand for Government Workloads” belongs in a cost model with people, power, idle time, AMC and the cost of a failed pilot.

On-demand is a price. Reservation is a date. If the workload has a gazette, buy the date. If it is a genuine experiment, rent the hour. IndiaAI subsidy, if you use it, is a live notice — not a permanent discount. On-prem TCO includes ops headcount. Do not invent Rs/hour. Cite the source of every rupee.

  • Separate capex, opex, and one-time cleanup.
  • Show utilisation, not just peak GPUs.
  • Price the human fallback, not only inference.
  • Date every tariff and subsidy assumption.

Close this loop before the next CAB

Put “Reserved vs On-Demand for Government Workloads” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P1 CIO/CTO, not “the vendor.”

Revisit the item when the model, the GeM term, the region, or the SI changes. “reserved capacity AI government” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.

What must be true before you file this

If “Reserved vs On-Demand for Government Workloads” is only a heading, it will not survive a file inspection. A P1 CIO/CTO should be able to attach one artefact that proves “reserved capacity AI government”: a log export, a clause, a scored row, a dated notice, or a refusal rule.

Write three dated sentences: what was decided, who owns it, and when it will be re-checked. Unsigned sentences are souvenirs. Dated sentences are controls.

  • Name the owner of “reserved capacity AI government” inside the institution.
  • Attach one artefact a stranger can open next year.
  • Revisit when the model, the notice, or the SI changes.
  • Do not treat a vendor slide as evidence.

Questions this usually raises

Is reserved always cheaper?
Per hour, often. In total, only if you use the window. A reserved year for a one-month job is expensive assurance.
Does IndiaAI offer reservations?
Mission price lists and allocation tables have shown reserved and demand-style SKUs. Terms, eligibility and pre-emption sit on the live portal and in your approval. Read those, not this sentence, as the rule.
Is on-prem just a reservation?
It is a reservation you operate. That is the point and the cost. Put that in the file next to “reserved capacity AI government” so a stranger can reconstruct it. A one-line yes/no under “Reserved vs On-Demand for Government Workloads” is not an answer a secretary can defend. Confirm against the live Gazette, circular or GeM term; this is not legal advice.
What about spot or pre-emptible GPUs?
Fine for a thesis. Not fine for a rights-affecting window unless a fallback is tested.
What will Prcept recommend?
Own the standing inference that cannot leave. Reserve the dated burst. On-demand the experiment. Mix them on purpose, not by accident.
Can we invent a discount percentage for the DPR?
No. Pull live reservation terms. Do not type 30 percent into a DPR because a blog liked the shape.

Sources