TL;DR
- Grid operators pay large power users to cut their draw through demand response programs. A GPU fleet usually cannot take that money, because cutting power to a running GPU destroys the work on it.
- Capping how much power the cards draw and holding back work that has not started need nothing saved, but they give you only a shallow cut.
- Two field trials, one in Phoenix and one in London, cut a GPU cluster's power on a grid signal without killing the job that was running. The deeper cut, stopping jobs and powering GPUs down, needs the job's state written down first.
- In this piece we walk through what a demand response event asks of a GPU fleet, what the two trials cut, and what they never say about the money. Then we cover which work can flex, and what a fleet needs before it can offer the deep cut.
A demand response event asks for a measured cut, and checks the reduction afterwards
A demand response event begins when something tells the cluster to cut its power, and two field trials, one in Phoenix and one in London, show what that looks like on a GPU cluster. In London, National Grid's signal told the cluster that an event had started, and in Phoenix, the arrival of the peak demand period did the same. What the program asks for is a reduction measured against the power the cluster would otherwise have drawn, and the cluster has to hold that reduction for a stated length of time. Afterwards the response is checked against the target, and in London against the ramp rate as well, meaning how fast the draw came down.
Neither trial sets a standard for anyone else, because these were the terms two particular programs asked for, and they tell you nothing about what a third utility would want.
Neither trial says what the flexibility is worth
Grid operators pay large power users to make cuts through demand response programs, but neither write-up says what they paid. Both report what the cluster was asked to do and whether it did it, and nothing more. So if you want to know what a cut is worth on your own site, the money is a question for the utility on the other side of the contract: it can come back as a payment for curtailing on command, or as a better price on a flexible interconnection agreement, the kind where you agree to cut your draw when the grid asks.
In both trials, the power came out of work that could wait
Both trials ran through EPRI's Datacenter Flexible Load initiative, DCFlex, and they differ in almost everything else: the hardware, the size of the cut, the length of the event, and the work that flexed.
| Phoenix | London | |
|---|---|---|
| Partners | Emerald AI, with Oracle Cloud Infrastructure, NVIDIA, and the regional utility Salt River Project | Nebius, National Grid, and Emerald AI |
| Cluster | 256 GPUs, built on NVIDIA A100 Tensor Core GPUs | More than 200 NVIDIA Blackwell Ultra GPUs, about 130 kW, roughly the draw of 400 UK households |
| Reduction | 25% against the average base load during the peak demand period | Up to 40% during grid events |
| Duration and scope | 3 hours of sustained reduction per event, across 33 experiments of 3 to 6 hours each, covering 212 individual jobs | 5 days in December 2025, testing more than 200 simulated grid event notifications |
| Verification | The reduction held during peak grid events while the cluster kept its AI quality of service guarantees | 100% compliance with all requested power targets and ramp rates |
| Work that flexed | Batch-style training, fine-tuning, and inference tasks | Training workloads, including GPT-OSS, Llama, and Qwen models |
The Phoenix trial is written up in a preprint on arXiv titled "Turning AI Data Centers into Grid-Interactive Assets", posted in July 2025, and the software that ran the reduction was Emerald AI's Emerald Conductor. The Register reported the London trial.
Phoenix did not flex everything on the cluster: real-time inference, streaming, and model serving were not modified, so the whole 25% came out of the batch-shaped work. London ran commercially representative AI training workloads, meaning training runs rather than live traffic. The mix of work on your site therefore sets how much of your load you can offer, and a cluster mostly serving live traffic has less to give than one running training and batch work.
Work stopped to free power has to survive the stop
Neither cluster freed power by destroying work: Phoenix slowed or paused its batch jobs, and London paused them, deprioritized them, or moved them to a later time, so in both cases the work was still there when the event ended.
Slowing a GPU down and holding back work that has not started yet both need nothing saved, because no job that is already running is stopped. Phoenix slowed its GPUs by capping how much power the card is allowed to draw, which cuts the draw while the job keeps running. Both moves give a shallow cut.
The deep cut means stopping work that is already under way, by stopping a job outright, moving it onto fewer GPUs, or taking the power off the GPUs, and each of those needs the job's state written down first. The Phoenix paper says so directly: pausing and reallocating "require checkpointing for training jobs to ensure forward progress".
The state of a running GPU job, meaning everything it has built up since it started, lives in the GPU's memory, and it goes when the power goes. So without a saved copy of that state, the stop costs the run, and the job starts again from the beginning. That is why a fleet whose only way to free power is to kill a job chooses between the payment and the work every time a signal arrives.
Saving the full state of a running job so it can be brought back later is called checkpointing. Cedana's GPU power curtailment path, as designed, runs in four steps.
- Take heartbeat checkpoints continuously during normal operation.
- On the curtailment signal, checkpoint the workloads with the longest time since their last checkpoint first.
- Power down the GPUs.
- Resume everything when power returns, as of each job's last checkpoint.
Jobs that have gone longest without a save are the ones a power-down would cost most, so they are saved first while the clock runs. What the power-down costs you, then, is whatever each job computed since its last checkpoint.
Our stated design target is a 10-minute curtailment window with no advance warning, and it follows from the first step. Every workload is already checkpointed on a heartbeat, so the fleet needs no notice to start from a recent saved state. That is what we build to, and no field trial has measured it.
A grid signal is one more unscheduled stop, and the only one somebody pays for
A node fails, a maintenance window opens, or a higher-priority job takes the GPUs, and none of those stops asks your fleet first, so the need for a recent saved state is not particular to the grid. A fleet that answers those everyday stops by checkpointing continuously has a recent saved state whenever one arrives, which is already what a demand response program is asking for.
A site that cannot pause and resume its work is left with the shallow cut. You can still cap power and hold back work that has not started, but stopping running jobs and powering GPUs down is the cut you cannot offer. So you bring less reducible capacity to a demand response program or to a flexible interconnection agreement, and more of your power has to come from a firm connection, which is slower to get and costs more. Power then stays the binding constraint on how much the site can grow.
That constraint assumes a data center can only ever be a load on the grid. Steve Smith, president of National Grid Partners, said the London trial shows otherwise.
"This trial proves the opposite can be true. High-performance datacenters don't have to place additional strain on the grid."
A fleet that can save its running work and bring it back has turned a grid signal into one more stop it already knows how to take. Cedana is automated GPU checkpointing and migration infrastructure that increases the useful work your GPUs deliver. Here that means the same continuous checkpointing that brings a job back after a node fails is what lets a fleet power its GPUs down when the grid asks and pick the work up when the power returns. How much of your load you can put behind that depends on the mix of work on your own cluster.
Common questions
Could a data center actually flex or curtail its compute load in response to a grid signal or utility rates, or does that just mean killing whatever job is running?
A data center can flex without killing the job, and two field trials show it. In Phoenix and in London, a GPU cluster cut its power on a grid signal or a peak demand period without killing the job that was running, by slowing GPUs down, holding back work that had not started, or pausing running jobs. Capping power and holding back work give you a shallow cut and need nothing saved. The deep cut, stopping a running job and powering the GPUs down, needs the job's state written down first, which is what checkpointing does. Neither trial sets a standard for what any other utility or grid operator will ask for.
