# The Megawatt You Already Have: How Better Cooling Turns Power Into More AI Compute Canonical: https://www.reliabilityengine.com/insights/the-megawatt-you-already-have-ai-compute Markdown: https://www.reliabilityengine.com/insights/the-megawatt-you-already-have-ai-compute/markdown Site: Reliability Engine Published: 2026-07-23T10:00:00.000Z Updated: 2026-07-21T12:57:29Z Categories: AI Infrastructure, Cooling Systems, Data Center Design, System Integration A megawatt at the meter is not a megawatt of AI work. Some electricity keeps power moving and heat leaving. Some reaches processors that are idle, constrained, or throttled by temperature. The meter can tell you what came in. It cannot tell you how much useful work came out. That gap between connected power and useful compute framed a conversation at POWERUP Data Centers Infrastructure in Austin. Brenda Pak, founder and CEO of Reliability Engine, joined a panel on advances in processors, servers, and data center energy management. The panel explored how advances in processors, servers, and energy management affect onsite power and grid connection needs. Brenda took the conversation past the grid meter: capacity becomes valuable only when the facility can turn it into stable output. The grid delivers the budget. The facility decides how much becomes dependable compute. The race for new generation, transmission, and interconnection is real. So is the opportunity to make the power already connected work harder. ## The meter is the starting line, not the finish Power usage effectiveness, or PUE, is the familiar first lens. It divides total data center energy by the energy used by IT equipment. At a PUE of 1.20, the facility uses 1.20 units in total for every 1.00 unit delivered to IT. Start with 1,000 kW at the meter. At 1.20 PUE, about 833 kW reaches IT while about 167 kW supports cooling, power conversion, and other facility loads. Move the PUE dial to watch that allocation change. Treat the interaction as a transparent calculator, not a site benchmark. PUE is formally reported from energy measured over time. The model uses instantaneous power only to make the first division easy to see. ### PUE is the receipt, not the review of what you bought. Two sites can report the same PUE and still produce different amounts of useful work. PUE does not measure workload completion, server utilization, thermal throttling, or whether one constrained rack is setting the pace for the cluster. It tells you how much energy reaches IT, not what that IT energy accomplishes. That is why the next efficiency conversation cannot stop at the building boundary. It must follow power through the electrical path, the workload, the cooling system, and the operating conditions that keep silicon productive. ## AI loads behave more like a drummer than a metronome Grid planning loves a metronome: steady, predictable, and easy to count. AI workloads often behave more like a drummer. Training phases, checkpoints, communication steps, and changing inference demand can create bursts and pauses on very different timescales. Berkeley Lab measured characteristic fluctuations in GPU training loads and noted that these patterns can be especially taxing for grid operators. That does not make AI an impossible grid customer. It makes coordination valuable. The job is not to flatten every workload into a perfect line. It is to make the facility response understandable. Power controls, workload scheduling, local energy storage, ramp limits, and thermal buffering can each help, but only when their timing and limits are designed as one system. Replay the workload pulse and compare the two responses. The workload can change quickly while facility draw follows a controlled ramp and the thermal system responds on its own timescale. The timing is conceptual. Actual ride-through and ramp rates belong to the equipment and site design. A large load is easier to serve when everyone can see its next move. ## Cooling has entered the power conversation Not every AI server requires liquid cooling. As rack density rises, however, direct-to-chip cooling is becoming a central architecture for high-performance systems. Cold plates move heat into liquid close to the processor instead of asking room air to carry the entire thermal load. That change can reduce server fan work and, in suitable climates and designs, allow warmer water and less mechanical refrigeration. The result depends on supply temperatures, heat capture, climate, redundancy, controls, and the rest of the plant. There is no honest universal savings number. The deeper shift is conceptual. Cooling stops being the cleanup crew that arrives after compute. It becomes part of the production line. GPU management tools track thermal margin and thermal slowdown because temperature can directly affect clock behavior and performance. A watt delivered to a throttled processor still appears on a power report. It does not deliver the same result as a watt delivered to a processor operating with healthy thermal margin. ## The rack experiences one continuity problem Electrical and mechanical systems often live on separate drawings. The silicon experiences one system. If a voltage event occurs and pumps, controls, or heat rejection have the required ride-through, the cooling path can carry on while the electrical system recovers. If that protection is missing or misconfigured, an electrical disturbance can become a flow or temperature disturbance. Protective controls may then reduce clocks or shut equipment down. A loop can also provide thermal inertia. Fluid volume and metal mass can absorb heat for a period, much like a flywheel carries motion through a brief interruption. That period is finite and system-specific. It has to be calculated, tested, and visible to operators rather than assumed. This is why rack power, pump state, flow, pressure, supply and return temperature, thermal margin, and control events belong on the same timeline. A fast event makes more sense when the electrical and thermal evidence can be read together. ## One sensor is one witness, not the whole case A cooling loop rarely announces a developing problem with one perfect alarm. A restriction may appear as falling branch flow, changing differential pressure, higher pump effort, and a later temperature response. A heat-rejection constraint may raise supply temperature while flow still looks normal. Try the three loop conditions and watch the evidence change. A restriction narrows the path and slows flow. Warm supply leaves the path open but reduces thermal headroom. Stable operation is not a color on a dashboard. It is a set of independent signals agreeing over time. Industry guidance reflects that need for context. Open Compute Project cold-plate and cooling-loop documents identify temperature, flow, pressure, and power measurements across the system. Fluid condition adds another layer because heat transfer depends on what is moving through the hardware as well as how fast it moves. The useful question is not simply, "Did a value cross a limit?" It is, "What changed, what changed with it, and is the system still moving away from its known operating baseline?" ## Hardware is only half the readiness story A purchase order can deliver cold plates, coolant distribution units, pumps, controls, and sensors. It cannot deliver operating confidence. That confidence is built during design reviews, commissioning, failure testing, baseline capture, and the first months of operation. Teams need to know which signals matter, how they relate, what normal looks like at different loads, and who acts when the story stops making sense. Commissioning is where the conversion from installed hardware to trusted infrastructure begins. The loop is flushed and proven before sensitive cold plates depend on it. Sensors and protection logic are tested. Accepted chemistry and hydraulic behavior become the day-zero record that future drift will be compared against. The operating model matters just as much after startup. A loop that was healthy on handoff day can change as filters load, air moves, controls drift, materials age, or fluid condition evolves. Useful compute depends on detecting that change while there is still room to respond. ## Five questions before asking for the next megawatt - How much reaches IT? Use measured energy and a clearly defined PUE boundary, not a design number detached from actual operation. - How much IT power becomes accepted work? Connect utilization, workload completion, power limits, clock behavior, and thermal margin. - How does the load move? Understand ramps, repeated bursts, recovery periods, and which controls shape what the grid and onsite generation see. - How long can the thermal path ride through an event? Calculate and test the real response of pumps, controls, fluid volume, heat exchangers, and protective logic. - Can operators explain drift before output suffers? Put flow, pressure, temperature, pump behavior, fluid condition, and interventions on one timeline. These questions do not replace the need for more generation or faster interconnection. They make sure the capacity already secured is not treated as a black box after it crosses the meter. ## The next megawatt is not the only one that matters That is the idea Brenda Pak brought to the POWERUP conversation. The industry has to build more power, but it also has to become better at converting connected power into stable, productive AI infrastructure. Reliability Engine works in that conversion layer. It brings cooling-loop temperature, flow, pressure, fluid condition, alarms, samples, interventions, and accepted baselines into one operating record. The aim is straightforward: help teams see whether the thermal system is protecting the compute they planned to run. It does not create grid capacity or replace electrical protection, equipment controls, or engineering judgment. It makes the water-side evidence easier to read alongside them, so operators can spot drift, preserve thermal margin, and make better decisions before a cooling problem becomes a compute problem. The next megawatt matters. So does every useful calculation the current one can deliver. Planning or operating high-density AI infrastructure? Reliability Engine helps turn cooling-loop data into the evidence needed to protect connected compute. ## References 1. Infocast: POWERUP Data Centers Infrastructure, Austin, July 14 to 16, 2026 1. Berkeley Lab: 2024 United States Data Center Energy Usage Report 1. Berkeley Lab: Data center electricity demand and efficiency summary 1. ISO/IEC 30134-2:2026: Power usage effectiveness 1. ASHRAE: AI Data Center Energy Performance Framework, Integrated Design Principles 1. NVIDIA: GPU Debug Guidelines, power and thermal telemetry 1. Open Compute Project: Liquid Cooling Cold Plate Requirements 1. Open Compute Project: Cold Plate Cooling Loop Requirements