Same Power, More Compute

This is the first post in a series on Demand Management at Fluidstack. It covers why power oversubscription matters and what it takes to make it safe. Later posts will dive into the telemetry and topology systems that make Demand Management possible.

Across North America, the queue for power is quickly becoming the queue for compute.

NERC’s latest long-term assessment forecasts 224 gigawatts of additional summer peak demand over the next decade, with new AI data centers accounting for most of the increase. In Texas, ERCOT says it is tracking roughly 438 gigawatts of large-load requests – nearly 89 percent from data centers – and has begun reviewing large connection requests in batches to determine which projects the grid can support and what upgrades they require.

Whether power capacity comes through grid expansion, on-site generation, or new facilities, adding it usually takes longer than deploying another generation of compute. Demand Management offers another lever: getting more compute from every fixed megawatt. To understand how, we must start with a useful property of AI infrastructure – its workloads rarely reach peak power simultaneously.

Peak IT is not simultaneous power

AI systems are designed around a peak power number, but they rarely consume it continuously. Training moves through compute, communication, checkpointing, and data movement. Inference rises and falls with traffic. Even identical hardware can draw differently because models and execution phases differ. A facility must support the fleet’s demand at any point in time, but not necessarily every device’s theoretical peak added together.

Consider a site with a firm 30-megawatt limit. Conventional design caps installed peak IT capacity at 30 megawatts, assuming every accelerator could draw its peak power at once.

Let’s say instead that we were to deploy 40 megawatts of peak IT capacity across two workload groups, each capable of drawing 20 megawatts at its peak. Conventional design would reject this configuration – if both groups peaked simultaneously, demand would exceed the site’s rated capacity and risk tripping protective breakers. In practice, however, if their high-power phases do not coincide, their aggregate consumption can remain below the site’s 30 megawatt limit.

That separation creates additional capacity – but it cannot be assumed. If the peaks begin to align, the system must reduce demand before the facility crosses its limit. Deploying more peak IT capacity than the facility could support simultaneously is called power oversubscription.

Demand Management is the system we are building at Fluidstack to make this safe and deployable. It ensures that actual consumption is within the facility’s safe operating limit by continuously measuring facility conditions and actively controlling demand when workload peaks begin to align.

Variability is useful only when it is controllable

Oversubscription means the site now operates closer to the facility’s protective limits. If telemetry is wrong or control reacts too slowly, protective breakers may trip and take equipment offline – the system must act before protection does.

The facility needs an authoritative, live limit for the power and cooling its active equipment can support. This limit can change after a transfer to backup generation, cooling alarm, component failure, or maintenance operation. The system must compare aggregate demand against the current boundary and act before it crosses it.

The workload response must be equally concrete. We need to know how much consumption a scheduler can remove, how quickly it can respond, what happens if the first action is insufficient, and which fallback remains safe if the control path is unavailable.

The solution crosses the facility boundary

Demand Management depends on three preconditions.

First, the facility must be designed for the intended deployment. The busway, protection, cooling distribution, and control sequences must support the hardware that will actually be installed. Software cannot recover capacity from a component that was never sized to carry it.

Second, EPMS and BMS systems, exposed through facility APIs, must provide trustworthy telemetry: current power, thermal conditions, equipment state, and alarms with enough completeness and freshness for automated decisions.

Third, an accurate topology model must connect equipment to its current electrical and mechanical constraints in a form software can consume. It must remain synchronized with the facility as power paths and equipment states change to ensure loads are accurately mapped to their serving power and cooling equipment.

Together, those preconditions enable a closed control loop – observe the facility, understand the active constraint, calculate a safe limit, communicate it to the scheduler, and verify that demand changed.

The hard part is proving the loop

Demand Management appears trivial when utilization is low. However, things start to get interesting when several things change together: a training run enters a power-intensive phase, inference traffic rises, a cooling component alarms, and an electrical transfer changes the active path.

The system must calculate the new boundary and confirm the workload response quickly enough to remain safe. If any link in the chain is unavailable, it must fall back to a known limit rather than extrapolate from incomplete state.

That is why the next two pieces in this series focus on how we built our telemetry and topology systems. Before we can manage demand, we must trust the signals arriving from the on-premises facility that may still be changing beneath us. Then we must represent the facility so software can reason about capacity, redundancy, and failure.

Without Demand Management, peak IT deployment stops at the site’s conservative power boundary. With it, Fluidstack can leverage workload diversity to deploy a larger fleet while actively enforcing the same physical limit.

Fluidstack is building the infrastructure for abundant intelligence. Demand Management helps make that possible by letting us safely deploy and operate more compute with the power already available.