Why do my Mac's fans spin up when running a local LLM but not when compiling?

Fans respond to accumulated heat rather than to instantaneous load. Compiling saturates the CPU in bursts that finish before the chassis needs active cooling. Token generation holds the GPU at high utilisation continuously, so heat accumulates and the fans escalate.

Do loud fans mean my Mac is being throttled?

Not by themselves. Fan speed responds to heat rather than measuring lost performance, so check the macOS thermal state instead, with pmset -g therm or ProcessInfo. At nominal the machine is unconstrained. At fair, degradation has already begun: a five-model measurement on one MacBook Pro found throughput inside fair falling 26 to 33 percent on the heaviest workloads, while a small model that never left nominal stayed flat. At serious the reduction is larger still.

Why can't my Mac monitor show CPU temperature?

Temperature comes from best-effort SMC access, and key names and availability vary by Mac model and macOS release. Some machines expose no CPU temperature key that a third-party process can read. The macOS thermal state from ProcessInfo is available on every Mac and is a more reliable signal for diagnosing throttling.

How do I make my Mac quieter during local inference?

Give it a hard surface with good ventilation, which is Apple's own guidance for Mac laptops, and keep it out of bed, off pillows and out from under bedding. Then use a smaller or more heavily quantised model, and reduce context length. If the machine is also paging, fix the memory shortfall first, because sustained swap traffic produces both slowness and additional heat.

Why your Mac's fans spin up when running a local model

Compiling a large project pins every core and the fans often stay quiet. Running a 7B model for four minutes and they audibly spin up. The difference is not how hard the work is. It is how long it lasts.

Fans respond to accumulated heat, and heat accumulates on a delay. That delay is why bursty workloads finish before the fans react, and why inference does not.

Why inference is different from most desktop load

Most work a Mac does is spiky. A build saturates the CPU for thirty seconds and stops. A page render peaks for a moment. The heat produced has somewhere to go: the chassis absorbs it, and the machine returns to idle before the cooling system needs to escalate.

Token generation does not have that shape. It holds the GPU at high utilisation continuously for as long as the response takes, and if you are in a conversation, repeatedly. The chassis stops being a buffer and becomes a bottleneck, so the fans take over.

This is normal and it is the cooling system working. Apple describes the sound directly: when the processor is working on intensive tasks the fans run faster to provide additional airflow, and that rushing-air sound is a normal part of the cooling process. Spinning fans are evidence that the machine is removing heat successfully, not evidence that something is wrong. The condition worth diagnosing is the one where performance drops, which is a different signal and is covered below.

Fan speed is not the diagnostic

The instinct is to watch RPM. It is the least informative of the available signals for three reasons.

Fan speed lags the thing you care about. By the time RPM has risen, the thermal decision was made some time earlier. It is a consequence, not a leading indicator.

Fan speed is chassis-specific. The MacBook Air has no fan at all, so there is no fan signal to read on it and sustained load has to be shed some other way. MacBook Pros have one or two depending on the model. A Mac Studio has a much larger thermal budget. The same silicon under the same load produces completely different RPM figures across those machines, so no fan number generalises.

Fan speed is often unreadable. Fan sensors come from best-effort SMC access, and key names and availability vary by Mac model and macOS release. On the machine used here, two fans were discovered and both reported 0 RPM while idle, which is correct: Apple Silicon MacBook Pros stop their fans entirely when cool.

The signal that actually matters

macOS publishes its own thermal state, and unlike a temperature reading it is available on every Mac without any sensor access at all:

ProcessInfo.processInfo.thermalState
// .nominal | .fair | .serious | .critical

This is the system telling you what it has decided, rather than an observer inferring it from a number. It is the difference between reading a thermometer and reading the decision the thermostat made. Apple documents the property and its four states, and describes critical as the point at which thermal state is significantly affecting performance.

Thermal state and what it means for a running workload
State	Meaning	Expect
`nominal`	No thermal constraint	Full performance. Fan noise here is just cooling.
`fair`	Mild constraint, fans active	Degradation begins here. Measured losses of 26% to 33% under sustained load.
`serious`	System is reducing performance	Measurably slower tokens per second.
`critical`	Aggressive throttling	Large slowdown. Address the cause.

Loud fans are not themselves a performance measurement: fan speed responds to heat rather than reporting lost throughput. The state they accompany is what matters. A five-model run on this machine measured throughput inside fair falling by 26% and 33% on the two heaviest workloads, while a smaller model that never left nominal stayed flat. Treat nominal as untroubled, fair as the point where you begin paying, and serious as a later stage of the same process.

What to check, in order

1. Read the thermal state, not the temperature

Current recorded thermal and performance warning levels:

pmset -g therm

On an unthrottled machine this reports that no warning level has been recorded, which is the answer you want. Note that pmset -g thermlog is a different command: it streams continuously until you interrupt it, so run it only when you intend to watch.

2. Confirm the GPU is doing the work

If token generation is slow and the fans are loud, verify the workload is on the GPU at all. A model that has fallen back to CPU inference will be both slower and hotter for the same output.

ioreg -r -c IOAccelerator -d 1 | grep -A 30 PerformanceStatistics

Look for Device Utilization %. High GPU utilisation during generation is the expected picture on Apple Silicon.

3. Check Low Power Mode

Apple documents Low Power Mode as a setting that reduces energy use to increase battery life and, on Macs with a fan, reduces fan noise. Apple publishes no figure for its effect on compute, so treat the size of the slowdown as unknown rather than assumed. It remains a common and easily missed explanation for a machine that is slow and cool at the same time.

pmset -g | grep powermode

The key is powermode, not lowpowermode. On the machine used here it reads 0, which is the default state, and a non-zero value means a non-default power mode is active. The definitive reads are System Settings and, programmatically, ProcessInfo.processInfo.isLowPowerModeEnabled, which is the value Searoom displays.

4. Rule out memory pressure

A machine that is paging will feel slow and will also work harder, which produces heat. That is a memory problem presenting as a thermal one. If swap throughput is sustained and non-zero, fix that first, because no amount of cooling addresses it. The distinction between swap allocation and swap throughput is covered in swap I/O vs swap size.

What actually reduces the noise

Ranked by effect, on the assumption that the workload itself is fixed.

Give it a hard, ventilated surface. Apple's guidance is to use a Mac laptop on a stable work surface that allows for good ventilation, and specifically not in bed, on a pillow, or under bedding. Soft material against the chassis is the case that guidance addresses, and it is the lowest-cost change available. Apple does not publish where any given model draws its intake air, so be wary of advice that depends on a particular vent location.

Use a smaller or more quantised model. Less compute per token is less heat. A 4-bit quantisation of the same model does meaningfully less work than an 8-bit one.

Reduce context length. Attention cost grows with context, and a long conversation is doing more work per token than a short one even with an identical model.

Accept it, within limits. At nominal the fans are the system working correctly and costing you nothing measurable. At fair they are still working correctly, but the machine is already giving up throughput, so accepting the noise there also means accepting a slower run. Sustained compute produces heat, and the alternative to moving it is a larger loss than the one you are already taking.

Measured: one machine's fan curve

Six minutes of continuous generation on a MacBook Pro, Apple M5 Pro, 48 GB, macOS 27.0 build 26A5425a, Searoom 0.3.0. The model was Devstral Small 2 24B Instruct at Q4_K_M, a dense 24B, held at a 4096 token context with the GPU between 97 and 100% throughout. Fan RPM and temperature come from Searoom --dump-sample, thermal state from the same sample.

Fans under sustained inference, M5 Pro 48 GB, macOS 27.0 build 26A5425a
Elapsed	Fan 1 RPM	Fan 2 RPM	Temperature	Thermal state
0 s, idle	0	0	26.29 °C	nominal
39 s	2,318	2,504	26.29 °C	nominal
105 s	4,741	5,118	27.69 °C	nominal
172 s	4,952	5,351	30.00 °C	nominal
275 s	4,952	5,340	32.19 °C	fair
378 s, last request	4,946	5,354	33.59 °C	fair
420 s, 42 s idle	4,946	5,353	33.79 °C	fair
448 s, 70 s idle	4,841	5,223	33.79 °C	fair

Three things in that table are worth more than the RPM figures.

The fans did not come back down. Seventy seconds after the last request, with the GPU back at idle, both fans were still within about 2% of their loaded plateau. This is the lag described above, made concrete: fan speed is a consequence of a thermal decision taken earlier, and it stays high while the chassis sheds heat it has already absorbed. Anyone diagnosing by ear shortly after a run has finished is reading a stale signal.

Loud fans, full performance. The machine reached fair and never went beyond it. Generation held between 17.5 and 18.8 tokens per second across the whole run, a spread of about 6.6% with no sustained decline. Roughly 5,000 RPM on both fans, and the workload was not being slowed. That is exactly the case this article argues for: the noise was the cooling system succeeding.

The temperature reading barely moved. It rose 7.5 °C in total, from 26.29 to 33.79, while the GPU sat above 97% for six minutes. That is because the only readable sensor on this Mac is the battery pack, labelled BAT, and a battery is not where the heat is being made. No temperature figure that low should be read as evidence the machine is cool. It is evidence that the sensor is measuring something else.

Limits of this measurement

One machine, one chassis, one model, one macOS build. A MacBook Air has no fan to plot and would shed this load differently. A Mac Studio has far more thermal budget. The plateau near 5,000 RPM is this laptop's answer to this workload and generalises to nothing. What does generalise is the shape: a ramp reaching plateau in under two minutes, a long flat top, and a decline that had barely started 70 seconds after the work stopped. Observation ended there, so how long the fans took to reach zero was not measured.

Definitions for thermal pressure, temperature source, and fan readings are in the metric reference. The reason temperature is best-effort while thermal state is not is explained in reading SMC sensors from Swift. If the machine is not just loud but measurably slower, diagnosing thermal throttling separates heat from the three cheaper explanations.