An AI datacenter does not buy GPUs one at a time. It buys a fixed electrical envelope years before the accelerators arrive, then converts that envelope into useful model tokens. A 2026 paper from Meta documents this conversion at unusual resolution: five roughly 30 MW buildings, about 83,000 GB200 GPUs and a 150 MW power ceiling[1]. The deployment is part of a larger 1 GW campus, but its most useful lesson fits inside one sentence. The GPU setting that maximizes a device benchmark does not maximize the work completed by the cluster.
The authors follow the system from capacity planning through commissioning and live operation. Their result is not a new cooling loop or accelerator. It is a stack of decisions that jointly raises throughput by about 14% within the same facility limit. Specifically, Meta gains roughly 10% from fitting more GPUs at a lower initial power limit, about 2% after measured headroom permits a higher setting, and another 2% from a runtime controller. That ledger turns power from a procurement constraint into a schedulable cluster resource.
The 1,200 W GPU that loses to 960 W
GB200 can operate at a 1,200 W maximum GPU power setting, but Meta provisioned its deployment around 960 W. The apparent sacrifice is small at the device and large at the building. Reducing the setting from 1,200 W to 1,000 W cuts measured per-GPU performance by about 5% while reducing the power allowance by 16.7%. At 900 W, the respective changes are about 12% and 25%. Since a datacenter admits more accelerators when each one claims less of the electrical budget, the cluster throughput curve peaks below the device curve.
The paper normalizes this calculation against a 700 W H100 fleet under the same 150 MW ceiling. A 1,200 W GB200 plan fits about 74,000 GPUs and produces 1.7× the aggregate throughput of the H100 reference. At 960 W, the plan fits roughly 86,000 GPUs and reaches 1.9×. Thus, the lower setting yields about 11% more cluster work than the nominal maximum even though every individual GPU runs more slowly. Network radix and deployment details reduce the realized count to approximately 83,000, but do not change the decision.
This calculation must include everything that is not a GPU. The backend and frontend networks consume 8% to 9% of the entire 150 MW allocation. A Catalina compute pod combines two racks containing 72 GB200 GPUs in one NVLink domain with two air-assisted liquid-cooling racks, because the buildings lack facility chilled water. Every Grace CPU also carries two 400 Gb/s ConnectX-7 interfaces for the backend fabric and a separate 200 Gb/s frontend connection[2]. Power reserved for those paths cannot be sold twice.
Provisioning is a forecast, commissioning is an audit
Meta separates power management into three time scales. Planning begins 6 to 12 months before the next accelerator generation, when engineers have models rather than production measurements. Commissioning then checks those assumptions against rack and facility telemetry. Runtime control finally exploits short-lived headroom without placing breakers or jobs at risk.
The commissioning phase exposed why nameplate arithmetic is insufficient. Rack power-supply telemetry consistently reported more power than the upstream remote power panel (RPP) measured. Meta calibrated the former against the latter and found that a 70th-percentile aggregation represented the shared load better than a simple maximum. The discrepancy is not bookkeeping trivia. A conservative error multiplied by 83,000 GPUs strands megawatts that could have performed useful work.
Physical distribution also creates local limits inside a healthy building. Power flows from main switchboards (MSBs) through RPPs to racks, and the tightest element determines whether another watt is usable. The deployment showed that 13% of MSBs had less than 50 kW of remaining capacity. Average MSB headroom was around 160 kW, equivalent to about 100 W per GPU beneath that board, while RPPs retained more than twice as much on a per-GPU basis. Consequently, 5% to 10% of provisioned capacity could remain stranded behind imbalance even when the campus total looked comfortable.
Measurements nevertheless justified a controlled increase in the GPU setting from 960 W to 1,020 W. That step recovered an expected 2% to 3% of performance without changing the number of installed accelerators. The sequence matters: the original lower limit bought physical density, and only the audit established where some of the reserved margin could safely return to computation.
Flatten the pulse, then dim the fleet
Large synchronous jobs do not draw steady power. Compute phases raise demand together, while communication phases lower it together. A cluster-wide transition can therefore create a sharp pulse even when average consumption stays below the limit. Breakers tolerate overloads for a short interval, but the paper reports operational curves of roughly 1.2× for 45 seconds or 2× for 30 seconds. A controller that reacts after a long averaging window is protecting the wrong time scale.
Meta deploys two complementary mechanisms. Power Smoother fills predictable communication valleys with tensor-core instructions that use registers rather than HBM or L2. The extra operations do no application work, but they prevent the electrical system from repeatedly falling and surging. An adaptive backoff keeps the mechanism within the available budget, and the reported application cost stays below 3%. The trade is deliberate: a small amount of wasted arithmetic reduces a physical transient that could force a much larger safety margin.
Dimmer handles the remaining peaks. When device readings exceed 97% of an applicable limit, it gradually adjusts GPU caps using a seven-second average. Coordination is essential. An uncoordinated cap would slow one worker, turn it into a distributed-training straggler and leave the other workers consuming power while waiting. Dimmer therefore works with job and scheduler context so that ranks sharing a workload are adjusted together. The controller contributes roughly another 2% of cluster throughput by making temporary headroom usable rather than permanently reserved.
What operators should copy
The transferable idea is not the precise 960 W value. That number belongs to one accelerator, workload mix, network and building. The transferable unit is the optimization boundary. If the objective is device performance, the answer is the highest stable accelerator setting. If the objective is completed cluster work under a facility ceiling, the answer must include GPU count, non-compute loads, electrical hierarchy, workload synchrony and recovery from local imbalance.
This boundary also changes the role of telemetry. Rack sensors, RPP meters and MSB limits describe different parts of the same resource graph. Treating any one stream as ground truth either risks overload or strands capacity. The paper’s 14% result comes from closing the loop across time: forecast conservatively, measure at deployment, then spend verified headroom with coordinated controls.
There are limits to the comparison. The aggregate throughput estimates use Meta’s workload characterization and a specific generation transition. A service dominated by latency-sensitive inference may value the last watts differently from a dense training fleet. Power Smoother also exchanges energy for a flatter profile, so its merit depends on how the utility, cooling system and breaker hierarchy price transients. Even with those qualifications, the central accounting remains robust. At 100 MW scale, power is no longer an attribute of the cluster. Power is the cluster.
Source and attribution
This article is an editorial summary prepared for Silicon & Systems. It restates the cited paper in our own words. No text, tables or figures from the paper are reproduced; both figures were created for this article from reported results. The paper is available under the Creative Commons Attribution 4.0 International license. Copyright (c) 2026 the authors. The source paper and license are available through its arXiv record.