High-density AI rack power as a procured constraint: an 8xH200 SXM node runs at a measured 5.8 kW, so rack and PUE decisions follow from measured draw rather than from TDP
Fields
supply/ai-datacentre-power-capacity-run-costNotes
POWER DENSITY IS THE ACQUISITION CONSTRAINT, AND THE REAL NUMBER IS HIGHER THAN THE ONE ON THE SPEC SHEET. The headline people quote for an 8xH100 or 8xH200 node is roughly 10 kW. The audited MLPerf v4.1 system description for the H200 submission agrees with the intuition and sharpens it: nameplate GPU TGP is 700 W per device (hw_notes 'H200 TGP 700W'), so 8 GPUs are 5600 W, but the MEASURED whole-node plateau under a real 70B serving load is 5806.93 W - and that figure already includes two Intel Xeon Platinum 8480C hosts (56 cores each), 2 TB of host DRAM, ten 400 GbE InfiniBand NICs, NVMe and CIFS storage, and PSU conversion losses. So the two Xeon hosts and the interconnect add only ~200 W on top of the GPU nameplate; the density is set almost entirely by the GPUs, and it is the GPUs' 5600 W that a facility must cool, size and feed - not a smaller derived number. CONSEQUENCE FOR RACK PLANNING: 5806.93 W/node means a conventional 12 kW rack fits TWO such nodes, not three, once headroom is left. Sizing a rack on '10 kW per 8-GPU node' and then fitting three nodes is a 17.4 kW fit that does not exist. COOLING IS THE DECIDING DETAIL, AND IT IS RECORDED IN THE SAME SYSTEM FILE: cooling is 'Air-cooled'. At 700 W per SXM device the H200 generation is an AIR-cooled part. Anything denser - 132 kW-class NVL72 racks and Blackwell liquid-cooled designs - moves to direct-to-chip liquid, and that is a different facility class with different lead times, different retrofits and different failure modes (leak versus fan-failure), not a drop-in rack upgrade. A node that is air-cooled can go where liquid cannot; that flexibility is a real and rarely-priced advantage. IDLE CAPACITY IS THE OTHER HALF: the 2422.6 W idle floor means a provisioned-but-busy 8xH200 node holds 302.8 W per GPU of stranded capacity. Reserved-capacity contracts charge for that whether it is used or not. WHAT I COULD NOT VERIFY, STATED SO NOBODY FILLS THE GAP BY GUESSING: I did not obtain a quotable per-kW-month colocation rate from a named facility, and I did not obtain a vendor-published rack-density limit or PUE figure for a specific AI-hosting site. Those numbers exist commercially and are negotiated; they are absent here rather than guessed. Anyone needing them should quote a real facility. PUE in particular has no home in this repo's schema at all - see the gap flagged in the parent report.
EXPORT CONTROL (2026-10-04, mechanism-level; sources spl-bis-2026-05-d5-guidance, spl-bis-2026-01-advanced-computing-case-by-case): renting capacity does NOT remove the export-control question, it relocates it. Providing remote access to controlled computing capability can constitute a transfer under the EAR, so the provider must screen the end user; and separately, under the 91 FR 1684 licence regime the consignee must run KYC procedures to prevent unauthorized remote access and must manage and limit IaaS access to the hardware - obligations pushed onto the customer, who must be told to implement them. For a customer headquartered or parented in Country Group D:5 or Macau the 742.6(a)(6)(iii)(A) end-user/parent test can bite even when the capacity is consumed in a permitted region. Recorded true because the underlying hardware is controlled and the provider carries the screening duty, not because access to a US region is itself restricted.
LEAD TIME: null - and for this record that is the WRONG QUESTION, which is the point worth recording. This record measures a build constraint that is not the accelerator supply chain: the lead time for a 120 kW liquid-cooled rack is set by construction, electrical service, and CDU/manifold plumbing, not by GPU allocation. Its own notes already make this argument for the colo case, so this entry only fixes the boundary: do not read a GPU lead time into a facility lead time, and do not read a facility lead time into a GPU lead time. No vendor publishes a weeks figure for either, so both stay null - probe log in source spl-negative-no-oem-publishes-lead-time. Where a real published horizon exists for the supply side it is on the accelerator record (NVIDIA's $95.2bn purchase and supply/capacity obligations substantially payable through FY2027, source spl-nvda-10k-fy2026-supply-commitments).