The strongest case for the larger M5 Ultra is a workload that repeatedly makes you wait for fresh, long prompts to be processed, with enough measured time saved to justify the price. That is a reason to test the 80-core GPU model against your work. If your current system already finishes comfortably within your needs, these results alone are no reason to replace it.
Price the whole configuration
Apple’s two configurations pair a 30-core CPU with a 64-core GPU, or a 36-core CPU with an 80-core GPU. Both CPU and GPU change, so any comparison concerns the complete chip configuration. Apple lists the same memory bandwidth, Neural Engine core count and media-engine counts for both. Those shared resources do not establish identical application performance or identical language-model output speed. Apple’s specifications
For a concrete price reference, Apple’s US store on October 9, 2026 quoted the 64-core GPU configuration at US$9,999 and the 80-core GPU configuration at US$11,299, each with 256 GB of memory and a 2 TB SSD. The difference is US$1,300, before sales tax, without AppleCare or trade-in credit. This is a US reference quotation; use a current, like-for-like local quote for your own decision.
Where the long-prompt lead appears
Language-model waiting time has different parts. Prefill processes the input already supplied; decode generates the continuation token by token. Long-prompt prefill is often sensitive to available compute, while decode at low concurrency is often limited by memory bandwidth. Batching can change the bottleneck. These are general workload tendencies, not measurements of either Mac.
The relevant oMLX results are separate community submissions, not a controlled head-to-head test. Their reported common setup includes 256 GB of memory, oMLX v0.7.0, the nominal Qwen3.8-Flash-Next-oQ4e-mtp model with 4-bit weights, a Python-code corpus and multi-token prediction enabled. That makes the results useful leads for a similar workload, although a shared model name does not verify identical model files. 64-core submission, 80-core submission
At 64K context, prompt processing rises from 4,607 tokens per second on the 64-core GPU submission to 5,548 on the 80-core submission, about a 20% lead. Output generation goes the other way: 122.9 versus 119.7 tokens per second, respectively. A person watching the answer arrive would not see the same advantage suggested by prompt-processing throughput. 64-core 64K result, 80-core 64K result
At 128K, prompt processing is 4,469 versus 5,378 tokens per second, again about 20% higher for the larger configuration. This time output generation also favors it, at 110.2 versus 102.1 tokens per second for the smaller configuration. Decode changes direction between the two examples. Neither “20% faster everywhere” nor “the same output speed” describes these records. 64-core 128K result, 80-core 128K result
There are meaningful differences behind those rows. The submissions report different macOS versions, TurboQuant KV-cache settings and sampling settings; how much each affected the requests is unknown. Identical checkpoints and quantization recipes, output lengths, cache states and repeat-run variation are also unverified. The roughly 20% prompt-processing gap therefore cannot be isolated as the gain from extra GPU cores. These are observations worth reproducing on matched settings. 64-core setup, 80-core setup
Convert throughput into useful time saved
Even a reproducible throughput gain affects only the part of the wait it accelerates. As hypothetical arithmetic, 20% higher prefill throughput would reduce prefill time for a fixed input by about 16.7%, with everything else unchanged. If prefill originally occupied half of total latency, the whole request would finish about 8.3% sooner. Those are calculated examples, not measured Mac results. Prefill and decode remain separate stages of the wait.
That makes frequent fresh, long prompts a more promising reason to pay extra than short requests or conversations whose prefixes are reused from cache. If generating the answer accounts for most of your wait, the two decode observations above are a reason to measure that phase separately. If you serve several requests together, test that actual load too: the bottleneck can move, so a single-request result cannot establish concurrent serving capacity.
Establish a current software baseline first
A separate community tester reported 64K prompt processing increasing from 3,708 to 5,548 tokens per second on the same 80-core GPU, 256 GB machine when moving from oMLX 0.7.0rc1 to 0.7.0. The report used one run per point, with native kernels, multi-token prediction and 8-bit TurboQuant KV cache in both builds. It illustrates a software-and-dependency change on one machine, not the effect of choosing 80 rather than 64 GPU cores. The community comparison is consistent with the release notes’ prefill and decode kernel changes. Before spending on hardware, establish what your current machine does with the runtime and settings you intend to use.
Rendering deserves its own decision
Blender supplies another encouraging signal for the larger configuration. Filtering Blender Open Data to version 5.2.0, METAL and macOS gives a median score of 13,470.80 across 6 submission records for the 64-core GPU, versus 15,328.26 across 5 records for the 80-core GPU. The larger configuration’s median is 13.79% higher, using the smaller configuration as the denominator. 64-core records, 80-core records
These are community submissions hosted on Blender’s platform, not a controlled lab comparison or a known count of independent machines. Memory capacity and identical selected scene sets are unconfirmed. Blender’s score sums Cycles samples per minute across scenes; it is not elapsed seconds. The medians justify trying a representative Cycles job on both configurations, but they do not tell you how many minutes your render will save. How Blender defines its score
In two HandBrake tests converting 4K video to 1080p, the 64-core GPU model took 65 seconds and the 80-core GPU model took 64 seconds; both review systems had 256 GB of memory and a 4 TB SSD. The recorded times are close, but they come from separate reviews whose test conditions have not been fully matched. Treat them as reference results, not evidence that the upgrade saves exactly one second.
The buying rule
Favor the 80-core GPU configuration when long, uncached prompts or your own rendering jobs recur often, a matched test shows a worthwhile whole-task improvement, and that saving justifies the local premium. Count time that matters to you: shortening an interactive pause can be more useful than finishing an unattended job earlier. The public results make that test worthwhile; they do not settle its value for everyone.
Favor the 64-core GPU configuration when its task times already meet your needs, particularly if prefill is a small part of the workload and you have no demonstrated reason to pay for the larger configuration. If you already own a system that is adequate, keeping it is also a valid outcome.
Before ordering, repeat your typical workload with the same OS, runtime and kernel build, model and quantization, cache state, sampling, output length and concurrency. Record time to first token, generation speed and full completion time over repeated runs. For creative work, keep the application version, project and export settings fixed. Then compare the useful time saved with the current price difference at equal memory and storage. That is the practical bridge from promising benchmark results to a purchase you can justify.