How would you detect that GPUs are thermally throttling, and what is the right response when they are?

Throttling is the hardware protecting itself, so it produces no error and no failure, only a job that is quietly slower. The two telemetry fields that name it, the arithmetic linking clock to throughput, and why the response differs completely depending on whether the cause is one node or the room.

Updated Sep 2026 · Grounded in real AI infrastructure interview loops and written to a senior-engineer editorial bar, with every number worked and every diagram hand-built.

more free answers with an account · no card

The concepts behind this question

Ranked by how closely each one overlaps this question's topic, so the first card is the thing to read if the answer above moved too fast.

Advanced

🩺 Fleet Reliability & Observability🔒 Premium

Thermal, Power and Cooling EventsA GPU that gets too hot or is denied power does not fail; it slows down, and on a synchronous job a slow GPU is a slow job. Thermal and power events are the most common cause of the 'nothing failed but the run is 15% slower' ticket, and they are the incidents that scale from one node to a whole hall when a cooling distribution unit or a power feed has a problem. This page explains how throttling works, derives the step-time cost of a clock reduction, walks the failure modes of air and liquid cooling, and covers the power behaviour peculiar to training: thousands of GPUs going idle and busy in lockstep.

Foundational

🖧 Hardware & Cluster Build-Out

Direct-to-Chip Liquid Cooling and CDUsAbove roughly 40 kW a rack cannot be cooled by air in any practical hall, which is why every dense GPU deployment now runs liquid to the chip. A cold plate sits on each GPU, a coolant distribution unit isolates the clean rack loop from facility water, and the facility side runs warm, typically 30 to 40 degrees supply, because warm water is cheaper to make. The design numbers are flow rate and temperature rise, and both fall out of one equation that every operator should be able to do from memory.

Foundational

🩺 Fleet Reliability & Observability

Alert Design and On-Call LoadAn alert exists to change what a human does, so any alert that fires without a decision attached is a false alarm regardless of whether its condition was true. GPU fleets generate a specific set of noisy signals that look serious and are not, and separating those from the ones that need a person at three in the morning is what keeps a rotation sustainable. The measure of an alerting system is the fraction of pages that led to an action.

Core

🩺 Fleet Reliability & ObservabilitySign in

DCGM and GPU TelemetryNVIDIA's Data Center GPU Manager reads a GPU's counters, runs its diagnostics and exports both to the monitoring stack, and nearly every fleet's dashboards and alerts are built on it. The skill is knowing which of its hundreds of fields carry signal: the profiling metrics that say whether the tensor cores are busy (not the utilization number everyone reads first), the error counters that predict a failure, the throttle reasons that explain a slow step, and the diagnostic levels that decide whether a node returns to the pool. This page walks those fields, derives an MFU estimate from them, and gives a fleet's alert thresholds.

Explore the full curriculum →

UP NEXT ON YOUR JOURNEY

Next in this trackWhat do NVLink errors look like in telemetry, when is a link degrading rather than broken, and when do you drain the node?Next in this trackWrite the postmortem for a training run that lost twelve hours. What goes in it, and what makes the action items stick?Next in this trackYou own the on-call rota for a GPU fleet. What is allowed to wake someone at 3am, and what must not?

FEDITOR'S NOTE

Scored on the throttle-reason field rather than temperature alone as the signal, on the clock-to-throughput relationship, and on distinguishing a node-local cause from a facility one before acting.

DISCUSSION · 0

No comments yet — be the first to share your approach.