Compute follows energy

A small compute node with four coloured lights, cabled to a tilted solar panel tile

Electricity does not cost the same everywhere, and it does not cost the same at every hour. Its carbon intensity varies just as much and rarely in step with price. Meanwhile a large share of SI work — training runs, batch inference, evaluations, document processing — does not care when it happens, only that it finishes by a deadline. Two facts that fit together perfectly, and almost no scheduler is told either of them.

Two variables nobody exposes

Price varies by hour and place. Wholesale electricity markets move constantly, sometimes dramatically, and the pattern differs between grids. A workload that can run at 03:00 in one region rather than 18:00 in another is a different cost, with no change to the code.

Carbon intensity varies too. The mix generating a grid’s electricity changes through the day. Running flexible work when the mix is cleanest reduces emissions with no reduction in output — which is the rare kind of improvement that costs nothing.

The reason neither is used is mundane: the scheduler does not have the data, and the workload does not express its flexibility. Both are fixable, and neither is a research problem.

Making flexibility explicit

The unlock is not a smarter scheduler. It is workloads that say what they actually need.

Today a job says “run me”. Usefully, it would say: finish by 07:00, needs this class of accelerator, must stay in this jurisdiction, can be interrupted and resumed, and here is what I am willing to pay per unit of work.

Given that, placement becomes an optimisation with real inputs. Without it, everything is treated as urgent, which is how a datacentre ends up running deferrable batch work during the most expensive and dirtiest hour of the day.

Most jobs are far more flexible than their submitters have ever been asked to say.

The constraints that must win

Optimising for energy cannot override the things that are not negotiable, and a grid that gets this wrong is worse than no grid.

Jurisdiction beats price. If data may not leave a country, cheap electricity elsewhere is irrelevant. This is a hard boundary in the placement policy, not a weighting.

Deadlines beat price. Flexible does not mean unbounded. A job that must finish by morning finishes by morning, at whatever the cost turns out to be.

Latency beats everything for interactive work. Anything a human is waiting for runs near the human. Energy optimisation applies to the batch layer, which is where most of the consumption is anyway.

The honest limits

Moving data costs energy too. For a small job on a large dataset, the transfer can exceed the saving — so placement has to account for where the data already is, not just where the electricity is cheap.

Interruption has a cost. Checkpointing and resuming is not free, and for some workloads it is expensive enough that following the price is a net loss.

And carbon accounting is genuinely contested. Marginal versus average intensity, and how certificates are treated, change the answer materially. Any project claiming a precise emissions reduction without saying which method it used is telling you very little.

Why this belongs in a grid rather than a datacentre

A single operator can shift work between its own regions, and the large ones do. What they cannot do is move work to hardware they do not own, in a building they do not operate, powered by a supply they did not buy.

A grid can — which is the entire argument. The flexibility available across many participants is much larger than the flexibility available inside any one of them, and it is the kind of efficiency that only exists if the market for it exists.