Google signs demand-response deals with I&M and TVA to make ML workloads grid-flexible

From deferring a YouTube transcode to deferring ML jobs

Google says its first data center demand-response capabilities involved shifting non-urgent compute tasks — the post names processing a YouTube video as an example — away from hours when the grid is strained. Those capabilities have run through partnerships with Centrica Energy and transmission operator Elia in Belgium, and with Taiwan Power Company in Taiwan.

The two new agreements, with Indiana Michigan Power (I&M) and the Tennessee Valley Authority (TVA), extend that same idea to a harder category of work. Google states plainly that these deals 'represent the first time we're delivering data center demand response by targeting machine learning (ML) workloads.' The precedent is a demonstration with Omaha Public Power District, where Google reduced ML-associated power demand during three grid events last year.

That progression matters because ML training and batch inference are among the largest and fastest-growing loads in a modern data center. Making those jobs schedulable against grid conditions is a different problem than deferring a video encode, and it is the specific capability Google is now committing to under contract.

The product is a classification of which jobs can wait

Underneath the utility language, the actual engineering claim is a scheduling one. Demand response only works if a system can reliably sort compute into what must run now and what can be shifted or reduced 'during certain hours or times of the year,' as the post puts it.

Google frames flexible demand as something that 'can be deployed quickly, helping bridge the gap between short-term load growth and long-term clean energy solutions.' In practice that speed comes from software: the ability to pause, throttle, or relocate ML jobs on signal from a grid operator. The utility agreement is the contract; the classifier that decides what is deferrable is the mechanism.

A hard reliability boundary drawn around user-facing services

Google is explicit that this flexibility has ceilings. It writes that 'there are limits to how flexible a given data center can be, since high levels of reliability are critical for services like Search and Maps, as well as Cloud customers in essential industries like healthcare.'

Incorporating ML workloads is an important step to enable larger scale demand flexibility, delivering grid reliability and cost-saving benefits in the places where these capabilities are deployed.Montana Labs

That sentence draws the operational line clearly. Latency-sensitive, user-facing traffic — the frontend that people directly interact with — stays fixed. The deferrable capacity comes from background ML work. Demand response scales precisely because ML jobs sit on the tolerant side of that boundary, not because Google is willing to slow down Search.

What contracting flexible ML load signals for grid-aware scheduling

The concrete implication of these I&M and TVA agreements is that Google is treating deferrable ML compute as a negotiable grid resource, not just an internal efficiency lever. I&M's Steve Baker describes load flexibility as 'a highly valuable tool' for serving Google's new Fort Wayne data center, tying faster interconnection of large loads to Google's willingness to reduce demand on request.

Google is candid that this is early and location-specific: flexibility 'will only be available at certain locations,' and it names new generation and transmission investment as part of the same portfolio. But the structural point is that the split between urgent user-facing services and shiftable ML work is now written into utility contracts. For teams running large ML fleets, that reframes job scheduling as something with a value not only in cost and throughput but in grid commitments — and it puts a premium on knowing exactly which workloads can safely be told to wait.