Local LLM speed on a Mac, October 2026: Apple Silicon (M1 Max) vs Intel i9, tokens per second

In May we benchmarked local AI on two MacBook Pros, an M1 Max with 64 GB and a 2018 Intel i9 with 32 GB, to decide what Remember This should run by default (the May post). Five months and several ollama releases later we measured the same two Macs again, and the first number we looked at was this one:

Everything below was measured with the Mac plugged in and Low Power Mode off. We also ran the best image, video and speech models on the M1 Max against the hosted ones, which got its own post.

What to run on which Mac

The runtime doubled the speed

The whole difference is ollama, the runtime most people use to run models on their own machine. We ran an old and a new version against each other on the M1 Max, alternating round by round so that whatever else the Mac was doing hit both equally, and the new one was about 1.8 times faster at both reading the prompt and writing the answer. Part of the jump is that newer ollama runs these models through llama.cpp's server instead of its own engine, so updating ollama can change which engine runs your model without you noticing.

So every ollama number in our May post is roughly half of what you get today, and all you need to do to get the rest is update.

A local model can drive Claude Code

New since May, we pointed Claude Code at a model running on the Mac (through ollama launch claude) and gave it a real job from our own app: writing short biographies of the people in a test library of 76 photos and notes, which means reading, searching and calling tools for 30 to 90 turns. qwen3.6:35b did it, and in October a session took about ten minutes (7 to 21 over ten runs), where hosted Claude took five.

In July and August the same job took half an hour to an hour. Part of that is a newer ollama, and part is that the task changed (it no longer waits on shell commands, and its prompt grew), and agent sessions vary a lot from run to run anyway, so we read the months as a trend rather than a measurement. Two things to know if you try this. Claude Code's auto permission mode asks a model whether each command is safe, and on a local backend that is the same model on the same GPU, so the check queues behind the work (in one run a browser step sat blocked for 45 minutes). And with permissions skipped altogether, the model said it was done in three runs out of three when it had done the work in one. We have only measured speed so far; whether the local biographies are as good as Claude's is still to compare.

How long can a conversation get?

An agent working through your notes keeps everything it has read in its context, and those sessions peaked at 76,000 to 105,000 tokens. So this time we pushed every model that fits in 64 GB to 100K and 200K tokens.

The fastest model, qwen3.6:35b, is a mixture of experts: of its 36 billion parameters only a few billion work on each token. qwen3.8:27b is smaller on paper but dense, so all 27 billion work on every token, and it writes four to five times slower. The parameter count tells you how much memory a model needs, and surprisingly little about how fast it is.

Writing is only half of it. Before the first word of an answer the model has to read everything already in the conversation, and past 64K that is where the time goes:

Up to 64K the faster models read the whole conversation in about a minute. At 100K it is five minutes, and at 200K between a quarter of an hour and more than an hour. ollama keeps what it has read in a cache, so a follow-up question only pays for the new text, but anything that empties the cache (loading another model, or the conversation outgrowing the window) brings the full wait back. So a 64 GB Mac can hold a 200K conversation, and about 64K is where we would keep a local agent. Everything that answered at 64K and 200K stayed coherent, with none of the repetition gemma4 fell into past 80K in May, and ollama's own MLX builds of the same models (qwen3.6:35b-mlx, gemma4:26b-mlx) were no faster than the regular ones.

An Intel Mac reads three to six times faster than in May

On the 2018 i9 the new ollama mostly improved reading. In May a 16K prompt took nine to fourteen minutes to read on this Mac, and two prompts of 32K timed out after half an hour. Now both finish:

Writing did not get faster, and on a CPU it falls off quickly as the conversation grows:

gemma4:e2b is still the model for an Intel Mac, up to about 16K. The qwen3 models are thinking models and spend most of every answer reasoning, which at half a token per second means a 32K conversation takes half an hour per reply, and that rules them out for anything interactive.

Captioning photos: Apple Silicon is 9 to 20 times faster

In May we wrote that Apple Silicon captions photos 15 to 24 times faster than Intel. That compared ollama on the Intel Mac with MLX on the M1 Max, so it changed the chip and the runtime at the same time. This time we ran the same 30 photos, prompt, token limit and runtime on both Macs, which leaves only the chip:

That is about 14 times faster for a typical model. On the M1 Max, switching from ollama to MLX adds another 1.3 to 2.8 times on top, which is how May arrived at its bigger number:

So on Apple Silicon MLX is still the faster way to caption photos, while for chat models ollama is. The two runtimes use different quantisations, and the captions came out at similar lengths, so this compares them the way you would actually run them.

The trap: captions that were never written

gemma4 and qwen3-vl are thinking models, and ollama counts their thinking against the output limit you set. With a limit of 120 tokens they spent all of it thinking and the caption came back empty. Our first October run timed 30 photos per model like that, and nothing looked wrong: plausible seconds per photo, no errors, every request answered.

gemma4 respects think: false and qwen3-vl ignores it, so for captioning use its -instruct tags, which do not think. Whatever you benchmark, check that the output is not empty before you trust the timing. It happens with text too: flint:40b answered short questions normally, but given a 64K prompt it was still thinking after 8,000 tokens.

Smaller things worth knowing

• Quantising the KV cache made ollama slower, 1.8 to 3.7 times, for a modest memory saving. On mlx-lm it went the other way at long context.
• ollama caches your prompt even when Claude Code says 0%. A resent 8,000-token prefix took 0.3 seconds instead of 20; the response simply carries no cache fields.
• A model tag can change under you. qwen3.8:27b now points at a build that ollama 0.40 cannot load, where in August it was one that ran. Pin the exact tag, such as qwen3.8:27b-q4_K_M.
• A busy Mac produces numbers that look fine. Our first sweep ran beside other work and came out faster at 48K than at 32K, which a quiet machine never does. Log the load before every run.

Everything we measured is in the october-2026 folder of the benchmark repo, including what this post leaves out: the KV-cache tables, local models driving real Claude Code sessions, Apple's SpeechAnalyzer against whisper, and every raw sweep.

Run it on your own Mac

The scripts that produced every chart here are in the same repo. We measured exactly one M1 Max and one Intel i9, so the most useful thing you could add is a run on an M2, M3 or M4, especially one with 16 or 24 GB, where we have nothing at all. Open a pull request with your results and we will add them.

The results feed the model defaults in Remember This, one of our apps that runs this kind of model on your own Mac.