Your MacBook is fast for two minutes, then half as fast

Name: LLM Configurator — GPU VRAM Checker
Author: LLM Configurator

macOS

Written by Jakub Rusinowski · Last updated September 1, 2026

Founder, LLM Configurator — AI educator & workshop leader on local LLM deployment

The error

minute 1:   42.6 tok/s
minute 10:  19.8 tok/s     <- same model, same prompt, same machine

Which one is it?

If you see	The cause is	Go to
Speed is good for the first minute or two and then halves	The chassis has reached its sustained thermal limit	Fix 2: measure it, then Fix 4
It is slow from the very first token	Not throttling — a placement or memory problem	This is the wrong page; see model-loads-but-slow
It is fast on mains power and slow on battery	macOS caps sustained performance on battery	Fix 3: plug it in, and check Low Power Mode
Your numbers never matched the review you read	Published benchmarks are burst numbers from a cold machine	Fix 5: compare against sustained figures, not burst
A MacBook Air degrades far more than a Pro of the same generation	No fan — the Air has no way to shed sustained heat	Fix 4: expect it, and plan around it

When you see it

The pattern is specific and it is what separates this from ordinary slowness: the first responses are quick, and somewhere between two and ten minutes into real work the same model on the same prompt takes roughly twice as long.

You are summarising a long document or running a batch, rather than chatting in short bursts.
You have a MacBook Air, which is fanless.
The machine is on your lap, on a duvet, or in a closed stand with no airflow.
You are on battery, or Low Power Mode is on.
Your tokens per second never matched the benchmark in a review, and you assumed something was misconfigured.

What's actually going on

Sustained inference is close to the heaviest continuous load you can put on a Mac: the GPU runs flat out for as long as generation continues, and unlike a game there are no quiet frames. Every chassis has a sustained thermal budget lower than its burst one, and once the die reaches its target temperature the system lowers clocks to hold it there. That is designed behaviour, not a fault. How much you lose depends almost entirely on the chassis: a fanless MacBook Air has only the case to shed heat into and throttles hardest and soonest; the 14- and 16-inch Pro chassis have real cooling and hold clocks far longer; a Mac Studio or Mac mini on a desk is effectively unconstrained for this workload. Published benchmarks are almost always burst numbers from a cold machine, which is why the review you read does not describe your afternoon.

How to fix it

1. Confirm it is heat and not something else

The distinguishing test is time, not absolute speed. Run the same prompt at the start of a session and again after ten minutes of continuous generation, and compare the reported eval rate. A drop of roughly half over that window is throttling. Slowness that is present from the very first token is a different problem — placement or memory — and belongs on a different page.

zsh

# zsh — same prompt, cold and hot
ollama run qwen3:8b "Write exactly 200 words about the sea." --verbose
# ... run continuously for ~10 minutes, then repeat the identical prompt
ollama run qwen3:8b "Write exactly 200 words about the sea." --verbose

Did it work? The eval rate at minute 10 is materially below minute 1 on an identical prompt. If both are equally slow, this is not throttling.

2. Measure the GPU power and die temperature directly

powermetrics shows what is actually happening rather than what it feels like. Watch GPU power and the die temperature over a long run: power ramping to a peak and then settling at a visibly lower plateau, with temperature flat at a ceiling, is throttling in one graph. Sample once a second and leave it running through a real workload rather than a short test.

zsh

# zsh — GPU power and SMC sensors, once a second
sudo powermetrics --samplers smc,gpu_power -i 1000

# Just the two lines that matter, for 60 samples
sudo powermetrics --samplers smc,gpu_power -i 1000 -n 60 \
  | grep -E "GPU Power|die temperature"

Did it work? GPU power settles at a plateau below its early peak while die temperature holds flat at a ceiling. That pair is the signature.

sudo powermetrics --samplers smc,gpu_power -i 1000 -n 10 | grep -E "GPU Power|die temperature"

3. Plug it in and turn Low Power Mode off

macOS caps sustained performance on battery independently of temperature, so a machine can throttle while still cool. Low Power Mode (System Settings → Battery) does the same thing more aggressively and by design. Both are quick to rule out and both produce exactly this symptom. On mains power with Low Power Mode off you are measuring the chassis rather than the power policy.

zsh

# zsh — on AC, and is Low Power Mode on?
pmset -g batt | head -2
pmset -g | grep -i lowpowermode   # 1 = enabled

Did it work? pmset -g batt reports AC Power and Low Power Mode reads 0. Re-run the cold/hot comparison to see how much of the drop that accounted for.

pmset -g batt | head -2 && pmset -g | grep -i lowpowermode

4. Give the machine somewhere to put the heat

Physical and unglamorous, and it accounts for a real share of the difference. Keep the lid open — a closed-lid MacBook in a vertical stand loses the case as a heat path. Keep it off soft surfaces: a duvet or a lap insulates precisely the surfaces the machine sheds heat through, and an Air has nothing else. Raising it a couple of centimetres on a stand with airflow underneath measurably changes the sustained plateau on fanless machines.

Did it work? The die temperature plateau in powermetrics is lower after the change, and the sustained tok/s plateau is higher.

sudo powermetrics --samplers smc -i 1000 -n 10 | grep -i "die temperature"

5. Calibrate expectations by chassis — our characterisation, not measured

Label on this table: it is our characterisation from the physics and from community reports, not measurements from our benchmark dataset. Our published benchmark set holds a small number of entries with a single Apple hardware key and no sustained-load rows at all, so nothing here can honestly be called measured. Read it as expectations, not data. MacBook Air (fanless): expect the largest drop, arriving soonest — often within the first few minutes of continuous generation. This is normal for the chassis and not a fault. MacBook Pro 14" / 16": holds clocks far longer; a modest decline over a long run is normal. Mac Studio / Mac mini: effectively unconstrained for this workload; a large sustained drop here is worth investigating as a fault rather than accepting. What is not normal on any of them: a drop within seconds, or one that persists after the machine has cooled and been left idle.

zsh

# zsh — which chassis is this?
system_profiler SPHardwareDataType | grep -E "Model Name|Chip|Memory"

6. For long jobs, stop fighting physics Most common fix

If your work is genuinely sustained — batch summarisation, a long agent run, processing a corpus — the productive move is to reduce the load rather than to chase cooling. A smaller model or a shorter context lowers the work per token, which lowers the power draw, which raises the plateau you settle at. A model one tier down that holds its speed for an hour finishes a long job sooner than a larger one that halves after four minutes. Work out which size sits comfortably on your machine before starting the batch.

zsh

# zsh — compare sustained rates, not the first response
ollama run qwen3:8b   "Summarise this in 100 words." --verbose
ollama run llama3.2:3b "Summarise this in 100 words." --verbose

Did it work? The smaller model still reports close to its opening eval rate after ten minutes of continuous work. That plateau, not the first number, is what determines how long the job takes.

Check what fits your hardware — find a model size that holds its speed through a long job
Open the VRAM checker →

If none of this worked

If speed is poor from the first token rather than degrading, throttling is not the explanation and the cross-platform slowness page is the right one. If the machine is also swapping, that will dominate any thermal effect and should be fixed first.

Include this when you report it

Eval rate at minute 1 and minute 10 on an identical prompt
sudo powermetrics --samplers smc,gpu_power output covering both points
Your Mac model and chip from system_profiler SPHardwareDataType
Whether the machine was on AC power, and Low Power Mode state

A model that fits most setups:

View model & requirements →

Frequently asked questions

Why does my Mac slow down partway through a long generation?

Because sustained inference keeps the GPU at full load continuously, and every chassis has a sustained thermal budget lower than its burst one. Once the die reaches its target temperature, clocks drop to hold it there. That is designed behaviour, not a fault.

How do I tell throttling apart from a configuration problem?

By timing. Throttling starts fast and degrades over minutes; a configuration or memory problem is slow from the first token. Run the same prompt cold and again after ten minutes of continuous work and compare the eval rates.

Why does my MacBook Air throttle so much more than a Pro?

The Air is fanless, so its only path for shedding heat is the case itself. A 14- or 16-inch Pro has active cooling and holds clocks far longer under the same load. Both are working correctly; the chassis is the difference.

Why do my numbers not match published benchmarks?

Because published figures are almost always burst numbers from a cold machine, measured over a short run. Your sustained rate after ten minutes of real work is a different quantity, and it is the one that determines how long a job actually takes.

Does running on battery make it worse?

Yes. macOS caps sustained performance on battery independently of temperature, and Low Power Mode caps it further by design. Both produce this symptom while the machine is still cool, so rule them out before concluding it is heat.