Why air cooling is hitting its limit in AI GPU data centers
Air cooling was built for a different era of rack density. Legacy enterprise racks drawing 5-10 kW could be kept in thermal range with raised floors, hot/cold aisle containment and enough computer-room air handlers. AI GPU racks don't fit that envelope: training and inference clusters routinely push 40-60 kW per rack today, and the newest accelerator generations are designed to run denser still. Moving that much heat with air alone means more fan power, more airflow, more floor space for mechanical plant — and each of those has diminishing returns long before the rack gets anywhere near the density modern AI workloads actually want.
The practical effect is that air-cooled facilities cap out at a density ceiling well below what AI GPU rack density cooling now requires, which forces operators to spread a given GPU count across more racks and more floor space than the compute itself needs. That adds interconnect distance, networking cost and site footprint to every cluster, and it's the specific mechanical constraint — not general power availability — that liquid cooling for AI data centers is built to remove.
How liquid cooling works: direct-to-chip loops and CDUs
Direct-to-chip cooling data center design replaces most of that air path with a coolant loop that touches the heat source directly. Cold plates sit on top of the GPU and CPU packages themselves, and a dedicated coolant loop — typically a water-glycol mix — circulates across them, carrying heat away at a rate air convection can't match. Because the fluid contacts the component directly rather than relying on ambient air movement around a heat sink, the same rack can run denser and closer to its thermal limits without the airflow bottleneck that constrains air-cooled designs.
A coolant distribution unit, or CDU, sits at the center of that design. It manages flow rate, pressure, temperature and leak detection for the rack-side coolant, and — critically — it separates the fluid circulating through IT equipment from the fluid used to reject heat outside the building. That separation is what makes direct-to-chip cooling a manageable engineering system rather than a single fragile loop, and it's the building block every serious liquid-cooled data center design starts from, including Rinchen's.
Inside Rinchen's double-loop cooling design (IT loop vs. facility loop)
Rinchen's platform is built around a double-loop liquid cooling design: a closed IT-side loop dedicated to the GPU racks, and a separate facility-side loop dedicated to heat rejection, with the CDU as the boundary between them. The IT loop stays isolated from the outside environment, which keeps its coolant chemistry, pressure and cleanliness under tight, consistent control — the conditions GPU and CDU hardware warranties are written around. The CDU transfers heat out of that loop into the facility-side circuit without the two fluids ever mixing.
The facility loop then carries that rejected heat out to dry coolers, with climate-assisted operation used where ambient conditions allow it to reduce mechanical load further. Keeping the two circuits separate means the facility side can be sized, serviced and adjusted for a given site's climate and heat-rejection needs without touching the rack-side loop that GPUs depend on — which is the specific engineering reason a double-loop design is used rather than a single shared circuit.
Design targets liquid cooling unlocks: sub-1.3 PUE and up to 100 kW racks
Power usage effectiveness — the ratio of total facility power draw to power actually delivered to IT equipment — is one of the clearest ways to see what liquid cooling changes. Air-cooled legacy facilities commonly run PUE in the 1.5-2.0 range, most of it lost to fans and mechanical cooling load. By moving heat rejection into a closed liquid loop and reducing dependence on air handling, Rinchen's design target for data center PUE with liquid cooling is below 1.3. That is a design target based on the engineering of the system, not a completed-project performance figure, and actual results depend on site climate, load factor and execution — independent diligence is warranted before relying on it.
The density side of the same design is a target of up to 100 kW per rack, roughly double what a well-run air-cooled facility can sustain and directly enabled by removing the airflow ceiling described above. Higher density per rack means more compute per unit of floor space and per unit of interconnect distance — the inverse of the constraint air cooling imposes — though, again, realized rack density depends on the specific GPU generation, workload and site conditions being deployed.
From grid to chip: renewable power, BESS, and the cooling loop in Rinchen's platform flow
The cooling loop is one stage in a longer chain: renewable grid power and switchgear feed into battery energy storage for grid flexibility, which supplies the liquid-cooled GPU racks, which hand their heat load to the CDU and loop system, which rejects it through dry coolers. BESS absorbs the variability of renewable generation and the bursty power draw AI training workloads are known for, so the liquid cooling system downstream sees a more bounded, predictable heat load rather than sharp transients it has to react to in real time.
That flow is designed as a set of repeatable blocks rather than a one-off build, so the same cooling architecture underpins whichever product a customer is buying — GPU-as-a-Service, reserved AI clusters, IaaS and bare metal, wholesale capacity, or colocation and hosting for a customer's own hardware. The cooling design doesn't change between those products; only the commercial arrangement on top of it does.
Why cooling design shapes deployment speed and CAPEX
Cooling architecture isn't just a thermal decision — it's a delivery-timeline decision. A factory-integrated liquid cooling loop, with cold plates, piping and CDU pre-engineered and tested as a module, can be built and validated off-site in parallel with site works, rather than assembled and commissioned step by step on location the way conventional chillers, air handlers and ductwork are. Conventional data-center builds run 24-36 months end to end; that parallel, modular approach is part of what underlies Rinchen's target of a 3-6 month module deployment window after approvals — a module deployment target, not a claim about the full timeline from first meeting to a commissioned campus, which still includes feasibility, framework agreements and site works.
The same standardization affects capital cost: less site-built air-handling infrastructure, less floor space per kW of IT load, and less bespoke engineering rework between deployments feed into Rinchen's target of a 20-30% CAPEX advantage versus conventional builds. Both figures are design targets, not demonstrated outcomes, and they're still subject to Rinchen's five stop/go decision gates — site and power, demand, design, capital and scale — the same discipline applied to every phase of the platform, cooling included.
