Liquid cooling retrofit: CDU capacity is the ceiling on rack density in an existing building (LiquidStack CDU-1MW, up to 1.35 MW per row)
Fields
supply/liquid-cooling-retrofit-cdu-density-ceilingNotes
RECORDED AS A SUPPLY CHANNEL BECAUSE WHEN YOU CANNOT BUILD A NEW DATAHALL, A CDU IS THE PRODUCT THAT DETERMINES WHAT FITS. LiquidStack publishes the density ceiling of its own hardware, which is the honest upper bound on a retrofit: CDU-1MW 'Supports rack densities up to 1.35MW per row, compatible with next-generation GPU platforms', quick-ship 'live in weeks', with 'In-row and perimeter configurations for new builds and retrofit environments' and 'third-party validated performance and global service through Trane Technologies'. The GigaModular CDU scales 'from initial deployment to multi-megawatt capacity without infrastructure redesign', with N+1/N+2 redundancy, dual-redundant communications, and a thermally important claim: 'Supports 45C return water for chillerless operation - optimized for hyperscale efficiency'. Chillerless operation matters because a colo whose whole strategy is air-cooled chillers (as Vantage's is) can be brought into direct-to-chip service by running the loop warm enough to reject heat without chillers, which is a cheaper retrofit than adding a chiller plant. TREAT THE DENSITY NUMBERS AS VENDOR-MARKETING CAPABILITY CLAIMS, not measured deployments: 'up to 1.35MW per row' is a per-ROW figure across multiple racks, not a per-rack figure, and it is ~11x the 120 kW of a GB200 NVL72 rack, so it is a headroom statement about the CDU class rather than a claim about any specific rack. The vendor names NVIDIA Vera Rubin as a supported platform - the rack-scale generation AFTER the parts in this repo - so treat current-generation fit as inferred from 'next-generation GPU platforms' rather than certified per SKU. The strategic read: CDU vendors are the ones telling you the industry has decided the transition is to liquid, and that the binding constraint on a retrofit is the coolant-distribution hardware, not the server.
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).