IndiaAI's Third Tender Buys Pool Access, Not India-Fabbed GPUs

IndiaAI Mission's third GPU tender is the clearest cost signal Indian builders have gotten this year on what "sovereign compute" actually buys.

Abhishek Singh, IndiaAI Mission CEO, told The Economic Times the round adds about 3,850 accelerators to the shared cluster. That lift takes the pool from 34,333 toward roughly 38,183 units. Inc42 carried the same vendor split. No new companies were empaneled. Capacity came from vendors already on the list.

The headline number is not the architecture. The chip mix is.

(01)What actually landed in the pool

For the first time, the subsidized IndiaAI pool includes Google Trillium TPUs: about 1,050 units. Sify is contributing 1,000 Trillium TPUs, plus 800 Nvidia H200 GPUs and 700 Nvidia L4 GPUs. Locuz is adding 1,300 Nvidia H100 GPUs. Ishan Infotech adds 50 more Trillium TPUs. Vensysco cut prices but did not add hardware in this round.

That is Nvidia CUDA SKUs and Google TPU silicon, supplied through Indian cloud and systems partners. It is not India-fabbed accelerators. PIB later summarized the compute pillar as more than 38,000 GPUs onboarded, with subsidized access reported at ₹65 per hour for the onboarded pool. Treat that as a pool-level rate signal, not a Trillium-specific quote. ET had already framed IndiaAI pricing as among the lowest globally, often under a dollar per GPU hour across earlier rounds.

Financial evaluation for round three is done. Singh said L1 prices moved slightly. Empaneled bidders from rounds one and two are expected to match. Price discovery is still a tender mechanic, not a single national SKU.

(02)The cost architecture that follows

If you ship multi-model products, the operator question is not "did India get more GPUs?" It is "which accelerator can I schedule, at what rate, under which runtime?"

H100 and H200 work sit in the CUDA lane. L4 is a different density and memory profile, often better for lighter inference. Trillium is a TPU path. Toolchains, kernels, batching, and failure modes do not transfer cleanly. Anyone shipping multi-LLM products already knows routing and hard cost caps. A national pool with four accelerator families just raises the same problem to infrastructure scale.

India's "sovereign" compute story here is multi-vendor foreign silicon at subsidized rates, not indigenous GPUs. Cost architecture for builders is pool access plus chip mix, not a Made-in-India accelerator stack.

Peers can disagree. Some will argue subsidy plus Indian operators is sovereignty enough for startups. Fine. Argue that with unit economics, not with branding. If your training job needs H100 interconnect behavior and you land on L4 capacity because it was cheaper that hour, you did not buy sovereignty. You bought a mismatched SKU.

(03)What I would wire before requesting quota

Map workloads to SKUs first. Training and heavy fine-tunes: H100 or H200 where interconnect and memory matter. Latency-sensitive speech inference: test L4 against your current commercial cloud baseline. Only move a job to Trillium if your stack already speaks TPU (or you budget the port). Do not assume "IndiaAI GPU hour" is one fungible commodity.

Second, treat L1 matching as a moving price floor. Round-to-round drops on the same model have already ranged from a few rupees to over a thousand rupees per hour in earlier ET reporting. Your architecture should re-quote, not hardcode.

Third, separate indigenous models from indigenous silicon. IndiaAI is also funding foundation-model work (Sarvam, Gnani, and others appear in the mission narrative). That is model sovereignty. This tender is compute access. Mixing the two stories blurs the budget decision.

(04)The failure mode that matters

Teams that hear "sovereign compute," assume one Indian chip path, then discover their cost model collapses across H100, H200, L4, and Trillium. The third tender made that mix explicit. Build for pool access and chip mix, or the subsidy will not save the invoice.