AI Has a Power Problem

Part 2 of 30 · Series date: September 8, 2026

Before we move the machines, we need to understand what keeps them working—and which work deserves the power.

Imagine buying a new refrigerator, having it delivered, and discovering that your house cannot supply enough electricity to turn it on. Now replace the refrigerator with an entire campus of computers. The equipment may be ready, the customers may be waiting, and the money may be committed. None of that makes a missing electrical connection appear.

This imagined delivery problem captures a real distinction. Owning computing hardware is not the same as having usable computing capacity. A machine earns its keep only when power, cooling, networking, and software work together.

The invisible factory

An AI service feels weightless because its work arrives as information. Yet the service resembles a factory. Inputs enter, machines perform operations, and outputs leave. Instead of shaping steel, processors manipulate numbers.

Training adjusts a model using examples and feedback. Inference uses an already trained model to generate an answer or perform another task. Both require electricity, but their operating patterns differ. A training run may occupy a tightly connected cluster for an extended period. Inference demand can rise and fall with users, applications, and time of day.

There is no single honest electricity figure for “an AI question.” A short text response and a long generated video are different products. Model size, hardware, batching, response length, and utilization all matter. Counting requests without describing the work is like comparing the fuel used by “one trip” without saying whether the trip crosses a street or a continent.

Power is not energy

A megawatt measures a rate: how quickly electricity is being used or supplied. A megawatt-hour measures an amount. This distinction prevents some spectacular misunderstandings.

Consider a hypothetical facility drawing a steady 100 megawatts. Over one day, it uses 2,400 megawatt-hours. Over a full non-leap year, it would use 876,000 megawatt-hours, or 0.876 terawatt-hours. These are arithmetic examples, not specifications for a particular campus.

The utility must plan for the rate at which the facility draws power, while the customer pays for energy and whatever other charges its contract includes. Annual clean-energy purchases do not, by themselves, establish that every hour of operation is supplied by carbon-free generation at that location.

The International Energy Agency's April 2026 central projection puts worldwide data-center electricity consumption at about 950 terawatt-hours in 2030. That updates the roughly 945-terawatt-hour figure in its 2025 base case. Both figures cover all data centers, rather than AI alone; both are forecasts with uncertain assumptions. IEA: April 2026 report, executive summary, page 10.

The difficult last mile

Electricity does not arrive because an area looks empty on a map. A large new load can require substations, transformers, transmission upgrades, and operating agreements. The relevant question is not merely whether a region generates enough electricity over a year. It is whether the network can reliably deliver it when and where the new customer needs it.

For a town considering a facility, practical questions follow. Who finances the upgrades? What happens if the promised customer never reaches full operation? Can other users be left paying for unused infrastructure? What equipment runs during outages, and what local effects does it have?

These are project-specific questions, not reasons to assume every development is harmful. They are also not objections that disappear because a project uses fashionable technology.

Water is a design choice with consequences

Cooling links electricity demand to another local resource. Some cooling systems evaporate water; others transfer more heat to ambient air. Closed internal liquid loops do not automatically mean zero water consumption across the whole site. Nor does a water-intensive facility establish that every data center uses the same design.

Ask for annual consumption, peak demand, water source, drought arrangements, and the boundary of the calculation. Electricity production can also have water requirements. A useful comparison considers the complete service rather than one conveniently chosen pipe.

The smallest machine that does the job

Before moving a workload into orbit, it is worth asking whether the workload needs to be so large in the first place.

Imagine a service that receives three kinds of requests: finding a business's opening hours, summarizing a long document, and analyzing a difficult engineering question. Sending all three to the same expensive model may be convenient, but it is not automatically efficient. A simpler tool may handle the first request well, leaving the larger model for work that benefits from it.

Other opportunities include reusing a valid earlier result, grouping compatible requests, and avoiding unnecessary recalculation. Each needs quality checks. An old answer can be dangerously efficient if the underlying information has changed.

The useful goal is less energy per successful task at the required quality, not less energy per request regardless of what the customer receives. A system that returns weak answers and forces users to try five times may perform worse than a more capable system that gets the job right once.

This is a design argument rather than a promised saving. It reminds us that electricity demand is shaped by decisions about software as well as decisions about power plants.

Why a cooling score cannot grade the whole factory

One common facility measure, power usage effectiveness, or PUE, compares total facility energy with the energy used by its information-technology equipment over the same period. It can help reveal the overhead involved in keeping the computers operating. It does not measure whether those computers do useful work. The U.S. Department of Energy's data-center efficiency resources place facility management within a broader efficiency effort.

Consider a hypothetical site where computers use 10 units of energy and supporting equipment uses two. Its PUE is 12 divided by 10, or 1.2. If the computers perform unnecessary calculations all afternoon, the ratio could remain excellent while the service wastes energy.

The same problem will arise in space if operators count only payload electricity and omit the supporting spacecraft. A favorable boundary can make almost any installation look impressive.

Customers need more than one measure: facility overhead, processor utilization, verified output, and the consequences of interruption. Communities also need water and local air-quality information where those issues apply. No single number can responsibly stand in for the whole operation.

Some work can wait; some cannot

Imagine an energy system experiencing a temporary shortage. A video call and an overnight research batch have different needs. Delaying the batch may be acceptable; interrupting every live interaction may not be.

A computing operator could offer a lower-priced class of work that pauses when power is constrained. The contract would need a deadline, a limit on interruptions, and a way to preserve progress. It would also need to explain whether restarting consumes enough extra energy to undermine the intended saving.

This flexibility could help an Earth facility cooperate with its grid. It could also help an orbital platform live within an eclipse or thermal schedule. In both cases, the useful capability is not simply having more generation. It is knowing which work can move in time.

There is a human question underneath that scheduling choice. Who gets priority when resources are scarce? A hospital's urgent service, a scientific experiment, and a low-priority entertainment batch should not be treated as interchangeable merely because all arrive as data.

The infrastructure conversation becomes more productive when it asks what society needs computing to accomplish, as well as how much computing companies hope to sell.

Why orbit enters the conversation

Orbital computing offers a different package of constraints. Its operators could generate solar electricity beside the processors and reject heat using radiators. They would exchange terrestrial siting problems for spacecraft manufacturing, launches, radiation protection, communications, and replacement challenges.

That trade may suit some jobs. It does not establish that all computing should leave Earth. Improving software efficiency, increasing chip utilization, building transmission, and choosing better terrestrial locations remain competing approaches.

What would prove this?

A credible proposal should disclose actual facility consumption, useful output, cooling needs, and the difference between planned capacity and installed operation. An orbital alternative should be compared with the same workload, reliability, and delivery deadline—not with a deliberately inefficient Earth facility.

AI's power problem is not that electricity has stopped existing. It is that ambitious digital services require physical systems that take time, money, and public trust to build. Understanding that foundation is the first step toward judging whether space offers a useful extension.

Previous article · Next article