Blog
A20 Pro and on-device AI: It’s showtime
Ricky Takkar
Published September 20, 2026
Apple says the A20 Pro has 50% more memory bandwidth and twice the AI processing power. I wanted to know what that feels like (i.e., how much sooner the first token and the full response arrive) when I actually run an on-device language model, so I compared my iPhone 18 Pro (A20 Pro) and my iPhone 17 Pro Max (A19 Pro). Both have 12 GB of RAM and 256 GB of storage. Why not an iPhone 18 Pro Max? Two words in defiance of auramaxxing: smartphone pinky.
Short version. With two downloaded models running on MLX, Apple’s open-source machine-learning framework for Apple silicon, the 18 Pro generated text 53-85% faster and showed the first words 42-53% sooner. The answers themselves were identical on both phones, word for word (greedy sampling made that possible). Apple’s own on-device model, AFM 3 Core Advanced, got faster too, but by less: 35-42% more output per second and 23-33% less waiting for the first words, over 48 more runs.
Two things I didn’t expect. While MLX results beat 1.5×, which is how much the memory bandwidth went up, Apple’s model didn’t. And the 18 Pro was remarkably consistent: run to run it barely moved, while the 17 Pro Max wandered by a quarter to a third.
Disclosure: I make Russet. Both phones ran the same research Release build (slightly different from what’s available on the App Store).
What Apple promised
Apple’s announcement promises 50% more memory bandwidth, up to 40% faster GPU performance, and twice the AI processing power from a new 32-core Neural Engine.
Geekerwan’s (impressively) detailed teardown and tests show LPDDR5X at 9,600 MT/s on both generations, with the interface widening from 64 to 96 bits: theoretical bandwidth rises from 76.8 to 115.2 GB/s. (That’s where Apple’s “50%” comes from.)
Their GPU results range from about 44% faster for BF16 matrix math to 184% for FP8 E4M3. A model stored in four-bit weights won’t necessarily touch that FP8 path, so I wouldn’t read much into the big number. The Neural Engine came in at 1.83× for FP16 and 1.78× for INT8. Close to Apple’s “twice the AI processing power,” but not quite there.
Figure 1. Ratios from Geekerwan’s numbers, measured on Pro Max phones for both generations (not my phones). The grey bar is a spec; the colored ones are microbenchmarks. Source units were GB/s for bandwidth, TFLOPS for floating point and TOPS for integer.
What I measured
TL;DR: Same models, same files, same prompts, same answers. Only the phone changed (18 Pro vs 17 Pro Max).
I tested Qwen3.5 0.8B at 6-bit and Gemma 4 E2B Instruct at 4-bit, both MLX conversions from Hugging Face and available on Russet. They’re about 0.84 GB and 3.61 GB to download, so one is small and the other is about four times bigger (neither is “large”).
Both phones ran iOS 27.0 and the same optimized Russet build (which bundles MLX Swift 0.31.6). I checked the model files too: Gemma’s seven files matched byte for byte and Qwen’s weights and runtime files matched (its tokenizer config differed only in how the JSON was serialized; the parsed contents were identical). Downloads and hashing happened before any timing started.
Torrance is Russet’s built-in benchmark for local models. It runs three fixed prompts (about privacy, latency and thermals), and I ran each model at two input sizes, roughly 256 and 2,048 tokens, with output capped at 256 tokens. Four loops per condition gives 12 measurements per phone per condition, 96 in total, all after warm-up. The long prompts are padded with benchmark-related filler, so they test how the phone copes with a long context.
Something I caught along the way: my first exploratory runs weren’t actually greedy. The model catalog’s sampling settings were quietly overriding the temperature the benchmark asked for, so I threw those runs out and hard-coded greedy sampling in the research build. Qwen’s reasoning mode was off, each prompt got a fresh session, and model loading wasn’t timed.
| Model / input target | First response: A19 Pro → A20 Pro | Output tokens/s: A19 Pro → A20 Pro | Output gain |
| Qwen 0.8B / 256 | 0.329 → 0.178 s | 86.2 → 132.1 | +53.3% |
| Qwen 0.8B / 2,048 | 0.870 → 0.408 s | 72.3 → 134.0 | +85.4% |
| Gemma E2B / 256 | 0.442 → 0.256 s | 41.2 → 71.7 | +74.3% |
| Gemma E2B / 2,048 | 0.810 → 0.465 s | 38.5 → 69.8 | +81.1% |
Method. Medians of 12 runs. “First response” is the first nonempty callback the app gets. “Output” is the visible response, retokenized and divided by the time after that first callback. In other words, this is what the app sees. I didn’t time GPU stages directly. Output was capped at 256 tokens; actual counts are in the data download at the end of this artic essa… whatever this is.
Actual inputs came out to 256-257 or 2,048-2,049 tokens depending on the prompt. Every kept response hit the full 256 output tokens, and all 48 cross-phone pairs were identical. In wall-clock terms, Gemma with the long input went from 7.58 to 4.13 seconds per answer, and Qwen with the short input went from 3.27 to 2.14 seconds. That’s latency reduction you’d actually notice.
Beating the bandwidth
Figure 2. Each dot is one prompt run. Diamonds are medians (labeled), and lines span the observed range. The ranges aren’t confidence intervals.
Quick background. Before a model outputs anything, it reads your prompt (prefill), and that work runs in parallel across the input tokens. Writing the answer is different: one token at a time, and for a single conversation a lot of that time goes to hauling weights and cached state through memory. That’s why memory bandwidth matters so much for local models.
It also gives a nice test. If a workload were limited by bandwidth alone, 50% more bandwidth could make it at most 1.5× faster. (If only half of it benefited, you’d get 1.2×.) So 1.5× is the line.
All four MLX runs crossed it: 1.53×, 1.85×, 1.74× and 1.81×. Time to first response improved even more, 1.72-2.13×. Yet Apple’s model stayed under, at 1.35× and 1.42×.
That doesn’t pin down the bottleneck. It does tell me bandwidth isn’t the whole story for MLX, otherwise it would have topped out around 1.5×. My best guess is the GPU improvements from Figure 1, though the A20 Pro also changes how the phone manages power and I can’t pull those apart here. It’s also why I keep the MLX and Apple Intelligence numbers separate instead of boiling everything down to one “A20 Pro is N× faster” figure.
The other surprise was consistency. On the 17 Pro Max, output speed for a given workload bounced around over a range of 23.3 to 35.5 percent of its median. On the 18 Pro that range was 1.9 to 4.2 percent (16.5 percent for short-input Qwen, where the phone was still speeding up between loops). You can see it in Figure 2: long coral lines, tight blue clusters. I only have one phone of each, so I can’t say whether that’s the chip, the chassis or the scheduler. Either way, it’s nice when the answer shows up at the same speed every time because predictability is valuable.
For short answers, the wait before the first word matters most (time to first token). For long ones, generation speed takes over (tokens per second). Total time (end-to-end latency) is a mix of both.
A note on hardware. The pinned MLX version does include Metal kernels for the GPU’s new neural accelerators, but that doesn’t prove these particular quantized models used them. Those GPU accelerators also aren’t the Apple Neural Engine (ANE), which is separate hardware. So treat this as app performance; it says nothing about ANE use.
Apple Intelligence
TL;DR: Apple’s model got 35-42% faster at generation. Cool, but it stayed on the other side of the 1.5× line.
Russet talks to Apple’s on-device model(s) through Apple’s Foundation Models framework. Both phones reported AFM 3 Core Advanced running on device with an 8,192-token context window. I forced the local route, so Private Cloud Compute and tools weren’t involved. I only tested text generation through the framework; other Apple Intelligence features weren’t part of this.
Apple describes Core Advanced as a 20-billion-parameter sparse model with 1-4 billion parameters active. The whole model lives in flash, and only the selected experts get loaded into memory, with routing per prompt and periodic reselection. So “20B” doesn’t mean 20 billion parameters sitting in RAM. Only 1-4 billion of them are active at a time.
Short inputs: output speed went from 57.2 to 77.3 tokens/s (+35.3%) and first response from 0.485 to 0.371 seconds (-23.4%). Long inputs: 40.6 to 57.6 tokens/s (+41.9%) and 1.879 to 1.251 seconds (-33.4%). The long-input tasks finished in a median 4.15 seconds instead of 5.83. All 24 response pairs matched exactly. The gains are smaller than MLX’s, but that says how each path responded to the new SoC. It isn’t a ranking of the two.
Figure 3. Twelve unprofiled runs per phone and input size, in the same device colors as Figure 2. AFM has its own tokenizer and tasks, so compare the two phones within this chart. Its token rates don’t line up with the MLX ones.
Figure 4. Speedup for each matched workload (1× means no change). The dashed line is the 1.5× bandwidth increase from Figure 1. Every MLX workload clears it and neither AFM workload does. Models, tokenizers and protocols differ between the two groups.
Looking inside with Instruments
TL;DR: Both stages of Apple’s model got faster. I couldn’t get Instruments to tell me which (part of the) chip did the work.
The AFM setup used three short explanation or summary tasks at the same 256 and 2,048-token input sizes, with greedy sampling, light reasoning and a 256-token cap. Three warm-ups, then four loops with 15-second pauses. My first try asked for long essays and the model refused, so those runs are out. Apple’s model stops on its own, so real answer lengths set the output rate: 168-175 tokens for short inputs and 141-171 for long ones. Prompts were 255-256 and 2,048-2,049 tokens, plus 82 tokens of instructions. The timer uses monotonic uptime and stops at the API boundary, before I count output tokens.
Every AFM condition started at the nominal thermal state. On the 18 Pro, 9 of 12 runs in each condition hit “fair,” while the 17 Pro Max stayed nominal throughout. One short-input launch was blocked, so I let the phone cool and retried. The blocked one contributes nothing.
I also ran separate sessions under Xcode’s Foundation Models and Core AI instruments. The Foundation Models trace splits each request into prompt processing and generation and reports its own token counts, which differ from what my app timer sees. Apple’s WWDC26 profiling session walks through those stages.
Figure 5. One diagnostic pass per phone after warm-up, long inputs. Both stages are shorter on the A20 Pro in all three tasks. Instruments reported zero cached prompt tokens. Profiling overhead and different token accounting mean these won’t line up exactly with Figure 3.
The Core AI instrument recorded no operations at all. That doesn’t mean the Neural Engine sat idle, just that this capture couldn’t see how the system service scheduled its hardware. Nothing here, Apple’s own description included, proves the model ran only on the Neural Engine.
One detail in the traces is worth pointing out. The main model and tokenizer asset IDs matched between phones, but the draft model’s ID didn’t. A draft model next to a main model is how speculative decoding works: the small model guesses tokens and the big one checks them. If that’s what’s going on, a different draft model could change how many guesses get accepted, and with it the token rate. I’m reading that off an ID string, though, and I can’t tell you what changed or whether it mattered. The same IDs include “instruct_3b”, which at least fits Apple’s description of a small active model. Bottom line: I compared the AFM model files each phone had installed (both on iOS 27.0), and I can’t promise the weights were identical.
Russet’s memory numbers also leave out whatever the system service holds. The AFM data and method have the details.
Heat
TL;DR: These were short bursts with rests in between. Warming up to “fair” didn’t slow the 18 Pro down.
John Gruber’s review makes a point of sustained performance, local models included, and he’s right to. Apple redesigned the packaging and put in a much larger, second-generation vapor chamber this year, so it’s worth checking instead of assuming peak numbers last forever. Even from my own experience, the newer guy feels hotter to the touch when challenged, which I read as better heat spreading, though I didn’t measure it.
Every MLX session started at nominal, and it didn’t always stay there. On the 18 Pro, 9 of 12 runs in each short-input session were “fair.” On the 17 Pro Max, 10 of 12 long-input Gemma runs were. Everything else stayed nominal. One Gemma launch on the 18 Pro was blocked while it was fair, so I let it cool and tried again. The blocked launch isn’t in the data.
But “fair” didn’t cost the 18 Pro any speed. In the short-input Qwen session it actually sped up, from a median 121.6 tokens/s in the first (nominal) loop to 138.2 in the last (fair) one. Gemma went from 71.5 to 72.0. The 18 Pro set its numbers while it was the warmer phone. It had more headroom when warm, though I can’t separate the cooling from the chip.
That cuts both ways. My warm-up didn’t fully settle the 18 Pro, which makes +53.3% for short-input Qwen the shakiest number in the table: using only the first loop, when both phones were nominal, it’s +41.5%. In the other direction, the 17 Pro Max was fair for 10 of 12 long-input Gemma runs, which could make that +81.1% look better than it is. First loop only, it’s +79.1%, so not by much. Neither changes the picture.
Torrance (Russet’s built-in performance test) waits 15 seconds between loops, so the phones got regular breaks. I never held either one at full load for long. Both phones were plugged into my Mac with Low Power Mode off, and I logged charging and thermal state. I didn’t measure room, case or battery temperature, and I had no power meter, so none of this says anything about efficiency or battery life.
Median process memory was about 1.14-1.28 GiB with Qwen loaded and 3.02-3.26 GiB with Gemma, about the same on both phones. These are samples taken at app callbacks, app included, so they can miss spikes in between, and they aren’t the model weights alone. The loop-by-loop plot shows every run with its thermal state.
One more caveat: this is an 18 Pro against a 17 Pro Max. It tells you whether this year’s smaller flagship beats last year’s bigger one on these workloads. It can’t separate the chip from the chassis, cooling, scheduling or power management. And with one phone per generation, I’d treat the exact percentages as this pair’s, not everyone’s.
For CPU context, I also ran AboutMyDevice, a separate app of mine for looking up device specs and testing performance. Its SoC benchmark is called Redondo, the same way Russet’s is called Torrance. (Yes, both are named after South Bay cities. Picking between Hermosa and Manhattan for next.) Redondo mixes compression, hashing, convolution, matrix multiplication and JSON parsing. It scored single-core 31,243 → 38,705 and multi-core 92,868 → 115,449, up 23.9% and 24.3% for the 18 Pro.
So what do you get?
For on-device language models, not a blanket “twice as fast.” With these MLX models on these phones, the smaller 18 Pro started sooner, finished sooner and was steadier doing it. Qwen ran at about 132-134 visible tokens/s versus 72-86 on the 17 Pro Max, and Gemma at about 70-72 versus 39-41. Those are ranges of the condition medians; individual runs spread wider.
The part I find most interesting is the 1.5× line. Every MLX workload beat it and Apple’s model didn’t, so whatever the A20 Pro improved for downloaded MLX models, it’s more than just a wider memory bus.
RAM didn’t change, so there’s no extra room for bigger weights, longer context or working buffers. Faster inference can make a heavier model usable within the same wait, but I didn’t test the biggest model each phone can load. I also didn’t grade answer quality (though I did ensure there was no gibberish output).
Apple Foundation Models improved too, by less: long-input answers took a median 4.15 seconds instead of 5.83. That’s why Russet supports both. Apple’s model is managed by the system, downloaded MLX models are yours to pick, and their token rates aren’t interchangeable.
My takeaway in building Russet is to continue showing people the model, the quantization, the context length, the time to first word and the output speed. That’s a better way to pick a phone than assuming twice the Neural Engine means twice as fast at everything.
Sources and reproducibility
The Apple Intelligence experiment has its own measurement table, methodology and evidence archive. The MLX build and archive are kept separate so each keeps its own provenance.
For MLX, there’s the measurement table, full methodology, build provenance and per-run results. The figures show every controlled run I kept; exploratory sessions and failed launches are out. Model manifests, the actual prompts and outputs, token counts and thermal snapshots are all in the archive.
As mentioned earlier, I watched (with English subtitles) Geekerwan’s awesome iPhone 18 Pro review. I also read John Gruber’s The iPhones 18 Pro (September 17) and Anton Shilov’s Apple’s A20 Pro shatters Geekbench 7 single-core record at Tom’s Hardware (September 12).
Hardware numbers from Apple and Geekerwan are theirs, not mine. I ran the final comparison on September 20, 2026, and no cloud model produced any of the timed responses.
