AI heeft de koelkring herschreven. Dit moet debietregeling eraan doen.

Two years ago, a data hall meant rows of warm servers cooled by chilled air pushed under a raised floor. Engineers commissioned each cooling cabinet once and walked away. The shared cold-water header had headroom — small imbalances in flow between cabinets disappeared into thermal margin. Heat density was modest, perhaps five to ten kilowatts per rack at the high end. The loop forgave.

Today, a data hall means rows of liquid-cooled cabinets, each one its own thermal microclimate. The shift was not gradual.

This is an article about what happens to the cooling loop when one cabinet draws more heat than an entire row used to — and about the unsung component that decides whether the loop survives the change.

The cooling loop that used to forgive

A traditional data-center cooling loop is a shared system. One cold-water main feeds a manifold; the manifold distributes to several cooling cabinets sitting in adjacent rows. Each cabinet pulls its design flow rate from the manifold and returns warmed water to a return header. The chiller plant absorbs the heat from the return water. A cooling tower sheds it to the atmosphere.

This architecture worked because the design conditions were stable. Air-cooled racks at five to ten kilowatts each could be cooled by chilled air at room temperature. Heat changed slowly across a day. If one cabinet pulled five percent more flow than another, the other quietly compensated. The thermal margin was wide enough that an engineer commissioned the system once at startup and the system held its commissioned state for years.

Any hydronic engineer recognises this loop. It is the same shared-header architecture that distributes chilled water in commercial HVAC, that feeds parallel branches in district cooling, that supplies process water to multiple consumers in an industrial plant. The forgiveness is what made it the default architecture.

What AI did to the loop

The arrival of dense GPU clusters changed the heat density per rack by an order of magnitude. NVIDIA H100 racks pushed cabinet loads to fifty kilowatts and above. Blackwell-generation racks for AI training cross one hundred kilowatts and continue upward. The cooling cabinet, formerly a passive thermal node, became an active thermal control system — a coolant distribution unit (CDU) pulling precise, ramping flow on demand.

Liquid cooling, until recently exotic, became standard. The liquid cooling market approached three billion dollars in 2025 and is forecast to approach seven billion dollars by 2029 as AI deployments accelerate. Vertiv, Panasonic, and Schneider Electric all launched new CDU product families targeted at high-density AI workloads during the first half of 2026. The hardware caught up. The cooling loop architecture, in many sites, did not.

Why shared headers break

The mechanical problem is straightforward. When one cabinet ramps up — a training run starting on a GPU cluster — its CDU pulls more water from the shared manifold. Pressure across the manifold drops. The neighbouring cabinets, through no fault of their own design or commissioning, quietly under-circulate. Their CDUs see less coolant than they need, push the return water hotter than design, and watch their internal thermal margins collapse.

Some CDUs compensate by ramping their own pumps higher. Some do not. Either way, the manifold becomes a battlefield: every cabinet competing for finite supply pressure. Supply temperature rises. The chiller plant works harder to recover it. The cooling tower, the last component in the heat-rejection chain, increases its bleed-off rate. More water leaves the system as blowdown. More energy goes into replacing it.

At campus scale, the cost is measurable. Data centers across the United States may require between 697 million and 1.45 billion gallons of additional water capacity per day by 2030 — the upper bound approaches New York City’s daily municipal water supply. Not all of that demand is preventable. A meaningful fraction, however, comes from systems running outside their design operating envelope because the architecture cannot hold per-cabinet flow steady under variable load.

Pressure-coupled flow — the silent failure mode

A CDU pulling water from a shared manifold is pressure-coupled to its neighbours. When their flow changes, its flow changes too — whether the designer wanted that or not. The CDU’s onboard control logic does not see the manifold pressure shift; it sees only the flow rate change downstream of its own pump. By the time the CDU adjusts, the upstream condition has already shifted again. The control loop chases an upstream variable it cannot directly observe.

This is what we call Pressure-Coupled Flow — a field condition, not a textbook category. It is the default state of any shared-loop cooling system without flow-control intervention at the cabinet level. In traditional HVAC, pressure-coupling produced commissioning drift, perpetual room-temperature complaints, and the recurring callbacks that gave hydronic balancing its bad reputation. In AI data center cooling — where thermal margins are thinner and load changes are abrupt — pressure-coupling produces accelerated equipment wear, intermittent thermal shutdowns, and water waste that scales linearly with site capacity.

The fix is not bigger pumps. Bigger pumps move the problem to a different operating point on the curve; they do not solve the coupling between cabinets. The fix is to make every cabinet hydraulically independent of every other cabinet. Decouple the cabinet from the manifold, and every CDU operates as if it were alone on the loop.

The Over-Circulation Penalty

The second-order consequence of pressure-coupling is what we call the Over-Circulation Penalty. Cabinets that over-pump to compensate for pressure swings push more water through their heat exchangers than the thermal load requires. The water-side ΔT across the cabinet collapses. The chiller plant, designed for a specific return temperature, sees colder return water and operates at lower efficiency. The cooling tower bleeds more water per kilowatt of heat removed than the design calculations assumed.

Multiply by fifty cabinets in a row, ten rows in a hall, eight halls on a campus. The Over-Circulation Penalty becomes the dominant water-loss mechanism on a high-density AI site — and it is invisible on the facility energy bill until someone runs a mass balance on the cooling tower. By then, the campus has been paying for it for months.

Decoupling at the cabinet

A passive constant flow valve — a cabinet flow regulator, in the per-context terminology — installs directly in the cabinet pipework upstream of the CDU. It holds the cabinet flow rate constant regardless of what is happening at the manifold. The valve is mechanical: a rubber element deforms against a conical seat in proportion to upstream pressure, opening or closing the flow path to maintain the pre-set flow rate. No electronics. No PID tuning. No commissioning step.

The implications are operational, not just thermal:

• Each cabinet operates within its design thermal envelope regardless of neighbouring cabinet load.
• Manifold pressure swings are absorbed by the regulator, not by the CDU control loop.
• Cooling tower blowdown returns to design rate.
• ΔT across each cabinet returns to design specification, and chiller efficiency returns to its rated curve.

The cabinet-level thermal envelope is governed by ASHRAE TC 9.9 thermal guidelines for data processing environments — the reference document for cabinet supply, return, and approach temperatures. A correctly-sized cabinet flow regulator is the simplest mechanical assurance that those guidelines are actually met under variable load, not only at commissioning.

The proof point

Bertfelt’s case study, Controlling the water flow rate inside a cooling system, describes BT-Maric Insert-Type Flow Control Valves installed directly in cooling cabinet pipework. Pre-set flow holds steady regardless of upstream pressure variation, protecting the sensitive electronics in the cabinet and the chiller plant downstream. The case study documents the standard application. This article describes why that standard application now matters at every cabinet on every campus, not only the ones a careful engineer remembered to specify.

Frequently asked questions about data center flow control

How is a constant flow valve sized for a specific cabinet thermal load?

The valve is sized from the design coolant flow rate, which is itself derived from the cabinet thermal load (kW) and the design water-side ΔT. A 50 kW cabinet at a 5 °C design ΔT requires roughly 143 L/min of coolant; the constant flow valve is specified at that flow rate. The valve holds it across the operating pressure range, regardless of upstream variation.

Where in the cooling cabinet pipework should the valve install?

Upstream of the CDU, on the supply side of the cabinet, after any isolation valve and before any in-cabinet filtration. The objective is to place the regulator between the variable upstream condition (the manifold) and the controlled downstream condition (the CDU). Insert-type variants are designed for installation inside existing cabinet pipework without modifying the cabinet enclosure.

Can the valve be retrofitted into existing data halls, or only specified in new builds?

Retrofit is the more common installation pattern. The Insert-type variant fits inside existing pipework with a flange-to-flange dimension that matches standard inlet connections. Retrofit campaigns typically run cabinet by cabinet during scheduled maintenance windows without interrupting hall operation.

What pressure differential is required for the regulator to enter its operating range?

A minimum ΔP of approximately 1.4 bar across the valve is required for the rubber element to deform into its regulating position on standard Precision rubber. Below that, the valve passes flow without regulating — the mechanism is paused, not failed. Maximum ΔP on the standard compound is 10 bar. For high-pressure cooling loops or sites with extreme pump curves, alternate rubber compounds extend the range up to 20 bar.

Is the valve compatible with the glycol-water mixtures used in liquid cooling?

Yes, with appropriate rubber compound selection. The standard Precision compound is compatible with typical propylene-glycol blends used in data-center cooling. For high-concentration glycol or aggressive treated water chemistry, EPDM or Viton variants are specified. The mechanism is the same; the rubber is selected for the fluid.

How does this compare to using a PICV for cabinet flow control?

A pressure-independent control valve (PICV) is active — it includes a flow sensor, an actuator, and a controller. It performs essentially the same function in a different way, with different trade-offs. The mechanical constant flow valve has no power requirement, no commissioning step, no firmware, and no failure modes that depend on sensor calibration. In data center cooling, where thousands of cabinets need identical flow-control behaviour and any control-system fault has thermal consequences within seconds, the passive mechanism is the simpler engineering assurance.

The cooling loop that AI demands is not a different loop. It is the same shared-header architecture under a different set of operating conditions. The difference is whether each cabinet is decoupled from the manifold. BT-Maric Constant Flow Valves — in Insert form for cabinet pipework, in Threaded form for branch-level distribution, in Wafer form for main lines — are the mechanism that does the decoupling. The Bertfelt case study on cooling system flow control is the existence proof. The article above is the reason every high-density site now needs one.