Building the Right Foundation for Liquid Cooling Design

The race to deploy AI infrastructure is putting unprecedented pressure on data center operators to bring high-density compute capacity online quickly. But while deployment timelines are shrinking, the infrastructure needed to support these workloads is becoming more complex.

There’s nowhere that this tension is more apparent than liquid cooling. Many of today’s organizations are deploying liquid cooling technology for the first time, and they’re finding themselves navigating an industry that is still developing common standards and best practices. To make matters worse, experience with traditional HVAC, chillers, and air-based cooling architectures doesn’t readily translate to cooling high-density IT equipment at the chip level.

This tension reveals a truth that operators are now facing: the faster organizations need to deploy liquid cooling, the more important it becomes to get the foundation right.

That means looking beyond individual components and approaching liquid cooling as a single, interconnected system. And in this system, decisions about the workload, facility, coolant distribution units (CDUs), technology cooling system (TCS), and controls all influence one another in complex and meaningful ways.

In this first installment of our three-part series on liquid cooling at AI scale, we’ll be looking at some of these factors and highlighting the overarching principles required to get liquid cooling design right from the ground up. This blog post will provide a high-level overview of the more in-depth, technical guidance in our latest whitepaper, Building the Right Foundation for Liquid Cooling Design, co-authored by some of our own LiquidStack experts and our partners at data center design firm Leading Edge Design Group (LEDG). If you find this blog post helpful, be sure to check back in the coming weeks for our next installment, along with the second whitepaper in our ongoing series, “Liquid Cooling at AI Scale: Lessons from the Field”.

Now, on to the learning…

Start With the System, Not the Components

One of the easiest mistakes to make when approaching liquid cooling is treating it primarily as an equipment-selection exercise. Determine the IT load, buy enough cooling capacity to support it, and connect the pieces. But, in practice, liquid cooling requires a much more intentional, holistic approach.

Unlike traditional air-cooled environments, where cooling can be addressed more uniformly at the room level, liquid cooling creates a much closer relationship between the IT equipment and the infrastructure supporting it. Data hall design can influence how the system responds to failure. Facility water conditions can affect CDU performance. And the TCS determines whether cooling is actually delivered effectively to the racks. And all of those decisions must ultimately align with the thermal requirements of the given workload.

This is why liquid cooling design needs to begin with an understanding of the complete system at work. Optimizing individual components does not necessarily produce an optimized (or resilient) liquid cooling environment. 

Design for Failure, and for What Comes Next

Successful liquid cooling designs must account for situations that go beyond normal operating conditions. 

Consider redundancy. A deployment might use an N, N+1, or fully redundant 2N architecture depending on workload criticality, acceptable failure scenarios, cost, and a host of other requirements. However, there is no universally correct answer. What matters is taking into consideration and truly understanding the trade-offs involved, and designing in accordance with the level of operational risk the organization can tolerate.

A closely related consideration is the system’s blast radius, or how much infrastructure could be affected by a single failure. As cooling becomes more tightly coupled to IT equipment, data hall layouts and TCS architectures should be designed to contain failures wherever possible, rather than allowing one problem to compromise a larger compute cluster. And in order to do so, one must once again look at one’s deployment at a holistic, system-wide level. 

But resilience is about more than just preventing failure. It’s also about being able to adapt to change. AI hardware is evolving rapidly, and the rack densities a facility supports today may not reflect what it will need to accommodate over the next handful of hardware generations. 

Designing too narrowly around current requirements can create constraints that are difficult and expensive to correct later on. The foundation therefore needs to support both what can go wrong and what might change down the road.

Think of the CDU as a Bridge, Not an Island

Nowhere is the importance of system-level design clearer than with the CDU. It can be tempting to evaluate a CDU primarily based on its nameplate cooling capacity. But the CDU sits at the center of a much larger system, translating conditions on the facility side into stable cooling for IT equipment.

That means selection depends on more than megawatts. Capacity and flow requirements are driven by the IT load, while pressure requirements are influenced by piping, fittings, cold plates, and the system’s physical layout. Facility water temperatures and pumping configurations introduce another set of variables. Controls must then enable the CDU to respond appropriately as those conditions change.

The takeaway here is simple but significant: CDU selection shouldn’t be relegated to procurement after the broader architecture has already been decided. Instead, it should be treated as a critical part of the design process itself. A CDU that performs well in isolation may still underperform if it is poorly matched to either the facility supplying it or the IT infrastructure it is expected to cool.

Don’t Lose Sight of the Last Mile

Generating and controlling cooling is only part of the equation. That cooling still has to consistently and reliably reach the IT equipment it’s meant to support.

The TCS (i.e., the piping and distribution network connecting the CDU to the rack) is where that happens. Pipe sizing, flow, pressure, materials, coolant compatibility, filtration, and balancing can all influence how effectively the system performs.

Pressure differences, for example, can cause some racks to receive insufficient flow while others are oversupplied. Inadequate filtration can create blockages in downstream components with strict particle-size tolerances. Material incompatibility can contribute to corrosion or contamination over time.

In other words, having enough theoretical cooling capacity is not enough. Overall performance can ultimately be won or lost in the space between the CDU and the rack it serves.

Liquid Cooling Design Is Also an Ownership Question

Some of the most consequential liquid cooling design questions aren’t purely technical. In traditional air-cooled environments, operators generally controlled the cooling infrastructure from the chiller plant through the data hall. Liquid cooling complicates that model because infrastructure extends much closer to (and interacts more directly with) the IT equipment itself.

That raises a number of novel questions. Questions like: Who owns the equipment? Who monitors its performance? Who is authorized to adjust operating parameters? And how is visibility shared between operators, tenants, and other stakeholders?

The last thing a deployment needs is for those boundaries to be discovered (and likely first debated) during operations. Instead, clear roles and responsibilities should be established during the design phase. Remember, technical integration without clear operational ownership can create its own class of risks.

Build the Foundation Before You Build the System

Liquid cooling asks operators to make more interconnected decisions earlier in the infrastructure lifecycle. Complicating matters further, those decisions sometimes must be made before every detail of the eventual IT environment is known.

Eliminating uncertainty isn’t possible. Instead, it should be actively managed through informed assumptions, collaboration among stakeholders, and designs that adapt as requirements evolve.

Getting that foundation right can make the difference between infrastructure that simply meets today’s specifications and a liquid cooling architecture capable of delivering resilient, scalable performance over time.