The scorecard

Two reviews published local-model figures on 21 September: BGR (Christian de Looper; M5 Ultra 256 GB against an M3 Ultra, in LM Studio) and MacStories (Federico Viticci; M5 Ultra 256 GB against an M3 Ultra 512 GB, in oMLX with multi-token prediction). BGR’s runs match the index’s protocol — plain decode on short prompts — so they go straight into the dataset. MacStories measured something different, and the section below explains why that matters.

ModelMacIndex estimateMeasured (BGR)Estimate vs measured
Qwen3.8-27B, 4-bitM5 Ultra57 tok/s~55 tok/s+4% (slightly high)
Qwen3.8-27B, 4-bitM3 Ultra39 tok/s~40 tok/s−3% (slightly low)
Qwen 3.5 122B-A10BM5 Ultra~58 tok/s~80 tok/s−28% (too cautious)
Qwen 3.5 122B-A10BM3 Ultra~41 tok/s~60 tok/s−32% (too cautious)

Only the first line existed as a row in the index before this week. The other estimates are what the published formula gives for those chips, computed exactly the way every other estimate is. BGR did not state the quantization for its 122B test, and the dataset records it as unstated rather than guessing.

Dense models: the formula held

The index estimates decode speed from memory bandwidth with a two-term model fitted in August to vendor-published runs on the M5 Max, then checked against one figure it had never seen. It had never seen an Ultra at all. Qwen3.8-27B is a 27.8B dense model, about 16 GB of weights at 4-bit, and the M5 Ultra’s 1.2 TB/s is 50% more bandwidth than the M3 Ultra’s 819 GB/s. The formula predicted 57 and 39; BGR measured about 55 and 40.

The M5 Ultra came out 37% faster than the M3 Ultra on that model, against its 50% bandwidth advantage. That sub-linear scaling is exactly what the model’s fixed per-token overhead predicts: the faster the memory, the larger the share of each token’s time spent on work that bandwidth does not speed up.

What that buys a reader: for dense models, the index’s estimates on chips nobody has measured yet are trustworthy to within a few percent. That covers most of what the 44 Best-by-Mac pages rank.

Sparse models: the index was too cautious

Mixture-of-experts models read only their active parameters for each token, which the raw bandwidth formula rewards generously — too generously, the index decided in September, because its one measured MoE run at the time (DeepSeek V4 Flash at 39 tok/s on an M5 Max, 2-bit) came in at 0.42 of the raw figure. Every MoE estimate since has been scaled by that factor.

Qwen 3.5 122B-A10B, with 10B active, lands near 0.6 on both Ultras in BGR’s runs. So the factor is conservative, by about a third for this model. We are keeping it for now rather than refitting to three data points spread from 0.42 to 0.61: under-promising a buyer’s speed costs less than over-promising it. The practical rule is simple — treat MoE estimates in the index as floors. Where a model has its own measured rows, as Qwen 3.5 122B-A10B now does, its other chips are scaled from those measurements instead of from the factor.

MTP figures measure a different workload

MacStories ran its tests in oMLX with multi-token prediction on. MTP is speculative decoding with prediction heads the model ships with: it drafts several tokens and verifies them in one pass, and oMLX’s documentation puts the typical gain at 1.5–1.7×. LM Studio has supported it since version 0.4.14 in May. It is real speed you can use — but it is not the same measurement as plain decode, so these figures stay out of the dataset:

MacStories, oMLX with MTPM5 UltraM3 Ultra
Qwen3.8-27B, 4-bit, generation48 tok/s31 tok/s
Qwen3.8-Flash-Next, 4-bit, generation at a 16K prompt52 tok/s37 tok/s
Qwen3.8-Flash-Next, 4-bit, prose generation111.6 tok/s

Two more things separate them from BGR’s figures. The prompts were long — 8K and 16K tokens — and reading a large KV cache slows decode. And MTP’s gain depends on how predictable the text is: prose drafts well, code less so. The Flash-Next results are still the most useful data on that model so far, and the index’s plain-decode estimate for it (~85 tok/s on M5 Ultra) stays labelled an estimate until someone publishes a figure without MTP.

The real M5 story is prompt processing

Decode rose about 40% from M3 Ultra to M5 Ultra. Prompt processing rose about 150%. MacStories measured Flash-Next reading a 16K prompt at 2,887 tok/s on the M5 Ultra against 1,143 on the M3 Ultra, and time to first token fell from 13.9 seconds to 5.6. For Qwen3.8-27B the prefill figures were 1,701 against 414 tok/s. BGR saw the same at short prompts: first tokens in about half a second instead of over one.

That is the M5’s GPU Neural Accelerators at work, and it matters more for agents than for chat: an agent re-reads a long context on every step, so prefill is most of its waiting. The index ranks on decode, because decode is what bandwidth predicts. If you run a coding agent locally, the M5 generation’s gain is larger than any tok/s column shows.

The M6: still waiting for a published figure

No press review we could find had published local-model figures for the Mac mini M6 as of 23 September. An early hands-on video, summarised on daily.dev, reports Qwen3.8-27B at 8–9 tok/s on a 32 GB M6 in LM Studio with plain MLX — where the index’s estimate of 8 sits — and 17–19 tok/s with MTP enabled. That is corroboration, not a dataset entry. The M6 rows stay estimates until a published figure with its setup appears; the 16 GB model’s 153 GB/s makes it slower than the 24 and 32 GB models’ 170.

What changed in the index

Frequently Asked Questions

How fast is Qwen3.8-27B on an M5 Ultra Mac Studio?

About 55 tok/s at 4-bit in LM Studio, according to BGR's review of the 256 GB model published 21 September 2026; the same model ran at about 40 tok/s on an M3 Ultra. The LLMCheck index had estimated 57 and 39 tok/s from memory bandwidth. With multi-token prediction on and long prompts, MacStories measured 48 tok/s.

Is the M5 Ultra worth it over the M3 Ultra for local LLMs?

For decode, expect roughly 40 percent more tokens per second on dense models and more on sparse ones: BGR measured 55 against 40 tok/s on Qwen3.8-27B and 80 against 60 on Qwen 3.5 122B-A10B. The bigger gain is prompt processing — MacStories measured about 2.5 times faster prefill on a 16K prompt, cutting time to first token from 13.9 to 5.6 seconds, which matters most for coding agents.

What is MTP and does it make local LLMs faster?

Multi-token prediction is a form of speculative decoding that uses prediction heads built into models such as Qwen3.8: the model drafts several tokens and verifies them at once. oMLX's documentation puts the typical speedup at 1.5 to 1.7 times, and LM Studio has supported it since version 0.4.14. The gain depends on how predictable the text is, so LLMCheck keeps MTP figures out of its plain-decode dataset.

How fast is the Mac mini M6 for local LLMs?

No press review had published local-model figures for the M6 as of 23 September 2026. The LLMCheck index estimates Qwen3.8-27B at about 8 tok/s on the 24 and 32 GB models, and an early hands-on video reports 8 to 9 tok/s with plain MLX. The 16 GB model has less memory bandwidth, 153 GB/s against 170, and is slower.

How accurate are LLMCheck's speed estimates?

For dense models the first independent Ultra measurements landed within 4 percent: 57 against 55 tok/s on the M5 Ultra and 39 against 40 on the M3 Ultra for Qwen3.8-27B. For sparse mixture-of-experts models the index is deliberately conservative and came in about 30 percent low against BGR's Qwen 3.5 122B-A10B figures, so treat MoE estimates as floors. Every figure is labelled estimated, published or community.