A 2022 MacBook Air (M2, 16GB) against the MacBook Pro that replaced it (M5 Pro, 64GB) — ten fixed-duration benchmarks across CPU, disk I/O, and local LLM inference, run on each machine and compared line by line.
Each test runs for a fixed wall-clock duration rather than a fixed workload size, so the same script produces a comparable number regardless of which machine is faster — the slower machine simply completes fewer iterations in its window. Total runtime: about four minutes per machine.
The disk write test originally reported ~12,000 MB/s on both machines — including a plain RAM disk, which gave nearly the same number. That was the tell: write() was returning as soon as the bytes hit the kernel's page cache, not when they reached the SSD. The fix was opening the file with O_SYNC and F_NOCACHE so every write blocks until it's actually durable on disk. After the fix, the Pro's number dropped to a believable 6,385 MB/s and the Air's to 759 MB/s — the real gap this report is built on.
Adding a prompt-processing (prefill) test to isolate compute-bound work from bandwidth-bound decode, the first version sent the exact same prompt on every call — and Ollama's prompt cache recognized the repeat and skipped real work, reporting ~40,000–580,000 tok/s. Fixed by shuffling the prompt's sentence order on every call so nothing repeats. The Air's deepseek-r1 prefill run happened before this fix landed, so that one number is excluded below rather than shown wrong.
Indexed to the Air's own result as 1.0×. Sorted by how much the Pro pulled ahead. The gemma4 prefill result carries a low-confidence flag — see below.
Prime-counting (single-core integer), a 2048×2048 float32 matrix multiply (NumPy/Accelerate), and sustained SHA-256 hashing. All three land in the same narrow band — 1.3× to 1.7× — which is what you'd expect from clock speed and IPC gains across M2 → M5, without a dramatic jump in core count for single-threaded work.
Sequential write and read, both bypassing the page cache so the numbers reflect the SSD itself, not RAM. This is as much a storage-tier story as a chip story: the Air's 256GB configuration ships a single NAND chip, a documented Apple tier limitation independent of the M2 chip's own capability — the Pro's larger SSD spreads writes across more NAND in parallel. Write comes out furthest apart at 8.4×; read, less bottlenecked by that single-chip ceiling, still trails at 3.9×.
All five tests run against a local Ollama server. nomic-embed-text embeddings are the weakest discriminator (1.5×) — the model is small enough that per-request overhead, not raw GPU throughput, sets the pace. Token-by-token generation is memory-bandwidth-bound — read the whole model once per token — so deepseek-r1:1.5b (1.5B params) tops out near the two chips' bandwidth ratio: 2.5×. Prompt processing (prefill) is the opposite: compute-bound and parallel across the whole prompt at once, which is exactly what more GPU cores are for. That's where gemma4:e4b-mlx (8.1B params, big enough to actually load the GPU) opens up: 4.6× on decode, and a striking n=1 13.3× on prefill.
| Spec | M2 Air (rAir) | M5 Pro (rPro) |
|---|