IndiaAI Mission: 34,000 GPUs at Rs 150 per hour — what builders need to know before applying

What the IndiaAI Mission compute pool actually offers

The IndiaAI Mission, the Government of India's flagship sovereign-AI programme run through MeitY, has been quietly stitching together a compute fabric of roughly 34,000 GPUs across MeitY-empanelled providers and government-funded clusters. Per public coverage of the scheme, the subsidised rate for eligible applicants sits at approximately Rs 150 per GPU-hour. That figure is the part that has builders' attention. At a representative rate of roughly Rs 83 to the US dollar, Rs 150 works out to about $1.80 — broadly in the same neighbourhood as Crusoe's MI300X spot, below typical H100 on-demand pricing from most Western hyperscalers, and competitive enough to change the planning calculus for any India-incorporated team training a model bigger than a fine-tune.

Before we go further, three honest caveats. First, this is single-source territory in the sense that almost all current public detail traces back to a small handful of policy announcements and follow-up coverage. The exact composition of the pool, the per-provider tariff sheet, and the eligibility filters all change between allocation rounds. Second, "subsidised compute" is not "free compute" — the rate is heavily discounted but still billable, and allocations come with usage windows. Third, the 34,000-GPU headline figure appears to include both directly funded clusters and the GPUs that empanelled commercial providers commit to the scheme; the share immediately addressable by a given applicant is smaller. Treat every number in this piece as a planning starting point, not an SLA.

• Approximate pool size: 34,000 GPUs across the empanelled fabric, per public coverage.
• Headline rate: roughly Rs 150 per GPU-hour for eligible workloads, subsidised.
• GPU mix: H100, MI300X, and selected domestic options where available.
• Cadence: allocations are made in rolling rounds rather than a single open queue.
• Verification: every number here should be re-checked against the IndiaAI portal before a budget is signed.

Eligibility — who can apply and what the typical filters look like

The eligibility filters described in public coverage cluster into four buckets. The clearest, most consistent filter is Indian incorporation — the entity holding the allocation needs to be registered in India, with an Indian PAN, GST registration, and an Indian bank account for any settlement. The second is MeitY-recognised startup status or, for research labs, recognition under one of the supporting science-and-technology programmes. The third is workload focus: subsidised allocations have been weighted toward training, fine-tuning, and applied-research workloads rather than general inference serving. The fourth, less formally stated, is the existence of an open-source or India-public-interest commitment — many of the successful applications surface a model, dataset, or evaluation that will be released openly.

None of those filters are absolute. Each round has carried exceptions for strategic verticals — healthcare imaging, language models for Indian languages, agritech, defence-adjacent research — where the workload focus rule has been relaxed. The MeitY-startup recognition is a strong signal but not a hard prerequisite; consortia involving recognised academic partners have also won allocations. Read every published list of awardees before assuming you fall inside or outside the cohort.

The Rs 150 per hour rate in context — how it compares to spot prices

The cleanest way to evaluate the subsidised rate is to put it next to the spot and on-demand options a builder would otherwise reach for. The numbers below are rough comparisons drawn from publicly listed rates as of publication and should not be treated as live quotes — providers update tariffs frequently. The point is the order of magnitude, not the decimal places.

Provider / scheme	GPU class	Headline rate	Approx Rs equivalent	Notes
IndiaAI Mission (subsidised)	H100 / MI300X (mix)	Rs 150/hr	Rs 150/hr	Eligible India-incorporated applicants only
Crusoe spot	MI300X	~$1.71/hr	~Rs 142/hr	Per recent coverage; spot preemption applies
Lambda Cloud	H100 80GB	~$2.49/hr on-demand	~Rs 207/hr	Reserved rates lower; on-demand availability fluctuates
Modal serverless	H100	~$3.95/hr metered	~Rs 328/hr	Pay per second; great for bursty inference, dearer for sustained training
Indian commercial cloud (non-subsidised)	H100	Rs 240 to Rs 360/hr	Rs 240 to Rs 360/hr	Tata, Yotta, E2E and others — wide spread

Rates as of publication; convert at roughly Rs 83 to the dollar. Crusoe's MI300X spot is the closest direct comparator because both are AMD silicon at aggressive pricing. The IndiaAI rate matches it on cost while removing the spot-preemption risk and adding domestic data-residency. Against H100 spot from Western hyperscalers the subsidised rate is dramatically cheaper, but only for workloads that can actually run on the offered chips — see the workload-fit section below.

How to apply — typical workflow, with caveats

The application workflow has evolved between rounds, and the IndiaAI portal is the source of truth at any given moment. The shape of it is reasonably stable, even if the screens change. The typical sequence is, first, register your entity on the IndiaAI portal with PAN, GST, and MeitY-startup or research recognition certificate. Second, submit a workload proposal — a short technical document covering model size, dataset, training steps, expected GPU-hours, and the open-source or public-interest commitment. Third, an evaluation window during which the panel reviews proposals against the round's stated priorities. Fourth, an allocation decision that names the empanelled provider, the GPU class, the time window, and the per-hour rate. Fifth, onboarding with the chosen provider — SSH keys, storage buckets, network configuration.

The first three steps typically take four to eight weeks. The fifth — the actual provider onboarding — has been the step most teams underestimate. Empanelled providers vary widely in their developer experience. Some hand you a polished console; some hand you raw SLURM access on a cluster that has never been hardened for a small team. Budget at least a week of engineering time for the first run, and longer if your training stack assumes a specific kernel version or driver release.

Documents you will likely need

• Certificate of incorporation and PAN of the applicant entity.
• MeitY startup-recognition or research-organisation certificate.
• Two to four-page technical proposal: model card, dataset card, training plan, evaluation plan.
• Public-interest or open-source commitment statement.
• Estimated GPU-hour budget broken down by training phase.

What workloads work best on the subsidised pool

Not every workload is a fit. The pool's design — round-based allocations, time-windowed access, mixed silicon, and a clear preference for training-and-research workloads — naturally favours some shapes of work over others. The matrix below is a starting point for self-assessment.

Workload	Locality requirement	Spot tolerance	Subsidised-pool fit
Pre-training a foundation model (1B to 30B params)	Flexible — India works fine	Tolerates scheduled windows	Strong fit
Fine-tuning open-weights model on Indian-language data	Strong India preference for data-residency	Tolerates batch scheduling	Strong fit
Sustained inference for a production product	Flexible	Needs always-on, low jitter	Weak fit — use commercial cloud
Bursty serverless inference	Flexible	Sub-second cold start	Weak fit — Modal or similar is better
Research-grade evaluation runs (eg agent benchmarks)	Flexible	Tolerates queueing	Strong fit
Long-horizon RL training	Flexible	Needs sustained multi-day blocks	Moderate fit — depends on allocation window

The pattern is consistent: anything that looks like a scheduled, finite training or evaluation job is a good candidate; anything that looks like a production serving plane is not. For the production side, builders setting up self-hosted inference will get more mileage from the patterns described in our recent walkthrough on vLLM 0.9 with PagedAttention, Docker, and KEDA, and the break-even analysis in our DeepSeek V4 Pro self-host on 8×H100 piece is the right mental model.

The latency-locality angle — why running training in India can be a feature

One of the underrated benefits of the IndiaAI pool is geography. For a team training on Indian-language corpora, healthcare data covered by DPDP, or any dataset that carries sensitivity or residency obligations, keeping the training run on Indian soil — and on a provider operating under Indian law — is not a constraint to engineer around but an asset to claim. The argument used to be "we have to train in US-East because that's where the GPUs are; we'll move inference home later". The argument now can be "we train and serve in India because that's where the data lives, the regulator is friendly, and the GPUs are price-competitive".

For builders working on India-public-interest workloads, that locality story is part of the application narrative the IndiaAI panel actively rewards. A team that can credibly say "this model was trained on Indian compute, on Indian data, by an Indian-incorporated entity, and the weights will be released openly" is exactly the profile the scheme was designed for. We have seen that thread running through the funding signals around India's sovereign-AI stack as well — our coverage of Sarvam's Series C and the India sovereign-AI thesis tracks the broader pattern this scheme sits inside.

UK builders with India ops — when this is accessible, when it isn't

For a UK-headquartered team reading this, the immediate question is whether any of this applies. The short answer is: only via an Indian arm. A standalone UK Ltd. or PLC cannot apply to the IndiaAI Mission. What can apply is an Indian subsidiary, a joint venture with an Indian partner, or — in a research context — a collaboration agreement with an Indian academic or research institution that is itself eligible. The route most commonly used by UK teams in practice has been an Indian wholly-owned subsidiary or a co-applicant arrangement with an Indian research lab.

If you are a UK team weighing whether to spin up an Indian subsidiary purely for the compute, the maths is worth running carefully. The subsidiary carries ongoing compliance overhead — annual filings, audit, transfer-pricing documentation, GST compliance, employee provident-fund administration if you hire locally. For a one-off training run, the overhead almost certainly does not pencil out. For a sustained India-focused product play with a real reason to be in-country — Indian users, Indian data, Indian go-to-market — the compute access becomes one of several reasons the subsidiary makes sense.

Where this gets genuinely interesting for the UK side is on the comparison with European compute schemes. The EuroHPC JU allocations, the UK's own AI Research Resource (AIRR), and the IndiaAI Mission are now three roughly comparable subsidised lanes serving slightly different cohorts. For a UK team with India operations, IndiaAI is the most cost-aggressive of the three at the per-hour figure; AIRR is the right route for UK-resident workloads; EuroHPC remains the long-horizon option for very large pre-training. The pragmatic answer for many cross-border teams will be "use whichever lane your data and entity make eligible, and don't overthink it".

Application-decision tree

Question	Answer	What it tells you
Is your applicant entity India-incorporated?	No	Pause — find a co-applicant or spin up an Indian arm first.
Is your applicant entity India-incorporated?	Yes	Continue.
Is the workload training, fine-tuning, or research?	No (eg pure serving)	Use a commercial provider; the pool is the wrong tool.
Is the workload training, fine-tuning, or research?	Yes	Continue.
Can you commit to an open-source or public-interest output?	No	Application is weaker but not necessarily blocked.
Can you commit to an open-source or public-interest output?	Yes	Lead with this in the proposal.
Do you have a fallback commercial provider lined up?	No	Build one before you apply — allocations can shift.
Do you have a fallback commercial provider lined up?	Yes	Apply.

Five risks builders should weigh before committing

1. Allocation revocability. The rate is favourable in part because the allocation is conditional. If you do not draw down the hours you were granted within the window, or if the round's priorities shift, the allocation can be reshaped or reduced. Checkpoint religiously and plan around windows, not unlimited runways.
2. Provider-mix uncertainty. You apply to the scheme, but you run on a specific empanelled provider. That provider's developer experience, driver versions, storage layer, and uptime track record matter enormously. Get reference calls with current users of the provider you are assigned before you cut over.
3. Stack lock-in risk on AMD. A meaningful share of the pool is MI300X, and while ROCm has improved sharply, some training stacks still assume CUDA. Test your full pipeline — including any custom kernels or quantisation code — on MI300X before committing the bulk of the allocation. Our recent coverage of Crusoe's MI300X price war walks through the practical CUDA-to-ROCm porting story for similar workloads.
4. Data-egress and ingest economics. The Rs 150 per hour figure does not include moving terabytes of training data in and out. If your dataset lives in a US-East S3 bucket, the transfer cost and time may dwarf the compute saving. Localise data before you start.
5. Policy and political risk. The scheme is a government programme. Programme rules, priorities, and budget envelopes can change between rounds and between governments. Do not architect a multi-year product roadmap that fails if the scheme winds down or pivots.

None of those risks are deal-breakers individually. Cumulatively they are the reason the right posture is "use this lane for what it is good at, and keep your overall infrastructure portable". A team that does that gets the benefit of the subsidised rate without becoming dependent on it. A team that does not — that builds its entire training and product economics around the assumption that Rs 150 per hour is forever — is taking on more risk than the saving justifies.

So — should you apply?

If you are an India-incorporated startup or research lab running training, fine-tuning, or evaluation workloads, and you can articulate a clear public-interest or open-source angle, the answer is straightforward: yes, apply, and apply early in the round. If you are a UK team without an Indian entity, the answer is "not until you have a reason beyond the compute to be in India". And if you are a team running production inference for a paying customer base, this is not the lane for you — use it for training, keep your serving on a commercial provider, and treat the two as separate infrastructure tracks.

Primary public coverage of the scheme: abhs.in/blog/indiaai-mission-34000-gpus-cheap-compute-developers-2026. Verify the live tariff, eligibility, and current allocation cadence with the IndiaAI portal directly before applying.