Mac performance questions, answered from measurement

Answers here are short by design. Each question is answered in two or three sentences, and each links to the maintained reference or field note that carries the full method, the raw tables, and the limits of every measurement.

How do I check if my Mac is thermal throttling?

Read the state macOS itself publishes rather than inferring from heat. In Terminal, pmset -g therm prints the machine's thermal pressure, and the programmatic equivalent is ProcessInfo.thermalState, which reports nominal, fair, serious, or critical — the four states macOS manages, with no sensor access required.

Measured on a MacBook Pro, Apple M5 Pro, 48 GB, macOS 27.0 (build 26A5425a), Searoom 0.3.0: degradation begins at fair, not at serious. Sustained inference inside fair cost one model 6.6% of throughput over six minutes, and the two heaviest workloads of a five-model run lost 26.3% and 32.9%, with neither run ever reaching serious. A control model that never left nominal stayed flat across the same duration.

Fan noise and temperature readings are poor evidence for throttling; the published state is the evidence. The checks, the four-cause separation, and the per-request tables are in the thermal throttling reference, and the five-model run is in five models under one sustained workload.

What does memory pressure mean on a Mac?

Memory pressure is the kernel's judgement about whether it can keep meeting memory demand without doing something expensive. It is not a measure of how full the RAM is: Apple computes the Activity Monitor graph from free memory, swap rate, wired memory, and file cached memory together, and a Mac that is 90% occupied can be perfectly healthy.

Free memory near zero is the design working, not an emergency. Measured on the same 48 GB machine (Searoom 0.1.1, build 26A5421a): an 8 GiB allocation with every page touched drove free memory from 4.05 GB to 0.24 GB while swap stayed at zero and the kernel never left its normal state.

The signals that say the machine is genuinely short are the pressure state and swap throughput, not free memory and not swap size. Why three tools report three different numbers for one Mac, and which counter answers which question: the memory pressure reference and what macOS memory pressure actually measures.

How much RAM do I need to run a local LLM?

Budget what the model occupies while generating, not its file size. Measured across five models under one identical workload at a 4096-token context on a 48 GB M5 Pro (Searoom 0.3.0): resident cost ran from 88% to 195% of file size, and the error was worst at the small end — a 2.78 GB model occupied 5.43 GB.

Sampling once, right after load, understates too: that same model reported 3.67 GB after load and 5.43 GB at peak, a third more. Five models is enough to show a direction and not enough to fit a curve, so these are ratios and a method from one machine — not a table of which Mac fits which model.

The measurement, the per-model table, and the sizing method: how much RAM a local model really needs and the five-model report.

MLX vs GGUF: which is faster on Apple Silicon?

Nobody has published a measured answer. The comparisons in circulation run different models on different machines with undisclosed prompts, their results contradict each other, and no same-model, named-hardware comparison with a disclosed method exists.

What a five-model run on this machine did measure is residency by format: the GGUF model held at 98% of its file size while the MLX models materialised lazily to between 120% and 195% of theirs. Why that happens is reasoned, not measured. A same-model controlled run is pending and will be published here when it exists.

The run behind those figures, with the per-model residency table: five models on one Mac.

Why did my Mac slow down after loading a second model?

Because both models stay resident. LM Studio unloads a model only after five minutes idle by default, Ollama's keep_alive default is five minutes, and Apple Silicon gives the CPU and GPU one shared pool of memory — so the second model's weights, the first model's, and everything else on the Mac all draw from the same capacity.

The slowdowns measured in the field note were memory-side — compression, cache reclaim, and in the worst case swap — rather than compute-side, and both runtimes offer configurable unload behaviour that changes these defaults. What to check and in what order: your Mac slowed down after loading a second model, and how the GPU draws on the same pool is in unified memory.

Does a menu-bar monitoring app slow down a Mac?

A well-built one costs a fraction of a percent of a core. Measured with powermetrics on an otherwise idle M5 Pro (macOS 27.0, Searoom 0.7.0, popover closed, battery): at a two-second cadence, about 4.2 timer wake-ups per second and 0.36% of one core; at one second, 9.5 wake-ups and 0.84%; at ten seconds, 0.8 wake-ups and 0.08%. Across all 192 samples at every cadence, zero wake-ups landed in the sub-5 ms deadline buckets.

For scale: the same idle machine ran about 2,066 timer interrupts per second across its CPUs before any monitor ran, so the default-cadence monitor adds roughly 0.2% to that background. The post includes the commands to measure any monitor the same way: what a menu-bar monitor costs.

How do I check my Mac's hardware health?

For component faults, Apple Diagnostics: on Apple silicon, shut down, then restart holding the power button and press ⌘-D at the Options screen; it runs a hardware test and reports a reference code for the component it suspects.

For the performance side — whether the machine is short of memory or running hot — macOS reports both directly, no diagnostics needed: the memory pressure state and the thermal state, both covered in the references above. Apple's own guidance on whether a Mac needs more RAM reads the memory pressure graph rather than a free-memory figure.