--- title: "LM Studio Slow on Mac: Prompt Processing Is Usually the Culprit" description: "Slow local inference on Apple Silicon is usually prompt processing, not generation. The difference decides which fix works, and most advice targets the wrong one." date: 2026-08-10 author: "Ben Racicot" tags: ["LM Studio", "Apple Silicon", "Performance", "Local LLM", "macOS", "Troubleshooting"] type: "article" canonical: "https://modelpiper.com/blog/lm-studio-slow-mac" --- # LM Studio Slow on Mac: Prompt Processing Is Usually the Culprit > Slow local inference on Apple Silicon is usually prompt processing, not generation. The difference decides which fix works, and most advice targets the wrong one. ## TL;DR Local inference has two speeds, not one. Prompt processing chews through everything you sent before the first token appears, and generation produces tokens after that. They are bound by different hardware limits and they have different fixes. If the wait is before the first token, no amount of model swapping will help you. "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](/blog/lm-studio-gpu-offload-mac). ## 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](/compare/is-lm-studio-free). ## Steps ### 1. Time the two phases separately Send a short prompt in a fresh chat and note how long until the first token appears, then how fast the text flows after that. A long gap before the first token is prompt processing. A quick first token followed by a crawl is generation. Everything below depends on knowing which one you have. ### 2. Start a new chat If the slowdown grew over a session, the conversation is the cost. A new chat resets the context to nothing and should be immediately fast. If it is, you have your answer and the fix is habit rather than configuration. ### 3. Put context length back down Set context to what the task needs, not to the model's maximum. It costs you twice: processing time on every turn, and memory that comes out of the same pool as the weights. This is the highest-leverage single setting on Apple Silicon. ### 4. Check what else is resident Run `lms ps` to list models currently in memory. A model you loaded an hour ago is still holding its full footprint, which pushes everything else toward the ceiling. Unload it. ### 5. Only now change the model If generation is the slow half and the machine is otherwise clear, the model is too big for your memory bandwidth. Drop one quantization step or one size class. If you want the speed back without the size change, try a compatible draft model for speculative decoding instead. ## FAQ ### Why is LM Studio slow on my Mac? Decide first whether the wait is before the first token or during generation. Before the first token is prompt processing, which scales with how much context you sent, and the fix is a shorter context or a fresh chat. During generation is memory bandwidth, and the fix is a smaller model or quantization. Most advice online targets generation while most complaints are actually prompt processing. ### Why does prompt processing get slower every message? Because each turn resends the whole conversation, so there is more to process every time. If the cache from the previous turn is not reused, the entire history is reprocessed from scratch on every message and the cost compounds. Starting a new chat when the topic changes fixes it immediately, which is also how you confirm this is the cause. ### Does GPU offload make LM Studio faster on Apple Silicon? Setting it to maximum does, because anything less moves work to the CPU for no memory saving. But it is a one-time correctness fix rather than a tuning dial: on unified memory there is no separate pool, so there is nothing to optimize past all layers on Metal. If offload is already at maximum, this is not your lever. ### Is LM Studio slower than Ollama or llama.cpp? Not in any way our own measurements support. We ran identical Q4\_K\_M GGUF files through two engines on an M2 Max and the spread was single digits in both directions, with the winner flipping by model. When two llama.cpp-based apps differ noticeably on the same Mac, compare context length, KV cache precision, GPU offload and what else is resident before concluding the engine is the difference. ### What is speculative decoding and will it help? It pairs a small draft model with your main one. The draft proposes several tokens, the main model verifies them in a single pass, and generation gets faster with no quality loss when the drafts are accepted. LM Studio supports it. The constraint is compatibility: the draft has to match the main model architecturally, and for many models no suitable draft exists, which is what most people run into. ### Why are my model downloads so slow? That is a network question, not an inference one. Models come from Hugging Face, so speed depends on their CDN, your connection and your distance from an edge node. No inference setting changes it, and a slow download says nothing about how the model will perform once it is on disk.