M5 Ultra and M6, Measured: How the LLMCheck Estimates Held Up (2026)

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.

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.

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. (Superseded: small-MoE estimates were refit on 5 October, and large-MoE estimates have since erred in both directions; see October below.) 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 most of 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:

Corrected 18 October 2026: this table also listed MacStories’ Qwen3.8-27B race, 48 against 31 tok/s, as an MTP result. The review ran that race with multi-token prediction off, after a 6,091-token prompt, so both figures are plain decode and now sit in the dataset as published rows.

Two more things separate the MTP figures from BGR’s. The prompts were long — up to 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. (One has since arrived: 57.0 tok/s, community-measured on an M5 Ultra in llama.cpp, a third below that estimate; see October.)

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: the first published figures

When this was written, on 23 September, the index had found no press review with local-model figures for the Mac mini M6; tbreak’s review of 21 September had in fact published two (see the 18 October update above). 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 stayed estimates until published figures with their setup were linked; the 16 GB model’s 153 GB/s makes it slower than the 24 and 32 GB models’ 170.

October: fifteen more runs against the formula

Since this post, the index has added the runs below. Each is set against the index’s formula estimate for the same chip at the same quantization; where a source does not state its quantization, the 4-bit estimate. A filled square marks a published figure (a vendor, or a press review that documents its setup); a hollow circle marks one person’s documented run.

Three things stand out. Short-prompt plain decode of a dense model is where the formula is tightest: the mlx_lm.benchmark runs sit within 2% on both Ultras, in line with BGR’s figures. Prompt length and runtime move a figure by 10–17% either way: Tom’s Hardware’s llama.cpp run came in 17% under, MacStories’ runs after a 6,091-token prompt 10–15% under, and Apple’s BF16 runs at an 8K context up to 17% over. And the large mixture-of-experts estimates are not reliable floors: Qwen3.8-Flash-Next’s first plain-decode M5 Ultra figure came in a third under its estimate, while MiMo-V2.6-Flash ran about twice as fast as estimated on a 256 GB M3 Ultra (59.4 and 59 tok/s, community).

Apple’s tables also give the cleanest chip-to-chip comparison yet, because both Macs ran the same tool, model and context: the M5 Ultra decodes 1.58 times faster than the M3 Ultra on Qwen3.8-27B and 1.56 times faster on Mistral Medium 3.5. That is slightly more than the 1.5-times bandwidth ratio between them; the formula, with its fixed cost per token, predicts slightly less (about 1.49). The full cross-check of every new run, by model class, is in How accurate are LLMCheck’s speed estimates?, and the three Studio chips are compared in M5 Ultra vs M3 Ultra vs M5 Max.

What changed in the index

• Four published measurements added from BGR, each marked with a filled square and linked. Qwen3.8-27B’s M5 Ultra estimate is replaced by the measurement.
• Qwen 3.5 122B-A10B added — an Apache 2.0 122B MoE from February that the index had missed, now listed with its two measured rows. It needs a 96 GB Mac.
• The provenance marks mean one thing everywhere. A filled square is a published figure from an accountable source — a vendor’s model card, or a press review that documents its setup. A hollow circle is one person’s run. The tooltip, the methodology page and the dataset had drifted apart on this.
• Best-by-Mac pages mark every speed. They used to label a figure “est.” only when it was scaled from another chip, so estimates read straight from the dataset appeared as bare numbers. A chip with no row of its own is now filled from the model’s nearest measured or estimated row.
• Nine 8-bit rows corrected. They carried 4-bit speeds — above what 8-bit physics allows on those chips — because the estimator costed every row at 4-bit bytes whatever its label said.
• One of our own posts corrected. The M5 Max guide from March presented M5 Max vs M4 Max figures as tests we ran, showing 28% gains. LLMCheck does not run lab tests, and 28% is not consistent with a 10% bandwidth difference. It now carries an editor’s note and the index’s estimates.

Frequently Asked Questions