Embedded GPU thermal throttling on a Jetson Orin NX or Nano module begins when the SoC junction reaches its 99 °C maximum operating temperature. At that point software starts reducing clock speeds, and the module shuts down at 105 °C. How close your sustained inference gets to that line depends on the workload, the heat path out of the sealed box and the hottest ambient the device will face, so NVIDIA’s own guide tells designers to instrument the system under heavy use cases in the hottest environment it will run in. In one measured edge-SoC run of sustained LLM inference with fan-assisted cooling, the first sustained GPU frequency cut came after 22.25 minutes at 98.56 °C.
TechnoLynx does this measurement and tuning through its GPU Performance Engineering work. The engagement starts by defining the duty cycle the device has to survive: a full shift, the sealed enclosure, worst-case ambient and every workload that shares the module. It then instruments a soak run on the target hardware and tunes clocks, precision and batching to fit the budget that run reveals.
Where embedded GPU thermal throttling starts on Jetson Orin
On Orin NX and Orin Nano, NVIDIA’s thermal design guide sets the maximum SoC operating temperature at 99 °C and the shutdown temperature at 105 °C. Below 99 °C the module runs at its specified clocks and DVFS is free to vary frequencies and voltages. Once a sensor reaches the threshold, an interrupt starts a software control loop that polls temperature, calculates a throttle degree and caps CPU and GPU clocks to match. If software cannot hold the temperature, hardware clock throttling takes over as a last resort. The guide says this “will also significantly reduce the overall Orin SoC performance”, and the settings cannot be changed.
NVIDIA’s own sizing example targets 95 °C, not 99 °C. NVIDIA quotes a sensor accuracy of ±3 °C and tells designers to choose their headroom based on how much performance reduction they can tolerate. Power fluctuations that briefly push the junction over the threshold also cause temporary clock reductions.
A separate set of hardware throttling levels handles electrical events such as overcurrent. On Orin NX and Nano, average and instantaneous power limits on the VDD_IN rail trigger hardware clock throttling of the GPU and CPU whenever module power exceeds the TDP budget. NVIDIA’s table lists three levels, light, medium and heavy, at 50, 75 and 87.5 in its clock-throttled percentage column. The host OS is not notified of these events. You can detect them by sampling clock rates with a performance tool.
The studies cited here measured a Jetson AGX Orin, Jetson AGX boards, an Orin Nano and a Raspberry Pi 5, not a sealed, fanless Orin NX. So treat the NX figures on this page as specification values, and treat your own soak run as the first real data point.
Why datasheets and short benchmarks don’t predict when a fanless GPU throttles
The datasheet power figure is defined for a specific workload and conditions. NVIDIA defines total module power (TMP) as the average power dissipated while running the target workload under worst-case conditions in steady state. Its thermal model assumes uniform heat loading of the die, and the guide warns that real workloads load the die unevenly, so designers must allow margin. The module also has no system-level thermal solution of its own. Getting the heat out is the integrator’s job, and so is qualifying the module in the system.
In a Raspberry Pi 4B CPU study without cooling, throughput fell from around 16 fps to a stable 10 fps, which it reached only after roughly 1,000 seconds of continuous inference. The authors ran every test until it reached steady state, and their longest indoor test took 5,340 seconds. On Orin, ThermE (2026) logged staged reductions: a 6.7% GPU frequency cut at 22.25 minutes, a CPU cut 1.53 minutes later, more steps after that, and clocks that recovered only after a restart. A five-minute benchmark ends long before the 22.25-minute cut and the 1,000-second plateau.
Synthetic stress tests can mislead in the other direction. In a climate-chamber study of an AGX Orin in an outdoor enclosure at +40 °C, a CPU and GPU stress test triggered throttling at GPU 95.6 °C and CPU 99.0 °C. A YOLOv8s TensorRT FP16 workload under the same conditions sustained 108.8 FPS at 19.1 W, about half the stress-test power, and stayed well below the threshold. The stress test showed where the device throttles under maximum load. The real model never reached that point.
Two more variables change sustained performance. Ambient temperature is one: across outdoor ambients of 22 to 36 °C, the uncooled Pi 4 lost up to 27.7% of its maximum throughput. Board-to-board variation is the other. With throttling excluded, a study of 13 nominally identical Jetson AGX Xavier boards found runtime differences of up to −10% to +20% for some networks, and power differences of up to −30% to +20%. A budget measured on one reference board at room temperature is therefore a sample, not a guarantee for the fleet.
Is the throttling set by the DVFS governor or by the heat the enclosure can shed?
It can be either: power limits and temperature both trigger clock throttling. The governor is the mechanism in both cases: when a sensor crosses a trip point, the board support package uses DVFS to lower clock frequencies and rail voltages, which cuts power and controls temperature. The real question is what pushed the chip to the trip point.
- Power-limit throttling. Module power exceeds the configured TDP limit and hardware caps the clocks, even while the die is still below 99 °C. MAXN mode is the classic trigger: it removes the clock caps, but NVIDIA notes that it engages hardware throttling once total module power exceeds the TDP budget.
- Package or heat-sink limited. Here the limit is the thermal interface or heat sink. NVIDIA calls good contact critical and recommends a thin, uniform TIM bondline.
- Enclosure limited. The sealed box cannot pass the heat to the outside air, so the internal air temperature rises.
If clocks drop while temperature sits below the trip point and power is at its limit, that points to power-limit throttling. If clocks drop at 99 °C while internal air stays close to outside ambient, the heat sink path is the bottleneck. If internal air itself climbs steadily over the run, the enclosure is the bottleneck. ThermE measured that each 1 °C rise in the Orin CPU zone raised the GPU zone by 0.72 °C, because all three zones share one package and cooling path. Heat from co-located preprocessing on the CPU therefore reduces the detector’s headroom.
NVIDIA is also clear about how far tuning can go: “Tuning cannot remedy a faulty TDP,” and deleting thermal zones can cause resets or irreversible damage.
How much sustained power can a fanless enclosure dissipate?
NVIDIA’s guide sizes the heat sink as R = (T.SoC target − T.ambient) / P. nVent’s enclosure guide gives the heat leaving through the walls as Qs = k × A × ΔT, where ΔT is the difference between inside and outside air.
Worked example: from heat sink to enclosure wall
NVIDIA’s example takes 55 °C ambient, a 95 °C SoC target (4 °C below the limit, to cover sensor error and workload swings) and 25 W of TMP. That gives (95 − 55) / 25 = 1.60 °C/W for the heat sink.
In a sealed box, “ambient” means the air inside the enclosure, not the room. Assume for illustration that the internal air sits 10 K above a 55 °C outside temperature, so 65 °C. On that illustrative assumption, NVIDIA’s formula gives (95 − 65) / 1.60 = 18.75 W with the same heat sink.
The wall sets the internal rise. nVent’s worked figures put one free-standing enclosure at 310 W dissipated at ΔT = 20 K, which is 15.5 W/K, or 155 W at a 10 K rise. A small sealed housing carrying 25 W of module power plus camera, lighting driver and power supply needs a k × A large enough that total watts divided by k × A stays inside the ΔT you can afford. Shedding 25 W at a 20 K rise, for example, needs 25 / 20 = 1.25 W/K of wall conduction. Solar loading on the housing raises the internal temperature further, and the formula does not capture that, which is one more reason to measure.
| Quantity | How it is set | Source of the number |
|---|---|---|
| T.SoC target | 99 °C limit minus sensor and workload margin | NVIDIA thermal design guide |
| Heat sink R (°C/W) | (T.SoC target − internal air) / sustained power | Your heat sink, verified in the soak run |
| Enclosure k × A (W/K) | Total dissipated power / allowed inside-outside ΔT | Enclosure data or measurement |
| Sustained power | Measured on the real pipeline at steady state | Your soak run, not TDP |
When an embedded GPU throttles, do detections fail or does it just get slower?
Vendor governors react to temperature, current or power, not to your frame deadline, and near the thresholds they can cut frequencies by up to 50%. Every model configuration slows down together once the governor down-clocks the chip. In a simulation of a Jetson-class module in a sealed enclosure at 45 °C, a policy that always ran the largest detector went 12.5 seconds without an on-time detection, and 91 seconds at 55 °C. Those are modelled values, and the authors say only hardware measurements can settle real throttle behaviour. The mechanism still holds: if the camera triggers at line speed and frames queue or drop, a slower pipeline means parts that were never inspected.
That is why the budget has to be a worst-case bound, not an average. On an Orin Nano, mean pipeline latency for one YOLO feed was 83.91 ms, yet p99 pipeline latency was 105.15 ms. With three concurrent feeds, 81.30% of frames exceeded 100 ms. In 60-second trials, the same study found that thermal load raised GPU temperature without a comparably large increase in single-stream latency. In that study, adding streams raised latency far more than sustained heat did. Tracking, logging or a second camera has to be added to the soak run and measured, not assumed to fit in leftover headroom.
We would define the degradation behaviour before deployment: a temperature or p99 threshold at which the device switches to a lighter model or a reduced rate, or raises an alarm, so that it never slows down silently. One study’s conclusion supports this: routers that read temperature stayed out of throttling, while routers that watched only latency throttled in every hot run the authors tried.
Measuring the budget on your own module: the soak-run procedure
Advice such as “use a lower power mode” or “quantise the model” only makes sense in context, and that context comes from profiling the real workload, not from general best practice. Run the steps in this order:
- Define the duty cycle. Fix the full shift length, line rate, every co-located process and the worst-case ambient the enclosure will see, including sun load if it applies.
- Instrument the real unit. Log junction temperatures, CPU, GPU and EMC clocks, and rail power at sub-second intervals. The AGX Orin enclosure study used tegrastats and jtop for chip data and calibrated RTDs for internal air. Orin’s on-chip sensors report with 0.5 °C precision after boot calibration, but design to the ±3 °C accuracy figure.
- Log clocks as well as temperature. The host OS is not notified of hardware throttling events, so log clock rates to detect them.
- Run to steady state at worst-case ambient. Use a climate chamber or the real installation. Stop only when temperature and throughput have both flattened, not after a fixed few minutes.
- Decompose by stage. Time capture, preprocessing, inference and postprocessing separately, so you know which stage stretches first once clocks drop.
- Repeat on more than one unit. Board-to-board variation is large enough that results from a single board do not transfer cleanly to the fleet.
- Record the margin. Write down steady-state temperature against 99 °C, p99 latency against the frame deadline, and the remaining power headroom. That becomes the budget future changes are checked against.
Turning this into a protocol you rerun after every firmware or model change is a topic of its own, covered in our guide to instrumented sustained-operation profiling for thermal and power behaviour. If you are still choosing the module, LynxBenchAI’s published results show how each device runs the public PyTorch stack that most teams’ own models also run on, so they are broadly indicative for custom PyTorch models. They do not run your pipeline or reproduce your enclosure. The soak run on your hardware is still required. Compare candidate modules on the LynxBenchAI results pages before you commit to one.
How can you prevent embedded GPU thermal throttling without redesigning the enclosure?
Lower the steady-state power until the measured plateau sits below the trip point with margin, then check that the slower pipeline still meets the deadline. The levers, roughly in the order we would try them:
Pick a power mode instead of MAXN. Orin supports predefined budgets and custom modes that cap CPU, GPU and memory clocks and core counts, set with nvpmodel and kept across power cycles. NVIDIA tells you to test your use case to choose core counts and frequencies, and advises against running heavy workloads in MAXN for long periods. Running jetson_clocks pins clocks at the mode’s maximum.
Cap clocks below the knee. On a passively cooled Raspberry Pi 5 running YOLOv8n, a 25% clock cut cost only about 15% of FPS while board power fell about 26%. In 30-minute runs the capped states did not throttle, while full speed throttled 1,823 times. That study’s calibrated scheduler delivered 6.8% more FPS than a temperature-only reactive policy. There is a catch: the passive envelope closed at ambients of 27 °C and above, where even the lowest state crossed the threshold. A cap tuned at one ambient also drifts. In one study, a duty cap tuned at 45 °C throttled 16% of the time at 50 °C and 31% at 55 °C.
Reduce work per frame. A smaller model, a lower input resolution or reduced precision through TensorRT all lower sustained power. Whether a quantised model still catches the defects it caught in the lab is a separate field-validation question, and it needs its own evidence before it counts as a fix.
Batch with care. Batching, power caps and fixed DVFS settings change instantaneous power or latency but say nothing about future headroom. A choice that helps now can trigger lower frequencies later.
| What the soak run shows | Likely cause | First fix to try |
|---|---|---|
| Clocks drop, temperature below 99 °C, power at limit | Power-limit (TDP) throttling | Lower power mode or clock cap |
| Clocks drop at 99 °C, internal air close to outside ambient | Heat sink or TIM path | Check contact and TIM bondline |
| Internal air climbs all run, then clocks drop | Enclosure cannot shed the heat | Reduce power, or add active cooling to the enclosure |
| Latency tail grows with no clock drop | Contention from co-located streams | Remove or schedule co-located work |
If no software budget holds at worst-case ambient, NVIDIA’s guide lists the remaining changes: a lower maximum ambient, lighter use cases or a better thermal solution. That is a cost decision in its own right, and the soak data is what makes it defensible.
Who can profile and tune our fanless embedded inference device?
TechnoLynx profiles sustained inference on your target module inside its real enclosure and tunes the pipeline to fit the thermal and power budget it finds. It starts by defining the duty cycle, then selects the instrumentation for your SoC: stage-level latency breakdown plus thermal and power telemetry. It then tunes clocks, precision and batching on the hardware, validates with full-shift worst-case runs, and sets up telemetry on production units to catch drift from the validated budget. This work runs as GPU Performance Engineering, within TechnoLynx’s broader AI engineering for IoT and embedded devices.
A specialist is worth bringing in when the budget fails and you need to know which software levers are left before you pay for a hardware change.
FAQ
What is the difference between junction temperature and case temperature?
Junction temperature (Tj) is the SoC die temperature read from the on-die sensors, used for high-temperature Tj management. Case temperature is measured on the board components NVIDIA lists, and NVIDIA asks designers to instrument them under heavy use cases at maximum ambient.
Should I disable thermal throttling to keep performance up?
No. NVIDIA warns that removing thermal zones does not guarantee maximum performance and can cause resets or irreversible damage. Lower the sustained power instead.