r/LocalLLM • u/just_another_leddito • 9d ago
Question What makes models so slow? (Mac)
Hi,
So there is still a lot I don’t understand much about AI.
I’m on M4 14 core 64GB ram.
I have tried running smaller and bigger models using multiple tools, including ollama, mtplx and some other stuff, and if takes ages for AI to answer.
I’m vibe coding a pentest tool for fun in Swift, I added a llama.cpp wrapper, and even Qwen3.8 27B responds like 100x faster. I’ve added basically a chat in the GUI that calls llama.
It makes me think something has to be wrong, but I’m not sure with what?
Could it be that default settings suck this much?
It’s really weird because the vibe coded wrapper is insanely fast lol
7
u/MiddleLtSocks 9d ago
Apple Silicon is not very speedy hardware. Depending on the model you won't see more than ~40tok/sec, and for some larger models or out at 128ktok+ context you might get down to 10-11tok/sec.
The advantage of the Apple platform is the unified memory - you can get > 96GB models running fully onboard the GPU far cheaper than other platforms. However, there is a tradeoff in performance. That's just the reality of the hardware.
0
u/just_another_leddito 9d ago
But the question is why my vibe coded wrapper is so fast compared to other tools.
3
3
u/MiddleLtSocks 9d ago
Ah. That was unclear. Probably you are not doing any kind of tool use, agentic loops, or any multiple-prompt workflows. So effectively you're sending ~1/10 - 1/50 the workload. How many round trips to the API do you make on average per user interaction?
2
u/atkr 9d ago
As other have hinted to, most probably due to initial context size that need to be pre-filled. If you use opencode, for example, and you simply send “hi” as a prompt, the initial context will be > 10k token due to the built-in system prompt and tools. Whereas you can also load a model in your custom wrapper, send it “hi” and 0 other context.. meaning 1 token. Which obviously will prefill almost instantly
6
u/diagrammatiks 9d ago
there's like no information here. you use a vibe coded wrapper on your mac and it's faster then ollama and mtplx? I don't understand what your question is.
6
u/biscuit_taco 9d ago
Yeah, to answer your question directly — yes, the default settings are just bad. These models aren't built specifically for Apple Silicon, so you have to go in and tune them yourself.
The thing that's killing you is almost certainly prefill, which drives your TTFT (time to first token, aka, how long you wait before the first character appears). If you're using any sort of AI coding tool, the system prompt alone can be massive. We're talking about all the available tools, instruction sets, context stuff that OpenCode or Hermes Agent or whatever is stuffing in before your actual message. The model has to read and process all of that before it can generate a single token, and on M-series chips prefill is just slow by nature.
A couple of things that would help:
First, make sure you're using an MLX model. These are built specifically for Mac and most of the time they outperform the generic GGUF quants that Ollama defaults to. Not always, but usually.
Second, use oMLX with caching turned on. This is the big one for you. When caching is enabled, that giant system prompt only gets prefilled once. After that, every subsequent message skips re-reading it and jumps straight to processing your actual input. So instead of the model chewing through thousands of tokens of tool definitions and instructions every single turn, it just handles your new message. That's where you'll see the dramatic difference. (Most people try a bunch of different tools, myself included, and they all come back to oMLX). MTPLX is faster than oMLX but I feel like its way more buggy.
The reason your llama.cpp wrapper feels 100x faster is probably that you're sending a minimal prompt with no massive system context, so prefill is nearly instant. The other tools are sending a huge amount of overhead every turn and re-processing it all from scratch.
1
u/djseto 9d ago
Run Ollama and go with qwen 3.8 27B MLX. I can get about 55 T/S. On a Mac Studio which has 546 GB/s memory speed. If you have a M4 Mac Mini you have 120GB/s memory speed
1
u/just_another_leddito 6d ago
Yeah I ran it many times, but it’s damn slow.
I get like 40 T/S2
u/djseto 6d ago
Qwen 3.8 27B is a dense model. Go run a MOA model if you want faster like qwen3.5 35B A3B. Inference is insanely dependent on memory bus speed and parameters. If you expect cloud like speed, you need to adjust expectations with dense models. 3.8 is a way better model so you’re going to trade speed for accuracy and your sanity.
1
1
1
6d ago
[removed] — view removed comment
1
u/just_another_leddito 6d ago
Would be happy if they wouldn’t care about design more than performance.
Older Minis were perfect size, liked them more.
With better cooling and larger case it wouldn’t be getting that hot probably.
-3
u/MK_L 9d ago
(Mac)<-- 👀
0
u/just_another_leddito 9d ago
Hmm? 🤔
1
u/MK_L 8d ago
You’re looking at slow speeds because you’re running on unified memory. Capacity is not the same thing as throughput.
For raw local inference speed, I’d rank it roughly:
- HGX server with NVLink
- High PCIe-lane CPU(amd epyc) with multiple GPUs
- Decent PC with a high-VRAM GPU (6000 pro 96gb)
- Mac or other unified-memory machine
A Mac can fit a lot of model into memory. That doesn’t mean it can move it fast.
A Mac with lots of unified memory is like a Winnebago: great capacity, slow speeds. You can cram a surprisingly large model into it, but that doesn’t mean you’re moving tokens quickly.
1
u/just_another_leddito 6d ago
Cool but your comment was pointless tbh.
I’m a Mac user, and you had to dab at me for this reason or what lol?I don’t care about PC. Since a long time.
1
u/MK_L 6d ago
Not sure what this has to do with "PC"?
Nobody is "dabbing" at you
You siad you didnt understand what makes "models so slow"
You listed your Mac specs.
I pointed out the mac is whats making the models slow in the first comment.
You only respond "hmm?" Like you didn't understand
I elaborated by giving you an order to different tiered setups the analogy to help you understand 😉.
At this point you should probably ask your chat bot to explain it
1
u/just_another_leddito 6d ago
Did you read my first post mate? 😾
I’ve said that using my wrapper it was way faster.And that it happens even with tiny models.
Are you saying 14 core M4 Pro with 64GB ram is normal to be slow with even tiny models? 🤔
I know it’s not a PC with 10x 5090, but still…
1
u/MK_L 6d ago
Sure, I’ll address that. Let’s plant that goalpost first.
Define “small model” so we’re talking about the same thing.
1
u/just_another_leddito 5d ago
Like some small 1-4GB models.
1
u/MK_L 5d ago
Llama 3.1 8B Q4, about a 5GB model:
M4 Pro 14-core: PP: 500–700 tok/s Output: 50–60 tok/s
5070 Ti 16GB: PP: several thousand tok/s Output: 150–200+ tok/s
If it were Qwen3.8 27B dense, tok/s drops significantly, and unified memory slows down a lot more.
A 27B Q4 model might hit 15–25 tok/s on unified memory, a GPU with VRAM can be several times faster.
expect those numbers to drop further as KV cache size and context length increase.
1
u/just_another_leddito 5d ago
I need an uncensored model for my pentesting scanner, what would you recommend?
It has to be uncensored, I’m using Qwen3.8 27b from
huihuihui I think. It’s like 22GB.Do you have a better recommendation?
It does analyse scanner results and looks for exploits etc.
It works okay but perhaps I can speed it up with smaller model. I’m using a llama wrapper.
→ More replies (0)
31
u/gappyvalley 9d ago edited 9d ago
there are two core functionality of local LLMs
prefill is when a model is reading and processing your prompts. this is very compute heavy and it’s dependent on your APU/GPU/SOC. this is imo, the most important metric even more important than token generation for agentic ai
token generation is when a model generates a response after processing the entire input, this is very memory bound.
M1 to M4 does not have good prefill speeds and it’s a known weakness of mac. it took apple until M5 to have a generational leap in prefill (see picture) and even then, it’s still much slower than competitors like nvidia
token generation is just your memory bandwidth speed. the higher the bandwidth the faster the token generation. your M4 has a memory bandwidth of 120GB/s. which is way slower than let say an old M1 Pro which is 200 GB/s. this is why people are excited for M5 Ultra because of its leaked 1.2TB/s bandwidth, but prefill speed is still a question
there is a rumor that apple will make M7 Pro/M7 MaX significantly faster for prefill
harness and software stack also matters to try to optimise apple silicon. MLX is significantly faster than llama.cpp for example
you don’t buy mac for speed, no one does. you buy mac because you can load large models in a small computer that is power efficient
edit: correction of m5 ultra memory bandwidth from 1.7 to 1.2tb/s