To make Qwen 3.8 27B faster on an M1 Mac, do not add a speculative-decoding adapter — on M1-generation hardware they measured slower in every configuration we tried. Speed up prompt processing instead. Kynd's wide-GEMM prefill and last-row vocab projection measured 1.476× faster prefill at lower peak memory, with byte-identical output, and its caching layer removes prefill altogether on repeat turns.
There is a quiet assumption in local-AI tooling that a Mac is a Mac. It is not. The optimisation that wins on an M4 can lose on an M1 — not by a little, and not by accident.
Kynd is built and benchmarked on Apple Silicon that people actually own, including the M1, M2 and M3 machines that most new inference packages are no longer tuned against. This post shows the measurements behind that, using Qwen 3.8 27B as the example.
Why new adapters go backwards on M1
Every inference optimisation is a trade between two resources: arithmetic (compute) and memory traffic (bandwidth). Which one you have spare decides which trades pay.
An M1 Max has roughly 400 GB/s of memory bandwidth against about 10 TFLOPS of GPU compute. It is bandwidth-rich and compute-poor. An M4 Pro — the machine most MLX packages publish their numbers on — has meaningfully less bandwidth and comparable compute. It sits on the other side of the line.
Now look at what speculative decoding does. A small "drafter" model guesses several tokens ahead, and the big model verifies them in one wider pass. You do more arithmetic per step in order to read the weights fewer times. That is a superb trade when bandwidth is your constraint. It is the wrong trade when compute is.
The adapter benchmarks
We have now measured three separate "make your local model faster" adapters on this hardware. All three published real speedups on newer or larger machines. All three were net losses here.
The DSpark result is the instructive one, because the drafter was not at fault. It hit an acceptance rate of 2.38 tokens per round against a published 2.44, and it cut the number of expensive full-model passes from 200 down to 63. It did everything it promised. The model still got slower:
Read that table downwards. The better the drafter did, the slower the machine got. Fewer full-model passes, more time. That is the signature of an optimisation running against the grain of the hardware, and no amount of tuning the adapter fixes it.
The real bottleneck is prompt processing
If you want a local 27B model to feel fast, decode speed is not where the time goes. Prompt processing — prefill — is. On an uncached agent turn it is the overwhelming majority of the wait.
Qwen 3.8 27B is unusually slow at it, and there is a specific architectural reason. It is a hybrid model: only every fourth layer is standard attention. The other 48 of its 64 layers are recurrent GatedDeltaNet layers, which must walk a prompt one token at a time. Normal prefill is fast because it processes the whole prompt as one parallel operation — and three quarters of this model cannot do that.
This is worth knowing because it looks like a bug and is not. Measured on M1 Max at 4-bit, prefill runs around 52–59 tokens/sec where a conventional dense 27B would suggest double that. Chasing it through settings is wasted effort. The answer is to make the prefill that remains cheaper, and to avoid doing it at all where possible.
What actually works on M1
1. Wide-GEMM prompt processing. MLX's quantized matmul re-expands each block of compressed weights every time it processes another slice of rows. During decode that is free. During prefill it is repeated work. Expanding the weight once and running an ordinary matrix multiply trades a little extra memory traffic for a lot less arithmetic — exactly the right direction on this chip.
Measured against the same operation, comparing an M1 Max with the package author's published M4 Pro figures:
On the M4 Pro this technique is marginal — at the narrowest width it is a small loss. On the M1 Max it more than doubles the operation. It is the same idea, on the same software, with opposite conclusions. Which is precisely why it is absent from tools that only benchmark on current hardware.
2. Stop computing logits nobody reads. During prefill, the standard generation loop pushes every prompt token through the model's vocabulary projection, then discards all but the last. With Qwen 3.8's 248,320-token vocabulary that is around 5% of prefill arithmetic and a temporary buffer of roughly 1 GB per chunk, thrown away. Projecting only the final row removes both.
Together, on a 2,059-token prompt, three interleaved rounds, medians:
Note the last column, and the memory one. The two techniques pay for each other — wide-GEMM's temporary buffers cost memory, the last-row projection gives more back — so the tuned configuration is faster than stock while using less peak memory than stock. And the generated tokens are identical, verified token by token, not "similar".
3. Do not prefill at all. The largest win is structural. Kynd saves the model's working state after each turn and reloads it on the next, so a continuing conversation skips reprocessing everything that has not changed. On this machine that has measured 18–37× on repeat turns, and there is a second layer that processes tool output while the tool is still running, when the GPU would otherwise be idle — turning a 31-second wait after a large command into under a tenth of a second.
Does this apply to Qwen 35B and other models?
The principle does; the magnitude varies, which is why Kynd measures rather than assumes.
Qwen 3.6 35B-A3B is a mixture-of-experts model — only a fraction of its parameters are active per token — so it prefills far faster than a dense 27B to begin with, and it benefits less from wide-GEMM because its expert weights sit in a different layer type that the technique does not reach. Kynd calibrates on first load and simply does not enable what will not help.
Prompt-processing batch size is another per-machine constant rather than a universal one. On this Mac with Qwen 35B, 2,048 tokens per batch measured fastest at 492 tok/s, against 403 at 512 and 427 at 4,096 — the curve has a peak in the middle, and that peak moves with the chip and the model.
That is the difference in approach. A hardcoded constant is right for the machine it was measured on and slowly wrong everywhere else. Kynd calibrates for the Mac in front of it, caches the result, and re-measures when the chip, the runtime or the model changes.
M1 Mac speed FAQ.
How do I make Qwen 3.8 27B faster on an M1 Mac?
Target prompt processing, not decode. Wide-GEMM prefill plus last-row vocabulary projection measured 1.48× faster on an M1 Max at lower peak memory, and cache reuse removes prefill entirely on continuing turns. Avoid speculative-decoding adapters on this generation of hardware — every one we tested measured slower.
Why did my speculative decoding adapter make things slower?
Because it is trading the wrong resource. Speculative decoding spends compute to save memory bandwidth, and M1-generation chips have bandwidth to spare and limited compute. A high acceptance rate does not rescue it — in our sweep, the settings with the best acceptance were the slowest overall.
Is 50–60 tok/s prompt processing normal for Qwen 3.8 27B?
Yes on an M1 Max at 4-bit. The model is a hybrid in which 48 of 64 layers are recurrent and cannot process a prompt in parallel. Independent reports for this model class on M1 Max land in the same range. It is architectural, not a setting you have missed.
Do these tunings change the model's output?
No. Both are verified bit-exact — Kynd checks that each weight shape reproduces the original result before using the faster path, and falls back to the standard path wherever it cannot. We compare generated tokens directly, not just quality impressions.
Should I just buy a newer Mac?
A newer chip does decode faster. But the tuning that helps is generation-specific, and an M1 Max with plenty of unified memory will run a large model that a newer machine with less memory cannot load at all. For big local models, memory capacity comes before chip generation.
Does Kynd work on M2 and M3 too?
Yes. Kynd calibrates on the machine it is installed on rather than shipping one chip's constants, so each Mac gets the settings that measured fastest on it — including the decision not to enable something that does not help.