Overview
Your local LLM is usually slow on a Mac because the model, its KV cache and macOS together need more unified memory than you have free, so work spills to swap or to the CPU. Large contexts, a throttled chip and a poorly matched speculative-decoding draft model are the next suspects. This page orders the checks from most to least common in the public issue threads cited below. It gives no speed numbers: this site publishes none, and how fast your own Mac is can only be learned by measuring it with measure-tokens-per-second-mac. The ordering is this site’s reading of those threads, not a measured frequency.
Why is my local LLM slow on Mac? Start with memory
Check memory first, because a model that does not fit is the cheapest cause to rule out and the one the fit arithmetic below can test.
Apple’s Activity Monitor guide says Memory Pressure “graphically represents how efficiently your memory is serving your processing needs”, determined by “the amount of free memory, swap rate, wired memory, and file cached memory”. It defines Swap Used as “the amount of space being used on your startup disk to swap unused files to and from RAM.” Open Activity Monitor while the model generates. Swap growing during generation means the run is competing for memory. Apple’s page does not say what the green, yellow and red colors mean, so this page does not interpret them.
Then do the fit arithmetic from methodology: total_GB = weights_GB + kv_GB + overhead_GB, with weights_GB = params × bits / 8 / 1e9 and a 2 GB overhead assumption. Worked example from how-much-ram-for-local-llm: Qwen2.5-32B-Instruct at 4.0 bits and context 4096 is 16.25 + 1.074 + 2 = 19.324 GB. On a 16 GB Mac that total is already above installed memory, before the macOS reserve, which is unknown. A 4.0-bit figure is a round number, not a measured GGUF size, so real files differ. For crashes rather than slowness see ollama-out-of-memory-mac.
Is the model running on the CPU instead of the GPU?
A partly offloaded model is slower, and Ollama shows the split. Ollama’s FAQ says ollama ps shows what is loaded, that “100% GPU means the model was loaded entirely into the GPU”, and that “48%/52% CPU/GPU means the model was loaded partially onto both the GPU and into system memory”. Anything short of 100% GPU is worth fixing by choosing a smaller model, a smaller quantization or a shorter context.
The same cause appears in Ollama issue 11577, “Why ollama is so slower than LLM Studio ?“. The reporter was on Windows 11 with an NVIDIA GPU, not a Mac. A maintainer found that 24 of 49 layers were on the GPU and that the prompt exceeded the context window. They noted that “model weights in RAM are processed by the CPU, which is slower than model weights in VRAM”, and that “LMStudio is not intrinsically faster than ollama. It comes down to configuration.” On a Mac, GPU-usable memory is a separate limit; see mac-gpu-memory-limit and unified-memory-vs-vram.
Is it slow before the first word, or while writing?
Waiting a long time before output starts is prompt processing (prefill), and it is a different cost from writing tokens. llama.cpp issue 2428, “Is there a way to speed up prompt processing for Metal? (M1/M2)”, opened because prompt evaluation was much slower than generation. Commenters attributed it in part to a missing GEMM kernel for quantized data and not to the tokenizer, and later Metal batch-processing changes were credited with large gains. The thread is from 2023 and was closed by a stale bot, so it shows the symptom and the vocabulary, not a current fix. Practical checks: shorten the prompt, trim chat history, and update your runtime.
Is your context size too large?
A longer context adds KV cache and more prompt to process. The KV formula is kv_GB = 2 × layers × kv_heads × head_dim × context × 2 / 1e9. For Qwen2.5-7B-Instruct that is 0.235 GB at context 4096 and 1.879 GB at 32768 (see long-context-on-mac). Ollama’s FAQ says “By default, Ollama uses a context window size of 4096 tokens”, changeable with OLLAMA_CONTEXT_LENGTH, while its context-length page lists defaults of 4k, 32k and 256k by VRAM tier and the Modelfile reference says “(Default: 2048)” for num_ctx. These disagree, so check the CONTEXT column of ollama ps (details on long-context-on-mac). Raising it to fit a big codebase raises memory, which can push a borderline model into swap. If a prompt exceeds the window, it is truncated, as in issue 11577 above.
Is your Mac throttling?
Possibly, and some of it is controlled by macOS, not by your runtime. In llama.cpp issue 10444, “Heavy throttling during token generation on Apple Silicon”, the reporter on a 14-inch M3 Max with 128 GB saw repeated benchmark runs slow down while core temperatures stayed at 60-70°C. A contributor testing an M2 Max with an 8B model used powermetrics and showed GPU frequency falling from about 1385 MHz to about 873 MHz after the initial burst, writing that “The frequency scaling is controlled internally by the OS and DCVS FW.” A maintainer could not reproduce it on an M1 Pro, M2 Ultra or M4 Mac mini, while others reproduced it on an M3 Max and M2 Max. No fix was made in llama.cpp and the issue was closed as stale, and a later commenter reported that external cooling plus High Performance mode on AC power raised GPU power. What Apple’s High Power mode does is unknown to this page: the Apple support pages read on 2026-10-13 did not describe it.
A Hacker News thread on a MacBook Pro 14 with M5 Max shows commenters disagreeing over whether the cause is heat or a power cap. Treat it as discussion, not evidence. Whether any given Mac throttles, and how soon, is unknown here.
Why is speculative decoding slower on my Mac?
Speculative decoding only helps when the draft model is cheap and well matched. LM Studio’s documentation says it “requires more computation and resources than running the main model on its own”, that the draft model must share the main model’s vocabulary, and that with a poor draft model “the generation speed will not increase, and could actually decrease.” llama.cpp issue 23011 reports a multi-token-prediction setup on an M1 Pro with 32 GB that ran far slower than baseline on Metal even with high acceptance. A commenter later linked #23752 as a duplicate; the page read does not confirm a fix. A maintainer also advised dropping the --cache-type flags because KV quantization is not optimized for Metal. If a run got slower after enabling a draft model, turn it off first.
Is Ollama slower than LM Studio on a Mac?
No source this page read shows one tool is inherently slower on a Mac. The only thread with the exact complaint (issue 11577) was Windows with an NVIDIA GPU, and the maintainer’s answer was configuration. A commenter there suspected LM Studio warms up the model on load, which is unverified. Ollama’s FAQ says models stay in memory for 5 minutes by default before unloading, so a first request after a pause includes loading. Compare both tools with the same model file, the same quantization, the same context and the same prompt; the side-by-side feature view is lm-studio-vs-ollama-mac.
A regression can also be version-specific. Ollama issue 16030 reports NVFP4 MLX models becoming very slow on an M1 Max with 32 GB when the same model was run again while still loaded. The reporter also saw it on an earlier version, and the issue was open with a “needs more info” label when read, so no cause is confirmed. If it started after an update, note your version and try the previous one.
Quick checklist
| Check | Where to look | Source |
|---|---|---|
| Swap growing while generating | Activity Monitor, Memory | Apple |
| Not 100% GPU | ollama ps, PROCESSOR column | Ollama FAQ |
| Total above installed memory | total_GB formula | methodology |
| Long wait before first word | Prompt size, context | issue 2428 |
| Slows over minutes | powermetrics GPU frequency | issue 10444 |
| Slower with a draft model | Turn the draft model off | LM Studio docs |
Questions
Why is my local LLM slow on Mac?
Most often the model plus KV cache plus macOS overhead is close to or above your unified memory, so work goes to swap or the CPU. Check Activity Monitor for swap, run ollama ps for the CPU/GPU split, then check context size, throttling and any draft model. Exact speeds are unknown until you measure them.
Is Ollama slow on Mac?
No primary source read here shows Ollama is inherently slow on a Mac. Reported slowness traces to partial CPU offload, oversized context, or a version-specific bug such as Ollama issue 16030. Run ollama ps and confirm it reports 100% GPU.
Is LM Studio slower than Ollama?
Unknown on a Mac. The one public thread asking this ran on Windows with an NVIDIA GPU, and a maintainer answered that “LMStudio is not intrinsically faster than ollama. It comes down to configuration.” Compare them on identical model, quantization, context and prompt.
Why is LM Studio slow?
The same causes apply: a model that barely fits, a large context, or a draft model that does not help. LM Studio’s own docs say a poor draft model can leave generation speed unchanged or lower. Turn speculative decoding off and retry with a shorter context.
Does Mac thermal throttling slow a local LLM?
It can. A llama.cpp thread reports slowdowns on an M3 Max with core temperatures at 60-70°C, and a contributor measured GPU frequency dropping during sustained generation on an M2 Max, saying scaling is controlled by the OS and firmware. How soon your Mac throttles is unknown.
Does speculative decoding make a local LLM slower on Mac?
Sometimes. LM Studio’s docs say speed “could actually decrease” with a poor draft model, and a llama.cpp issue reports a Metal setup far slower than baseline. Disable it to test.
How do I measure whether a fix helped?
Change one thing at a time and time the same prompt before and after, as described in measure-tokens-per-second-mac. This site gives no speed figures.
Sources read on 2026-10-13
- Ollama issue 11577: 24 of 49 layers on GPU, prompt over context, maintainer quote; Windows/NVIDIA report.
- Ollama issue 16030: NVFP4 MLX slowdown on M1 Max 32 GB on repeat runs, open, “needs more info”, no confirmed cause.
- llama.cpp issue 10444: throttling on Apple silicon (M3 Max report, M2 Max powermetrics), OS-controlled scaling, closed as stale.
- llama.cpp issue 23011: MTP slower than baseline on an M1 Pro 32 GB, maintainer advice on
--cache-type; #23752 linked as duplicate by a commenter. Reported speeds not repeated. - llama.cpp issue 2428: prompt processing slower than generation on Metal; 2023.
- Hacker News item 47384970: comments only, heat versus power-cap debate; no figures taken.
- Ollama FAQ:
ollama psPROCESSOR column, 4096 default context,OLLAMA_CONTEXT_LENGTH, 5-minute keep-alive. - LM Studio speculative decoding docs: draft model requirements and caveats.
- Apple Activity Monitor guide: Memory Pressure, Swap Used definitions.
- methodology: fit and KV formulas, 2 GB overhead assumption.