Thermal throttling and sustained throughput

A simple lumped thermal model treats the device as one heat capacity connected to ambient by a thermal resistance. Constant power initially raises temperature, then heat removal grows with the temperature difference. This approximation gives intuition about time constants and steady temperature, but a real device has multiple hotspots, sensors, nonlinear cooling, and policy thresholds. Do not fit one curve and claim to predict every package, battery, or skin temperature from it.

The relevant power includes more than inference arithmetic. Sensors, radios, display, memory traffic and charging can heat the same physical system. Two workloads with equal operations per inference can have different duty cycles and average power. Record the initial temperature and idle history before comparing trials, and repeat after cool-down where that matches the experiment. For continuous operation, inspect whether temperature and performance stabilize within the tested duration; a run ending before stabilization cannot establish the eventual steady regime.

Under constant power and an ambient-temperature start, the lumped model approaches ambient plus power times thermal resistance. The thermal time constant is resistance times heat capacity. A load can stay below a temperature threshold for tens of seconds even when its predicted equilibrium exceeds that threshold. A controller may then reduce clocks, migrate work, change accelerator use, or shed load. Those actions change the model’s power and throughput, so the original constant-power extrapolation no longer describes the managed device.

Android’s fixed performance mode, introduced at API level 30, provides a concrete caution: it constrains CPU/GPU clock behavior for comparison but does not disable every dynamic behavior or guarantee indefinite thermal sustainability. The official documentation explicitly recommends thermal monitoring. Treat such a mode as an experimental setting, not as the normal product performance promise. Also separate thermal effects from compilation, caches, battery saving, background work and input changes that can produce similar latency trends.

Run representative requests long enough to observe the intended duty cycle and thermal regime, including warm restarts and background interference. Report latency percentiles, deadline misses, energy boundary, temperatures, and throughput over time. If service capacity falls below arrival demand, choose an explicit policy: reduce input frequency, select a validated smaller model, coalesce stale observations, or refuse work according to product requirements. Silently building an ever-growing queue preserves throughput counters while destroying response usefulness.

The queue lab illustrates only a capacity change’s consequence. Reset, set arrival lambda to 4 and service mu to 5, predict backlog three after two Steps, then take those Steps. Compare a fresh Reset with both lambda at 4 and mu at 3 before two Steps: backlog five. Initial backlog is four and two Steps are one second. These are independent fresh experiments with supplied rates, not a live throttle transition, temperature simulator, or measured device performance.