AI Workload Power Density Forecasting for Campus Capacity Roadmaps

AI workload growth is a density problem before it's a power problem. The rack has become the unit that decides everything else, and campus capacity roadmaps that still start with headcount forecasts or square footage are working from the wrong end of the equation. Get the density forecast wrong and every downstream number, power, cooling, structural, follows it off a cliff.

The density numbers that campus planners are working against

The hardware roadmap is the density roadmap, full stop. NVIDIA now ships a new data center GPU architecture on a cadence that resets the power envelope roughly every year, with bigger jumps every two years and Ultra refreshes in between. Each jump changes what a rack draws, and the changes are not small.

GB200 NVL72 already pulls 120 kW per rack. That's the standard unit of purchase for frontier AI clusters right now, not some future edge case. Vera Rubin is slated to push that to 246 kW. NVIDIA's roadmap points to rack densities exceeding 300 kW by 2026 and surpassing 600 kW by 2027 with its Rubin Ultra platform. Google's Project Deschutes has already demonstrated a 1 MW rack, made possible by direct-to-chip liquid cooling alongside advanced power delivery.

Average rack density went from about 7 kW in 2021 to 16 kW in 2025, according to AFCOM's State of the Data Center report. It's projected to hit 27 kW in 2026. It's a curve bending sharply upward. It's a curve bending upward fast, and the curve, not raw server count, is what strains power budgets and cooling loops now.

Only one in five operators, per that same report, say they're ready to support the 50 to 70 kW racks that AI deployments already need. That gap, between what planners assumed and what showed up on the loading dock, is behind most of the mid-project redesigns happening across the industry right now.

GPU-level behavior makes the picture worse. Individual GPUs in modern AI workloads draw 300W to 1,200W, and power swings at the rack level exceed 132 kW/s on GB200 NVL72 systems. Those aren't steady loads. Power swings that fast are fundamentally different from the steady loads that traditional planning assumptions were built around.

Hyperscaler average rack density is around 36 kW today, headed toward 50 kW by 2027. But hardware shipping right now already runs two to three times higher than that average. The average has been playing catch-up with deployed reality for years, and nothing suggests that gap closes soon.

None of this means every rack in a facility runs hot. It means the average is hiding the real design problem. A campus running AI training alongside inference and legacy enterprise workloads has a bimodal density distribution, not a single number to plan against. The rack itself, not the server, is now the atomic unit of procurement, since frontier systems ship as complete NVLink domains occupying a full cabinet. Planners who keep reaching for one average kW/rack figure are modeling the wrong thing. What matters is the mix of densities those racks represent, and how that mix shifts as hardware generations turn over underneath the facility.

How AI workload growth translates into campus-level power demand

Zoom out to the grid level and the scale gets hard to picture. Global active data center IT power capacity is set to grow from 24.4 GW in 2025 to 147.1 GW by 2035, according to ABI Research. That's roughly sixfold in a decade, and AI accounts for most of the new capacity.

AI-dedicated active capacity hits 11.5 GW in 2026 and climbs to 43.6 GW by 2031, the point at which AI workloads overtake legacy compute in total active power draw. Training compute for frontier models has grown at something like 4 to 5 times a year since 2010, and the biggest individual training runs now pull past 100 MW. That load doesn't spread evenly across a campus. It sits concentrated in one or two halls.

xAI's Colossus cluster in Memphis runs roughly 200,000 H100 and H200 units drawing nearly 300 MW. Meta's Prometheus project, expected in 2026, is a 1 GW supercluster built for up to 500,000 GPUs. OpenAI's Texas facility is among the large-scale AI campuses being developed with ambitions toward gigawatt-scale power capacity.

Supply isn't catching up, and pretending otherwise is the mistake. Even assuming every announced project lands on schedule, the US faces a projected shortfall of more than 15 GW by 2030, driven almost entirely by AI-ready capacity demand. Campus power budgets built off historical utilization curves miss this completely, because the load is concentrating in specific halls rather than spreading out the way old models assumed. It's landing hard in specific halls, with power profiles nothing in the legacy data center world prepared operators for.

Why the traditional build-as-you-grow model fails for AI campuses

The old playbook made sense for a slower world. Add a pod once utilization crosses a threshold. Order transformers a year ahead of need. Lease more space once demand signals firm up. That worked fine as long as the variables held still long enough to react to them. The variables no longer hold still long enough to react to them.

Three things are breaking that model at once, and none of them are getting better on their own.

Lead times have blown past planning horizons. Power transformers that used to take 6 to 8 months now take 3 to 4 years. Wood Mackenzie projects a 30 percent supply deficit for transformers in 2025, with conditions expected to worsen before they improve.

Utility interconnection now often takes longer than construction itself. In several major US markets, securing new power capacity runs 3 to 4 years, and power availability constraints are already stretching overall construction timelines by 2 to 4 years, in some markets by as much as 6. Meanwhile hardware turns over faster than infrastructure cycles ever assumed it would. With a new GPU architecture landing roughly every year, the power and cooling envelope a facility was built around can be outdated before the concrete cures.

Stack those three together and long-lead procurement stops being a scheduling detail. It becomes a genuine risk to the whole project. If a change order revises the one-line diagram after transformers and liquid-cooling equipment are already committed at 12 to 18 month lead times, that's not a cost overrun. That's a schedule gap with no straightforward workaround.

Incremental planning under these conditions produces one of two bad outcomes: infrastructure that doesn't match the hardware that actually shows up, or facilities left underprovisioned for the density arriving next generation. Neither is acceptable at the capital scale AI campuses run at now. Utility power, liquid-cooling loop capacity, and GPU roadmaps need to get treated as one interconnected system starting at site selection, not bolted together after the fact. Density forecasting has to happen before the site is picked.

Structuring a kW/rack forecast that accounts for hardware generation turnover

A forecast that actually holds up blends two things most planning processes still keep separate. Top-down demand forecasting looks at model roadmaps, training schedules, and the mix of workload types planned for the facility. Bottom-up hardware trajectory analysis looks at vendor platform roadmaps, specifically what rack power envelope will exist for the hardware generation deployed in year one, year three, and year five of the facility's life.

The forecast window needs to span at least two hardware generations. Transformer sizing, busway capacity, and liquid-cooling loop capacity all get committed today for hardware that hasn't shipped yet.

Model the distribution. A campus running AI training, AI inference, and legacy enterprise workloads side by side has a bimodal density profile, and an average kW/rack figure buries exactly the peak loads that drive electrical and mechanical design decisions. Treat the rapid power swings, that 132 kW/s figure on GB200 NVL72 systems, as a design input from day one rather than something UPS sizing discovers the hard way later.

Scenario planning built around hardware generations, rather than generic growth curves, is what gives a forecast teeth. Scenario A: current-generation hardware, GB200-class at 120 kW, at the planned rack count. Scenario B: next-generation hardware, Rubin-class at up to 246 kW, same rack count. Does the power and cooling design still close? Scenario C: the generation after that, with roadmap densities projected to exceed 300 kW and beyond. How much headroom is left in the campus design, if any?

NJFX shows what securing power ahead of design actually looks like in practice. The company completed a Basis of Design for a 10 MW high-density AI data hall, 8 MW of usable IT load, targeting a 1.25 PUE, backed by a utility load letter supported by a $3 million deposit, with power delivery targeted for the end of 2026. The utility commitment came before the design was finished. Power first, design second, is the reverse of how campuses have traditionally been built, and it's becoming the norm rather than the exception.

None of this is a one-time exercise. Vendor roadmaps update, workload mix shifts, and every major procurement gate is a natural point to revisit the numbers.

How density forecasts cascade into power, cooling, and phasing decisions

Everything downstream traces back to the kW/rack number, multiplied by rack count and broken out by density tier. Power path sizing, utility service size, substation capacity, transformer ratings, busway and PDU specs, UPS ratings, all of it derives from the forecast. Every one of those is a long-lead item, and none of them can be revised late without blowing up both schedule and budget.

Cooling topology is where the density number becomes impossible to dodge. Air cooling hit its practical ceiling around 40 kW per rack with the H100 generation, per CUDO Compute's analysis. Anything at GB200-class density, 120 kW and up, needs liquid cooling. There's no version of that design where air alone works. That shift toward liquid-dominant cooling configurations carries a real cost: liquid-cooled facilities run 7 to 10 percent higher on construction cost than equivalent air-cooled builds, per Turner & Townsend's Data Centre Construction Cost Index.

Facilities that weren't designed for AI density from the outset face mechanical retrofit costs of $200 to $400 per kW, which works out to $10 million to $50 million on a mid-size build. Cooling now accounts for 43.2 percent of mechanical infrastructure spending as of 2024, the single largest line item in the budget, and density drives all of it.

PUE tells the efficiency story on its own. Direct-to-chip liquid cooling gets facilities into the 1.10 to 1.20 PUE range, against 1.55 to 1.67 for legacy air-cooled builds. For an operator working within a fixed utility allocation, every megawatt saved on cooling overhead is a megawatt of extra compute capacity that didn't require waiting on new grid power.

Phasing looks different too. Traditional buildouts spread commitments over time in smaller increments. Many AI campuses now deploy in large, tightly synchronized jumps, infrastructure and compute activating together instead of infrastructure running ahead and waiting idle. The density forecast decides whether one big infrastructure commitment or a staged rollout actually fits the power activation and procurement timeline on hand.

Structural loading deserves its own line item too. Racks above 40 kW force a hard look at floor loading assumptions, since liquid-cooling manifolds, CDUs, and rear-door heat exchangers concentrate weight in ways standard raised-floor designs weren't built to handle.

The campuses performing best going into 2026 start with a full AI infrastructure brief, power density, cooling strategy, structural loading, connectivity, security zoning, before anyone sketches a floor plan. The density forecast is what makes that brief possible in the first place.

The grid constraint as a hard planning boundary that density forecasts must respect

Writing in DCD in July 2026, Schneider Electric's Vance Peterson framed the job for AI infrastructure teams as squeezing the most AI capacity out of whatever power is actually obtainable. That's a real constraint on the design, not a rhetorical flourish.

Global data center electricity demand is projected to reach around 132 GW in 2026 and climb toward 290 GW by 2030, according to Gartner, with AI-optimized servers driving most of that growth. The IEA projects total data center electricity consumption roughly doubling, from about 485 TWh in 2025 to around 950 TWh by 2030, putting data centers close to 3 percent of world electricity demand.

In the US, the EIA estimates data center servers made up roughly 7 percent of commercial sector electricity use in 2025, a share projected to climb to somewhere between 22 and 33 percent of commercial building electricity use by 2050 across the Annual Energy Outlook cases. Utility interconnection policy is already shifting in response, and slowly at that.

Interconnection queues remain the binding constraint in practice. In several major US markets, new power capacity takes 3 to 4 years to secure, longer than it takes to build the facility itself. So the density forecast has to work backward from whatever power envelope is actually available, not forward from some idealized compute target that assumes the grid will cooperate.

Liquid cooling matters here for a second reason beyond heat removal: it stretches a fixed power allocation further. Cutting PUE from the 1.55 to 1.67 legacy range down to 1.10 to 1.20 means more AI racks running on the same utility allocation. Any serious density forecast has to model both the raw compute requirement and the cooling-efficiency scenario that makes that requirement achievable within the power actually on offer.

On-site generation, microgrids, small modular reactors, is entering planning conversations as grid access gets harder to secure on any predictable timeline. Whatever power source ends up anchoring a campus, its reliability and capacity characteristics belong in the density forecast alongside the utility grid connection itself, not treated as a backup plan bolted on afterward.

What connected design automation makes possible in a density-first planning workflow

Density-first planning only works if the power, cooling, and structural models actually talk to each other in real time, as assumptions change. A forecast that lives in a spreadsheet, cut off from the one-line diagram and the mechanical layout, goes stale the moment a vendor updates a roadmap or a workload mix shifts.

Connected design automation closes that gap. When a change to the kW/rack forecast, say, moving from a GB200-class assumption to a Rubin-class one, propagates automatically through the electrical model, the cooling topology, and the structural loading calculations, planners see the downstream consequence immediately instead of discovering it during a change order review eighteen months into construction.

That kind of connected workflow also makes scenario testing something planners actually use day to day, built into the life of a project rather than confined to its start. Running Scenario A, B, and C against the same campus model, and seeing exactly where the power and cooling design breaks, turns hardware generation turnover from a source of dread into a planning input checked at every procurement gate.

The payoff appears most clearly at the moments that used to cause the worst damage, such as the late-stage change order, the transformer spec locked in before the rack density assumption was finalized, and the cooling loop sized for a generation of hardware that never shipped. A density-first workflow, backed by design tools that keep every discipline synchronized against the same forecast, doesn't make the uncertainty in AI hardware roadmaps disappear. It just makes sure the campus can absorb that uncertainty without a schedule collapse every time NVIDIA or another vendor announces the next generation.