GPU power calculator: how many GPUs can a site’s megawatts run?

The calculator answers one question in two directions. Given a site’s power, how many GPU nodes or racks of a given type can it actually run? And given a planned cluster, how much power must the site deliver? The question came out of lender diligence on a GPU financing, where a borrower claimed that a 10 MW site could run 600 NVIDIA B300 nodes. Whether that is true depends on six numbers that capacity claims rarely state: what the 10 MW measures, the facility’s PUE, the redundancy built into the electrical plant, the power drawn by the network and storage around the GPUs, the node’s maximum (not typical) power, and any headroom the operator holds back.

The chain, from site power to GPUs, is:

real power (MW)        = stated MVA x power factor        (skip if stated in MW)
usable (MW)            = real power x redundancy fraction  (N = 1, N+1 = (n-1)/n blocks, 2N = 1/2)
after headroom (MW)    = usable x (1 - headroom %)
critical IT (MW)       = after headroom / PUE              (skip if the figure is already critical IT)
GPU budget (MW)        = critical IT / (1 + overhead %)
max units              = floor( GPU budget / (unit max kW x planned draw %) )
GPUs                   = max units x GPUs per unit
racks                  = ceil( max units / units per rack )

The reverse direction runs the same chain backwards. The planned units’ load plus overhead gives the critical IT load; dividing by one minus the headroom gives the firm IT capacity needed; multiplying by PUE gives the utility power; and the redundancy topology sets how much critical power equipment must be installed to deliver that load. Dividing utility MW by the power factor gives the MVA a transformer or utility contract must be sized for.

Every result is rounded down to a whole node or rack: a site cannot run 432.9 nodes. Whatever is left over is reported as stranded capacity. The logic lives in a small, pure module that is checked against the worked examples on this page, so the numbers in the text and the numbers the calculator produces cannot drift apart.

The single largest error in GPU capacity claims is treating two different megawatts as one. Utility (or facility) power is what the site imports from the grid: everything behind the meter, including chillers, pumps, fans in air handlers, lighting, and losses in transformers and uninterruptible power supplies (UPS). Critical IT load is the power delivered to the IT equipment itself: servers, switches and storage, measured at the output of the UPS or at the rack power distribution units.

The two are related by power usage effectiveness. The Green Grid, which introduced the metric, defines PUE as “the ratio of total facilities energy to IT equipment energy,” and defines IT equipment energy as the energy “consumed by equipment that is used to manage, process, store, or route data within the compute space.”^[30] A 10 MW utility connection at a PUE of 1.40 supports about 7.1 MW of IT; a facility marketed as “10 MW critical IT” at the same PUE needs a 14 MW utility connection. A 40% difference in GPU count hides inside one unstated word.

Developers, brokers and colocation providers use both conventions, often in the same document. Utility interconnection agreements and substation ratings are facility figures. Colocation leases, data hall specifications and “IT MW” in a data center pitch are usually critical IT. Construction and energization schedules can be either. The calculator makes you choose explicitly with the The figure is switch: Utility / facility divides by PUE; Critical IT does not.

Fans inside the servers are a subtlety that matters more for GPUs than for any earlier generation. They draw from the same UPS as the server, so they count as IT load, not as facility overhead. ASHRAE’s Technical Committee 9.9 notes that air-cooled servers can spend “10% to 20% fan power inside the server. In a 50 kW rack, the fan power translates to be at least 5 kW,” and that those fans “are powered by the same uninterruptible power supply (UPS) source as the server itself.”^[33] The vendor’s system maximum already includes them, which is one more reason to plan on the system figure rather than on GPU power alone.

PUE is an annual energy ratio. Capacity planning needs a power ratio at the worst hour: the hottest design day, with the IT load at maximum. The two differ because chillers and dry coolers work hardest exactly when the outside air is hottest. A facility that reports an annual PUE of 1.3 can need 1.4 or more at its summer peak. Ask for the design-day PUE (sometimes called peak or partial PUE), and use the annual figure only for energy cost.

What the surveys say

• Uptime Institute’s 2024 global survey reported an industry-average PUE of 1.56, a figure that “reveals a continuing trend of inertia,” while noting that “many recent builds consistently achieve a PUE of 1.3 — and sometimes much better.”^[27] Its 2025 survey found that average PUE levels “show little change for the sixth consecutive year.”^[28]
• Lawrence Berkeley National Laboratory’s 2024 United States Data Center Energy Usage Report models the US average falling from 1.6 in 2014 to 1.4 in 2023, and to between 1.15 and 1.35 by 2028, “driven again by the shift into more energy efficient hyperscale and colocation facilities, combined with the increase in liquid-cooled AI servers.”^[31]
• Google reports a fleet-wide annual average PUE of 1.09.^[32] That is the frontier of what a purpose-built hyperscale estate achieves, not a planning assumption for a third-party site.

Air versus direct liquid cooling

Air-cooled GPU servers reject all of their heat into room air, which the facility must cool with computer room air handlers backed by chillers or economizers. Direct-to-chip liquid cooling takes most of the heat out through cold plates into a coolant loop, which can run warm enough to reject heat to outside air without compressors for much of the year. ASHRAE classifies facility water by its upper supply temperature: W17, W27, W32, W40, W45 and W+.^[33] The warmer the class a platform can accept, the fewer hours the chillers run. For air, ASHRAE’s recommended inlet envelope for classes A1 to A4 is 18 to 27 °C.^[34]

The calculator’s defaults are 1.40 for air-cooled halls and 1.25 for direct liquid cooling. Both sit above what the best new builds report on an annual basis, on purpose: a capacity case has to hold on the hottest day of the year, in a hall that is not a hyperscaler’s. 1.40 is LBNL’s 2023 national average and below Uptime’s 1.56 industry figure; 1.25 is inside LBNL’s 1.15 to 1.35 range for the liquid-cooled 2028 fleet. Override both with the site’s own design-day value whenever you have it.

Transformers, generators and many utility contracts are rated in MVA (apparent power), while IT equipment consumes MW (real power). The ratio between them is the power factor:

MW = MVA x power factor          e.g. 12 MVA x 0.90 = 10.8 MW

Modern server power supplies correct their power factor close to unity at load; the 80 PLUS program requires a true power factor of 0.9 or higher for certification.^[35] The site as a whole also carries motors (pumps, fans, compressors) whose power factor depends on their drives. The calculator defaults to 0.95, a planning assumption between the 0.9 certification floor and unity. If the capacity you were given is in MVA, select MVA and use the power factor the utility or the electrical engineer of record states. In the reverse direction the calculator always reports the MVA equivalent of the facility load, because that is the figure the transformer has to carry.

Redundancy is the second place where megawatts disappear. Uptime Institute’s Tier system describes the ladder: Tier II adds “redundant capacity components for power and cooling,” Tier III is “concurrently maintainable,” and Tier IV has “several independent and physically isolated systems.”^[29] Underneath those labels are three electrical topologies that decide how much of the installed equipment can carry load:

• N: exactly enough capacity for the load. Every installed megawatt is usable; any failure or maintenance takes capacity offline.
• N+1: one spare block beyond what the load needs. With blocks of size B and n blocks installed, usable capacity is (n − 1) × B. The larger the block relative to the site, the more capacity the spare consumes.
• 2N: two complete, independent systems, each able to carry the full load. Usable capacity is half of installed capacity.

Apply redundancy only to figures that count redundant equipment. A utility’s firm import capacity is already the usable figure from the grid’s side; redundancy there is the utility’s problem (and, at the site, the generators’). Installed UPS nameplate, generator nameplate and “total installed critical capacity” on a single-line diagram, by contrast, usually include the spare units. If someone quotes “20 MW, 2N,” ask whether that is 20 MW usable or 20 MW installed: the answer is a factor of two in GPU count. The calculator warns when redundancy is applied to a utility figure.

GPU systems carry their own redundancy inside the box, which is separate from the facility’s. DGX H100 has six 3.3 kW supplies “configured for 4+2 redundancy”; DGX B200 has six in 5+1; DGX B300 has twelve in N+N.^[1][3][4] Add up the supply nameplates and you get far more than the system draws (6 × 3.3 = 19.8 kW of supplies for a 10.2 kW DGX H100). Power supply nameplate is not system power.

Derating is the deliberate loading of equipment below its rating. The most familiar example is the electrical code: NFPA 70, the US National Electrical Code, sizes conductors and overcurrent devices for continuous loads (three hours or more) at 125% of the load, which is why branch circuits and rack power strips are loaded to 80% of their breaker rating.^[36] GPU racks run near maximum for days at a time, so they are continuous loads. That rule lives inside the rack and branch-circuit design, not in site megawatts, so the calculator does not apply it automatically.

Headroom is capacity the operator holds back at site level: for load growth, for measurement error, or because a utility contract penalizes exceeding the contracted demand. The calculator’s headroom input defaults to 0% so the arithmetic stays transparent; 5 to 10% is a common operator choice, and at 10% the 10 MW example below falls from 432 to 389 B300 nodes.

Transients are the reason AI clusters need more electrical care than their averages suggest. Training synchronizes thousands of GPUs: they compute together, then wait together for communication or checkpoints. Meta’s Llama 3 paper describes how “tens of thousands of GPUs may increase or decrease power consumption at the same time,” which “can result in instant fluctuations of power consumption across the data center on the order of tens of megawatts, stretching the limits of the power grid.”^[44] Vendors have responded at rack level. Lenovo specifies its GB300 NVL72 rack at 135 kW TDP, “up to 155 kW peak depending on workload and EDP behavior.”^[14] NVIDIA added energy storage and power smoothing to the GB300 NVL72 power shelves, reporting that “the peak power demand seen by the grid is reduced by 30% when training the Megatron LLM.”^[15] Size feeders and protection for the peak; size the energy budget on the operating figure.

Two different numbers describe a GPU node’s power, and both are legitimate for different questions. Maximum (the vendor’s system max, sometimes TDP) is what the electrical system must be able to deliver. Typical or average draw is what the site actually consumes over a month, and drives the energy bill.

The best public measurement comes from LBNL’s 2024 report, which analyzed measured data and found that “across both single-node and multi-node AI training workloads, 8 H100 GPU nodes averaged 74% of manufacturer rated thermal design power in workload.” LBNL used 70% for its national energy model, varied between 60% and 80% for future years, and cites a Brookhaven National Laboratory measurement of idle draw at about 18% of rated maximum on an 8-GPU H100 node.^[31]

An average of 74% does not mean a site can be filled to 135% of its power. The average hides synchronized peaks at maximum, and a breaker trips on the peak. Classic warehouse-scale research is the strongest argument for oversubscription and also shows its limits: Google measured “a noticeable gap (7 - 16%) between achieved and theoretical aggregate peak power usage at the cluster level,” growing “to almost 40% in whole datacenters,” for conventional mixed workloads.^[42] Microsoft’s POLCA study found that “inference workloads offer substantial headroom for power oversubscription,” enough to “deploy 30% more servers in the same GPU cluster for inference.”^[43] Training, by contrast, runs every GPU in lockstep, and the same paper identifies training and inference power patterns as different.

Power capping makes a lower figure enforceable

The calculator’s planned draw input lets you plan below maximum, but only use it when a cap is enforced in hardware or firmware. NVIDIA supports power limits at the GPU through nvidia-smi and at the system through the DGX baseboard management controller.^[39] NVIDIA’s Blackwell workload power profiles report that the Max-Q profile achieves “power savings of up to 15% … with, at most, a 3% performance loss,” and “an overall throughput increase of up to 13% in a power-constrained facility.”^[40] AMD exposes the equivalent through amd-smi set --power-cap.^[41] For a 5 MW air-cooled H100 site, an enforced 80% cap raises the count from 318 to 397 nodes; whether that is a good trade depends on the workload’s throughput at the lower cap, which is a question for benchmarks, not for this calculator.

A site can have the megawatts and still not be able to run the GPUs, because power must arrive at the rack and heat must leave it. Uptime Institute’s 2024 survey found that average rack densities “remain below 8 kW,” that 4 to 6 kW racks are still the most commonly deployed, and that “the majority of facilities do not have racks above 30 kW.”^[27] Modern GPU racks sit far above that:

• NVIDIA’s DGX H100 SuperPOD design guide tabulates 10.2 kW per system and 40.8 kW per rack with four systems per rack.^[2]
• The DGX B200 SuperPOD reference layout notes that “power consumption per rack exceeds 25 kW.”^[11] Four 14.3 kW DGX B200 systems in one rack would be 57.2 kW.
• A GB200 NVL72 rack is fed by eight power shelves, each with “six 5.5kW PSUs” that “can deliver up to 33kW.”^[9] NVIDIA describes “the 120 KW cooling capacity required for the rack,”^[10] and Supermicro lists operating power of 125 to 135 kW.^[12]
• The Open Compute Project’s Open Rack V3 33 kW shelf carries “six 5.5kW power supplies with a maximum power of 33 kW, or 27.5kW with 5+1 redundancy,”^[37] and OCP’s Diablo 400 specification describes a “disaggregated power rack to deliver ±400VDC” scaling “from 800kW to 1MW+.”^[38]

The calculator reports power per rack from the nodes per rack input and flags air-cooled layouts above 30 kW. Its defaults are four 8-GPU nodes per rack for air-cooled HGX/DGX and AMD nodes (NVIDIA’s H100 reference layout), eight liquid-cooled MI355X nodes per rack (64 GPUs; AMD describes up to 64 GPUs per air-cooled rack and up to 128 per direct liquid-cooled rack for the MI350 series^[19]), and one NVL72 system per rack. Fewer nodes per rack spreads the load over more floor space and more power whips; it does not change the megawatts.

GPU nodes are not the only critical load. The compute fabric (InfiniBand or Ethernet), the storage system and its network, the front-end and management networks, and the management servers all draw from the same critical power. The calculator models them as a percentage of GPU-unit load, default 10%, and shows the figure explicitly so you can replace it.

The default is derived bottom-up from NVIDIA’s switch specifications, assuming a two-tier non-blocking fat tree:

• Each 8-GPU node has eight compute-fabric ports. In a two-tier non-blocking tree, each node port consumes one leaf downlink, one leaf uplink and one spine port: 24 switch ports per node.
• H100 generation: a Quantum-2 QM9700 switch has 64 ports at 400 Gb/s, “typical power with passive cables (ATIS): 747W” and “max power with active cables: 1,720W.”^[25] 24 ÷ 64 × 1.72 kW = 0.65 kW per node, or 6.3% of a 10.2 kW node at maximum (2.7% at typical).
• Blackwell generation: a Quantum-X800 Q3400 has 144 ports at 800 Gb/s, typical 2,900 W and “max power with active cables: 7,000W.”^[26] 24 ÷ 144 × 7.0 kW = 1.17 kW per node, or 7.8% of a 15 kW B300 node.
• Storage servers, storage and front-end switches, and management nodes add a few percent more, depending on the storage design.

A 10% default therefore covers a maximum-power compute fabric plus a modest storage and management estate. NVIDIA’s own DGX GB200 reference architecture is a useful cross-check: “each SU requires a Thermal Design Power (TDP) of 1.2 Megawatts (MW)” for eight racks,^[8] which is 1.2 MW against 8 × 120 to 135 kW of compute racks. NVLink switch trays inside an NVL72 rack are already in the rack figure; only the scale-out network, storage and management sit in the overhead. Inference clusters with a thin scale-out fabric can justify less; training clusters with large parallel file systems can need more.

Each preset uses the vendor’s published maximum where one exists. For NVIDIA 8-GPU systems that is the DGX user guide’s power specifications table; OEM HGX servers built on the same baseboard publish power supply configurations, not a system maximum, so DGX is the best public reference for them. For NVL72 racks it is the top of the OEM’s published operating range. AMD publishes per-GPU board power but no 8-GPU system maximum, so the AMD presets are GPU Smith estimates with the derivation shown.

Notes on individual platforms

• H100 and H200. NVIDIA rates both SXM GPUs at “up to 700W (configurable).”^[6][7] The DGX H100/H200 system maximum of 10.2 kW is 1.8 times the 5.6 kW of its eight GPUs; the difference is CPUs, NVSwitch, NICs, storage, fans and conversion losses.^[1] Supermicro’s HGX H100 server ships with “6x 3000W Redundant (4 + 2)” supplies, which bounds it at 12 kW of usable supply.^[24]
• B300. The DGX B300 user guide gives “Power consumption 14.5 kW” in its physical specifications and “15 kW system max.” in its power table; the product page says “~14 kW.”^[4][5] The preset uses the stated maximum, 15 kW. At 14.5 kW, the 10 MW example rises from 432 to 447 nodes.
• GB200 and GB300 NVL72. Supermicro lists GB200 NVL72 operating power at “125kW to 135kW” and GB300 NVL72 at “132kW to 140kW,” each with eight 33 kW shelves.^[12][13] Lenovo lists the B300 in GB300 NVL72 at 1,100 W total graphics power.^[14]
• AMD Instinct. AMD lists typical board power of 750 W for MI300X, 1,000 W for MI325X and 1,400 W for MI355X.^[16][17][18] For air-cooled nodes the estimate divides eight GPUs’ board power by 0.56, the GPU share of system maximum on DGX H100 (5.6 of 10.2 kW) and DGX B200 (8.0 of 14.3 kW), then checks it against the redundant supply budget of shipping chassis: Supermicro AS-8125GS-TNMR2 (MI300X) has “6x 3000W Redundant (3 + 3),” or 9.0 kW usable;^[20] Lenovo’s SR685a V3 has up to eight 2,600 W supplies with N+N redundancy, or 10.4 kW;^[21] Supermicro AS-8126GS-TNMR (MI325X/MI350X) has 6 × 5,250 W in 3+3, or 15.75 kW.^[22] For liquid-cooled MI355X, where fans mostly disappear, the estimate is the 13.2 kW redundant budget of Supermicro’s AS-4126GS-NMR-LCC (4 × 6,600 W in 2+2).^[23] Replace these with the OEM’s figure for the exact SKU being financed.

Example 1: is 10 MW enough for 600 B300 nodes?

This is the lender question that started the tool. Inputs: DGX/HGX B300 at 15 kW per node, 10% shared overhead, 100% planned draw, no headroom, air-cooled hall at PUE 1.40.

600 nodes x 15 kW                      = 9.00 MW   GPU-node load
9.00 MW x 1.10 (overhead)              = 9.90 MW   critical IT load
9.90 MW x 1.40 (PUE)                   = 13.86 MW  utility power required
13.86 MW / 0.95 (power factor)         = 14.59 MVA

Read as a utility figure, 10 MW supports 10 / 1.40 = 7.14 MW of critical IT, 7.14 / 1.10 = 6.49 MW for nodes, and 6.49 MW / 15 kW = 432 nodes (3,456 GPUs, 108 racks at 60 kW). The claim of 600 is 39% too high. Read as critical IT, it depends on the redundancy:

The naive version of the calculation, 600 × 8 GPUs × about 1.1 kW per GPU = 5.3 MW, suggests the site fits the cluster almost twice over. It ignores everything in the node other than the GPUs, the network, the cooling and the redundancy. The claim is only true if the 10 MW is critical IT, built with no redundancy reserve, and the operator runs at maximum with no headroom. That is three assumptions to verify, not one.

Example 2: what fits in a 5 MW utility connection?

Same defaults (PUE 1.40 air, 1.25 liquid; 10% overhead; N; 100% draw):

Two things stand out. GPU count per megawatt falls with each generation, because each GPU draws more; work per megawatt rises much faster, which is the point of the newer parts. And the liquid-cooled platforms gain part of their count from the lower PUE, not from the hardware: at the same 1.40 PUE, the GB300 figure would be 23 racks rather than 25.

Example 3: GB300 NVL72 racks

A 10 MW utility connection at PUE 1.25 gives 8.0 MW of critical IT and 7.27 MW for racks: 51 GB300 NVL72 racks, 3,672 GPUs. Sized on Lenovo’s 155 kW peak instead of the 140 kW operating figure, the answer is 46 racks. In the reverse direction, 100 racks need 14.0 MW of rack power, 15.4 MW of critical IT and 19.25 MW (20.26 MVA) at the utility. Built 2N, the site must install 30.8 MW of critical power equipment to deliver those 15.4 MW; built N+1 in 2.5 MW blocks, it installs 20 MW.

• Mixing utility and critical IT megawatts. A 40% swing in GPU count at a PUE of 1.40. Always ask which one a figure is.
• Multiplying GPU TDP by GPU count. Eight 700 W H100s are 5.6 kW; the DGX H100 they sit in is 10.2 kW. Use system maximum.
• Adding up power supply nameplates. A DGX H100 has 19.8 kW of supplies for a 10.2 kW system; that is redundancy, not draw.
• Using annual PUE for a peak capacity question. The chillers peak on the hottest afternoon, at full IT load.
• Counting redundant capacity as usable. 20 MW installed at 2N carries 10 MW.
• Forgetting the network, storage and management. Roughly 5 to 15% of GPU load in the derivation above, never zero.
• Sizing at average draw without an enforced cap. LBNL’s 74% average is an energy figure; the breaker sees the synchronized peak.
• Confusing MVA with MW. A 12 MVA transformer at a power factor of 0.90 delivers 10.8 MW.
• Ignoring rack density. A hall built for 8 kW air-cooled racks has megawatts, but cannot host 60 kW B300 racks or 140 kW NVL72 racks without new power distribution and cooling.
• Treating contracted power as energized power. Utility capacity often arrives in phases; the GPU count that matters for a loan is the one supported on each delivery date.
• Sizing feeders on operating power. NVL72 racks have published peaks well above their operating figure; protection and busway must carry the peak.

For lenders, investors and buyers underwriting a GPU cluster, a capacity claim is only as good as the documents behind it. The questions below turn a headline megawatt figure into a GPU count you can rely on:

• The utility agreement: firm or interruptible capacity, in MW or MVA, and the energization date of each phase.
• The single-line diagram: UPS and generator nameplates, block sizes and topology (N, N+1, 2N, distributed redundant).
• The mechanical design basis: design-day PUE, cooling type, facility water class and rack density limits per hall.
• The vendor’s system maximum for the exact SKU, and the power capping configuration if the plan relies on it.
• The network and storage bill of materials, with switch and server power.
• Commissioning results: integrated systems test at full load, not only a vendor’s statement.

GPU Smith reviews these documents as part of technical due diligence for GPU financing. To discuss a specific site or cluster, contact us.

The calculator and its methodology are free to use and to cite. Links reproduce a result exactly: copy the address bar after setting the inputs. Journalists and analysts are welcome to quote the figures with attribution.

GPU Smith. (2026). GPU power-capacity calculator: MW to GPU nodes and racks. GPU Smith LLC. https://gpusmith.com/tools/gpu-power-calculator

<a href="https://gpusmith.com/tools/gpu-power-calculator">GPU power-capacity calculator (GPU Smith)</a>

Source: GPU Smith, "GPU Power Calculator: MW to GPU Nodes and Racks", https://gpusmith.com/tools/gpu-power-calculator, updated 2026-10-14.

1. [1]NVIDIA. DGX H100/H200 User Guide: Introduction (Power Specifications). docs.nvidia.com/dgx/dgxh100-user-guide/introduction-to-dgxh100.html
2. [2]NVIDIA. DGX SuperPOD Data Center Design (H100): Planning, Tables 1 and 2. docs.nvidia.com/dgx-superpod/design-guides/dgx-superpod-data-center-design-h100/latest/planning.html
3. [3]NVIDIA. DGX B200 User Guide: Introduction (Power Specifications). docs.nvidia.com/dgx/dgxb200-user-guide/introduction-to-dgxb200.html
4. [4]NVIDIA. DGX B300 User Guide: Introduction (Power Specifications). docs.nvidia.com/dgx/dgxb300-user-guide/introduction-to-dgxb300.html
5. [5]NVIDIA. NVIDIA DGX B300 product page. nvidia.com/en-us/data-center/dgx-b300/
6. [6]NVIDIA. NVIDIA H100 Tensor Core GPU: specifications. nvidia.com/en-us/data-center/h100/
7. [7]NVIDIA. NVIDIA H200 Tensor Core GPU: specifications. nvidia.com/en-us/data-center/h200/
8. [8]NVIDIA. DGX SuperPOD Reference Architecture (DGX GB200): Architecture. docs.nvidia.com/dgx-superpod/reference-architecture-scalable-infrastructure-gb200/latest/dgx-superpod-architecture.html
9. [9]NVIDIA. DGX SuperPOD Reference Architecture (DGX GB200): Components. docs.nvidia.com/dgx-superpod/reference-architecture-scalable-infrastructure-gb200/latest/dgx-superpod-components.html
10. [10]NVIDIA Technical Blog. NVIDIA Contributes NVIDIA GB200 NVL72 Designs to Open Compute Project. developer.nvidia.com/blog/nvidia-contributes-nvidia-gb200-nvl72-designs-to-open-compute-project/
11. [11]NVIDIA. DGX SuperPOD Reference Architecture (DGX B200): Architecture. docs.nvidia.com/dgx-superpod/reference-architecture-scalable-infrastructure-b200/latest/dgx-superpod-architecture.html
12. [12]Supermicro. Supermicro NVIDIA GB200 NVL72 SuperCluster datasheet. supermicro.com/datasheet/datasheet_SuperCluster_GB200_NVL72.pdf
13. [13]Supermicro. Supermicro NVIDIA GB300 NVL72 SuperCluster datasheet. supermicro.com/datasheet/datasheet_SuperCluster_GB300_NVL72.pdf
14. [14]Lenovo Press. Lenovo NVIDIA GB300 NVL72 Rack Scale AI, Product Guide LP2357. lenovopress.lenovo.com/lp2357-lenovo-nvidia-gb300-nvl72-rack-scale-ai
15. [15]NVIDIA Technical Blog. How New GB300 NVL72 Features Provide Steady Power for AI. developer.nvidia.com/blog/how-new-gb300-nvl72-features-provide-steady-power-for-ai/
16. [16]AMD. AMD Instinct MI300X Accelerators: specifications. amd.com/en/products/accelerators/instinct/mi300/mi300x.html
17. [17]AMD. AMD Instinct MI325X Accelerators: specifications. amd.com/en/products/accelerators/instinct/mi300/mi325x.html
18. [18]AMD. AMD Instinct MI355X GPU: specifications. amd.com/en/products/accelerators/instinct/mi350/mi355x.html
19. [19]AMD. AMD Instinct MI350 Series and Beyond: Accelerating the Future of AI and HPC. amd.com/en/blogs/2025/amd-instinct-mi350-series-and-beyond-accelerating-the-future-of-ai-and-hpc.html
20. [20]Supermicro. Supermicro AS-8125GS-TNMR2 (8x MI300X) product page. supermicro.com/en/products/system/gpu/8u/as-8125gs-tnmr2
21. [21]Lenovo Press. ThinkSystem SR685a V3 Server, Product Guide LP1910. lenovopress.lenovo.com/lp1910-thinksystem-sr685a-v3-server
22. [22]Supermicro. Supermicro AS-8126GS-TNMR (8x MI325X/MI350X) product page. supermicro.com/en/products/system/gpu/8u/as-8126gs-tnmr
23. [23]Supermicro. Supermicro AS-4126GS-NMR-LCC (8x MI355X, liquid) product page. supermicro.com/en/products/system/gpu/4u/as-4126gs-nmr-lcc
24. [24]Supermicro. Supermicro SYS-821GE-TNHR (HGX H100/H200) product page. supermicro.com/en/products/system/GPU/8U/SYS-821GE-TNHR
25. [25]NVIDIA. NVIDIA Quantum-2 QM97x0 switch: Specifications. networking-docs.nvidia.com/qm97x0hw/specifications
26. [26]NVIDIA. NVIDIA Quantum-X800 XDR switches: Specifications. networking-docs.nvidia.com/xdrswitcheshw/specifications
27. [27]Uptime Institute. Uptime Institute Global Data Center Survey 2024 (report). datacenter.uptimeinstitute.com/rs/711-RIA-145/images/2024.GlobalDataCenterSurvey.Report.pdf
28. [28]Uptime Institute. Uptime Institute Global Data Center Survey 2025 (key points). intelligence.uptimeinstitute.com/resource/uptime-institute-global-data-center-survey-2025
29. [29]Uptime Institute. Tier Classification System. uptimeinstitute.com/tiers
30. [30]The Green Grid. WP#49, PUE: A Comprehensive Examination of the Metric. datacenters.lbl.gov/sites/default/files/WP49-PUE%20A%20Comprehensive%20Examination%20of%20the%20Metric_v6.pdf
31. [31]Lawrence Berkeley National Laboratory. 2024 United States Data Center Energy Usage Report (Shehabi et al., LBNL-2001637). escholarship.org/uc/item/32d6m0d1
32. [32]Google. Data center efficiency: fleet-wide PUE. datacenters.google/efficiency/
33. [33]ASHRAE. Emergence and Expansion of Liquid Cooling in Mainstream Data Centers (white paper, TC 9.9). ashrae.org/File%20Library/Technical%20Resources/Bookstore/Emergence-and-Expansion-of-Liquid-Cooling-in-Mainstream-Data-Centers_WP.pdf
34. [34]ASHRAE. Thermal Guidelines for Data Processing Environments, reference card (TC 9.9). xp20.ashrae.org/datacom1_4th/ReferenceCard.pdf
35. [35]CLEAResult. 80 PLUS program details. clearesult.com/80plus/program-details
36. [36]NFPA. NFPA 70, National Electrical Code. nfpa.org/codes-and-standards/nfpa-70-standard-development/70
37. [37]Open Compute Project. Delta 33 kW 1OU Open Rack V3 power shelf (OCP Marketplace). opencompute.org/marketplace/facilities-physical-infrastructure/delta-33kw-1ou-open-rack-v3-power-shelf/
38. [38]Open Compute Project. Diablo 400 specification v0.7.0. opencompute.org/documents/ocp-specification-diablo-400-v0-7-0-final-pdf
39. [39]NVIDIA. DGX H100/H200 User Guide: Power Capping. docs.nvidia.com/dgx/dgxh100-user-guide/power-capping.html
40. [40]NVIDIA Technical Blog. Optimize Data Center Efficiency for AI and HPC Workloads with Power Profiles. developer.nvidia.com/blog/optimize-data-center-efficiency-for-ai-and-hpc-workloads-with-power-profiles/
41. [41]AMD ROCm documentation. AMD SMI CLI tool: power-cap. rocm.docs.amd.com/projects/amdsmi/en/latest/how-to/amdsmi-cli-tool.html
42. [42]Google. Power Provisioning for a Warehouse-sized Computer (Fan, Weber, Barroso, ISCA 2007). barroso.org/publications/PowerProvisioning.pdf
43. [43]Microsoft Research. POLCA: Power Oversubscription in LLM Cloud Providers (Patel et al., arXiv:2308.12908). arxiv.org/abs/2308.12908
44. [44]Meta. The Llama 3 Herd of Models (arXiv:2407.21783), section 3.3.4. arxiv.org/abs/2407.21783

All sources accessed and figures checked on 2026-10-14.