On an August evening in Silicon Valley, with the air hot and air conditioning load peaking, the local utility sent a signal to a data centre: adjust your consumption.
Nobody touched anything. The workload orchestration layer at the data centre received the signal, slowed the work that could wait, and consumption began to fall on the screen.
This guide covers how that mechanism works, which workloads can be flexed, and what a data centre has to solve first in order to do it. The approach described is not tied to one product; the logic is set up the same way at any facility.
Why the problem arose
AI workloads are an unusual customer for an electricity grid. Their demand is large, continuous and concentrated at one point.
On the grid side the difficulty is not average consumption but peak moments. When air conditioning load peaks on a hot summer evening, the grid's capacity in that instant is what matters, and a data centre adds another load onto that peak.
The classic answer is building capacity: more generation, more lines. But that answer is measured in years, while AI demand grows in months.
A second difficulty is location. Data centres cluster at particular points on the grid, and line capacity at that point is a constraint independent of national generation capacity. Building a new plant does not solve a bottleneck in the wrong place.
How flexibility answers it
The alternative shifts demand in time rather than adding capacity. The logic is simple: not every job in a data centre carries the same urgency.
- Inference services answering a user in real time cannot wait.
- Model training can usually absorb a few hours of delay.
- Batch data processing and backups can move to the middle of the night.
- Experimental jobs can be stopped entirely and resumed later.
Once that distinction exists, what you have is a buffer. When the grid is strained, work in the second and third groups is slowed while services in the first are untouched.
Which jobs can wait how long
For flexibility to work, the distinction has to be fine rather than coarse. "Training waits, inference does not" is a good start but insufficient on its own.
Training jobs differ among themselves. A training run with checkpoints, able to stop and resume, can absorb a few hours with no loss at all. A run without checkpoints starts over when stopped, and there flexibility produces loss rather than gain.
The same distinction exists on the inference side. Inference behind a user's screen is immediate, but an overnight batch classification job is also inference, and it can wait for hours.
How the signal arrives
The system needs a communication channel between the grid and the data centre. The utility sends a signal about grid conditions, and the orchestration layer at the data centre receives it and adjusts the flexible loads.
In the trial described, that loop ran without manual intervention. The team watched on screen and cheered when the reduction appeared; but the process itself was automatic. In the trial it was applied across thousands of graphics processors at once and nobody changed a setting by hand.
| Step | Who does it |
|---|---|
| Grid condition signal | The utility |
| Interpreting the signal | Orchestration layer |
| Slowing or deferring loads | Automatic |
| Maintaining critical services | Automatic |
The signal itself is not uniform either. In some markets notice comes in advance and the facility can prepare; in others the request is immediate and reaction time is measured in minutes. The second case makes it essential that load management is already in place.
The contract side
Even with the technical setup ready, switching flexibility on is a matter of signature. Because the work being slowed belongs to someone, and that person has to know about it.
- For internal use the decision is easy: the workload owner and the facility owner are the same company.
- In rented capacity a defined service level has been promised to the customer.
- Flexibility cannot be applied without being written into that promise as a separate clause.
- In exchange, a discounted price is usually offered.
The last item also explains how this model spreads. The customer gets cheaper capacity, the facility earns the right to flex at peak, and both sides gain; the only condition for it to work is that which job can wait how long is written into the contract.
The hard part: classification
This is where the technology is less easy than it looks. For a data centre to flex its loads, it first has to know how long each job can wait.
In most organisations that information is not written down. Jobs enter queues and all run at the same priority; the knowledge that "this one can wait two hours" usually lives only in the head of whoever wrote it.
So while flexibility looks like an energy project, it is really an inventory project. There is no point building a system to receive signals without classifying the workloads.
How many megawatts can be flexed
The figure varies by facility and quoting a single percentage would mislead. Still, the arithmetic is simple.
Whatever share flexible load holds in total consumption is roughly the share that can be given back at peak. If forty percent of a facility's load is deferrable training work, a serious portion can be released at the peak moment.
But not all of that share is usable. Some of the slowed work has to continue anyway and going to zero is rarely possible; the realistic target is a percentage reduction, not a full stop.
Who it works for
This approach does not produce the same value for every data centre. The benefit depends on the share of flexible load in the total.
- A facility mostly doing training has a wide flexibility window.
- A facility mostly running inference services has a very narrow one.
- Where mixed loads can be separated, the gain is meaningful.
- At single-tenant facilities the decision belongs to that tenant.
The last item draws an important boundary. In a rented capacity model the operator cannot slow a customer's work on its own judgement; that has to be defined in the contract.
Making that distinction also requires the data centre to know something about its own workloads. An operator who does not know what the servers are running cannot decide which job to slow.
What it means on the grid side
Seen from the utility, this is a kind of virtual capacity. A data centre able to shed 50 megawatts at peak produces value close to building a new 50 megawatt plant.
That is why in some markets flexibility is priced as a separate product. The data centre does not buy cheap electricity; it receives payment in exchange for committing to curtail demand at peak.
Pricing it that way turns a data centre from a passive consumer in the energy market into an active participant. The same facility both buys electricity and sells its capacity to flex.
Seen from a growing market
In markets where data centre investment is growing, this debate has not yet been framed this way. Demand-side participation is not, however, a new heading in grid regulation.
The practical conclusion: classifying workloads from the start in a new facility is far easier than doing it later. Changing the queue structure and prioritisation after they are established means rewriting a running system. In new facilities that cost is close to zero; in an operating one it is measured in months.
This model also changes the logic of grid planning. Once demand stops being a fixed input and becomes a negotiable variable, capacity is no longer calculated from the generation side alone.
The limits
Flexibility is a buffer, not a solution. As long as total demand keeps growing, peak management buys time but does not remove the need for capacity.
The second limit is the perception of reliability. Telling a customer "your job may sometimes slow down" is not an easy sentence on the sales side; how flexibility is written into the contract can therefore matter more than the technical side.
A third limit is technical: not every load can be slowed. Pausing a training job requires checkpointing, and that infrastructure is not ready everywhere; where it is not, the promise of flexibility stays on paper.
It does not work without measurement
A facility switching flexibility on has three questions to answer, and all three are answered by measurement.
- How much was shed at peak: shows whether the commitment was actually met.
- Were critical services affected: shows whether flexibility crossed its boundary.
- When did the deferred work complete: shows the operational cost of the delay.
- How many times did a signal arrive: allows the annual return of the model to be calculated.
The fourth item matters more than expected. The return on building flexibility infrastructure in a region that signals twice a year is entirely different from one that signals weekly.
Where to start
The first step at a facility is not measurement but classification. List the jobs that run and ask each one a single question: what happens if this is delayed by two hours?
Every job whose answer is "nothing" belongs to the flexibility pool. If that pool holds under ten percent of total consumption, the return on this approach does not cover the setup cost; above that, the number becomes worth discussing. Making that calculation does not require a new system either; a week of records from the existing job queues is usually enough.