“Liquid-cooled” describes part of a heat-removal system. It does not fully specify the facility surrounding it. A useful explanation begins at the component, follows the coolant path, and ends where heat is released or reused. Otherwise, two very different designs can appear equivalent under the same label.

Berkeley Lab documents a high-performance computing retrofit using water-cooled cold plates on heat-producing components, with the remaining heat removed by air. The case is a concrete reminder that liquid and air cooling can coexist. It does not establish that every server component, or every facility, uses the same arrangement. [1]

NVIDIA describes a direct-to-chip design in which a technology cooling loop transfers heat through a coolant distribution unit and a heat exchanger to the facility loop. Capturing heat near the component is therefore only one stage; the facility still needs a way to remove that heat from its own system. [2]

Water can circulate through a loop without being continually evaporated. Microsoft describes a datacenter design that recirculates water through a closed-loop, chip-level cooling system without evaporation for cooling. That is Microsoft’s description of a particular design, not a claim that all its facilities—or all liquid-cooled facilities—operate identically. [3]

By contrast, the US Department of Energy describes conventional cooling towers that reject heat through evaporation. The difference is important: asking whether liquid reaches the chip is not the same as asking whether the facility consumes water to reject heat outdoors. [4]

Our interpretation is that environmental claims need a measurement boundary. Does “zero water” concern cooling operations, the entire site, or a broader lifecycle? Does the number exclude electricity generation and manufacturing? A narrow claim may be accurate and still be mistaken for a much broader one. The boundary should travel with the number.

A cooling system must be tested as a working system. Berkeley Lab’s commissioning research describes leak-pressure tests, checks of flow and valve operation, and simulated loads. The authors emphasize that interrupted fluid flow can threaten liquid-cooled equipment. This is an operational requirement, not merely an installation detail. [5]

For a deployment discussion, we would ask who owns the cooling loop on each side of the interface, who responds to an alarm, how maintenance is coordinated and what happens during a component failure. These are diligence questions, not claims that a particular provider lacks a safe design.

Our view is that cooling should be evaluated as part of an infrastructure plan. A useful supplier response would identify the supported equipment, intended load, cooling interface and operating conditions, then separate measured performance from design targets. Broad claims about efficiency should not be transferred to a different climate, workload or facility without evidence.

The same principle applies to cost. A component-level improvement does not by itself calculate a customer’s total bill or the environmental impact of a completed AI task. Those require a stated system boundary and workload measurement. This article does not assign a universal saving to liquid cooling or rank specific sites.

The opportunity is not simply to make a rack colder. It is to make the relationship between IT hardware and facility engineering explicit enough that buyers can understand what is being delivered. That is the conversation a credible cooling specification should enable.