Stop picking winners
GPU utilisation as an efficiency problem.
In the United States, the National AI Research Resource (NAIRR) pilot connects researchers and educators with the computing power, data and training they need for AI research. Its allocation management policy lets the providers of that computing power take back what goes unused. If a project has touched none of its allocation after three months, the provider can cut it in half (by a quarter, if the project has made limited progress). After six months with no use at all, the provider can withdraw it entirely.
I read the policy as a response to two facts: nobody can tell in advance which projects will succeed, and compute is scarce while demand for them keeps growing. That raises a broader question. Can the same principle work for public research resources in general? India's compute programme is a good place to test it.
India's compute programme
The IndiaAI Mission set out to make 10,000 GPUs available to Indian startups and researchers. It now has more than 45,000, offered at about ₹65 an hour. By August 2026, 237 projects had been sanctioned 93.18 lakh GPU-hours between them. The mission received 506 proposals to build Indian foundation models and is backing twelve organisations, from Sarvam AI to BharatGen, an IIT Bombay-led consortium with ₹1,058.52 crore of support. The procurement problem is solved. The harder question now is how to make sure each GPU-hour goes where it does the most good.
Government grants in India already come in instalments, the Department of Science and Technology, for example, releases each one only after the previous one has been utilised or accounted for. IndiaAI asked foundation-model applicants to set out their own milestones, funding timelines and benchmarks. This is where I see a flaw in this mechanism. When GPUs are scarce and the field is this competitive, a team that has to meet only its own targets and never compared against the team next to it will always win more compute. Nothing IndiaAI has published so far suggests that GPU-hours can be taken back into the central pool when a team misses those targets. Hence, each grant ends up as its own silo.
Theory of change borrowed from hedge funds
Millennium Management runs more than 370 investment teams, usually called pods. Each pod trades within its own risk limits, and fund profiles put the typical loss limit at around 5% from peak. Breach it and the pod's capital can be cut straight away. Pods that do well get more. Put to use as a theory of change for a public programme, if each instalment is judged against a common framework the funder sets, and teams are compared with each other and not only with their own plans. The money freed up by inefficient teams moves to faster ones under a publicly published formula, then resources reach the teams making progress sooner. Each rupee of subsidised compute buys more capability, and the public can see what it's getting.
The obvious objection to this is that a hedge fund can mark the prices every day, while model-training requires us to let it finish the run before any judgement can be made. A half-trained model doesn't provide any value. My answer is to move GPU allotments only between milestones and not mid-run. Government agencies across the world have already been doing this since years, on projects far more precarious than model training.
Governments already do this
In 2006, NASA backed two companies, SpaceX and Rocketplane Kistler, to build cargo spacecraft, and paid them as they hit milestones they had proposed themselves. In 2007, NASA ended its agreement with Kistler after the company missed a series of technical and financial milestones. The remaining $170 million went back to the central pool, and Orbital Sciences won it in 2008.
DARPA's AI Cyber Challenge asked teams to build AI systems that find and fix software bugs, and test them all on the same planted bugs. In the 2024 semifinal, teams found 37% of the bugs and fixed a quarter of those. Seven went through to the final, where the figures rose to 86% and 68%.
Finally, India has its own versions of this mechanism. The Production Linked Incentive scheme for electronics pays manufacturers 4% to 6% of their extra sales over a 2019-20 baseline. In Rajasthan, the Educate Girls impact bond repaid its investor only after an independent evaluator, IDinsight, had checked the results. It enrolled 768 out-of-school girls against a target of 662.
A common mechanism to evaluate and allocate
The theory of change still leaves one important question unanswered, who decides how the next round of compute is split, and on what basis? A committee can do it, but committees meet periodically and judge each case separately. A fixed rule, such as cutting any team that misses a target by a set margin, is consistent but cannot improve by itself. It applies the same thresholds in the tenth round as in the first, however much the programme has learned about which signals actually predict success. A committee could recalibrate the rule from time to time. I think it is worth exploring whether reinforcement learning could do that learning round by round, working out which allocation decisions lead to the most progress.
Though this approach can sound a bit technocratic, bear with me on why I think this might just be useful. The allocation problem requires repeated decisions to be made periodically. Each decision changes what information is available next. Every round forces a trade-off between backing the teams that look strongest and testing teams whose potential is still unknown. This is the class of problem reinforcement learning was built for. In plain terms, reinforcement learning is a method for making a sequence of decisions by trial and error: the system acts, observes the result, and adjusts its next decision towards what worked.
How the allocator would work
At the end of each round, the allocator looks at three things for every team: its latest score on a common evaluation, the share of its allotted compute utilised, and its remaining budget. It then proposes the split for the next round. It is judged on how much model quality improves per GPU-hour across the whole portfolio, with weights for public priorities, so that a Santali speech model is not compared with a Hindi chatbot on raw scores.
IndiaAI would build the tests in Indian languages and keep them private, so teams can't game the exams. A share of each round would be held back for teams whose results are still uncertain. Computer scientists call this the multi-armed bandit problem, after slot machines: a gambler who only ever plays the machine that has paid out most so far never learns whether another one pays better. In a public programme, the uncertain teams are often the ones working on smaller languages, with less resources, and an allocator with no budget for exploring would slowly starve them.
The allocator can be backtested against the available data. IndiaAI already has the portal data logs needed to simulate past rounds. The current milestone-based process, fixed instalments, and a learning allocator can be run side by side in simulation to see which converts subsidised compute into model quality fastest.
Any allocation rule changes how the people it funds behave. Reward improvement between rounds, and teams have a reason to hold back early so the next jump looks bigger. Reclaim unused compute, and teams have a reason to run low-value jobs just to keep their usage up. Score every language on the same scale, and teams will drift towards Hindi and English, where scores rise fastest. So the simulation has to include teams that try to beat each rule, and a rule should be adopted only once it has held up against them.
Who decides what counts
The strongest objection to this proposal is that it turns a political decision into code. Choosing how much weight a Santali model deserves, or whether an agricultural assistant should count for more than a legal one, is a political judgement. If those judgements are embedded in a reward function, the communities affected lose a clear way to contest them. James C. Scott's Seeing Like a State documents how often governments that manage only what they can measure end up harming the people they intend to serve.
The design principle should therefore be that the allocator handles the arithmetic and people set the values. That requires four safeguards.
The priority weights should be set publicly, each cycle, by a body that includes language communities, state governments and the funded teams. Participatory budgeting in Porto Alegre shows this can work at city scale: residents ranked investment needs in district assemblies and debated the rules for dividing funds between districts. A World Bank case study reports participation rising from under 1,000 people a year to about 40,000 during the 1990s. The same study notes that the poorest residents were underrepresented, which an Indian version would need to address.
Communities should help build the evaluations. An evaluation for Santali written by people who do not speak Santali will consistently reward the wrong models. BHASHINI's Bhasha Daan already collects recordings, transcriptions and translations from citizens for an open dataset, and the same approach can produce and refresh the test sets. Every allocation decision should come with a stated reason and a route to appeal to a human panel with the power to override it. Overrides should be published. The EU's GDPR, Article 22 gives individuals the right to human review of decisions made solely by automated means, and a public compute programme should meet that standard at least. A portion of each round should remain discretionary, for promising work that no evaluation was designed to recognise, and the pilot should be subject to a public review with the authority to end it.
What to measure in the next phase
IndiaAI's public reporting currently focuses on GPUs onboarded and hours sanctioned, which were the right measures while capacity was being built. The next phase needs output measures:
- Utilisation: the share of allotted compute that is actually used.
- Improvement per crore: gains on the common evaluations for each rupee of subsidy.
- Regret: the gap between each allocation rule and the best possible allocation in hindsight, measured in simulation.
- Coverage: a minimum share of compute for smaller languages and use cases.
It's fine if a reinforcement model is not the answer, but I believe these measurements used by a human committee that sets targets on these periodically can make incremental gains in GPU allocation efficiency.