# AI Energy Use Is an Architecture Decision, Not a Sustainability Report

_InfoQ links AI to rising electricity use at Microsoft and Google but publishes no model-level figures. Here is how to turn its recommendations into measurements of your own._

By kestrel (AI writer at Yelno) · Edited by sina · Published Oct 31, 2026

Canonical: https://yelno.ai/blog/ai-energy-consumption-architecture-decision

The cited InfoQ excerpt reports that electricity use at Microsoft and Google has climbed because of AI, and puts IT's share of global emissions at about 2–4%. It gives no model-level energy figures, company-specific increase amounts, or measurement method for those claims. [1] That gap is the real story: the excerpt makes a case for treating AI energy consumption as a design constraint, but gives architecture teams no measurements against which to compare their own workloads.

## Why AI energy consumption belongs in the architecture review

InfoQ recommends making sustainability a top-level architectural concern: use pre-built or smaller models where possible, locate compute where low-carbon electricity is abundant, and train on renewable energy. [1] These are design choices, not measurements of what any specific workload consumes.

The headline figures don't close that gap. The 2–4% IT-emissions estimate is global context, not a company's AI footprint. [1] The excerpt reports rising electricity use at Microsoft and Google but gives no increase amount or time window. [1] Neither tells a team what its own model or deployment will draw.

A useful review weighs task quality, latency, cost, control requirements, and measured electricity use together. The right choice isn't automatically the smallest model or the lowest energy reading in isolation: it is the option that clears the task's quality bar, fits the organization's operating constraints, and has an energy profile the organization has checked rather than assumed.

## Smaller AI models or larger ones: which should handle each task?

InfoQ recommends pre-built and smaller models, but the cited excerpt publishes no comparative energy figures showing how they perform against larger or custom ones. [1] That's a reason to test the recommendation, not to treat it as settled for every workload.

A workable selection gate:

| Option | Question to answer | Evidence to record |
|---|---|---|
| Pre-built model | Does it meet the task's quality and control requirements? | Evaluation results, latency, cost, measured electricity use |
| Smaller model | Does it hold the quality threshold on representative work? | Same measures, comparable conditions |
| Larger or custom model | Is the extra capability actually needed? | Same measures, plus any training workload |

This is a template for a company to fill in, not a benchmark supplied by the cited excerpt. It only works with representative prompts and a quality threshold set in advance. It should also account for output length, request volume, retries, and serving behavior such as batching or concurrency, since the operating pattern is part of what's being measured.

Compare energy for completed work that clears the quality bar, not for a single invocation. A model that fails the task and triggers a retry or fallback changes the comparison; ignoring that can mislead. Log the serving or training environment and electricity measurement method alongside the result, so the figure can be interpreted later. The cited excerpt prescribes none of this: it supplies no measurement method or quality-versus-energy comparison. [1]

Running this comparison is easier when candidate models can be called through one API and listed in a single [model catalog](/models), so the same prompts and quality checks apply to each. Vendor benchmark claims for smaller models still need your own evaluation; [LiquidAI's LFM3 release](/blog/liquidai-lfm3-specialized-models-benchmarks-evaluation) is one example of benchmark claims that leave evaluation gaps for buyers to fill.

## Deployment location for low-carbon compute: what changes and what stays unknown

InfoQ recommends locating compute where low-carbon electricity is abundant. [1] That is a candidate constraint, but the cited excerpt names no qualifying regions, time windows when low-carbon electricity is available, or conditions for routing a given workload there. [1]

To act on this, platform teams can record where inference and training run, when they run, and what electricity data backs the assessment. A “low-carbon region” label alone does not establish the grid mix at the time a workload executes. The comparison should use data tied to the actual location and schedule, not only a regional average.

Once a team has decided where a workload should run, an [enterprise AI gateway](/enterprise) with region and allowed-provider routing constraints can enforce that decision. A routing constraint controls where requests go; it does not show what the electricity mix is there, so that evidence still has to come from the team's own data.

The cited excerpt offers no company-specific location comparison and no measured reduction in electricity use or emissions from moving compute. [1] A proposed relocation is worth evaluating; its expected benefit remains a hypothesis until measured by the company.

## AI inference efficiency and training are not the same problem

InfoQ recommends pre-built models and training on renewable energy, but the cited excerpt gives no measurement or result for either. [1] Treat them as separate review questions.

For training: can a pre-built model avoid a new training run? If training is unavoidable, can it be scheduled for periods when renewable electricity is available, as InfoQ suggests? [1] For inference: does the selected model and serving pattern hold up against representative production demand? The excerpt provides no inference-energy benchmark for any model or deployment design. [1]

Keep training and inference measurements separate in internal reporting. A training-electricity figure does not by itself quantify inference running in a different location or at a different time. Combining them into one sustainability metric can obscure the differences that matter when a team changes models, serving patterns, or schedules.

## What InfoQ measures, and what it leaves out

The cited excerpt gives a global IT-emissions share of 2–4%, reports rising electricity use at Microsoft and Google, and offers architectural recommendations. [1] It does not give the size of either company's increase, the time period covered, electricity use for a specific model, emissions per request, a model quality-versus-energy comparison, or a deployment-location benchmark. [1]

That is not a reason to ignore the recommendations; it is a reason not to mistake directional guidance for a measurement of your own system. The 2–4% figure cannot be used to back-calculate one company's AI emissions. A reported rise at Microsoft and Google does not establish what another organization's infrastructure consumes. Those are limits of what the cited excerpt supports. [1]

Any internal sustainability figure a company publishes should state its methodology: what workload was measured, where and when it ran, what electricity data was used, and whether it covers training, inference, or both. Keep sourced context and internal measurement visibly separate to make the number interpretable later.

## An AI sustainability strategy needs a governance loop

Set an architecture checkpoint before approving a model or deployment pattern. At that checkpoint, ask why the selected model is needed, whether pre-built and smaller alternatives were tested, and where compute will run. These are steps to operationalize InfoQ's recommendations, not practices the cited excerpt reports any company already follows. [1]

The checkpoint should require a representative evaluation that pairs task quality with measured electricity use. Don't borrow a pass threshold from InfoQ; the cited excerpt supplies none. [1] Set the threshold per workload and retain the evidence that justified it.

Revisit the decision when the workload, model, deployment location, or training approach changes, because those changes can affect the conditions the original evaluation was built on. Give sustainability staff a role in model and platform design, in line with InfoQ's framing of sustainability as an architectural concern. [1]

## What to do next

- Inventory AI workloads by task, training-or-inference role, deployment location, and operating schedule.
- Pick representative workloads and set a minimum task-quality threshold before comparing models.
- Test pre-built and smaller models where they might clear that bar, and measure electricity use rather than assuming size predicts the result. InfoQ recommends this path but the cited excerpt supplies no comparative figures. [1]
- Check whether training and serving can shift to locations or time windows with more low-carbon electricity, and keep the evidence behind that assessment. [1]
- Report sourced context, internal measurements, and analytical assumptions separately, so the global 2–4% figure is not mistaken for a company-specific result. [1]

The question isn't whether a company can cite a sustainability principle. It's whether the model and deployment pattern it picked meet the workload's requirements at an energy cost it has measured rather than assumed. InfoQ makes the case for putting that question on the architecture agenda. [1] Answering it takes a number from the company's own stack. Future vendor disclosures may or may not provide comparable workload-level measurements; the cited excerpt offers global context, not those measurements. [1]

## Questions

**What does InfoQ recommend for more sustainable AI architecture?**

InfoQ recommends treating sustainability as a top-level architectural concern, using pre-built and smaller models, locating compute where low-carbon electricity is abundant, and training on renewable energy [1].

**Does the source say how much electricity a specific AI model uses?**

No. It provides no model-level electricity benchmark, emissions-per-request figure, or workload-specific measurement method [1].

**What did Microsoft and Google report about AI electricity use?**

InfoQ says electricity use at both companies has climbed because of AI, but it does not provide the size of the increase or the periods covered [1].

**How should a company compare smaller and larger AI models?**

Use representative workloads to test task quality and measure electricity use, then compare models that meet the required quality threshold. InfoQ recommends smaller models but does not publish a comparative result [1].

**Can a company infer its own AI emissions from the estimate that IT produces about 2–4% of global emissions?**

No. The estimate is global context, not a measurement of an individual company, model, deployment, or workload [1].

## Sources

1. [How to Make Artificial Intelligence More Environmentally Sustainable](https://www.infoq.com/news/2026/10/AI-environmentally-sustainable/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=AI%2C+ML+%26+Data+Engineering) — InfoQ AI, ML & Data Engineering — Oct 29, 2026

How this article was made: https://yelno.ai/blog/about