At a glance
- Author: Mike Donahue, Solution Architect, North America Operations A neocloud can secure colocation space and electrical capacity yet still lack the cooling conditions its GPU racks require
- A facility’s advertised rack density leaves important questions unanswered: what happens during maintenance, how the system responds to..
# AI Colocation Cooling: How US Neoclouds Specify Liquid-Cooled Multi-Tenant Capacity
A neocloud can secure colocation space and electrical capacity yet still lack the cooling conditions its GPU racks require. An advertised rack-density figure leaves critical questions unanswered: what happens during maintenance, how the system responds to a leak, and whether the next hardware generation will fit the existing thermal architecture. For multi-tenant AI deployments, cooling must be specified around the actual GPU platform rather than density alone.
US Deployments Make the Questions Concrete
Recent US projects illustrate how these specifications are being applied in practice. Switch has announced a liquid-cooled NVIDIA GB300 NVL72 deployment for CoreWeave. Meanwhile, TeraWulf’s Lake Mariner campus in New York is integrating Motivair by Schneider Electric cooling equipment across three buildings to support cloud-provider tenants. These deployments highlight the need to coordinate rack-level cooling with facility-wide heat rejection while defining clear interfaces between colocation providers and neocloud operators.
Define the Service Boundary First
Multi-tenant AI capacity involves two distinct relationships. A colocation provider hosts a neocloud’s infrastructure, and that neocloud may then serve multiple customers through its platform. A customer’s logical cloud environment does not automatically require a dedicated physical cooling loop.
The practical requirement is to define how cooling events affect the infrastructure supporting those customers. A rack, branch, row, or pod may form an isolation boundary, and each choice changes how much capacity is exposed to a maintenance activity or fault. Before selecting equipment, the colocation provider, neocloud, specifier, and contractor should agree on who owns the coolant distribution units (CDUs), manifolds, hoses, coolant monitoring, and emergency response. Those responsibilities belong in the design and service agreement, with measurable delivery conditions at the handoff between facility and IT cooling.
The service agreement should also describe a cooling-service breach in measurable terms. Temperature, flow, pressure, duration outside tolerance, and affected capacity provide measurable criteria. Agreed measurement locations and escalation procedures give both parties a shared basis for responding when delivered conditions move outside the equipment’s approved limits.
Specify an Operating Envelope for the Actual GPU Platform
A rack-density figure is useful only alongside the conditions under which cooling can deliver it. The AI colocation cooling specification should identify facility-side and technology-side supply and return temperatures, required coolant flow, pressure limits, system pressure drop, approved coolant chemistry and wetted materials, heat captured by liquid, and any remaining air-cooled load. Performance must be defined for normal operation, maintenance, and defined equipment failures.
These inputs establish whether the complete cooling path can support the proposed installation. A CDU’s nominal capacity cannot compensate for inadequate facility flow or insufficient outdoor heat rejection. At the densities delivered by platforms such as NVIDIA’s Vera Rubin, the rack, coolant distribution, facility plant, and electrical supply require coordinated engineering.
The liquid-to-air heat split also varies by platform and configuration. Operators should obtain requirements for their actual equipment rather than carry a fixed percentage from an earlier installation into a new specification. Before reserving adjacent racks for a second GPU platform, a neocloud should check its temperature, flow, and coolant requirements against the existing cooling envelope. Floor space alone cannot establish compatibility.
Make Rack Isolation and Maintainability Explicit
Rack-level monitoring and isolation controls are especially important in shared infrastructure. Designs should allow operators to monitor flow, temperature, pressure, and leaks and isolate an affected rack or branch without unnecessarily disrupting neighboring capacity. A procurement specification should state what happens after an alarm, including valve closure, workload shutdown requirements, and the capacity that remains operational while the affected section is drained, repaired, and recommissioned.
Maintenance access deserves the same attention as fault response. Shared infrastructure needs accessible isolation points, documented fluid-handling procedures, and an agreed method for returning serviced equipment to operation. The Open Compute Project’s modular technology-cooling guidance provides a useful framework for branch isolation, cleanliness, and future adaptation.
Follow the Heat Through the Facility
Liquid cooling moves heat through several interfaces before it leaves the site, and each interface needs a defined duty, operating condition, and owner. In a liquid-to-liquid architecture, CDUs transfer heat between the technology coolant circuit and facility water while separating those circuits. Direct-to-chip accessories, including in-rack manifolds and hose kits, complete connections near the IT equipment and need compatible materials, pressure ratings, and service access.
Chillers and heat rejection equipment handle the downstream thermal duty. Selection depends on rack requirements, facility-water temperatures, local design weather conditions, and resilience strategy. A system specified for a Texas site needs assessment against that site’s conditions even if its rack layout matches a New York deployment. Warmer coolant can create opportunities for economization, but direct-to-chip cooling does not automatically eliminate chillers. Energy and water performance depend on the complete heat-rejection design.
Evaluate Retrofit Options Against Remaining Capacity
Heat Dissipation Units (HDUs) provide a liquid-to-air path where an appropriate facility-water connection is unavailable. Motivair by Schneider Electric’s HDU transfers heat from liquid-cooled equipment to room air, meaning the existing air-cooling system must carry that additional load. Rear-door heat exchangers (RDHx) capture heat from rack exhaust air and transfer it to a liquid circuit, supporting hybrid environments with residual air-cooled loads subject to equipment and facility compatibility.
For a neocloud leasing space in an existing air-cooled hall, an HDU may provide a connection path for liquid-cooled servers, but the assessment must establish room-level cooling headroom. A rear-door approach requires a suitable liquid heat-removal path. Both decisions should follow a site assessment before capacity is committed to customers.
Build Repeatable Expansion Around Defined Interfaces
The useful unit of expansion may be a row or pod with defined electrical, thermal, control, and service interfaces. Prefabricated modular IT pods can organize that infrastructure into a repeatable deployment framework, provided the selected configuration supports the intended equipment and cooling design.
As capacity grows, additional racks change flow demand and pressure conditions, while a new GPU platform may change temperatures, fluid requirements, or the air-cooling load. Design teams should identify what can remain standard and what requires reassessment for each phase. Reserve connection points, document expansion limits, and align cooling increments with electrical capacity.
Test Under Representative Operating Conditions
Acceptance testing should demonstrate how the installation behaves when compute, power, controls, and cooling operate together. The project team should agree on tests for sustained load, changing load, partial occupancy, and selected failure or maintenance scenarios. Relevant measurements include rack-inlet coolant temperature, flow, pressure, alarms, and recovery behavior, with acceptance limits tied to the hardware requirements.
For a shared loop, test an isolation event and confirm conditions at neighboring racks. For phased construction, establish how a new section will be flushed, checked, connected, and commissioned alongside operating capacity. Handover should document control sequences, alarm ownership, maintenance procedures, and escalation paths so the operations team has a clear basis for protecting service after construction ends.
Apply an End-to-End Approach to Shared AI Capacity
TeraWulf’s Lake Mar
MegaWatt Intelligence Desk
Hyperscale & Grid Analyst. `More stories by $MegaWatt Intelligence Desk →`
