"Slow" is two completely different problems wearing one word, and picking the wrong one is why so much tuning advice does nothing.
Prompt processing, sometimes called prefill, is the work done before the first token appears. The model reads everything you sent, the system prompt, the conversation so far, any attached file, and builds the state it needs to answer. This is compute-bound and it scales with how much you sent.
Generation, or decode, is what happens after. One token at a time, each one requiring a pass over the model weights. This is memory-bandwidth-bound and it scales with how big the model is.
Time the gap. If the delay is before the first token and generation then runs at a reasonable clip, you have a prompt processing problem and swapping to a smaller model will barely help. If the first token comes quickly and then the text crawls out, that is generation, and the model is too big for your machine's bandwidth.
Why does it get slower the longer the conversation goes?
Because prompt processing cost scales with everything in the context, and a conversation grows. Every turn resends the whole history, so turn twenty has far more to process than turn one. If the cache from the previous turn is not reused, the app reprocesses the entire conversation from scratch on every single message, and the slowdown compounds until it feels like the app broke.
This is the single most common shape behind "it was fine yesterday" and "it suddenly got slow", and it is also why the searches cluster around prompt processing progress rather than tokens per second. Nothing degraded. The conversation got long.
The fixes are unglamorous and they work. Start a new chat instead of continuing a long one when the topic changes. Keep the system prompt short, because it is reprocessed as part of every turn. And be deliberate about attaching large documents to a chat you intend to keep using, since the document stays in the context for every subsequent message.
Why context length is the setting that costs you twice
A long context makes the KV cache large, and the KV cache competes with the model weights for the same unified memory. So raising context length both slows processing and shrinks the budget the model has to fit in. On Apple Silicon those come out of one pool, which is why a context increase can turn a working setup into a failing one.
Set context to what the task needs rather than to the maximum the model advertises. A 128K window on a machine that has to hold the cache for it is a real cost paid on every turn, not a free capability.
Is the model simply too big for the machine?
Generation speed is bounded by memory bandwidth, so a model that needs to stream more bytes per token generates more slowly, in a fairly linear way. But there is a cliff, not just a slope, and the cliff is the one worth knowing.
macOS reports a working-set ceiling to Metal that is a fraction of installed RAM, not all of it. On our M2 Max with 32GB it reads 26,800,603,136 bytes, roughly 25GiB. When the model plus its cache approaches that number, the machine starts fighting itself, and what you feel is not gradual slowness but a sudden collapse. If throughput fell off a cliff rather than degrading, this is where to look. The mechanism is in the GPU offload piece.
Three Mac-specific things that are not the app
Thermals. A MacBook Air has no fan. Sustained inference will heat it and the chip will throttle, so the first few minutes are faster than the tenth. This is not fixable in software and it does not happen on a Mac Studio or a Mac mini.
Memory pressure from everything else. The Metal ceiling is fixed but the space under it is shared with your browser, your editor and any container runtime. Check Activity Monitor's memory pressure graph before blaming the model.
Low power mode. It does what it says. If it is on, inference is one of the first things to feel it.
Why is LM Studio slower than another app on the same Mac?
If two llama.cpp-based apps differ noticeably on the same machine with the same model, the difference is configuration rather than engine. We measured this directly: our 2026 same-bytes benchmark ran identical Q4_K_M GGUF files through two engines on an M2 Max and landed within single digits in both directions, with the winner flipping by model. Engine choice is not where local inference speed comes from.
What does differ between apps is what they set for you: context length defaults, whether the KV cache is quantized and at what precision, how many layers go to Metal, whether the cache is reused across turns, and whether another model is still resident. Compare those four before concluding one app is quicker. Nine times out of ten the settings are not the same and the comparison was never like for like.
Speculative decoding is worth knowing about here, because LM Studio supports it and it genuinely helps generation. It pairs a small draft model with the large one, and the large model verifies several drafted tokens at once instead of producing each from scratch. When it works, generation gets meaningfully faster at no quality cost. The catch is that the draft model has to be architecturally compatible with the main one, which is why the searches around it are mostly people discovering no compatible draft model exists for what they are running.
Slow downloads are a different problem entirely
A large share of "LM Studio is slow" searches turn out to be about download speed, which has nothing to do with inference. Model downloads come from Hugging Face, so throughput depends on their CDN, your connection and your distance from an edge node. A multi-gigabyte file at a rate you would not accept from a browser download is a network issue, not an app one, and no inference setting affects it.
The alternative: fewer defaults to get wrong
Nothing on this page is a speed claim, and this section is not either. ToolPiper embeds upstream llama-server directly, build b10068, unmodified, and against Ollama on identical bytes we measured parity, not an advantage. Anyone selling you a faster local runner on Apple Silicon is selling you a configuration difference with a badge on it.
What is different is which decisions you have to make. The engine launches with full Metal offload every time, because on unified memory that is always correct. The KV cache type is chosen per model by reading the GGUF header and checking what Metal can actually serve for that architecture, rather than being one global setting applied to everything you load. Model suggestions are sized against your installed memory and the live Metal ceiling, so the cliff described above is something you are warned about rather than something you discover.
Around that, the free tier is the whole runner: unlimited GGUF downloads, multi-model switching, the local OpenAI-compatible API, embeddings, developer tokens, all speech, browser automation, and an MCP server with over 420 tools. Local RAG over your files is the $10 Pro tier. No account, no caps, no terminal.
The honest limits: macOS 26 or newer and Apple Silicon only. LM Studio requires macOS 14.0 and runs on Windows and Linux as well, and its model browser is better than ours.
One more thing to weigh, because slow prompt processing is usually when people look around: price is not the differentiator here and we will not pretend it is. LM Studio is free for local use and meters its cloud by the token. Our runner is free, and what we charge for sits above the model-running layer entirely. The split, in detail.