IndiaAI’s compute portal makes the application, not the GPU count, the starting point

Launch figures, dated policy and the public application route describe different stages of shared AI-compute access.

India’s public AI-compute programme has moved from a launch announcement to a published application route. For a small research team, the useful development is access to a broader infrastructure market without first owning a cluster. The harder question is whether its particular project is eligible, approved and ready to use the requested service. A national accelerator count cannot answer that question.

The sources reviewed on 16 October 2026 describe different moments in this transition. A government launch release establishes the portal’s introduction; a later government briefing describes expanded capacity; the public portal explains onboarding; and a dated policy spells out conditions that a short FAQ compresses. Read together, they offer a more practical account than a single headline about inexpensive GPUs.

What the launch actually established

The [MeitY release of 6 March 2025](https://www.pib.gov.in/PressReleasePage.aspx?PRID=2108961) announced the IndiaAI Compute Portal and AIKosha together. It described access to compute, networking, storage, platforms and cloud services through empanelled suppliers. Its initial access figure was 10,000 GPUs, with another 8,693 to be added. Those are the release’s staged quantities, not a count of machines available to a new applicant today.

The same release presented AIKosha as a repository of datasets, models and use cases with development tools and permission controls. That pairing matters: renting an accelerator is only one part of building an application. A team also needs usable inputs, permission to use them and a way to evaluate the resulting model. The launch does not establish that every listed dataset is suitable or licensed for every commercial purpose.

A [PIB briefing dated 4 February 2026](https://static.pib.gov.in/WriteReadData/specificdocs/documents/2026/feb/doc202625780001.pdf) subsequently described access to over 38,000 GPUs and 1,050 TPUs through the portal. These are government-reported programme figures at that date. They are neither a current spare-capacity inventory nor a published allocation to this article’s reader. Different accelerator families should not be treated as interchangeable units of application performance.

This distinction changes how infrastructure should be assessed. Programme capacity can indicate the breadth of a public initiative; an approved request determines what a team may use; a successful workload establishes whether that resource meets its needs. Moving between these stages requires additional evidence. None is supplied by multiplying a hardware count by a vendor’s advertised peak speed.

The public application route is conditional

The [portal’s public page](https://compute.indiaai.gov.in/login), reviewed without signing in, describes registration, eligibility verification and a compute request supported by a project proposal and estimated bill of materials. It names categories including researchers, students, startups, MSMEs and government entities. These are categories with supporting requirements, rather than an invitation for every visitor to start an unrestricted session.

The February 2025 [End-User Policy for AI Services on the Cloud](https://compute.indiaai.gov.in/files/end-user-policy.pdf), particularly sections 3–5, is more detailed. Its allocation workflow considers GPU hours, the number of GPUs and whether subsidy is requested. The lower-volume route refers to no more than 5,000 GPU hours, a maximum of 50 GPUs and no subsidy request, with category-specific verification or endorsement. Allocation remains subject to availability.

The current public FAQ simplifies the distinction around 5,000 GPU hours. The dated policy includes additional conditions. Applicants should therefore obtain the applicable policy version and confirmation for their category before treating the shorter explanation as a guaranteed approval rule. This is a documentation distinction, not evidence that an application has failed or that the service is unavailable.

There is also a difference between permission to consume compute and permission to use data. A research endorsement does not grant rights over patient records, copyrighted collections or a partner’s confidential documents. The project description should identify its inputs and intended outputs early, so that an infrastructure request does not become an accidental commitment to upload material the team cannot use.

Ask for a workload, not a hardware trophy

An infrastructure request becomes easier to assess when the team can explain the experiment it wants to finish. Does it need to train a model, adapt one, run an evaluation or process a batch of documents? These tasks have different memory, storage and interruption needs. An oversized request can obscure an unresolved design question; an undersized one can leave a valid experiment unable to complete.

The useful planning unit is a reproducible run: permitted input version, software dependencies, resource estimate, expected output and stopping condition. A small preparation run can reveal whether time is spent reading data, preparing it or calculating model updates. This proposed planning method is not a measurement of IndiaAI suppliers, and it does not assume that all accelerator types support identical software.

Storage and transfer also belong in the request. An experiment may need its input collection staged before compute begins and its checkpoints retained after a session ends. Ask which service owns those files, how long they remain accessible and what happens when an approval expires. Avoid presenting a discounted compute rate as the entire cost of operating an application; no price comparison is made here.

Fictional, unrun example: sorting a college’s public document scans

Imagine a college in Coimbatore testing document recognition on fictional, non-personal notices. This is an invented learning exercise, not a reported IndiaAI beneficiary. Its aim is to identify headings, dates and tables in scans so that a librarian can check an accessible text version. The system will not decide admissions or alter official records.

The team first creates synthetic notices with known answers, including blurred dates, rotated pages and similar course names. It separates preparation material from an untouched evaluation set. A useful outcome would be a traceable error report: which field was missed, what evidence was visible and whether the system admitted uncertainty. No accuracy figure or successful run is asserted.

Its compute proposal can then explain why a smaller trial is necessary, what input rights it holds and which result would justify further work. A librarian checks the extracted content before release. If the model confuses a deadline, the exercise records the mistake rather than quietly correcting the answer and counting it as a success.

The final output should remain understandable outside the chosen cloud: synthetic input files, permitted software references, configuration notes and a reviewed error catalogue. Portability here means keeping the experiment intelligible and repeatable, not promising that moving it to another accelerator will require no engineering. This distinction also gives students a useful portfolio of decisions rather than a screenshot of a rented machine.

The next evidence is an allocation and an evaluated result

IndiaAI’s portal is a concrete access mechanism, while government capacity briefings describe its wider ambition and growth. The evidence reviewed does not establish current queue times, approval success rates, supplier uptime or outcomes for a particular applicant. Those questions need dated service records and actual project results. For a prospective user, the productive next step is a well-scoped, eligible proposal with lawful inputs and a testable purpose—not an assumption that a national inventory is already its own computing allocation.