The cooling capacity written into an AI data center specification can look reassuringly precise. Yet the number alone says surprisingly little about how much high-density computing the facility can support. A site may already have chillers, heat exchangers, pumps, coolant distribution units and substantial heat-rejection equipment. Only part of that infrastructure may serve a particular cluster under its required operating conditions. Liquid-cooled systems make this distinction important because thermal performance depends on several connected variables rather than one equipment rating.

Flow rate, supply temperature, return temperature and pressure differential all influence what the system can support. Heat-exchanger approach and the thermal requirements of the IT equipment matter as well. ASHRAE guidance notes that facility water flow and pressure-drop requirements vary between configurations. Manufacturers typically specify those requirements for particular equipment arrangements. A CDU also sits between facility infrastructure and the technology cooling loop in many direct-liquid-cooling architectures. Buyers therefore need evidence that the complete thermal path can remove the heat generated by their intended computing environment.

Installed Equipment Does Not Automatically Define Deployable Capacity

A useful starting point is to distinguish physical cooling assets from the operating envelope they can deliver. A CDU can have a megawatt-scale thermal rating. That rating still applies under defined hydraulic and thermal conditions rather than every possible temperature and flow combination. Open Compute Project’s Deschutes specification illustrates the relationship clearly. Its 2 MW CDU design also specifies 500 GPM on the IT side, facility flow parameters and a 3°C approach temperature.

Those accompanying values describe conditions associated with transferring the specified heat load between cooling loops. Changes elsewhere can alter conditions available at the CDU or rack while the installed unit remains unchanged. Pipe dimensions, control settings and pump operation can affect hydraulic performance across a distribution network. Shared-loop behavior can influence it too. Facility-side temperature also matters because the heat exchanger must maintain suitable technology-side temperatures. However, nominal heat-transfer equipment does not establish that every rack position can simultaneously receive the required thermal service. Installed capacity should remain an equipment measure until engineering analysis connects it to an achievable operating state.

The Cooling Chain Matters More Than a Single Nameplate

Direct liquid cooling shows why capacity cannot be understood by examining one component in isolation. Heat moves from cooled components into a technology cooling loop. It then passes through distribution equipment and heat exchangers before reaching the facility heat-rejection system. Each stage needs compatible temperatures, flow characteristics and hydraulic conditions to operate as designed. ASHRAE specifically notes that facility designers must account for CDU approach temperature. This calculation helps ensure that liquid reaches IT equipment at the appropriate temperature.

Open Compute Project also treats CDU integration as a facility-level engineering problem. Its work covers connections between advanced cooling systems and facility water systems. Operating conditions outside the requirements of connected equipment can limit the supported deployment. An upstream component can retain its nominal rating while this occurs. The relevant question is therefore not simply how much cooling machinery exists inside the property. Buyers need to determine how much heat can move continuously from their racks through the complete thermal chain. Every required operating limit must remain satisfied during that process.

Flow Can Become a Capacity Constraint

Thermal megawatts often dominate discussions because they provide a convenient measure of facility scale. Liquid systems also depend directly on coolant movement. Heat removal through a liquid loop depends on mass flow and the fluid’s thermal properties. The temperature rise between supply and return also matters. A system designed around a particular flow regime cannot automatically support arbitrary increases in rack heat load. Engineers need to examine those relationships before assigning additional capacity.

The Deschutes CDU specification links its 2 MW thermal load with defined flow and pressure requirements. That relationship demonstrates why hydraulic information belongs beside thermal ratings. Pump capability must support the required operating point. Piping and connected components also introduce pressure losses that the system must overcome. Different IT configurations may impose different flow and pressure-drop requirements, as ASHRAE guidance recognizes. Therefore, a megawatt shown on a cooling schedule cannot prove that sufficient coolant reaches the assigned racks. Capacity becomes operational only when thermal and hydraulic requirements can be satisfied together.

Temperature Determines What the Same Infrastructure Can Support

Supply temperature adds another dimension because liquid-cooled IT depends on the temperature delivered by the cooling system. ASHRAE’s liquid-cooling classes include W17, W27, W32, W40, W45 and W+. These classifications give designers a common framework for matching IT capability with facility conditions. Equipment supporting one thermal envelope cannot automatically support another. Engineers first need to check the specified operating requirements. Temperature differences introduced between loops also need consideration when a CDU separates facility water from the technology cooling system.

ASHRAE states that designers need to account for the planned CDU’s approach temperature. Doing so helps ensure that the correct liquid temperature reaches IT equipment. Outdoor conditions and heat-rejection architecture can influence facility-side temperatures across different operating periods. Temperature can limit a configuration when facility conditions cannot deliver coolant inside the IT equipment’s specified thermal envelope. This constraint can exist even though heat-transfer and pumping equipment remains installed. AI capacity assessments should therefore identify the temperatures under which claimed cooling output remains achievable. That approach makes the thermal envelope visible before hardware deployment reaches commissioning.

AI Racks Are Making the Difference More Material

The distinction becomes commercially significant as rack-scale AI systems concentrate large electrical and thermal loads into small footprints. NVIDIA documents the GB300 NVL72 as a liquid-cooled rack-scale architecture. It contains 72 Blackwell Ultra GPUs and 36 Grace CPUs. Its enterprise reference architecture states that a full rack can require up to 142 kW. That figure illustrates the infrastructure intensity associated with current high-density systems. Cooling planning at these densities cannot rely solely on assumptions developed around lower-density racks spread across a data hall.

A small number of racks can place concentrated demands on piping branches, CDU capacity and pumps. Facility heat rejection must accommodate those loads as well. Cooling systems must also handle the portion of rack heat that remains air cooled. Liquid cooling does not necessarily remove every watt through the liquid circuit. NVIDIA’s simulation metadata for a GB300 rack models both liquid and air cooling components. Uptime Institute also notes that direct liquid cooling adds piping, CDUs and operational boundaries to facility infrastructure. The practical question is whether the exact cooling configuration can support the proposed deployment’s density and topology.

Redundancy Changes the Capacity Available for Customer Commitments

Another gap can emerge when theoretical maximum output gets compared with capacity available during maintenance or equipment failures. Cooling infrastructure for critical environments often includes redundant components. These arrangements aim to preserve service when part of the system becomes unavailable. The Deschutes specification addresses high-power dense IT pods. OCP-listed implementations based on it can include N+1 pumping arrangements and redundant power feeds. Those resilience features serve a different purpose from maximizing the quantity of connected cooling hardware.

A design may reserve components specifically to maintain service during an outage or maintenance activity. Capacity planning needs to preserve that redundancy instead of treating reserved equipment as normal customer capacity. Planned servicing deserves similar attention because pumps, heat exchangers, controls and heat-rejection equipment require maintenance. Buyers should ask how much cooling remains available when the facility enters its defined maintenance configuration. Normal-state output alone cannot answer that question. Available capacity may differ from the sum of installed nameplates where common infrastructure supports several halls or clusters. Separating these operating states provides a clearer basis for sustained capacity commitments.

Shared Cooling Creates Allocation Questions

Many AI deployments operate inside facilities that also support other customers or legacy computing environments. Some sites also contain several cooling architectures. An installed plant may therefore serve multiple loads whose demands change over time. Allocation becomes as important as equipment quantity in these environments. Uptime Institute has noted that operators increasingly prefer standardized approaches to liquid cooling rather than isolated systems for individual IT deployments.

Shared infrastructure can simplify facility design, but capacity still depends on how operators manage common thermal resources. A buyer assigned rack space needs corresponding flow, CDU service and upstream heat rejection. Electrical capacity and physical rack availability cannot establish readiness if the thermal path remains constrained elsewhere. An additional high-density rack requires its cooling branch to satisfy the specified thermal and hydraulic requirements. Upstream infrastructure must support those conditions as well. Operators can manage these dependencies through engineering and allocation controls. Customers still need enough evidence to understand the basis of the promised deployment capacity.

Retrofit Sites Require Particular Attention

Existing data centers can introduce liquid cooling without rebuilding every part of their original mechanical architecture. Retrofit options still depend on the infrastructure already available. Schneider Electric’s reference designs illustrate liquid-to-air and liquid-to-liquid CDU approaches for high-density AI clusters. Its documentation presents liquid-to-air CDUs as an option where facility water systems are unavailable. Liquid-to-liquid CDUs apply where a connection to facility water exists.

Those alternatives show how the same objective can place heat into different downstream systems. Available capacity must reflect the architecture actually selected rather than a generic assumption about the cooling plant. A retrofit may also place concentrated new loads alongside traditional air-cooled equipment. That arrangement can create simultaneous demands across separate or interacting cooling systems. Engineering teams need to trace where each load sends its heat. They must then confirm that downstream infrastructure can accommodate the resulting operating state. Customers should also identify which thermal systems are new, shared or still subject to legacy constraints.

Commissioning Should Prove the Thermal Path

Design calculations establish whether an architecture should work. Commissioning tests whether installed systems actually behave as intended before customer workloads depend on them. For liquid-cooled environments, that verification should extend across relevant interfaces. Individual equipment simply powering on does not complete the process. Pump operation, flow control, pressure conditions, temperatures, alarms and controls all contribute to the thermal service delivered to IT.

OCP’s cooling work focuses on integrating advanced cooling solutions into data center facilities. That work reflects the importance of connections between facility systems and liquid-cooled computing equipment. Flow, pressure and temperature conditions depend on the behavior of the connected cooling network. System-level commissioning can verify whether relevant branches achieve their specified design conditions under representative operating states. Testing can also examine defined abnormal or maintenance conditions where redundancy becomes important. Moreover, measured performance provides operators with a stronger basis for assigning capacity than equipment schedules alone. Customers can then ask which measurements establish the supported operating envelope.

Monitoring Needs to Follow the Same Boundaries

Cooling conditions continue to change after a cluster enters service. Workload, control behavior, maintenance states and environmental conditions can all influence system operation. Monitoring should therefore cover variables that define the thermal operating envelope. Plant status or room temperature alone provides an incomplete picture. Supply and return temperatures show how the liquid loop behaves thermally. Flow and differential pressure help describe hydraulic conditions at relevant points.

CDU controls commonly manage variables such as flow, temperature and pressure difference. Those measurements are central to liquid distribution. Alarm states and component availability add operational context because a system can remain online with reduced resilience. Historical telemetry can also help operators separate persistent capacity limitations from temporary conditions. Customers do not necessarily need unrestricted access to every facility sensor. Shared environments can make that impractical. A more workable approach is evidence that providers monitor variables tied to the promised cooling service. Defined intervention thresholds can then support operational management.

Hardware Refreshes Can Change the Cooling Equation

AI infrastructure rarely remains fixed for the full life of a data center. Cooling commitments should therefore account for hardware changes as well as the initial deployment. New rack architectures can change one or more operating parameters. These can include power density, liquid-temperature requirements, heat capture and flow requirements. The balance between liquid and air cooling can change as well. Uptime Institute’s September 2026 analysis notes that facilities may experience overlapping IT hardware cycles from different vendors.

That pattern creates a reason to develop standardized liquid-cooling infrastructure. Standardization can improve adaptability, but it does not remove the need to confirm compatibility with each hardware generation. ASHRAE notes that flow and pressure requirements vary among datacom equipment configurations. A cooling system suitable for one rack cannot automatically provide equivalent capacity for its successor. Direct liquid cooling alone does not establish compatibility. Procurement teams should include thermal requirements in hardware-refresh planning before committing future compute density. Providers can support this process by documenting the temperature, hydraulic and heat-load envelope available at the customer boundary.

Capacity Contracts Need Better Thermal Definitions

Commercial agreements for high-density AI infrastructure can become clearer when they describe measurable cooling conditions. Broad readiness language provides less technical precision. A useful schedule could identify supported rack heat loads, supply-temperature ranges and required flow conditions. It could also define infrastructure boundaries and the resilience state associated with the commitment. Those values should correspond to the hardware configuration that the customer intends to deploy. A generic maximum from one component provides less useful information.

Contracts can also clarify responsibility where facility water, CDUs and technology cooling loops cross organizational boundaries. IT hardware introduces another boundary. Uptime Institute has identified blurred service-level boundaries as an operational effect of direct liquid cooling. Clear definitions matter because a thermal excursion can originate at different points in the system. A measurable framework helps both parties identify which operating condition failed. Change-control provisions can require reassessment after material changes to rack configuration or coolant requirements. Relevant facility modifications can trigger the same review. This structure gives cooling commitments a technical basis that can follow the deployment through operation.

AI Buyers Need a Cooling Evidence Package

An end user does not need to redesign a provider’s mechanical system to perform meaningful due diligence. It does need evidence connecting reserved compute capacity with a supportable thermal configuration. That evidence can start with the rack design load. Documentation can identify how much heat enters the liquid circuit and how much remains in air. It can also show which infrastructure removes each portion. The provider can then describe the relevant CDU arrangement, temperature envelope and flow assumptions.

Redundancy and the upstream heat-rejection path should form part of the same technical picture. Commissioning results can demonstrate whether the configuration achieved its required conditions. Operational telemetry can show whether those conditions remain observable after deployment. Capacity documentation should distinguish normal capability from availability during defined maintenance or failure states. Shared infrastructure also requires controls that prevent overlapping allocations from exceeding supported conditions. Hardware changes should trigger another compatibility check when their thermal requirements materially differ. This evidence gives procurement, infrastructure and engineering teams a common basis for assessing deployment readiness.

Cooling Capacity Has to Become an Operating Metric

Rising AI rack density makes cooling difficult to treat as a background facility attribute. Modern liquid-cooled architectures connect computing performance to a chain of thermal systems. Engineers can measure, design and test the conditions across that chain. Installed chillers, fluid coolers, pumps, CDUs and piping establish the physical foundation. Their presence alone does not define how much computing can operate at a particular location. Flow availability, pressure and supply temperature help determine whether the system can support a deployment.

Approach temperature, heat-rejection capability and redundancy also shape the available operating envelope. Rack-level requirements complete that picture. Current high-density reference architectures increasingly integrate facility cooling, IT space and lifecycle operation in their designs. The distinction matters before capacity gets sold, reserved or accepted. An apparent thermal margin can otherwise become a deployment constraint. Providers can express cooling through validated operating envelopes to give customers a more precise view of supported conditions. AI buyers can then compare compute reservations with the thermal requirements needed to make those reservations operational. Separating installed equipment from deliverable performance makes cooling a quantity that customers can evaluate and manage throughout a deployment.