Can AI Be Sustainable?

The Question We Don't Ask

Read enough AI benchmark leaderboards and a pattern emerges. Reasoning quality. Context window size. Parameter count. Tokens per second. Cost per million tokens. Latency, measured in milliseconds, argued about in forum threads with the intensity usually reserved for sports rivalries. These are the numbers the industry has agreed to compete on, and they are all, in their own way, useful. They tell you something real about what a model can do and how quickly it can do it.

One number is almost never on that scoreboard: how much energy did that answer cost?

Not "how much did it cost the company," which shows up eventually as a line item somewhere. How much electricity was actually converted into the response sitting in front of you, the matrix multiplications, the memory movement, the cooling required to keep the silicon from melting under the load. That number exists for every single AI response ever generated. It is simply not one anyone puts on the leaderboard next to the benchmark score.

This article asks a straightforward engineering question: as AI keeps scaling, bigger models, more inference, more devices, more constant background use, should sustainability become another axis engineers deliberately optimise for, the way they already optimise for performance, accuracy, latency, cost, and privacy? Not instead of those things. Alongside them, as one more entry on a list every engineer already juggles.

To be direct about what this piece is not arguing: it is not anti-AI, not anti-cloud, and not anti-big-tech. Hyperscale data centres are a remarkable engineering achievement, and cloud AI has made genuinely capable models available to anyone with a browser tab. The argument here is narrower and, hopefully, more useful than a verdict on any of that: sustainability is currently invisible on most AI engineering scorecards, and invisible costs tend to stay unmanaged costs. FarmakoMed shows up later in this piece as one example of a team that made a different set of architectural choices, not as a hero of the story, and not as a claim that its approach is greener in some general sense. It's a case study in one alternative, offered alongside the acknowledgment that plenty of good engineering happens the other way too.

Intelligence Has a Physical Cost

Start with the part that's easy to forget precisely because modern software has gotten so good at hiding it: every AI response requires physical resources. Electricity to power the processors. Processors, CPUs, GPUs, TPUs, NPUs, to do the arithmetic. Memory to hold the model's weights and the conversation's context. Cooling to remove the heat that computation always generates as a side effect. Networks to carry the request there and the answer back.

None of this is unique to AI. It has always been true of computing in general. What's changed with large language models is the scale and concentration of the computation involved in producing a single response, and the fact that inference, not just training, now runs continuously, for millions of people, many times a day, indefinitely. Training a large model is a headline-grabbing, one-time (or occasional) event. Inference is the part that never stops, because it happens every time someone opens a chat window.

That reframing matters because it moves the conversation away from a moral question, "is AI bad for the planet", toward an engineering one: given that every inference has a physical cost, where should that cost be paid, how large should it be, and who is responsible for measuring it? Those are exactly the kinds of questions engineers already know how to answer for latency, memory, and spend. Energy has simply not been treated as belonging on the same list.

The Hidden Infrastructure Behind Every Prompt

A cloud AI response looks instantaneous from a browser tab, which is precisely the point of good infrastructure engineering, the complexity is supposed to be invisible. Behind that instant reply sits GPU clusters running near continuous utilisation, cooling systems fighting the heat those GPUs generate, water in many facilities doing part of that cooling work, networking fabric moving requests and model weights between racks, and a hardware lifecycle, manufacturing, deployment, eventual replacement, that has its own embodied environmental cost before a single inference ever runs.

None of that is a secret, and none of it is unique to AI, data centres have run this way for decades. What's changed is the trajectory. The International Energy Agency's 2025 Energy and AI report puts data centre electricity consumption at roughly 415 terawatt-hours in 2024, about 1.5% of global electricity use, and projects it will nearly double to around 945 TWh by 2030, naming AI as the single most important driver of that growth.^[1] That's a genuinely fast curve: data centre electricity demand has been growing at roughly four times the rate of overall global electricity demand since 2017.

The hyperscalers' own disclosures tell a more nuanced version of the same story, one that deserves to be read carefully rather than reduced to a single villain. Google's 2024 Environmental Report shows data centre emissions actually falling 12% year-over-year, achieved through clean energy procurement and hardware efficiency gains that pushed the company's fleet-wide power usage effectiveness down to 1.09, even as electricity consumption climbed 27% over the same period.^[2] Both of those numbers are true at once, and together they say something more interesting than "AI is wasteful": efficiency is improving quickly, and demand is currently growing faster than efficiency can offset it. Microsoft's disclosures echo the pattern from a different angle, total emissions running roughly 23% above its 2020 baseline, driven chiefly by data centre construction and AI/cloud expansion, even while direct operational emissions fell around 30% over the same period through renewable energy purchases.^[3] Building the capacity costs something before the capacity ever runs a single model.

Water is the part of this infrastructure that gets discussed least, and it deserves a place on the list precisely because it's less visible than a power bill. Peer-reviewed research from the University of California, Riverside estimated that training a GPT-3-scale model in a modern U.S. data centre can directly evaporate several hundred thousand litres of freshwater for cooling, and projected that global AI-related water withdrawal could reach several billion cubic metres a year by 2027, a volume the researchers compared to the total annual water use of a mid-sized European country.^[4] Most of a data centre's water footprint, direct and indirect combined, traces back to the same root cause as its electricity footprint: heat has to go somewhere, and moving it costs resources.

Bigger Models Are Not the Only Path

The AI industry has, for the last several years, mostly celebrated one axis of progress: bigger. Bigger models, bigger context windows, bigger training clusters, bigger benchmark gains purchased with bigger compute budgets. There are good reasons this happened, scale has produced real capability gains, and for a foundation model provider serving enormous, diverse traffic, a larger general-purpose model genuinely can be the right call.

But "bigger produced gains" is not the same claim as "bigger is the only way to produce gains," and it's worth being honest that the industry conversation often quietly slides from one to the other. Smarter engineering is a second, parallel path that gets far less attention because it's harder to put on a single leaderboard: more efficient inference kernels, better model selection for the actual task at hand, specialised smaller models trained for a narrow job instead of a general one, edge AI that runs closer to the user, quantisation that shrinks a model's footprint with a measured accuracy trade-off, model routing that sends easy queries to cheap models and hard ones to expensive models, and energy-aware execution that treats power draw as a scheduling input rather than an afterthought.

This is not a call to declare small models, quantised models, or on-device models categorically superior to large cloud models, that would just be swapping one oversimplification for another. A foundation model provider training a frontier model to serve hundreds of millions of unpredictable queries has different constraints than a team shipping a narrow, well-defined feature. Diversity of approach, matched to the actual constraint each team is solving for, is the healthy state, not a single "correct" architecture that every team is implicitly expected to converge on.

Sustainability Becomes an Engineering Metric

Software engineering already has a long tradition of optimising for constraints that never show up in a product demo: speed, latency, memory footprint, storage, network bandwidth, and cost. Nobody considers it strange that a design review asks "what's our p99 latency budget" or "how much memory does this add." Those questions are simply part of how mature engineering teams think, baked into code review, architecture documents, and on-call runbooks.

AI adds a metric that has largely been missing from that list: energy. Not as a replacement for the others, accuracy still has to be good enough, latency still has to be fast enough, cost still has to fit the budget, but as an additional dimension in the same multi-objective optimisation engineers already run every time they ship a feature. The question "how much energy does this feature require" is not a fundamentally different kind of question than "how much memory does this feature require." It's simply one that most engineering review processes haven't learned to ask yet, because for most of software's history the honest answer would have rounded to "not enough to matter."

The Role of On-Device AI

Local inference is the most obvious place to look once energy becomes a metric worth tracking, because it visibly relocates computation away from a data centre and into a device the user already owns. It's tempting to treat that relocation as an automatic sustainability win. It isn't automatic, and claiming otherwise would be exactly the kind of unsupported claim this article is trying to avoid.

A phone's chip is, per unit of computation, considerably less energy-efficient than a purpose-built data-centre GPU cluster running at high utilisation with mature cooling. Manufacturing a smartphone carries its own embodied environmental cost, amortised across the device's lifetime regardless of what runs on it. And a model that runs locally but gets invoked far more often, because it's fast, private, and frictionless, can, in aggregate, spend more energy than the same task handled by an occasional, well-utilised cloud call. Total energy is a function of model size, hardware efficiency, how often something runs, and the carbon intensity of whichever grid is actually supplying the electricity at that moment, not simply a function of "local versus cloud."

The more useful engineering framing is choosing the most appropriate execution environment for a given workload, rather than picking a side. Some tasks, short, latency-sensitive, privacy-sensitive, needed offline, may naturally belong on-device. Others, large, infrequent, benefiting from a bigger model than any phone can host, may naturally belong in the cloud. Between those two poles sits hybrid AI, where a task is split or routed depending on context. Worth naming explicitly: energy locality, the idea that where a joule is spent also matters, not just how many are spent, because grid carbon intensity varies by region, by time of day, and by how much renewable generation happens to be available at that moment. A joule spent on a grid running mostly on renewables is not equivalent to a joule spent on a grid running mostly on coal, even if the device-level efficiency numbers look identical.

What FarmakoMed Explores

FarmakoMed is one example of a team that chose the on-device end of that spectrum for a specific class of healthcare tasks, and it's worth being precise about what that choice actually looks like in practice rather than describing it in the abstract.

FarmakoMed's Trust Center documents a document-understanding and medication-recognition pipeline that runs entirely on the user's phone: a photographed medication package or prescription is processed by an on-device text-recognition engine, structured locally, and interpreted by a local AI model, Gemma, served through Google's LiteRT-LM runtime, with no network connection required at any step of that pipeline, and no document photo, prescription text, or question sent to an external AI service. The company's own FAQ states plainly that it does not use OpenAI or any other third-party AI provider for this work; medication recognition, document understanding, and the on-device assistant all run on that local model.

The stated motivation for that architecture, as FarmakoMed's own materials describe it, is not only privacy. It is also reducing unnecessary dependency on a remote service for a task the device is capable of handling itself. That's a meaningfully different framing than an environmental one, and it's worth keeping the two separate rather than quietly merging them. But the two framings do share an underlying engineering instinct worth naming: don't send a task somewhere else, with all the network, infrastructure, and standing-service overhead that implies, if the task can be completed correctly with the compute already sitting in the user's hand.

That instinct shows up concretely in a decision FarmakoMed's engineering team has already published elsewhere in this journal. When evaluating how to extract text from a photographed document, the team tested reusing its existing vision-language model, the same Gemma model already used for medication recognition, for plain text extraction, and measured roughly 2–4 GB of peak memory and multi-second per-page latency for that approach. They rejected it in favour of a purpose-built, much smaller on-device text-recognition engine that added roughly 12 MB to the app and returned results in a few hundred milliseconds on a mid-range flagship device, fully offline.

It's worth being explicit here, in the interest of not overstating what's been measured: FarmakoMed has not published joule-level or carbon-level measurements of this architecture. Nothing in this section should be read as a quantified environmental claim on the company's behalf. The point being made is structural, not statistical, an architecture that avoids unnecessary round trips and avoids running an oversized model for an undersized task is, by construction, doing less computation than one that doesn't, whether or not anyone on the team ever framed that choice using the word "sustainability."

Engineering for the Next Decade

The hardware underneath all of this is moving quickly enough that some of today's trade-offs are likely temporary. Dedicated NPUs are becoming standard components in flagship phones rather than rare exceptions. Silicon keeps getting more efficient per computation. Quantisation techniques keep shrinking the memory and power envelope required to run a given level of capability. Runtimes built specifically for on-device inference are under active development to extract more useful work from the same battery and the same chip.

What's less certain, and more interesting from an engineering standpoint, is how applications will decide, at runtime, where a given piece of work should actually happen. FarmakoMed's own on-device runtime already has to reason about which hardware backend is genuinely available on a given phone at a given moment: whether GPU or NPU acceleration is supported, available, and actually usable, or whether the runtime needs to fall back to CPU, and its diagnostics deliberately preserve "unknown" as a distinct state from "false" when the answer genuinely can't be determined, rather than guessing. That's a narrow, concrete example of software already having to make an adaptive decision about where computation should run, based on what the hardware in front of it can actually do right now.

None of that hardware progress is a reason to defer thinking about energy until "the chips get good enough." Better hardware raises the ceiling on what's affordable to run continuously; it doesn't remove the value of asking whether something needs to run continuously at all. That discipline, treating energy as a metric worth naming and measuring, whichever environment a workload ends up running in, is the part that doesn't expire with the next generation of silicon.

Conclusion

Perhaps the next generation of AI shouldn't be judged only by how much smarter it gets. Perhaps it should also be judged by how responsibly that intelligence is delivered. Accuracy, speed, and benchmark scores will keep mattering, nothing here argues otherwise. But energy efficiency, resource efficiency, and a habit of long-term thinking about infrastructure deserve to sit on the same scorecard, not as a substitute for the metrics engineers already track, but as the metric that's been quietly missing from it.

To restate the boundary this article set for itself at the start: this is not an argument against AI, against the cloud, or against the companies building at hyperscale, several of the most credible numbers cited here came directly from those companies' own disclosures, which is itself a sign the industry is already starting to measure what it used to leave unmeasured. It's an argument for adding one more entry to a list of things engineers already know how to think about carefully.

One Last Thought

The next real advance in AI may not come from a larger model. It may come from systems smart enough to know when enough intelligence is already enough, and engineers disciplined enough to measure the difference.