inference/research
draftlow · 0.62updated 2026-10-04

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

global (colo and hyperscale regions generally)
This record is a draft. Not yet verified. Provisional. Treat every number on this page as provisional.

Fields

id
supply/ai-datacentre-power-capacity-run-cost
Kind
integrator
Region
global (colo and hyperscale regions generally)
Channels
contact-salesintegrator
Price basis
NO PRICE SET, DELIBERATELY. Colocation is sold as a per-kW-month recurring charge and that figure is site-specific to the point of being unquotable without a named facility, a named power envelope and a signed contract. Publishing a representative per-kW-month number here would be an invented price. What IS recorded is the QUANTITY that such a price is levied on, sourced and measured: 5806.93 W measured whole-node draw for a fully loaded 8xH200 SXM node, and 2422.6 W for the same node's idle floor, from the MLPerf v4.1 MaxQ power trace. Per-GPU at node level: 725.9 W loaded, 302.8 W idle. The same system description records the node as AIR-COOLED with hw_notes 'H200 TGP 700W'.
Availability
lead-time
Lead time source
structural-na
Lead time basis
STRUCTURALLY NOT APPLICABLE, and this is the distinction that matters: the lead time for this record's subject is set by construction, electrical service and cooling/CDU plumbing, not by GPU allocation. The accelerator is not the scarce item, so an accelerator lead time is the wrong question - the record's own notes make this argument. Null here means 'wrong question', not 'no data'.
Export controlled
yes
Export control regime
EAR 742.6(a)(6)(iii)(A) + EAR 744.23/744.6 (Entity, Unverified, MEU list screening of the end user) + the advanced-computing IaaS obligations of 91 FR 1684 (consignee KYC, and management/limitation of IaaS access to the hardware)
Export control note
LAYER 1, EXPORT LICENCE: under the Jan 2026 BIS rule 91 FR 1684 (effective 2026-01-15) the license review policy for advanced-computing commodities with TPP < 21,000 AND total DRAM bandwidth < 6,500 GB/s - the NVIDIA H200 and AMD MI325X are the rule's named examples - moved from PRESUMPTION OF DENIAL to CASE-BY-CASE REVIEW, but only for exports FROM THE UNITED STATES to end users located in China or Macau, and only against six exporter certifications filed via SNAP-R before shipment: (1) items below the thresholds with the count of units shipped in the US; (2) sufficient US supply, judged 'taking into account normal lead times'; (3) no diversion of global foundry capacity away from US end users; (4) aggregate China+Macau shipments <= 50% of total US end-use shipments of that product; (5) no end-user or use prohibition; (6) the consignee runs rigorous KYC. Every shipment must then pass a qualified third-party testing lab - US-headquartered, not controlled by a D:5/Macau entity, no ownership stake in any party, qualification revocable by BIS at any time - verifying TPP, total DRAM bandwidth, interconnect bandwidth and copackaged DRAM capacity. Reexports and in-country transfers of the same chips to China/Macau REMAIN PRESUMPTION OF DENIAL. LAYER 2, END-USER AND PARENT SCREENING: per BIS guidance of 2026-05-31 a licence is required where the consignee is HEADQUARTERED in Country Group D:5 (15 CFR part 740 supplement no. 1) or Macau OR whose ULTIMATE PARENT COMPANY is so headquartered - even when the consignee itself sits outside D:5/Macau. The requirement sits at EAR 742.6(a)(6)(iii)(A) for destinations outside the US, with an exception available only under the license exception at 740.2(a)(9)(ii). The destination country alone therefore never answers the question; screen the parent. LAYER 3, REMAINING LIMITS: exports to D:5/Macau-headquartered OR -parented entities stay PRESUMPTION OF DENIAL wherever the buyer sits, and the AI Diffusion Rule that would have set a country-tier structure on who could lawfully buy what was RESCINDED on 2025-05-13 and is not being enforced, so any recorded status rests on the instruments named here rather than on tiering.
notes
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).

Notes

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).

Cross-references