Thermal derating is invisible. It does not show up in your power bill. It does not trigger an alert in your monitoring stack. It costs you compute throughput without ever declaring itself a problem.
Here is what happens. A cooling unit underperforms. Supply air temperature rises. The GPUs see temperatures above their thermal design point. The thermal management firmware responds exactly as designed. Clock speeds drop. Power consumption flattens. Throughput falls.
Your operations team sees nothing wrong. Power draw is within spec. No alarms fired. The infrastructure looks healthy. But your H100 cluster just delivered 15 percent less work in the same time window, burning the same power budget.
That is the hidden tax. Same cost. Less output. No alert to tell you it happened.
Most data center monitoring is designed around thresholds. A sensor crosses a limit. An alert fires. Someone investigates. This model works well for discrete failures. It does not work for gradual thermal degradation.
The GPU thermal throttle activates at a defined temperature. Below that temperature, the GPU runs at full speed. Above it, the firmware reduces clock frequency to stay within its thermal envelope. The transition is smooth and automatic. No alarm fires. The system is behaving correctly.
Your monitoring tool reports GPU utilization as normal. It is. What it is not reporting is that throughput per watt has dropped 15 percent because the firmware is trading compute for thermal headroom.
Thermal derating does not stay in the thermal domain. That is what makes it a consequence problem rather than a cooling problem.
When GPU throughput drops, job completion times extend. Scheduled workloads miss their windows. The scheduler queues more jobs to compensate. Power headroom that should have been available for the next batch is now committed to jobs running long. The facility has less flexibility than the power budget suggests.
In a dense AI compute environment, this cascade happens fast. A cooling event in one hall affects compute scheduling across the row. Compute scheduling affects power allocation across the PDU. A thermal problem becomes a capacity problem before anyone has noticed the temperature spike.
This is exactly what consequence intelligence is designed to detect. Not the temperature reading. The chain.
The first step is visibility. You cannot manage what you cannot see. Correlating CDU telemetry, GPU junction temperatures, and workload throughput data in a single model gives you the full picture that individual monitoring tools miss.
The second step is speed. Thermal events evolve in seconds. Detection has to be faster than the throttle threshold. That means real-time correlation across domain data streams, not batch analysis.
The third step is consequence tracing. Understanding that a temperature event in Hall B is about to strand 42 kW in PDU-B4 is actionable information. Understanding that temperatures are high in Hall B is less useful.
Synestra's consequence engine traces the chain from thermal anomaly to stranded power in under 800 milliseconds. By the time the throttle would have fired, the intervention is already proposed. Sometimes already executed.
A 200 MW AI compute campus running at 2 percent throughput loss due to recurrent thermal derating events is losing real money. At $200 per kW per year in compute value, 4 MW of effective throughput loss is $800K per year. That is not a line item anyone is tracking. It is not a failure. It is not a reportable event.
It is a hidden tax. And it compounds across every thermal event, every affected cluster, every impacted workload.
The good news is that it is recoverable. The thermal conditions that cause derating are typically manageable. Cooling setpoint adjustments, airflow corrections, workload migration to cooler zones. The interventions are not complex. Finding them fast enough to matter is the hard part.
That is the problem Synestra is built to solve.