Data center power capping and oversubscription field guide

Power capping and oversubscription, and why AI dragged both back to center stage

Power capping and oversubscription are the two levers that let a data center pack more compute into the same installed power. Capping limits how much a server, a rack, or a row is allowed to draw, holding it under a set budget. Oversubscription provisions more nameplate IT than the power chain could actually serve if every box pulled its worst case at once, betting that they never will. They are different tools that solve the same problem from opposite ends, and they work together: the cap is what makes the oversubscription bet safe to take.

Both ideas are old. Servers have run below nameplate for as long as there have been servers, and operators have packed rooms against that gap for almost as long. What changed is the load. AI GPU training and inference draw power in violent, synchronized swings, a rack jumping a large fraction of its load in milliseconds with thousands of GPUs stepping together, and that behavior breaks the quiet statistical assumption that oversubscription has always rested on.

So the discipline came back to the front of the room. Doing this safely now means real metering per rack and per circuit, a capping policy that actually enforces the budget, headroom held back for the spike, and protection coordinated so a synchronized surge never trips the breaker that drops the job. The power density and capacity planning guide covers sizing the kilowatts per rack, and the stranded capacity guide covers reclaiming the power those caps free up. This guide is about capping the draw and provisioning past the worst case without tripping anything.

What is power capping?

Power capping is a hard limit on how much power a device, a rack, or a row is permitted to draw, enforced in firmware and software so the load throttles before it exceeds the budget rather than after. Set a node cap at 6 kW and the management layer pulls back clock speeds and power states to hold the draw at or under that number, trading a slice of performance for a draw the operator can count on.

The point of the cap is predictability. An uncapped rack can draw whatever the gear demands at the moment, which means the operator has to provision for the worst case the equipment could ever produce. A capped rack draws no more than its budget, so the operator can plan the floor, the feed, and the cooling around a known ceiling instead of a nameplate guess.

Capping happens at several tiers and they stack. A per-GPU limit holds the accelerator under a watt figure. A node or chassis cap holds the server. A rack or row cap holds a group, redistributing budget among the nodes under it. Google has described a power capping service coordinating caps across very large sharing domains, tens of megawatts of equipment, which is the same idea scaled from the chip to the room.

What is power oversubscription?

Power oversubscription is provisioning more nameplate IT load onto a power path than that path could carry if everything ran at its worst case at the same moment. A 1 MW feed might be sold or filled with 1.3 MW of nameplate gear, on the reasoning that the actual aggregate draw never reaches the sum of the parts. The ratio of provisioned nameplate to installed capacity is the oversubscription ratio, and a higher ratio packs more compute behind the same megawatts.

The behavior that makes it work is statistical multiplexing. Any one server peaks now and then, but a large group of servers is unlikely to peak together, so the aggregate sits well below the sum of the individual maxima. A research framing of it is plain: oversubscription is possible because of the low likelihood of simultaneous peak operation across many servers. The more independent the loads, the wider the gap between nameplate and real aggregate, and the more you can safely provision into it.

The gain is real and so is the risk. Done right, oversubscription turns the reservation gap that would otherwise sit idle into delivered compute, the same gap the stranded capacity guide treats as money on the floor. Done wrong, on a bet that does not hold, the aggregate draw climbs past the installed capacity and something upstream has to give. The cap is what keeps that from happening, which is why the two tools belong together.

Capping versus oversubscription: related, different, and paired

These get conflated, and keeping them straight is the start of doing either one well. Oversubscription is the bet: you provision more nameplate than the installed power could serve flat out, wagering that diversity keeps the aggregate under the limit. Capping is the enforcement: you set a hard ceiling on the draw so that even if the bet starts to fail, the load throttles before it overruns the capacity. One commits the capacity. The other guarantees the commitment is safe.

Run oversubscription without capping and you are gambling with nothing backing the bet. The day a workload pattern lines up and the loads do peak together, the aggregate sails past the feed and the protection trips, dropping every job on that path. Run capping without oversubscription and you have left the gain on the table, holding a hard ceiling on racks you provisioned conservatively anyway.

The working pattern pairs them. Provision the floor at an oversubscription ratio the diversity supports, then cap the racks and the rows so the sum cannot exceed the installed capacity even under a synchronized surge. The cap converts a statistical bet into a bounded one. Set the ratio with the cap in mind, and set the cap with the ratio in mind, because each one sizes the other.

Why is AI power so spiky?

AI power is spiky because GPU compute is bursty by nature, swinging from near idle to full draw and back in milliseconds as the workload moves through its phases. A GPU running a training step pulls hard during the compute, then drops while it waits on communication between accelerators, then pulls hard again on the next step. The result is a sawtooth of large, fast power transients rather than the steady plateau a traditional server presents.

The amplitude is what makes it a facilities problem and not just an electrical curiosity. A dense AI rack can swing a large fraction of its load in a few milliseconds, and the gear feeding it, the rack PDU, the busway, the UPS, and the upstream transformer, sees every one of those swings. Vendor and operator writeups through 2025 and 2026 describe exactly this: rapid power consumption changes on GPUs that stress transformers, UPS systems, and PDUs, and can trip upstream protection when the peak amplitude was underestimated.

This is the part to lead with, because it inverts the old assumption. A traditional enterprise floor was easy to oversubscribe precisely because its loads were smooth and uncorrelated. AI loads are neither. They are spiky at the rack and, as the next section covers, synchronized across the cluster, and that combination is what forced capping, headroom, and protection coordination back to the front of every dense build. Treat the millisecond swing as the design event, not an edge case.

The synchronized swing: when the whole cluster steps together

The spike at one GPU would be manageable if every GPU spiked at a random moment, because the swings would average out across the rack the way ordinary server loads do. They do not. Large-scale training runs in lockstep: thousands of accelerators execute the same step, hit the same communication barrier, and ramp power up and down together, so the individual sawtooths add up instead of canceling out. The cluster behaves like one enormous load switching on and off.

At scale the numbers get serious. Operators have described synchronized training swings reaching tens or even hundreds of megawatts at a site, fast enough that the same signature shows up at the rack, at the hall, and out at the utility interconnect. SemiAnalysis and others have raised the question of whether gigawatt-scale training loads oscillating in sync pose a grid stability risk, not just a facility one. The swing that starts at a chip ends up visible on the transmission line.

For capping and oversubscription this synchronization is the whole danger. Diversity, the assumption that loads do not peak together, is exactly what synchronized training destroys. The next section takes that head on, because it is the difference between an oversubscription bet that holds for a web floor and one that fails for an AI cluster.

What is the diversity assumption, and why does AI break it?

The diversity assumption is the belief that the loads sharing a power path do not all hit their peak at the same instant, so the aggregate draw stays well below the sum of the individual maxima. Every oversubscription bet rests on it. Research on the topic states it directly: the oversubscription you can safely take is limited by the diversity of the workloads in the sharing domain, and the wider the sharing domain, the more statistical multiplexing you get and the more you can provision.

For decades the assumption held comfortably, because mixed enterprise and cloud floors ran thousands of independent, smooth workloads whose peaks scattered across time. You could provision well past the installed capacity and watch the aggregate never come close, because nothing coordinated the loads. That is the floor oversubscription was invented for, and on that floor it is close to free capacity.

AI training breaks the assumption at the root. A synchronized cluster is the opposite of diverse load: every node peaks on the same step, so the peaks add instead of scattering, and the aggregate can approach the sum of the maxima the moment the run synchronizes. An oversubscription ratio that is safe on a diverse floor can be dangerous on an AI cluster, because the diversity the bet was priced on is not there. This is the single most important shift in the field, and it is why a cap and real protection have to back any oversubscription on synchronized load. Size the bet to the diversity you actually have, and assume an AI training cluster has very little.

Nameplate versus actual: provisioning to the real load

Oversubscription only makes sense against actual measured load, not against nameplate. The nameplate on a power supply is the worst-case maximum the device could ever pull with everything spinning, and ordinary equipment almost never runs there. Actual draw commonly lands somewhere between roughly 20 and 85 percent of nameplate depending on the workload, so a server with a 1,200 VA nameplate might pull 400 to 700 W in service. Provisioning to nameplate reserves power that never gets used and strands it across every rack, which the stranded capacity guide covers as the largest single block of trapped power on most floors.

Oversubscription is, in one sense, the deliberate decision to provision to the actual load instead of the nameplate sum, and to fill the gap between them with real compute. The reservation that nameplate planning would have left idle becomes the room you pack into. That is why oversubscription and stranded capacity are two views of the same gap: stranding is the gap left empty, oversubscription is the gap deliberately filled.

The catch is that AI gear narrows the comfortable margin. A GPU under a synchronized training load runs much closer to its nameplate, and runs there in sync with its neighbors, so the old habit of assuming a deep gap between nameplate and actual is exactly the habit that gets a dense floor in trouble. Provision to the measured load, but measure the peaks and the synchronization, not just the average, because the average hides the swing that trips the breaker.

How does power capping work?

Power capping works by giving the management layer a knob on the actual draw and a target to hold it to. On CPUs the common mechanism is RAPL, Running Average Power Limit, the on-die feature that lets firmware set an average power ceiling the processor enforces by adjusting frequency and voltage. On GPUs the limit is set through the driver and the management interface: on NVIDIA gear, nvidia-smi sets a power limit in watts through the host, and an out-of-band path through the baseboard management controller sets the same ceiling without the operating system in the loop.

The baseboard management controller, the BMC, is the piece that matters for facilities, because it can enforce a cap on a node whether or not the host is healthy. A rack or row controller pushes budgets down to the BMCs, the BMCs hold the nodes, and the nodes hold the chips. The enforcement runs closest to the silicon, where the power management unit picks the most conservative active policy and throttles to hold it.

The number that decides whether capping protects you is latency. A cap reacts in some span of milliseconds to tens of milliseconds depending on the tier, the firmware, and the load, and a synchronized GPU swing can rise faster than that. A cap that reacts after the spike has already crested does not stop the spike. It only keeps the average down. The exact reaction time depends on the design and the equipment, so measure it on your gear, and read the next sections on why the cap alone is not the protection.

Dynamic and adaptive capping

A static cap is a fixed ceiling on every node, simple and safe but wasteful, because it holds back budget on idle nodes that a busy node next door could use. Dynamic capping moves the budget to where the work is. The management software watches the live draw across the sharing domain and shifts the per-node ceilings around in real time, tightening the cap on idle gear and loosening it on gear that is doing work, so the total stays under the domain budget while the active nodes get the most power the budget allows.

This is where capping stops being a blunt limiter and starts being a power scheduler. Done well, dynamic capping lets an operator run a higher oversubscription ratio safely, because the cap can claw back budget from quiet racks the instant a busy rack needs it, holding the aggregate flat even as individual racks swing. Google has described exactly this kind of priority-aware capping service coordinating multiple workload priorities on every node across a large power plane.

The limit on dynamic capping is the same latency problem as static capping, made sharper. Shifting budget across a domain takes a control loop, and a control loop has a reaction time. Against a synchronized swing that hits the whole domain at once, there is no idle neighbor to borrow from, because everyone spiked together. Dynamic capping smooths uncorrelated load beautifully and synchronized load poorly, which is the case AI presents. Plan for both, and do not assume the scheduler will save a synchronized surge.

Can a spike trip the breaker before the cap reacts?

Yes, and this is the failure that catches operators who trust the cap too much. A synchronized GPU swing can rise in a few milliseconds. A power cap, working through firmware and a control loop, reacts in a span of milliseconds to tens of milliseconds. If the spike crests faster than the cap can pull the load back, the draw exceeds the budget for the moments before the cap catches it, and a protective device upstream can see that overcurrent and trip while the cap is still reacting.

When the breaker trips, the job dies. Everything on that circuit drops, the training run loses its progress back to the last checkpoint, and the operator learns the hard way that the cap and the protection live on different clocks. The cap governs the average and the sustained draw. The breaker and the upstream protection respond to the instantaneous current. A cap set to a safe average does nothing about a transient that overshoots the trip curve for a few milliseconds.

This is the line to carry out of this guide: cap with protection, not instead of it. The cap is a budgeting tool, not a fast safety device, and treating it as the thing that keeps you under the breaker is how a synchronized surge takes down a hall. The protection coordination, the headroom, and the energy storage in the next sections are what actually catch the fast spike. The cap holds the average. Something else has to hold the millisecond.

Breaker coordination and the 80 percent continuous rule

The breaker is the line the draw cannot cross, and the cap has to be set with the breaker's behavior in mind, not the breaker's stamped rating. The NEC and UL convention treats a load running three hours or more as continuous and limits it to 80 percent of the breaker rating, so a 30 A circuit holds about 24 A of continuous IT load and a 20 A branch holds about 16 A. IT load is continuous by nature, which makes the 80 percent figure the working ceiling. Confirm it against the manufacturer's listing and the adopted code edition.

Set the cap so the sustained capped draw stays under that continuous limit with margin to spare for the transient on top. A cap parked right at 80 percent leaves nothing for the spike that overshoots before the cap reacts, and the breaker sees the overshoot. The cap and the protection have to be coordinated as a pair: the sustained budget under the continuous limit, and enough room above the budget that a synchronized swing does not push the instantaneous current into the trip curve.

Do not trust the cap alone to keep you under the breaker. The cap reacts on a control loop and the breaker responds to instantaneous current, so they are not the same defense and they do not protect the same way. Coordinate them deliberately, leave headroom between the capped budget and the trip point, and confirm the protective device's curve against the worst transient the load can produce. The breaker is the last line, and it does not negotiate.

Keep headroom for the spike

Headroom is the margin between the capped, provisioned load and the installed capacity, held back deliberately so the spike has somewhere to go. Oversubscribe to zero margin and the first synchronized surge has no room to rise into before it hits the limit. Hold headroom and the surge rides in the buffer instead of tripping the protection. This is the single most reliable defense against the AI swing, and it is the one that pure capacity math, chasing the highest oversubscription ratio, is most tempted to give away.

How much headroom is a judgment call that depends on the design, the equipment, and the load. A diverse, smooth floor needs little, because the aggregate barely moves. A synchronized AI cluster needs a great deal more, because the whole domain can swing at once and the buffer has to absorb that swing within the milliseconds before the cap and the protection respond. Size the headroom to the worst synchronized transient the workload produces, measured on the real gear, not to a number copied from a smoother floor.

The tension is honest and worth naming. Headroom is unfilled capacity, which looks like the stranded capacity the previous guide tells you to reclaim. The difference is that this margin is doing a job: it is the buffer that keeps a synchronized spike from dropping the job. Reclaim the capacity that is genuinely wasted. Keep the headroom that absorbs the swing. Meter the swing so you know which is which.

You cannot cap or oversubscribe what you do not meter

Capping and oversubscription both run on measured data, and without it you are guessing in both directions. To cap a rack you need to know what it actually draws, and at what speed it swings. To oversubscribe a path you need to know the real aggregate against the installed capacity, not the nameplate sum. The instruments are the metered and intelligent rack PDUs at the cabinet, the branch-circuit monitors at the floor PDU, and an electrical power monitoring system, an EPMS, watching the chain from the utility inlet down. The stranded capacity guide covers the same metering as the way to find trapped power.

For AI load the sampling rate of the metering matters as much as its presence. A meter that averages over seconds shows a smooth-looking load and hides the millisecond swing that trips the breaker. The synchronized transient lives below the resolution of slow metering, so an operator reading averaged data can believe the oversubscription is comfortable while the real peaks are brushing the limit. Meter fast enough to see the swing, or you are blind to the event that actually matters.

Metering is also how you set the oversubscription ratio honestly. The gap between the measured aggregate peak and the installed capacity is the room you have to provision into, and the gap between the capped budget and the swing is the headroom you have to hold. Both come from the meter, not from a spreadsheet. Meter first, fast, and per circuit, then cap and oversubscribe against what the meter says, because the meter does not guess and the nameplate always does.

Peak shaving: batteries and energy storage to absorb the spike

Peak shaving uses stored energy to cover the top of a power peak so the source never has to deliver it, and it is becoming a standard answer to the AI swing. A battery or other store charges during the low part of the load and discharges during the spike, so the surge is served from the store while the upstream feed sees a flatter, lower draw. The cap holds the average and the store absorbs the transient, which together keep the load the breaker and the utility see well inside the limit.

The energy-storage angle solves the problem the cap cannot, the fast swing. Battery backup units placed at or near the rack can cover the shortfall during a peak, and a growing class of them carries a peak-shaving function for exactly this duty, beyond ride-through for an outage. The same store that holds the load up during a utility blip can hold it up during a training-step surge, smoothing the swing that would otherwise stress the transformer and the UPS.

Match the store to the timescale of the swing, because that decides the chemistry and the placement. A synchronized training transient is a sub-second to seconds event, which is hard on a battery sized for minute-scale ride-through and easier on a high-rate cell or a capacitor bank built for fast discharge. The energy needed per swing is small but the power is large and the cycling is constant, so the store has to be rated for the rate and the cycle count, not just the capacity. Size it to the measured swing on the real gear, and treat the vendor headline figures as a snapshot of a fast-moving market.

Rack-level capacitors and the local buffer

The fastest swings are best caught closest to the load, which is pushing energy storage down to the rack and even into the shelf. Bulk capacitance on the rack bus absorbs the microsecond-to-millisecond transients that a battery a few tiers up is too slow and too far to catch, decoupling the swing locally so it never propagates to the rack bus and the power-sharing unit upstream. The capacitor handles the fast edge and the battery handles the longer plateau, each on the timescale it suits.

The hardware is arriving to do this on purpose. Vendors are developing rack shelves with capacitor backup units built around supercapacitors specifically to absorb fluctuations in the GPU power load, with production targeted for the next year or two, and high-rate battery cells aimed at sub-second response at rack scale. The emerging pattern is a hybrid local buffer: a battery for minute-level ride-through and a supercapacitor for the sub-second transient, sitting at the rack where the swing is born.

This is the layer to watch, because it changes the math on oversubscription. If the rack itself buffers its own swing, the synchronized transient that reaches the breaker is smaller, which means more of the diversity bet can be taken back safely. The local buffer does not replace the cap, the headroom, or the protection. It shrinks the spike they each have to handle, which is a different and welcome kind of help.

The utility side: demand charges and contracted demand

Capping and peak shaving reach past the building to the utility bill, because of how data center power is priced. A utility typically charges a commercial customer for the energy used and, on top of it, for the peak demand, the highest sustained draw in a billing period, often measured as the highest 15-minute average in the month. That demand charge is a per-kilowatt price on the single worst peak, and it can be a large share of the total electricity cost, with industry writeups putting the peak-related portion well into the majority on some bills. Treat those percentages as a snapshot that depends on the tariff and the operator.

This gives capping a second job beyond protection: holding the metered peak down to control the demand charge. A cap that flattens the aggregate, or a battery that shaves the top off the peak, lowers the number the utility bills against, and the savings can be substantial. Peak shaving has been described as cutting demand charges by something like 10 to 30 percent depending on the load and the approach, which again is a figure to verify against your own tariff and load shape.

There is a harder version on the supply side. A site may have a contracted demand or an interconnection limit, a hard cap on what the utility will let it pull, set in the agreement long before the racks landed. When that is the binding limit, capping is not optional and not just economics: the facility has to hold its aggregate under the contracted number or face penalties or a tripped interconnect. Cap to the contract, meter against it continuously, and treat the utility limit as one more ceiling the synchronized swing must stay under.

The performance-versus-capacity tradeoff

Capping is not free, and pretending it is leads to the worst version of it. A cap throttles the gear to hold the budget, which means a capped GPU runs slower than an uncapped one, and a job under a tight cap takes longer or delivers less. The trade is direct: a lower cap and a higher oversubscription ratio buy more density and more compute on the floor, at the cost of per-node performance. A higher cap protects performance and costs you density. There is no setting that gives both.

Where the trade lands depends on the workload's tolerance. Batch training that cares about total throughput over a long run can often absorb a modest cap with little practical loss, because a few percent slower over days is invisible against the capacity gained. Latency-sensitive inference and real-time work tolerate it far less, because the throttle shows up directly as slower responses and missed service targets. The right cap is workload-specific, and a single floor often carries both kinds of work.

The mistake to avoid is blind capping, a flat ceiling clamped across the floor with no regard for what each workload can tolerate. That destroys performance on the jobs that cannot absorb it while leaving capacity on the table from the jobs that could have been capped harder. The cap should be set per workload against its tolerance, which is exactly what the policy section covers. Cap to the trade you actually want, not to a number that looked safe.

Capping policy, priority, and QoS

A capping policy decides who gets throttled when the budget is tight, and a floor without one throttles blindly or not at all. The policy assigns priority to workloads so that when the aggregate approaches the cap, the management layer pulls power from the low-priority jobs first and protects the high-priority ones. A research and production pattern for this is priority-aware capping: the cap is enforced across the domain, but the throttle falls on the workloads that can tolerate it before it touches the ones that cannot.

This turns capping from a blunt limiter into a quality-of-service tool. A best-effort batch job and a latency-critical service can share an oversubscribed path safely if the policy throttles the batch job first, so the service keeps its performance until the batch job has given back all the power it can. The oversubscription ratio you can run climbs with a good priority policy, because the cap can protect what matters while reclaiming power from what does not.

Write the policy down and tie it to the actual workloads, because an unwritten policy is just whatever the firmware defaults to under pressure. Name which workloads are protected, which are throttled first, and what the cap and the headroom are for each tier. The policy is the difference between a cap that degrades the floor gracefully and one that degrades it randomly, and the only way the next operator can run it is if the priorities are recorded against the racks they govern.

How oversubscription recovers stranded capacity

Oversubscription, done right, is the deliberate reclamation of stranded capacity. The stranded capacity guide treats the gap between nameplate provisioning and measured load as the largest single block of trapped power on most floors, capacity that was built and paid for and left reserved against peaks that never come together. Oversubscription is the decision to fill that gap with real compute instead of leaving it empty, which is reclamation by another name.

The link runs both ways. Capping is what makes the reclamation safe, because it bounds the filled gap so a surge cannot overrun it, and metering is what reveals the gap in the first place, the same metering the stranded capacity guide uses to find trapped power. Provision to the measured aggregate, cap so the bet stays bounded, hold headroom for the swing, and the capacity that nameplate planning would have stranded becomes delivered work.

The discipline is the same on both sides. Reclaim the capacity that is genuinely wasted, the reservation gap, the imbalance, the zombie load. Leave the capacity that is doing a job, the redundancy reserve and the spike headroom. The difference between unstranding capacity and oversubscribing recklessly is whether the cap and the protection are there to bound the bet. With them, oversubscription un-strands the floor. Without them, it just moves the failure from idle waste to a tripped breaker.

Test the cap and the protection before production

A capping and oversubscription scheme is a set of assumptions about how fast the cap reacts, how the protection coordinates, and how big the synchronized swing really is, and assumptions that go untested are how a floor learns its limits during a real run. Test them first. Simulate the synchronized spike with a power-stress workload that ramps the cluster in lockstep, and watch what the cap, the breaker, and the energy storage actually do when the whole domain swings at once.

Measure the things that decide whether the bet holds: how fast the aggregate rises, how long the cap takes to pull it back, whether the protection rode through or moved toward a trip, and how much the headroom and the energy store absorbed. The reaction times and the swing amplitude depend on the design and the equipment, so the only numbers you can trust are the ones from your own gear under a realistic synchronized load, not the vendor figures or a smoother floor's history.

Commissioning is the place to do this, before the production jobs land, the same way the redundancy failover gets proven before the hall goes live. Prove the cap holds the budget, prove the protection coordinates with the worst transient, and prove the oversubscription ratio survives a synchronized surge with headroom to spare. Find the limit on purpose, in a test, instead of discovering it when a training run trips the breaker and loses a day of progress.

What to document

A capping and oversubscription scheme that nobody recorded is one the next operator cannot run or defend. The record is what answers the question months later when a job trips or a floor fills faster than expected and someone asks whether the cap, the ratio, and the headroom were ever set right. It is also what keeps the policy consistent as the floor changes and the people change.

Capture the oversubscription ratio per path, the cap setting at each tier and what it throttles, the headroom held for the swing, the measured aggregate and the measured swing amplitude, the metering source and its sampling rate, the breaker and protection coordination, and the priority policy that decides who gets throttled. Note the measured cap reaction time against the measured swing, because that pairing is what tells the next person whether the cap actually catches the spike. A field tool like FieldOS holds that record against the actual rack and row, so the cap policy, the ratio, the headroom, and the spike events travel with the cabinet instead of living in one engineer's head.

Common mistakes

• Oversubscribing on a diversity assumption that AI synchronized load breaks, so the loads peak together and the aggregate overruns the capacity.
• Holding no headroom for the spike, so the first synchronized surge has no room to rise into before it hits the limit.
• Trusting the cap to react faster than the breaker trips, when the cap governs the average and the breaker responds to the instantaneous current.
• Running no real metering, or metering too slowly to see the millisecond swing, so the dangerous peaks stay invisible.
• Ignoring the synchronized GPU swing and planning on the average draw, which hides the transient that actually trips the protection.
• Blind capping with a flat ceiling that destroys performance on jobs that cannot absorb it while leaving capacity on the table from jobs that could.
• Setting the cap at the breaker rating instead of under the 80 percent continuous limit, leaving nothing for the overshoot before the cap reacts.
• Treating the cap as the protection rather than a budgeting tool backed by coordinated breakers, headroom, and energy storage.

Field checklist

Standards and references

No single body owns power capping and oversubscription, so the references come from the pieces that govern each part, and every percentage and limit below hedges to the design, the equipment, and the operator. The electrical limits come from the NEC, NFPA 70, and the UL listings of the distribution gear, including the 80 percent continuous-load convention that sets the usable fraction of every breaker and the protective device coordination that the cap has to live alongside. The cap reacts on a control loop; the breaker responds to instantaneous current; coordinate them as a pair and verify the trip curve against the worst transient the load produces.

The capping mechanisms come from the silicon and platform vendors. RAPL is Intel's processor power-limit feature; GPU power limits are set through the vendor management interface, such as nvidia-smi and the out-of-band BMC path on NVIDIA gear; and the rack and row caps come from the platform and the management software. The redundancy framework that sets how far usable capacity falls below installed is the Uptime Institute Tier classification, covered in the capacity planning guide, and the cooling envelope the density lives inside is the ASHRAE Technical Committee 9.9 thermal guidance. The utility demand charge and any contracted-demand or interconnection limit come from the tariff and the interconnection agreement, which are operator-specific and govern the peak the cap has to hold.

Hedge every figure here to a snapshot. The cap reaction times, the swing amplitudes, the oversubscription ratios, the 10 to 30 percent peak-shaving savings, and the nameplate-to-actual range are working numbers that depend on the design, the equipment, and the operator, and the right value for your floor is the one the measured load and the equipment listings give you, confirmed against the adopted code before it goes on a submittal. Three rules hold above the rest: AI synchronized spikes break the diversity bet, so size the oversubscription to the diversity you actually have; meter the swing and keep headroom under the breaker; and cap with protection, not instead of it.

Units, terms, and acronyms

Capping and oversubscription carry vocabulary that travels across the policy, the meter, and the utility bill, and the same load reads differently on each.

Power is stated in kilowatts at the rack and megawatts at the site. Draw is the live load; nameplate is the worst-case maximum. The oversubscription ratio is provisioned nameplate over installed capacity. A cap is set in watts or kilowatts. Demand on the utility bill is the peak draw over a window, often the highest 15-minute average. The terms below are the ones a power team uses on the floor and in the policy.

Power capping

A hard limit on how much a device, rack, or row can draw, enforced by throttling before the budget is exceeded

Oversubscription

Provisioning more nameplate IT than the installed power could serve if everything ran at worst case at once

Load diversity

The degree to which loads do not peak together; high diversity is what makes oversubscription safe

Power volatility / spike

Large, fast swings in draw, idle to full in milliseconds, characteristic of AI GPU workloads

Synchronized swing

Many GPUs ramping power together on the same training step, so the peaks add instead of scattering

Headroom

The margin held between the capped load and the installed capacity, the buffer the spike rises into

Peak shaving

Using stored energy to serve the top of a peak so the source and the breaker see a flatter draw

Nameplate vs actual

Nameplate is the worst-case maximum draw; actual is the measured load, commonly a fraction of nameplate

RAPL / BMC

Running Average Power Limit, the CPU power-cap feature, and the baseboard management controller that enforces caps out of band

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What is data center power density?
• What is stranded capacity in a data center?
• How do you size a data center generator?
• How does power get from the utility to a server?
• Why are data centers moving to DC power for AI racks?