IndiaAI Mission's 34,000 subsidised GPUs: a builder's guide to using them well

What you need to know

• The headline rate is roughly ₹115–150 per GPU-hour for subsidised access — about 42% below the prevailing market. Published figures vary within that band, so treat it as a range, not a fixed sticker price.
• The pool is large and growing. 34,000 GPUs are live today, with a government commitment to scale to 100,000 GPUs by the end of 2026.
• It is a national-strategy programme. The IndiaAI Mission is a ₹10,371.92 crore (about $1.25 billion) effort to build sovereign AI infrastructure, and Sarvam AI was the first startup selected to build India's sovereign LLM under it.
• It is not free money. Eligibility approval, allocation queues and data-locality expectations mean the real cost lever only works for workloads you can plan around.

For Indian builders this is the most direct compute-cost reduction available right now. For UK builders it is a useful mirror: a different model for the same problem of getting affordable, sovereign GPU capacity into the hands of people actually shipping. We will cover both, and the practical question that matters most — when does subsidised compute genuinely beat reaching for AWS, Azure or a specialised AI cloud, and when does it quietly cost you more in time than it saves in rupees.

The real per-GPU-hour economics

Start with the number that decides everything. The whole appeal of the IndiaAI pool is the per-GPU-hour rate, so it is worth putting it side by side with what you would otherwise pay on the open market. The table below converts the subsidised band at roughly ₹83 to the dollar and lines it up against typical global cloud H100 pricing. Treat the dollar conversions as approximate — exchange rates and on-demand rates both move.

Option	Rate (per GPU-hour)	Approx. USD	Notes
IndiaAI Mission (subsidised)	₹115–150	~$1.40–1.80	~42% below market; eligibility + queue apply
Specialised AI cloud (H100 SXM, on-demand)	—	from ~$2.00	Fast to provision; no eligibility gate
Hyperscaler (AWS / Azure / GCP, H100 on-demand)	—	typically higher	Elastic, managed, multi-region; premium price

The gap is real but not enormous against a lean specialised cloud — roughly $1.40–1.80 versus $2.00 is a 10–30% saving, not a 3× one. Against a hyperscaler's on-demand H100 rate the saving widens considerably. So the honest framing is this: subsidised compute is a meaningful discount, largest when your alternative is a hyperscaler, and the discount only fully materialises if the workload fits the programme's planning model rather than fighting it.

Put the saving in terms of a concrete run. A modest fine-tuning job that consumes 5,000 GPU-hours costs roughly ₹575,000–750,000 on the subsidised pool. The same 5,000 hours at a $2.00 specialised-cloud rate is about ₹830,000, and materially more on a hyperscaler's on-demand pricing. On a single run the delta is a few lakh; across a research programme that burns hundreds of thousands of GPU-hours a year, it compounds into the kind of money that decides whether a second experiment gets funded. That is the case for taking the application paperwork seriously rather than defaulting to whatever cloud your team already knows.

Eligibility and how access actually works

The subsidy is delivered through empanelled compute providers rather than as a cash grant, so "applying" means requesting an allocation against the subsidised pool through the mission's portal. In practice you should expect to supply three things: proof of an eligible entity (an Indian-registered startup, a recognised research or academic institution, or an approved public-sector project), a workload description that explains what you are training or serving, and an honest GPU-hour estimate.

Allocation is granted in tranches and is not instantaneous. That single fact reshapes how you should plan. If your roadmap assumes you can spin up 64 GPUs this afternoon for an unplanned experiment, the subsidised pool is the wrong tool. If you can say "we need a 200,000 GPU-hour training run starting in three weeks," it is close to ideal — you queue, you get approved capacity, and you pay the subsidised rate for a job you were always going to run.

When subsidised compute beats a hyperscaler

The decision is not ideological; it is about workload shape. Map your job onto these patterns before you choose.

• Planned training and fine-tuning runs — large, batch-style jobs with a known start window are the sweet spot. You can absorb a queue, you keep data in-country, and you pay the lowest rate for compute you were committed to anyway.
• Research and academic workloads — long experiments where cost-per-hour dominates and latency-to-provision does not. The subsidy compounds over thousands of hours.
• Cost-sensitive Indian-market inference — if your users are in India, serving from sovereign infrastructure removes a cross-border hop and keeps both latency and data residency clean.

And the cases where a hyperscaler or specialised cloud still wins:

• Bursty, unpredictable demand — if you cannot forecast load, elastic on-demand capacity is worth the premium. A queue you cannot skip is a product outage waiting to happen.
• Global low-latency inference — serving users across the UK, EU and US needs multi-region presence that a single sovereign pool will not give you.
• Deep managed-service coupling — if your pipeline leans on a hyperscaler's managed training, vector or orchestration services, the migration cost can erase the per-hour saving.

The UK comparison: a different route to the same goal

UK builders reading this do not have a direct per-GPU-hour subsidy in the same shape, but they are not without options — and the contrast is instructive. The UK's approach has centred on capacity-building and siting rather than discounting an hourly rate. AI Growth Zones streamline planning permission, power connections and infrastructure for new data-centre and compute clusters, while the publicly funded AI Research Resource provides national supercomputing capacity aimed largely at research.

The philosophical difference matters for how you act. India's model puts a discounted price tag on an hour of an existing GPU and routes it through empanelled providers — a demand-side subsidy a builder can apply for directly. The UK model lowers the cost and friction of building and siting compute — a supply-side intervention whose benefits reach builders indirectly, through cheaper capacity and access schemes rather than a published per-hour rate.

What should a UK team actually do with that? Treat sovereign-compute access as a procurement exercise, not a console you log into. Apply early to whatever access programme fits — the AI Research Resource for research-grade workloads, or commercial capacity in an AI Growth Zone as those clusters come online. Model the queue the same way an Indian team models the IndiaAI allocation tranche. And keep a hyperscaler fallback wired up for the bursty inference that any subsidised or capacity-constrained pool will struggle to serve. The lesson travels in both directions: the Indian builder learns to treat cheap compute as planned capacity, and the UK builder learns to treat planned capacity as a cost lever worth chasing.

A practical decision checklist

Before you commit a workload to subsidised infrastructure, run it through these questions.

1. Can the job tolerate a queue? If a delay of days is acceptable, subsidised compute is in play. If not, stay elastic.
2. Where does the data need to live? Sovereign infrastructure is an advantage for DPDP-governed data and a constraint if you need free movement to overseas clouds.
3. What is your real alternative rate? Benchmark against your blended effective cost, not a list price, so the saving is honest.
4. Where are your users? India-centric inference favours sovereign serving; global users favour multi-region hyperscalers.
5. How locked-in will you be? Check egress, checkpoint portability and allocation terms before the first byte lands.

Get four or five "yes" answers in favour and the subsidised pool is likely the cheaper, cleaner choice. Get mostly "no" answers and you will spend more engineering time fighting the model than you save on the invoice.

Programme details and the official scope of the IndiaAI Mission are published at indiaai.gov.in. Always confirm current rates and eligibility through the empanelled-provider portal before budgeting a run, since both the rate band and the available pool are moving figures.