Apple Says 4.3x AI Performance. Which Half of a Local LLM Does That Touch?

September 5, 2026

Last time I lined the Mac Studio up against other machines and guessed that capacity is what matters for running big models, and the GPU is what matters for speed.

Apple’s own announcement puts it as “up to 4.3x the AI performance" and “an improved Neural Engine". Taken as numbers, that is a large jump.

But improved at what? If you run a local LLM, is that 4.3x something you would actually feel?

What I set out to find

Which part of running a local LLM the Mac’s “AI performance" improvements actually speed up. And whether the story changes for a different job, such as video generation.

How I checked this, and what it rests on

I do not own a Mac. This is built from Apple’s announcements and specifications, measurements published by Apple’s own research team, and the public documentation for each implementation. There are no numbers of my own here.

The previous article did carry measurements from my own mini PC (the EVO-X2), and I read the Mac figures against those.

Two words worth separating

From here on I split the work into two stages. Without that split it is impossible to tell which number speeds up which part.

Reading your input (prefill)

The stage where the model takes the text you handed it and processes the whole thing at once. Give it ten thousand characters and it computes ten thousand characters’ worth together.

That is a great deal of matrix arithmetic running in parallel. So compute is what counts.

Writing the answer out (decode)

The stage where the model produces its answer one character at a time. This is the confusing part —

we say “writing", but the time is actually going into reading.

Every single character means reading the model’s entire set of weights back out of memory.

producing one character from a 70B model (4bit, about 40GB)
   -> read 40GB out of memory
   -> next character: read the 40GB again
   -> and again for the one after that

Which is where characters per second ≈ memory bandwidth ÷ model size comes from. Divide 1.2 TB/s by 40GB and you get 30 a second. The measured figures from last time (17–18 tok/s) sit just under 70% of that.

Output speed is set by memory bandwidth not because of the writing, but because writing requires reading everything again each time.

The two stages side by side

Stage	What is actually happening	What counts
Reading the input	computing the text you gave it, all together	compute
Writing the answer	re-reading every weight for each character	memory bandwidth

Is the Neural Engine used at all?

Apple’s chips carry a separate block called the Neural Engine (ANE). It has 16 cores and gets strengthened every generation.

None of the main local LLM implementations use it.

• MLX, llama.cpp and Ollama all run on the GPU
• The Neural Engine cannot be programmed directly. There is no published instruction set and no kernel SDK — everything goes through CoreML
• Anything unsupported falls back to the GPU

The reason turns out to be plain. The Neural Engine is designed for small networks of fixed shape, the kind used in image classification. An LLM producing variable-length text one character at a time does not fit that shape to begin with.

CoreML also carries size limits that make it impractical past about 7B, and small operations are reported to pick up two to four times the overhead. For something invoked once per character, that is fatal.

So the “improved Neural Engine" on the spec sheet has next to nothing to do with local LLMs.

Then where does “4.3x AI performance" come from?

What Apple added in the M5 generation is matrix units embedded in each individual GPU core, described as “Neural Accelerators built into each GPU core".

These are not the Neural Engine. Circuits dedicated to matrix arithmetic, placed inside the GPU — close in spirit to what NVIDIA calls tensor cores.

And these can be programmed, because they are part of the GPU.

Which stage gets the benefit?

Apple publishes its own MLX measurements.

Model	Reading the input	Writing the answer
Qwen3-14B (4bit)	4.06x	1.19x
Qwen3-8B (BF16)	3.62x	1.24x

M5 against M4.

Reading the input is around four times faster. Writing the answer is about 1.2 times.

As set out above, the writing side is governed by memory bandwidth. Adding matrix units does not change how fast memory can be read. The 1.2x looks like the bandwidth increase and nothing more.

Getting the most out of an M5 or M6

There is a practical trap here.

Implementation	Uses the Neural Accelerators?
MLX	yes
llama.cpp	no
Ollama	no (llama.cpp underneath)

As of June 2026.

Run GGUF through Ollama and the headline M5 feature stays asleep. Moving to MLX is what brings out the three- to fourfold gain.

The same machine, and the performance depends on which implementation you pick — exactly the shape the video generation section takes later on.

Against an RTX 5090

Writing the answer comes down to bandwidth, so it compares cleanly.

	Bandwidth	Models under 32GB	Models over 32GB
RTX 5090	1,792 GB/s	1.5x faster	will not run
M5 Ultra	1,200 GB/s	slower	runs

A gap of 1.5x. MLX does not close it, because bandwidth is the limit.

Reading the input I could not compare. Apple’s 4.06x is against the M4, not against NVIDIA. As far as I could find, nobody has measured an M5-generation Mac and a 5090 under matching conditions.

Video generation is a different story

Everything above is about LLMs. On the same machine, video generation reverses the ranking.

Video generation is dominated by compute, and the bandwidth that mattered for LLM output does not count for much. And — whether an implementation exists at all turns out to be decisive.

ComfyUI does not use MLX?

This was the surprise.

Route	What it runs on
ComfyUI, stock	PyTorch MPS (not MLX)
ComfyUI-MLX nodes	MLX, but Flux only

Whether something supports MLX barely matters for video generation in ComfyUI. The MLX nodes are documented as Flux-only, with no SDXL, no ControlNet and no LoRA.

A thousandfold difference from the implementation alone

For a video model called MiniMax H3, there are reports from the same M5 Max.

Implementation	Time
ComfyUI, GGUF route (MPS)	a little over an hour
h3.c (native Metal implementation)	3.5 seconds (aggressive 4-step preset)

The same machine. Only the implementation changed. h3.c was written in C by Salvatore Sanfilippo, known as the author of Redis.

The step-by-step figures are published as well (512×512, M5 Max).

BF16 MPS baseline          36.30 s
+ int8 MLP                 25.80 s
+ int8 QKV (full int8)     19.32 s
fast preset                16.69 s
aggressive 4-step preset    3.5 s
full image + audio route   74.58 s (peak 40.1GB, no swap)

It was not “MLX support makes it fast". What counts is whether somebody has written an implementation aimed at that particular job.

Rough figures for video generation

The published conditions vary, so I normalised everything to 832×480, a 5-second clip, 50 steps.

The measurements I started from

Machine	Conditions	Measured
RTX 5090	1344×768, 5 s, 50 steps	231.2 s
DGX Spark	832×480, 5 s, 50 steps	181.3 s
Strix Halo (Ryzen AI Max+ 395)	832×480, 5 s, 20 steps	1,920 s

The first two are NVIDIA’s own figures (with Sol Engine applied); the third is a report under ROCm 7.3.

Normalised (my own calculation)

Machine	Estimated time	Against the RTX 5090
RTX 5090	about 1.5 minutes	1.0
DGX Spark	about 3.0 minutes	2.0x
Strix Halo	about 80 minutes	53x

Scaled linearly by pixel count and step count. These are my figures, not anybody’s measurements.

The Mac would not go in this table. Stock ComfyUI gives “a little over an hour"; h3.c gives something orders of magnitude faster. There is no like-for-like number. The h3.c figure most likely refers to a still image rather than a 5-second clip of 120 frames.

What that means in practice

The dividing line is whether you can iterate. Video generation means running the thing again and again until you like what comes out.

one 5-second clip
  RTX 5090     about 1.5 min  -> try as many as you like
  DGX Spark    about 3.0 min  -> workable
  Strix Halo   about 80 min   -> a dozen or so a day, at best

At 80 minutes a clip, it stops being work you can do.

Reading this against what I concluded last time

Last time I wrote:

“The 460,000 to 740,000 yen for a DGX Spark is an entry fee for CUDA."

For running LLMs alone, the EVO-X2 (256 GB/s) and the DGX Spark (273 GB/s) have almost the same bandwidth, and the difference was small.

For video generation that difference opens to about 26x (3.0 minutes against 80, at the same 832×480 and 5 seconds).

The entry fee now has something concrete attached to it.

What I could not verify

• I do not own a Mac. This article is research from start to finish
• No data exists that measures an M5-generation Mac and a 5090 under the same conditions. The input-reading comparison is missing
• I could not confirm whether the h3.c figure is a video or a still image, which is why it is absent from the estimate table
• The 80 minutes for Strix Halo is a 20-step measurement stretched to 50 steps, which assumes time scales with step count
• No measurements for VLMs (models that read images) turned up. Turning an image into tokens belongs to the input-reading stage, so the Neural Accelerators ought to help, but that is unverified

In summary: which number applies to what

The “improved Neural Engine" on the spec sheet had nothing to do with local LLMs. Every major implementation runs on the GPU, and the Neural Engine goes unused.

What does the work is the matrix units inside the GPU cores. And they only help the input-reading stage — output speed moves by about 1.2x, because that side is set by memory bandwidth.

You also have to be on MLX to see any of it. Run it through Ollama and the headline feature stays asleep.

Video generation reverses the ranking. Compute dominates, and the Mac lands on the unfavourable side. Since ComfyUI does not use MLX, even “does it support MLX" stops being a useful question.

And the implementation alone moved it a thousandfold: an hour or so against 3.5 seconds, on one machine.

What came out of writing this is that you will misread the numbers unless you know what the limiting factor is.

4.3x is not a lie. It is just a statement about the input-reading stage, using MLX, for an LLM. Carry it over to video generation and the view is completely different.

What is worth checking before buying is not the multiplier on the box, but where the limit sits for the thing you want to do.

The article this one builds on, looking at the Mac Studio itself, is here.