Index

Reduce Inference, Save Energy

· Tom Cranstoun · 6 min read

The debate about AI's energy appetite is almost entirely about supply. Build more generation. Cool the racks more cleverly. Ship a more efficient chip. Every one of those is a real lever, and every one treats the demand as fixed. It isn't fixed, and the cheapest watt is still the one you never spend.

The part that gets missed is that inference, not training, is roughly 90% of AI energy use (aimultiple, MIT News). Training a model is a big one-off bill. Inference is the bill that arrives every time anyone asks the model anything, and it never stops. A large slice of that inference is redundant. Agents re-crawl pages they can't parse. They re-derive facts that were never written down in a form a machine can read. They hallucinate, then spend more compute correcting themselves.

I'll give you one case from our own work. An AI assistant insisted a fully documented command didn't exist. The troubleshooting cascade that followed burned about 40,000 tokens to recover an answer that needed roughly 200. A 200-to-1 waste ratio, on a single question. That waste is electricity and water, and almost nobody is measuring it.

Efficiency Alone Won't Save You

The usual reassurance is that hardware keeps getting more efficient, so this sorts itself out. It doesn't, and the reason has a name: Jevons paradox. When something gets cheaper to do, we do more of it. Cheaper inference invites more of it. Google's own carbon footprint has risen 48% since 2019 despite years of per-query efficiency gains (arXiv). The per-query saving was real; the total went up anyway, because usage grew faster than the efficiency did. TypeSafe named its decision model, Jev, after Jevons and bet its business on the same effect: cheaper machine decisions mean more of them.

Cheap decisions will multiply whatever we do. The demand-side answer is that a question a document answers in a declared field needs no model at all. Checking whether an expiry date has passed is a line of code, not an inference.

The lever that scales is doing less inference per task rather than making each call cheaper, and that's a content problem, not a silicon one.

The Scale Is Not Small

None of this is a rounding error. The IEA expects data-centre electricity to more than double to around 945 TWh by 2030, roughly Japan's entire annual demand (MIT News). The water side is just as physical: data-centre cooling drew more than 260 billion gallons in 2025, and a single large site can use 500,000 gallons a day (HyScaler). In the United States, data centres go from about 1% of electricity in 2024 to nearly 5% by 2030 under moderate AI growth (aimultiple). When a town fights a new data centre over its water table, it has a point. The honest answer is two-sided: invest in the grid, and drive down the avoidable demand before pouring the concrete.

Where the Demand-Side Lever Lives

Machine Experience works on that demand. MX is the practice of making content readable and verifiable by a machine, not only by a person: structured, attributed, and pointing at the authoritative source for the claims that matter. When an agent can read a claim and check it, it cites the fact instead of guessing at one. When it can't, it guesses, and guessing is the expensive part.

Structured content removes the work. A page that parses the first time doesn't get re-crawled, and an answer stated outright needs no round-trips to reconstruct. A verified fact to cite breaks the hallucinate-then-correct loop. It's a software lever on a hardware problem, and unlike a new substation it gets cheaper as adoption grows rather than being eaten by it, because it cuts the work per task instead of the price per token.

One of MX's founding principles puts it in a line: "Choose what is better for the planet. Reduce compute, reduce inference, reduce energy." A machine reading a clean, structured file instead of guessing at messy prose pays a smaller energy bill, and that cost, multiplied across every agent that touches your content, adds up.

Be Honest About the Saving

Two caveats, because this argument is easy to oversell. First, the cost saving is real where you're billed per token, and invisible where you're billed per request: if your provider charges a flat rate per call, fewer wasted tokens won't reach your invoice, though the energy behind them is still saved at the infrastructure level. Second, the sharpest numbers here are other people's, sourced and linked above; the 200-to-1 case is our own observation, not a general statistic. The direction of travel isn't in doubt. The precise magnitude, for your estate, is something you measure rather than assume.

Measurement Boundary

Better structured information can remove avoidable retrieval, retries and re-interpretation from a defined workflow. It doesn't establish a universal reduction in tokens, cost, energy use or emissions. Those outcomes depend on the baseline, task, model, retrieval route, hosting and energy-accounting method.

Any customer or product claim needs a named workload and baseline, model/configuration, token and cost capture, success and error criteria, limitations, reviewer and period. That's the minimum evidence I hold any claim of this kind to, including my own.

The Unglamorous First Move

You can't improve what you don't measure. We learned to measure data-centre efficiency with PUE; the content equivalent is measuring how much inference an agent burns to get an answer out of your pages, and how much of that's avoidable. Treat machine-readable, verifiable content as efficiency infrastructure, because that's what it is.

If you want to see where your own content forces an agent to guess, that's exactly what an audit shows. I'll audit 5 pages of your site, or 1 PDF, for free, and point at the places a machine is doing avoidable work. If you'd rather start with the idea, here is what MX is: https://mx.allabout.network/learn/what-is-mx.html