Executive Summary

Key Figures

Source: Nature comment (d41586-026-02451-2), IEA, Gallup, NVIDIA

Data centres worldwide consumed roughly 485 terawatt-hours of electricity last year. That is close to what Germany generates in a year, and about 1.5% of global generation. The IEA expects the figure to double by 2030, reaching 945 terawatt-hours. In the same agency's most recent analysis, data centre power demand grew 17% during 2025 alone, far outpacing the 3% growth in overall electricity demand.

The money runs in the same direction. Combined capital spending this year by Amazon, Alphabet, Microsoft, Meta and Oracle passes $600 billion. That is 36% more than last year, and credit analysts estimate that about three quarters of it goes into GPUs, servers, network equipment and data centre buildings.

The route by which these numbers reach a researcher is not the electricity bill. In a Gallup survey released this past May, 71% of Americans opposed an AI data centre being built in their area, and 48% opposed it strongly. Asked why, 18% named water use and another 18% named electricity use, so resource concerns accounted for about half the answers, while 16% pointed to noise and air and water pollution. Gallup framed this sentiment as a major obstacle to the expansion of AI compute, and noted that it could turn into local organising and litigation.

There are already cases where that sentiment turned into procedure. On 17 February the city council of San Marcos, Texas, voted 5 to 2 against rezoning for a $1.5 billion data centre campus. The plan called for five buildings of 380 megawatts each on a 200-acre site, and the vote came at the end of an eight-hour meeting in which residents objected over water use and the environment. On 16 June the city went further and passed an ordinance banning data centres inside city limits, becoming the first city in Texas to block them, and a state senator signalled a lawsuit. About half of the 248 data centres planned across Texas, however, are slated for unincorporated areas that a city ordinance cannot reach.

The three people who wrote the comment come from environmental research rather than the AI industry. They are Cassidy K. Buhler, a postdoctoral researcher in environmental data science at the University of Colorado Boulder; Fernando Pérez, an associate professor of statistics at UC Berkeley; and Carl Boettiger, an associate professor in the same university's Department of Environmental Science, Policy and Management. They have built research computing environments themselves while working with climate and biodiversity data, and that experience is what the comment rests on.

Here is the point the comment presses. The free academic accounts and discounted plans researchers use today are subsidies resting on an assumption that this expansion continues. If neither the environmental cost nor the subsidised price of access can run indefinitely, then where the tools sit now decides the conditions of research a few years out.

While big-tech data centres handle billions of chatbot queries a day, the impression has hardened that advanced AI runs only in giant facilities. The comment's authors, drawing on their own experience, argue that this is not true. Building where solar power is abundant does solve the electricity problem and can sidestep local objections, which sounds reasonable enough, but the claim that a giant facility is a precondition for AI-based science is the part that is wrong.

The analogy they reach for is the history of the personal computer. Early computers filled a room, then came down onto a desk, and now sit on a lap. The AI era is only a few years old, the comment notes, and the same signs of shrinking are already visible. Their example is NVIDIA's new laptop chip, the RTX Spark, built to run models such as Google's Gemma 4 locally on laptops from Dell, HP and others. Apple's laptop chips have supported local models for several years already.

The RTX Spark's specifications back the analogy with concrete numbers. Announced jointly by NVIDIA and Microsoft on 31 May, the chip links a 20-core Grace CPU with a Blackwell RTX GPU carrying 6,144 CUDA cores over NVLink-C2C, with CPU and GPU sharing up to 128GB of unified memory. NVIDIA describes one petaflop of FP4 compute running a 120-billion-parameter model locally, and more than 30 laptops carrying the chip arrive this autumn.

Some of this needs no waiting for autumn hardware. The 12-billion-parameter version of Gemma 4 is designed to run on devices with 16GB of unified memory, and quantised to four bits its weights fit under 8GB. The speed is not generous, though. User measurements on a 16GB Mac mini M4 land around 12 tokens per second, workable for conversation and frustrating for long generations. On a device in this class it is context length rather than the weights that fills memory first, which pushes you toward a context of about 30,000 tokens.

Another of the comment's examples gives a better sense of scale for a lab. A single server rack the size of a small refrigerator can handle roughly 50 people sending questions and getting answers at the same time. Open-weight models have climbed to where they rival closed commercial ones on many tasks, and the remaining barrier is less performance than the technical know-how to stand one up and keep it running. The authors attach that caveat to their own recommendation.

The comment's diagnosis is that many research teams already have the capacity to stand up a server instead of buying a subscription, and that institutions still do not invest in that direction. So where does that inertia come from? A subscription ends with a single payment, while an in-house server has to keep meeting one condition: utilisation.

Analyses through 2026 mostly place the break-even point in the range of 60% to 70% sustained utilisation. Below that the cloud wins, and above it owned hardware pulls ahead on a three-year depreciation schedule. Many of these figures come from GPU cloud providers and server manufacturers writing to their own interests, so the safer reading treats them as a range to test against your own institution's usage curve. Hourly pricing for an H100 instance falling from the $7 range at launch to under $2.50 with specialist providers keeps shaking the calculation as well.

The load pattern of university research sits especially awkwardly with that condition. Training runs in bursts of days or weeks, and afterwards the cluster stands empty while results are reviewed and the next experiment is prepared. There are several reports of teams buying hardware because the hourly rate looked cheap and then leaving 60% of it idle. One company spent $6.8 million on 512 H100s, never designed a scheduling plan, and stalled at 34% utilisation. Once it had added power, cooling and three more engineers, it was paying more than the $800,000 monthly cloud bill it had left behind.

So the comment's proposal reads closer to reality as an arrangement that brings steady inference onto institutional servers and rents outside capacity for bursty training, rather than as a call to bring all compute in-house. That is in fact the common configuration in 2026. On top of it, the 0.5 to 1 person per cluster needed to operate the thing never appears on a GPU bill and is a cost all the same. Without that person, the in-house server does not get built.

The problem of an API-served model changing without notice is one this blog covered earlier this month in Doing Science with a Tool You Cannot Reproduce. Once the weights behind an alias are swapped, there is no way to run an experiment from a few months ago under the same conditions. The conclusion there was that reproducibility is another name for provenance.

Download the weights onto an institutional server and that drift disappears. In exchange, new items arrive that have to be written down. Which weight file you used can be pinned with a hash, but even with the same weights the output can differ with the quantisation settings, the numerical precision, the version of the inference runtime, and which GPU it ran on. A result inferred in FP4 and a result inferred in BF16 do not always agree for the same model on the same prompt. Moving local means bringing those variables into a place where you record them yourself instead of receiving them from a provider.

What you can record splits by where the tool sits.

In the right-hand column it is the last row that catches. Move to an institutional server and the execution record stays inside the institution, and how long those logs are kept and in what format is mostly undecided. Data lineage is already an item covered by various regulations and practices, whereas which weights ran on which hardware at what precision still lives, for the most part, in someone's lab notebook.

The GPU model named in a paper's appendix is information that someone trying to rerun that experiment five years from now needs as much as the source of the data. Left to individuals, it disappears when people leave; kept by institutions, it requires deciding retention periods and access rights. The decision to build your own infrastructure is also a decision about who carries that recording duty.

The comment closes by pointing to precedent. Science has long led the practice of publishing code, data and model parameters, and that experience holds here too. The authors write that the scientific community should show the public a model of more energy-efficient and sustainable AI use.

The people invoking this precedent are themselves part of it. Pérez built IPython as a graduate student, and it grew into today's Project Jupyter. When Nature picked ten computer codes that transformed science in 2021, that tool was on the list. Boettiger teaches reproducible and collaborative data science as a graduate course at Berkeley.

What makes this point persuasive is that open-source scientific tools did not spread because of performance. Open the code and someone else can produce the same result again, and that checkability was the tool's value. The argument now unfolding over open-weight models and local infrastructure sits in the same place. Regardless of how much electricity gets saved, what remains is whether the same result can be produced again a few years later.

Three questions are worth answering at lab scale right now. Can you point, file by file, to which version of which model produced the results going into your paper? If that model disappears next year, what becomes impossible to rerun? And is the place where you write those answers down a personal notebook or an institutional record?

Primary Comment

• 1.Buhler, C. K., Pérez, F., & Boettiger, C. (2026). "Why scientists should lead the shift away from AI mega data centres." Nature.

Data & Industry Sources

• 2.International Energy Agency. (2026). "Energy and AI — Executive Summary."
• 3.Gallup. (2026). "Americans Oppose Data Centers in Their Area."
• 4.NVIDIA. (2026). "NVIDIA GeForce RTX Computex 2026 Announcements."
• 5.eMarketer. (2026). "Big tech's $600 billion AI capex plans could fuel faster automation rollouts, spark investor jitters."
• 6.Modelfit. (2026). "Best LLM for Mac Mini M4 16GB."

News & Background

• 7.The Texas Tribune. (2026). "San Marcos becomes first Texas city to ban data centers."
• 8.KUT News. (2026). "San Marcos City Council blocks proposed data center."
• 9.UC Berkeley Computational Data Science and Society. (2026). "Project Jupyter celebrates 20 years: Fernando Pérez reflects on how it started, open sciences."