Lower PUE and WUE together, on the cooling plant you already run.
Cooling is the largest controllable overhead in a data center, and the two numbers that measure it, PUE (power) and WUE (water), are usually in tension. Koios runs a reinforcement-learning controller that holds the thermal envelope while continuously trading power against water to the balance you choose. It is hardware agnostic and control-system agnostic, deploys today on top of your existing plant, and starts producing value without ripping anything out.
Most cooling plants are run by rule-based and PID control with fixed setpoints. That control is safe, but it is static: it cannot anticipate the weather, it cannot read a time-of-use tariff, and it has no notion of the power-versus-water trade it makes every minute. When the outside air gets hot, a PID loop simply commands more fan and more water until it saturates, and PUE climbs to its ceiling exactly when energy is most expensive.
Koios replaces that static policy with a learned one. A Proximal Policy Optimization (PPO) agent is trained against a physics model of the hall and a shaped reward that puts thermal safety first, then prices in energy, water, actuator wear and time-of-use cost. The reward is the product's main lever: changing a small set of weights moves the controller along the PUE–WUE frontier, so each site, each season and each tariff gets its own balance. This paper details the PPO setup, the reward shape, and a seven-day seasonal validation showing power and water cut together while the cold aisle never leaves its envelope. Koios is hardware and control-system agnostic, so the same policy framework deploys across every site you operate.
Ai-OPs
·PUE & WUE Optimization01
Two efficiency numbers, pulling against each other
A data center is judged on PUE, total facility power divided by IT power, and increasingly on WUE, litres of water consumed per kWh of IT. Cooling drives both, and the cheapest way to win one is often to lose the other.
Evaporative and adiabatic cooling spend water to avoid running compressors and fans hard, which lowers PUE but raises WUE. Mechanical and air-side cooling spend electricity to keep water down, which does the reverse. Every cooling plant lives somewhere on this power-versus-water frontier, and the right point on it moves constantly, with the outdoor wet-bulb, the IT load, the price of electricity and the local cost or scarcity of water.
Conventional control does not see that frontier. A fan PID holds a cold-aisle setpoint; an evaporative-cooling PID holds a supply-air setpoint; a damper PID chases free cooling. Each loop is locally correct and globally blind. None of them knows that power is expensive at 4 p.m., that the utility is in a drought surcharge, or that there is thermal headroom to coast. So they hold their setpoints by brute force, and on a hot afternoon they saturate, pushing PUE to its ceiling precisely when a demand charge is being set.
Why this is worth solving now
AI build-outs are pushing rack densities and total cooling load up sharply, water-stressed regions are putting WUE under public and regulatory scrutiny, and time-of-use and demand tariffs make when you cool nearly as important as how much. The gap between static control and an optimum that respects all of these signals at once is now large enough to matter on the bill.
A PID can only hold a number. It cannot price energy against water, cannot use thermal headroom, and cannot anticipate a hot afternoon, so it saturates at peak and sets PUE at its worst exactly when power costs the most.
| PUE | Total facility power / IT power. Cooling is the dominant controllable term. |
| WUE | Water consumed / IT energy (L/kWh). Driven by evaporative cooling use. |
| The tension | Spend water to cut power, or spend power to cut water. |
| Moves with | Wet-bulb · IT load · electricity price · water cost |
| PID sees | One setpoint per loop. None of the above. |
FIG. 1: THE CONTROL PROBLEM. Safety is a hard constraint; efficiency is a soft, multi-objective cost that shifts with weather, load and price. A learned policy can optimize the second while guaranteeing the first, which is the gap conventional loops leave on the table.
Ai-OPs
·PUE & WUE Optimization02
Deploys today, on whatever you already run
Koios does not replace your control system; it sits on top of it. It connects to the plant over the protocols already in place, reads every relevant point, and writes optimized setpoints back, first as advice, then in closed loop. There is no new hardware to standardize on and no controller to rip out.
Hardware agnostic
Air-side or evaporative, fan wall or CRAH, one vendor's chillers or another's, Koios models the plant from its live points, not from a fixed equipment template. The same agent framework runs on a 2‑MW hall and a 40‑MW campus.
Control-system agnostic
It speaks to whatever holds your loops today, a BMS, a DCS, PLCs, or a hyperscale building controller, as a peer over standard protocols. Koios computes the setpoints; your existing controllers still actuate and still enforce their own safeties.
On-prem, air-gapped, no data leaves site
The model trains and runs inside the facility. Live inference executes on the edge in the same Koios runtime that handles connectivity and historization, so latency is low and the control loop never depends on a cloud round-trip. Each site stays autonomous; only KPIs and history travel north.
| Sits beside | Existing BMS / DCS / PLC, as advisory or closed-loop |
| Safeties | Native plant interlocks remain authoritative |
| Deploy | VM · server · Kubernetes · fully air-gapped |
Koios Lensfleet KPIs · data viewing · cross-site analysisFIG. 2: ONE FRAMEWORK, MANY SITES. At each campus a Koios edge node speaks bidirectionally with the existing DCS, PLC and SCADA, reading live tags and writing optimized setpoints while native interlocks stay authoritative. Every campus federates northbound to Koios Lens for fleet-wide KPIs, data viewing and analysis, no site data leaves its facility except the aggregated metrics you choose to share.
The same policy moves at your pace: shadow (proposes setpoints with no write access, so you compare on your own data) → advisory (operator-surfaced, supervised writes) → closed loop (continuous control inside an operator-set envelope, one-click handback). The side-by-side PUE and WUE comparison is visible before a single setpoint is written.
Ai-OPs
·PUE & WUE Optimization03
The PPO controller
We frame cooling control as a Markov decision process and train a policy with Proximal Policy Optimization, an on-policy, actor-critic reinforcement-learning algorithm that is stable, sample-robust and well suited to continuous setpoint control.
FIG. 3: THE LEARNING LOOP. At each 5-minute step the policy emits fan and evaporative setpoints, the plant model advances, and a scalar reward grades the outcome. PPO improves the policy over hundreds of thousands of steps spanning every season.
What the agent sees and does
The observation is a compact picture of the hall: outdoor dry- and wet-bulb, per-zone cold-aisle temperatures, supply-air temperature, IT load, recent control history, short forecasts, and two normalized price signals for electricity and water. The action is just two continuous knobs, fan speed and evaporative modulation; regulatory damper loops stay on their own PIDs, so the agent optimizes efficiency without owning safety-critical actuation.
Training spans summer, fall, winter, spring and shoulder weather, with randomized start times, so the single policy generalizes across the conditions a real site sees rather than overfitting one design day.
| Algorithm | PPO · MLP actor-critic |
| Rollout / batch | n_steps 2048 · batch 128 |
| Learning rate | 2.5e-4, linear decay |
| γ · GAE λ | 0.99 · 0.95 |
| Clip · entropy | 0.20 · ent_coef 0.03 |
| Horizon | 500k steps · 5‑min control |
| Action space | 2‑D continuous [0,1]² |
Its clipped objective bounds how far the policy can move per update, which keeps a controller that drives real cooling equipment from making large, unsafe jumps while it learns. Combined with a reward that makes thermal safety dominant, exploration stays inside the envelope.
Ai-OPs
·PUE & WUE Optimization04
The reward shape is the product
A reinforcement-learning controller does exactly what its reward tells it to. Ours is built as a strict priority stack: thermal safety first, by a wide margin, then a tunable blend of energy, water, smoothness and time-of-use cost. The shape, not the algorithm, is what makes the policy match a given site.
FIG. 4: THE PRIORITY STACK. Safety terms are an order of magnitude larger than efficiency terms, so the policy optimizes power and water only within the room thermal safety allows. Every weight maps to a single configuration key.
When the hottest zone runs above the warn line, the controller switches to a cooling-efficiency regime that re-weights the same terms toward removing heat, and the reward floor drops so a genuine excursion is punished hard. The structure is identical; only the weights and clip change. Those defaults, shown above, are the starting point we tune per site.
Ai-OPs
·PUE & WUE Optimization05
Validation: power and water, cut together
We evaluate the trained policy against a carefully tuned PID baseline over seven-day runs with realistic diurnal weather and IT load. In peak summer conditions, the regime where conventional control saturates, Koios wins on both numbers at once.
Ai-OPs
·PUE & WUE Optimization06
Thermal safety, then the dial
Across every season tested, the cold aisle stayed inside its envelope, the non-negotiable result. Beyond that, the gains track the weather, and the reward weights set where on the PUE–WUE frontier each site lands.
Gains scale with the heat
The hotter the day, the more a saturating PID leaves on the table, and the more Koios recovers. In peak summer it cut both power and water; in shoulder seasons it banked steady PUE savings; in cold, dry winter, where free-air cooling already makes the baseline near-optimal on power, PUE essentially ties.
FIG. 5: THE FRONTIER IS A SETTING, NOT A FIXED POINT. Each site, season and tariff gets its own balance of power against water by moving a handful of reward weights, while the thermal-safety stack stays fixed and dominant.
Ai-OPs
·PUE & WUE Optimization07
From one hall to the whole fleet
Koios runs the optimized cooling policy on the edge, inside each facility, and federates the fleet upward for monitoring and continuous improvement, so efficiency gains compound across every site you operate.
What you get on day one
- A side-by-side baseline. Shadow mode quantifies the PUE and WUE gap on your own plant before a single setpoint is written.
- A tuned reward. We set the energy, water and tariff weights to your site's economics and constraints.
- A safe rollout. Shadow → advisory → closed loop at your pace, with one-click handback and native interlocks untouched.
- Portability. The proven policy redeploys to the next site as configuration, not a new project.
Validation summary
| Method | PPO vs. tuned PID, 7-day runs |
| Conditions | Summer · spring · shoulder · winter |
| PUE savings | up to +7.8% (peak season) |
| WUE savings | up to +38% (same peak run) |
| Thermal safety | 0 envelope violations, all seasons |
| Control rate | 5-minute setpoints, 3-zone hall |
Results are from a reduced-order physics simulation of an outside-air / evaporative hall; absolute figures are calibrated against your site's data during deployment.
In cold, dry conditions the baseline is already efficient on power, so Koios's headline is water management, not PUE. That is the point: the reward weights decide which number to chase, and you set them per site and per season rather than accepting one fixed trade.