India’s AI compute gap is now a measurement problem

Executive summary: growth is visible; access is not yet measurable

India’s public AI-compute programme has moved well beyond its original announcement. The March 2024 Cabinet decision approved the IndiaAI Mission with a five-year outlay of ₹10,371.92 crore and a common compute infrastructure target of more than 10,000 GPUs. By 2025 and 2026, official releases described a larger facility, a provider network and subsidised access; the August 2026 factsheet says shared capacity exceeded 45,000 GPUs as of June. [10] [19] [11] [5]

That sequence is evidence of policy activity, not a clean measure of working capacity. PIB reported 38,231 GPUs onboarded from 14 providers in March 2026; a 29 July release again said “nearly 38,000” were onboarded. The August factsheet says shared capacity exceeded 45,000 GPUs as of June. ETtech then reported access to about 30,000 against a 45,000 commitment. These are distinct, attributed stages; no public source connects them in one inventory. [3] [4] [5] [6]

The same factsheet reports 237 projects and 93.18 lakh GPU-hours by August 2026, using “accessed” and “covering” language. It does not explain whether the hours are approved, reserved, provisioned, started, metered or completed. The portal gives applicants a route to compute, but the published allocation rows do not say whether users started their projects or whether a reservation remains active. The result is a gap between a visible supply headline and the practical question users need answered: what can they run now? [5] [1] [8] [9]

A separate physical layer is also growing. Government and market estimates place India’s operational data-centre stock around 1.5–1.6 GW in 2025–26. Knight Frank’s June 2026 reporting distinguishes live capacity from projects under construction, committed and at an early stage. These figures describe facilities serving cloud, enterprise, colocation and other workloads; they cannot be added to IndiaAI’s GPU counts or treated as AI-only capacity. [12] [13] [14] [20]

The evidence supports a careful conclusion: India has expanded its public compute programme, and official headline counts exceed the original target. But target, empanelment, onboarding, project allocation, reported installation, shared capacity, access, live schedulability, active reservation and metered use remain different states. No reviewed source supplies a crosswalk or a current free-GPU count, and the reported GPU-hours cannot be called consumed. [10] [1] [2] [4] [5] [14]

What a GPU count can mean

“Capacity” is not a single operational state. A target is a policy commitment; “empanelled,” “onboarded” and “shared” are programme labels whose exact relationships are not publicly defined. “Installed” appears in a June 2025 secondary report, not in a current provider-level public inventory. The IndiaAI hub’s dated allocation rows record project-level assignments with GPU type, provider and project dates, but do not say whether hardware was installed or the project started. Those rows are not an aggregate of active reservations. A schedulable GPU is one a user can book for a defined interval; metered use is a separate runtime measure. The reviewed sources do not publish current counts for schedulable GPUs or active reservations, or define the reported GPU-hours as metered use. [10] [11] [3] [4] [5] [1] [2]

A targeted search of the IndiaAI Compute Portal and PIB material found an official provider/category PDF. Its file metadata records creation on 2 September 2026, but the document prints no publication or as-of date. Fourteen bidder or consortium rows sum to 45,081 in the PDF’s total line; NVIDIA and AMD columns add to 38,085, while Intel Gaudi, AWS Trainium/Inferentia and Google Trillium categories add to 6,996. The PDF does not define whether these are offered, empanelled, installed or serviceable units, or explain the aggregate denominator. It therefore cannot reconcile the 34,333 empanelled-plus-additional figure, 38,231 or “nearly 38,000” onboarded figures, 45,000+ shared capacity, or ETtech’s roughly 30,000 access report. [7] [11] [3] [4] [5] [6]

The last distinction matters because several things can be true at once. A pool can include different providers and hardware states, while some commitments are delayed and some installed devices are allocated to projects. ETtech’s report of about 30,000 GPUs accessible against a 45,000 commitment is not automatically a contradiction of the factsheet’s 45,000-plus “shared” figure: dates and stage definitions differ, but the public evidence does not establish how. The July PIB statement that nearly 38,000 were onboarded reinforces that official reporting still uses a separate label; it does not bridge the gap. [6] [5] [3] [4]

A count also hides the mix. “GPU” can refer to accelerators with very different memory, interconnect, software support and suitability for training or inference. A raw total therefore says little about how many multi-GPU jobs a cluster can run, how much memory is available per device, whether a job can span providers, or whether the required software stack is supported. The IndiaAI allocation page lists GPU types and providers for project rows, but not a complete, dated series of free or schedulable devices by model and region. [1] [8] [9] [3]

The cleanest reading is to preserve the words each source used. A target is not a purchase; empanelment is not installation; onboarding is not proof of live availability; allocation is not proof that a user started; shared capacity is not the same as free capacity; and reported GPU-hours are not metered consumption unless the source defines them that way. [10] [1] [5] [6]

From mission target to a larger, still-unreconciled pool

The Cabinet’s March 2024 approval set the policy baseline: a five-year mission, a stated outlay and a plan to build common compute infrastructure above 10,000 GPUs. This is the right source for what government authorised. It is not a delivery audit, and the target should not be used as the current number of devices. The January 2025 release described roughly 10,000 GPUs in the initial facility and said another 8,693 would be added, a formulation that signalled expansion but left the status of that additional tranche open. [10] [19] [11]

By 30 May 2025, PIB said common compute capacity had crossed 34,000 GPUs and specified 34,333 as the total, made up of 18,417 empanelled GPUs and 15,916 additional GPUs. That is a substantially larger figure than the original target. But the release does not say that all 34,333 were installed in IndiaAI facilities, simultaneously usable, or generating jobs at the time. Its own use of separate “empanelled” and “additional” terms is reason to preserve the components rather than flatten them into “live GPUs.” [11] [19] [8]

The only specific installed count located in this review is older and secondary. On 24 June 2025, ET reported a little over 17,300 GPUs successfully installed, attributing the figure to a presentation at a 16 June review with empanelled cloud providers. The article also described provider installation and integration work still in progress. This is an early rollout snapshot, not an official status inventory and not a count that can be subtracted from later totals. [2] [11]

On 25 March 2026, a PIB release reported 38,231 GPUs onboarded from 14 empanelled service providers. On 29 July, another PIB release said “nearly 38,000” had been onboarded, without a new exact count or provider breakdown. The later statement preserves the same stage label, but neither release defines “onboarded” as installed, connected, active, or free to schedule. [3] [4]

The August 2026 factsheet reports 45,000-plus shared GPUs as of June. It does not provide a definition table connecting “shared” with “onboarded,” and it does not reconcile its June figure with the July release’s rounded onboarding statement. Read these as separately attributed snapshots, not as a cumulative series or a verified operational inventory. [5] [3] [4]

ETtech’s 1 October report says the mission had access to about 30,000 GPUs against a 45,000 commitment and describes delays affecting providers. This is secondary reporting. The reviewed public sources do not provide evidence that explains the difference among “access,” “shared,” “onboarded,” and “installed”; no reason should be inferred from the headline figures alone. [6] [5] [4] [2]

Portal access is a process, not a public utilisation metric

The IndiaAI Compute Portal makes the access pathway more concrete than a mission announcement. Its eligibility page describes the types of users who may apply, and the portal explains application, review and provider allocation. A separate IndiaAI hub page publishes dated project-allocation rows with GPU count and type, provider, project duration and the date by which an applicant must start. Those fields document project-level allocations; the page does not say whether the listed GPUs were installed or the user began running jobs. [9] [8] [1]

The allocation page is not a full hardware inventory. Its dated rows do not give a current provider-level total, completed-installation status, the number of active reservations, or the number of devices free for new jobs. The other reviewed pages likewise do not provide a time series for application volume, approvals, rejections, time to first allocation, wait time by accelerator, reservation cancellation, completed job count or provider reliability. A portal can be open and an aggregate pool can be large while access remains uneven across model family, job duration or applicant type. [1] [8] [9] [5]

The 237-project figure is a useful denominator only if the publication also explains what counts as a project and where it sits in its lifecycle. A selected or approved project may not have started a job. A job may be short, paused, failed or completed. A project can use several accelerators and run many workloads. Without these definitions, the project count cannot be converted into an average allocation, an active-user count or an estimate of unmet demand. The factsheet gives a scale signal; the portal does not supply the underlying event data needed to interpret it. [5] [8] [9]

The same caution applies to 93.18 lakh GPU-hours. The PIB wording says projects had accessed subsidised AI computing and that the activity covered that many hours. It does not state whether the number is approved hours, provisioned time, metered runtime or completed work. The distinction is consequential: reserved time can go unused, metered time can include failed jobs, and a completed training run does not reveal whether the work was reproducible or useful. Until the programme publishes a definition and a data dictionary, “GPU-hours accessed” should remain the quoted label. [5] [8] [3]

A minimally useful public dashboard would join demand and supply without disclosing applicant-sensitive information. It could report request counts, median and 90th-percentile time to allocation, rejection reasons, queue length, available hours by accelerator family, scheduled and metered hours, failure rates and uptime. The portal already supplies an institutional access route; the gap is a public operational record that would let users, auditors and policymakers tell whether that route reliably leads to compute. [8] [9] [5]

The physical data-centre estate is not the IndiaAI GPU pool

India’s data-centre build-out is large enough to be mistaken for the public compute programme if the units are not kept separate. PIB reported capacity rising from about 375 MW in 2020 to around 1,500 MW by 2025. CBRE estimated approximately 1,530 MW of operational stock for January through September 2025, while later market reporting put live capacity near 1.6 GW in 2026. These are facility-capacity measures, not counts of accelerators or an estimate of AI-only infrastructure. [12] [13] [14] [20]

The estimates broadly agree on the order of magnitude while reflecting different dates and market methods. PIB’s 1.5 GW statement is a government snapshot published in March 2026 about capacity by 2025. CBRE’s 1.53 GW figure covers the first nine months of 2025. Knight Frank reporting in June 2026 describes 1.6 GW as current live capacity, and JLL’s mid-year report also discusses a market close to that level. These are useful cross-checks, but not a single audited series with identical definitions. [12] [13] [14] [20]

The pipeline figures deserve even more care. Knight Frank’s June article gives an 8.33 GW headline for the development pipeline, then lists 0.32 GW under construction, 2.92 GW at the committed stage and 5.41 GW in early development. Those components sum to 8.65 GW, not 8.33 GW. The discrepancy is in the published account; this report does not silently adjust the headline or invent a reconciliation. Whatever the cause—rounding, scope or a source error—the listed stages should be presented individually and not used to imply that all pipeline capacity will be completed. [14] [21] [20]

A project under construction is not yet a live facility; a committed project is not necessarily financed, permitted, connected or under construction; an early-stage development is further from delivery. Knight Frank’s reporting makes these distinctions explicit. Market projections from JLL and CBRE similarly depend on delivery schedules, customer commitments and new build plans. They describe a potential expansion path, not current capacity available to IndiaAI users. [14] [21] [20] [13]

The official record uses 13.56 GW inconsistently. The 13 March 2026 PIB release labels it estimated data-centre electricity demand by 2031–32; the 30 March Rajya Sabha answer describes the same figure as projected data-centre capacity. Neither description is a measure of GPU supply or current site-level power availability. The reports do not reconcile the definitions, so this figure should not be compared with present operational capacity as if the scopes matched. The public record also does not say how much of the wider facility base is equipped for high-density accelerator jobs or connected to the IndiaAI framework. [12] [15] [14]

Location is another layer the national totals conceal. Knight Frank’s reporting describes Mumbai as the largest pipeline market and identifies Hyderabad, Chennai, NCR, Pune and Bengaluru among the expanding hubs. A national gigawatt figure cannot show whether a particular user can reach a low-latency facility, whether the site has network capacity for a distributed job, or whether the provider can reserve capacity in the needed region. Those questions need site-level and service-level data rather than another national headline. [14] [20] [13]

Power and water constraints are local, even when adequacy is national

A parliamentary answer says India’s national electricity supply is adequate and cites 524 GW of installed generation as of February 2026. That statement is relevant to national planning, but it does not prove that a particular data-centre site can obtain a timely connection, firm capacity at the required voltage, backup arrangements or a predictable power price. Those are local engineering and regulatory questions that aggregate installed generation cannot resolve. [15] [12] [17]

Data-centre demand is also geographically concentrated. Industry sources identify a small set of established hubs and a growing set of planned markets; this concentration means grid readiness, land, permitting, fibre and cooling can differ sharply between sites. IEEFA’s analysis warns that future data-centre growth will raise power-system planning questions, while CEEW argues for siting decisions that account for local resource and infrastructure readiness. These are risk analyses, not proof that every proposed site is constrained today. [17] [16] [14] [20]

Water is a parallel example of why a national assurance and a local measurement are not interchangeable. In its response, the government said data-centre water needs depend on cooling technology, described groundwater rules and pointed to direct-to-chip liquid cooling, adiabatic cooling and immersion cooling. The same response said no concerns had been received. That statement records what had been reported to the ministry; it does not establish total use, water stress by basin, or the share of sites using each cooling design. [22] [12] [16]

CEEW cites an estimate that cooling a 100 MW hyperscale facility can require roughly two million litres of water per day. That is a facility-scale estimate, not a measured national total, and actual use depends on climate, cooling design, water source and operating profile. IEEFA and CEEW both frame resource exposure as a planning issue, while the parliamentary record and PIB statements do not offer a site-by-site public inventory. The proper conclusion is not that India’s data centres have a known water crisis, nor that water is no issue; the footprint is not yet sufficiently measured in the reviewed public evidence. [16] [17] [22] [15]

For AI compute, power quality and thermal design affect more than sustainability. They influence how densely accelerators can be packed, how long workloads can run, what redundancy is affordable, and whether a provider can offer predictable availability. None of the reviewed sources joins a public IndiaAI GPU inventory to the electricity and cooling profile of the specific sites hosting those GPUs. This missing connection prevents a reader from attributing the data-centre sector’s growth directly to IndiaAI capacity. [8] [3] [12] [16]

The distinction between installed generation, grid connection and dependable site service should shape every public infrastructure claim. The government’s national adequacy statement and the market’s construction forecasts are both useful, but neither is an uptime record for a specific AI cluster. A credible access dashboard should therefore identify facility regions at an appropriate level, report interruptions and scheduled maintenance, and disclose water and power measurement methods without publishing sensitive operational details. [15] [17] [8]

Models, datasets and prototypes are outputs—not yet outcome evidence

IndiaAI’s compute framework sits inside a broader set of public capability programmes. The August 2026 factsheet reports 20 indigenous foundation-model proposals selected from 506 applications, including 12 large multimodal and eight small-language-model proposals. A March PIB release separately lists 12 organisations and consortia receiving support to develop foundational models. The two statements describe selection and support at different levels; neither is a comparative independent evaluation of the models produced. [5] [18] [8]

The same factsheet says AI Kosh hosted more than 14,000 datasets and 331 AI models as of July 2026. It reports 62 prototypes and 20 public-sector AI solutions as of August. These are useful counts of catalogue and programme activity, but a dataset count says little about provenance, licensing, documentation, language coverage or fitness for a particular task. A deployment count does not say whether a solution is still in use, saves time, improves accuracy or reaches its intended users. [5] [18] [9]

The records reviewed do not provide independent benchmark results for the selected models, adoption data for AI Kosh assets, or outcome evaluations for the public-sector solutions. Government releases describe aims and outputs; they are authoritative for what the programme says it selected or built, but they are not substitutes for third-party evaluation. Stronger evidence would connect compute projects to reproducible artifacts, model cards, evaluation sets, deployment records and measured changes in the service delivered. [18] [5] [8]

That distinction is not a reason to discount the infrastructure. Shared access, open datasets and domestic model work can lower barriers that would otherwise concentrate experimentation in a few large firms. It is a reason to judge the programme against outcomes that can be checked: who gained access, which work ran, what artifact resulted, whether results were reproduced, and whether a user or institution benefited. The current public reports show the scale of programme activity more clearly than its distribution or impact. [10] [5] [18]

The central finding: measure conversion, not just accumulation

The public record is strongest at the beginning of the infrastructure chain: authorised funds, stated targets, provider participation and headline capacity. It becomes less detailed at the moment a user attempts to convert a project into a scheduled job, and thinner still at the point where compute becomes a verified result. This pattern is visible across the mission releases, the portal, the GPU-hour figure and the separate model and data programme claims. [10] [3] [5] [8]

A useful maturity ladder would report nine measures separately: mission target; empanelled or committed supply; onboarded GPUs; delivered and installed hardware; live and schedulable devices; project allocations; active reservations; metered GPU-hours; and completed work with a reproducible output. Public material supplies partial snapshots for some early stages, a dated project-allocation register and an older secondary installation estimate. It does not publish a current status crosswalk, an active-reservation total, or a definition that makes the reported GPU-hours metered use. [10] [11] [3] [4] [1] [2] [5]

This distinction also prevents a common category error: adding data-centre megawatts to public GPU totals as if the two measured the same supply. One is a facility power-capacity estimate across multiple workloads; the other is a programme count of processors with an incompletely defined status. A facility can house CPUs, storage, network equipment and accelerators, and its full power envelope is not the amount consumed by IndiaAI jobs. Government and market sources support the separate metrics, not a direct conversion between them. [12] [13] [5] [14]

A second measurement gap is distribution. Aggregate counts cannot show whether access is spread across universities, startups, public agencies and regions or concentrated among a few applicants and providers. They cannot reveal whether small jobs are served promptly while large training jobs wait, or whether a user’s location changes latency and reliability. The portal’s eligibility and allocation information provides the start of a service map, but a public, privacy-safe set of allocation and performance statistics is needed to understand who benefits. [9] [8] [3]

A third gap is verification. Government model and deployment counts establish reported programme outputs, while the sources reviewed do not link those outputs to independent tests or measured user outcomes. Physical infrastructure estimates similarly describe stock and pipeline more clearly than site-level power and water use. A high-trust publication should not treat these absences as proof of failure; it should name them as the boundary of what the evidence can support. [18] [5] [16] [15]

Limitations

The most important unknown is the number of IndiaAI GPUs that are live, free and schedulable at a particular time, broken down by provider, accelerator family, memory configuration and region. Public releases use several capacity labels but do not reconcile them. The primary allocation table is project-level and historical; the 17,300+ installation figure is an attributed 2025 report; and ETtech’s 30,000 access figure is not accompanied by a government inventory. The evidence does not justify choosing one headline as the “real” count. [1] [2] [3] [5] [6]

The public meaning of 93.18 lakh GPU-hours remains unresolved. No reviewed source defines the metric as reserved, allocated, provisioned, metered or completed hours. The project-allocation rows do not say whether projects started, and the portal does not publish aggregate active reservations, queue time, approval and rejection counts, provider uptime or the share of allocations that expire unused. These absences prevent a reliable utilisation rate or user-access comparison. [5] [1] [8] [9]

The data-centre evidence has limits of its own: operational stock estimates vary by source date and method, the 8.33 GW pipeline headline does not reconcile with the article’s stated stage totals, and none of the national totals is AI-specific. The reviewed sources do not provide a consistent site-level series for electricity draw, grid connection time, water withdrawals, cooling intensity or network performance. Programme model and public-solution counts are not independent outcome evaluations. [14] [13] [12] [16] [18]

Recommendations: publish the bridge between supply and use

First, publish a monthly compute inventory with one record per provider and accelerator family. Each record should distinguish committed, delivered, installed, commissioned, live, schedulable and unavailable devices, state the snapshot date, and explain whether the count is physical devices or virtual allocations. A short definition note and a history of corrections would make later totals comparable without exposing provider-sensitive details. The current sequence shows why one undifferentiated “GPU capacity” number is inadequate. [11] [3] [5]

Second, define GPU-hours in a public data dictionary and report each stage separately: requested, approved, reserved, provisioned, metered, completed and cancelled. Add median and 90th-percentile time to first allocation, queue lengths, rejection reasons, failure rates and uptime. The 237-project and 93.18-lakh-hour headline would become much more useful if a reader could see the period, denominator and metering boundary behind it. [5] [8] [9]

Third, publish outcome evidence alongside programme outputs. For supported model and application projects, this could include a stable project identifier, compute stage, released artifact where appropriate, evaluation method, deployment status and a follow-up measure tied to the actual user or service. Dataset and model catalogues should show provenance, licensing, maintenance and evaluation information. These practices would let independent researchers distinguish a catalogue entry or prototype from a durable public capability. [18] [5] [8]

Fourth, report physical infrastructure separately and with consistent definitions. Data-centre operators and government can publish operational, under-construction, committed and early-stage capacity as distinct categories, with a stated date and methodology. The same reporting framework can include facility-level electricity and water measurement, cooling design, grid connection status and regional network readiness at a safe aggregation level. A national generation total and an investment pipeline should never be substituted for those site measures. [12] [15] [16] [17] [14]

Finally, commission independent reconciliation before presenting a new headline. An auditor or research consortium could compare provider records, portal allocations and metered service data, publish the rules used to deduplicate devices, and explain any gap between “shared,” “onboarded” and “accessible.” That would not diminish the programme’s visible expansion; it would make claims about public access stronger, more durable and more useful to the people deciding whether to build on it. [5] [6] [3] [8]