Apple M3 Ultra (Mac Studio, 2025)

Apple tech specs: '819GB/s memory bandwidth' for the M3 Ultra, listed at that bandwidth for both the 28-core CPU / 60-core GPU and the 32-core CPU / 80-core GPU configurations. Unified-memory bandwidth, package-level, shared with the CPU. Holding 819 GB/s while tripling capacity to 512 GB is why this part is package-only: it requires a much deeper memory stack, not a wider bus.

CORRECTED 2026-10-03: AUDIT 2026-10-03 (unified-memory pool verified against Apple primary source, no value changed): Apple's Mac Studio (2025) tech specs (support.apple.com/en-us/122211) state under Memory: 'Apple M3 Ultra chip - 96GB unified memory - Configurable to: 256GB or 512GB (M3 Ultra with 32-core CPU and 80-core GPU)', and under Chip: '819GB/s memory bandwidth' for BOTH the 28-core CPU / 60-core GPU and the 32-core CPU / 80-core GPU configurations. So vram_gb 512 here is the MAXIMUM UNIFIED POOL of the top configuration, not a fixed pool, and it is the largest unified pool Apple has shipped on any part. unified_memory is true and correctly set. The 819 GB/s is package-level and shared with the CPU - it does not scale with capacity, which is why a 512 GB M3 Ultra and a 96 GB M3 Ultra have identical bandwidth and the larger part exists purely to make a model FIT, not to go faster. THIS IS THE PART THE REPO DOCS CALL OUT: for a Mac-serves-LLM claim, 512 GB is a capacity number, and weights plus KV cache draw on that ONE pool - there is no second pool and no dedicated VRAM. The consequential caveat is therefore capacity headroom, not bandwidth: a 70B at 4-bit (~35 GB of weights) leaves the rest of 512 GB for KV and OS, which is why the 512 GB ceiling is what makes very long-context single-model serving viable on a Mac at all. Note also that the currently-shipping top configuration has since moved to M5 Ultra (apple.com/mac-studio/specs lists 'M5 Ultra with 36-core CPU, 80-core GPU ... 1.2TB/s memory bandwidth' and '256GB or 512GB unified memory'), so the 819 GB/s figure is specific to the M3 Ultra generation and must not be carried onto the M5 Ultra. Two M3 Max dies via UltraFusion; 60-core or 80-core GPU; 32-core Neural Engine; up to 512 GB unified memory. tdp_w caveat: 480 W is the Mac Studio's 'Maximum continuous power', a SYSTEM figure (CPU + GPU + memory + PSU loss), NOT a GPU TDP. It must not be compared against the 575 W RTX 5090 TGP or the 600 W RTX PRO 6000 TBP, which are GPU-only figures. UNIFIED MEMORY IS NOT VRAM - read this before comparing any of these numbers to a discrete card: 1. Capacity you can hand to a GPU kernel is smaller than the advertised capacity. On Apple Silicon the GPU can only address part of the unified pool; the OS and CPU take their share and a portion of the pool is not GPU-writable at all. A '128 GB' Mac does not present 128 GB to Metal. 2. The bandwidth is SHARED. The figure below is the ceiling for the whole system memory subsystem and must serve CPU, GPU and everything else. A discrete card's bandwidth is a private bus serving only the GPU's frame buffer. 3. Bigger is not faster for decode. Batch-1 LLM decode is memory-bound and roughly bandwidth-limited, so more-but-slower memory yields lower tokens/second even when the model fits. What large unified memory actually buys is CAPACITY - running a model you otherwise could not fit - plus the ability to offload layers to host RAM and pay a round-trip for them. 4. There is no NVLink or MIG analogue. Metal exposes one GPU and one pool; you cannot partition it across GPUs. Apple publishes memory BANDWIDTH and core counts but never GPU TFLOPS for these parts, which is why the flops array is EMPTY rather than filled with estimates. Any 'M-series TFLOPS' number in circulation is a third-party die-level extrapolation, not an Apple figure. This is the clearest case in the slice for refusing to collapse capacity and bandwidth into one ranking. 512 GB at 819 GB/s versus: - RTX PRO 6000 Blackwell: 96 GB ECC VRAM at 1792 GB/s. Mac has 5.3x capacity, 0.46x bandwidth. - RTX 5090: 32 GB at 1792 GB/s. Mac has 16x capacity, 0.46x bandwidth. - RTX 4090: 24 GB at 1008 GB/s. Mac has 21x capacity, 0.81x bandwidth. A 70B-class model at fp8/bf16 (~140 GB) fits on the Mac only, and only by accepting host-memory traffic for part of it; a 400B-class model fits on the Mac and nowhere else in this slice. But for a model that fits on BOTH (say 30B bf16, ~60 GB), the discrete card runs it entirely in dedicated ECC memory at 1792 GB/s while the Mac runs it in a shared pool at 819 GB/s - so the discrete card is roughly 2x faster per stream. '512 GB beats 96 GB' is correct about what fits and wrong about how fast it runs. Record both numbers; never rank on one. MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). The vendor publishes NO memory-bus width for this part, and none was back-computed from the published bandwidth. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH.[REPAIRED 2026-10-08 by w8-reverify. This sentence previously read '(2026-10-04). %s NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH' — a literal printf placeholder left in the JSON by the wave-3 pass (commit 9968769) across 34 accelerator records, and invisible to every check in this repo because validate.py never reads notes. The substitution text is the same boilerplate the 7 uncorrupted records in this family already carry, and it is only valid here because memory_bus_bit is null on every one of the 34, so "the vendor does not publish it" is the true state. A record with a non-null memory_bus_bit must NOT receive this filler.] That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either inference is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the note above names the specific document that was read and found not to carry it, so a future pass does not have to re-establish that from scratch. MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). Apple's own tech-specs pages publish MEMORY BANDWIDTH ONLY and have never published a memory-bus width in bits for any M-series part. Verified directly this pass on support.apple.com/en-us/111900 (Mac Studio 2022) and /en-us/122211 (Mac Studio 2025), which carry '400GB/s', '800GB/s', '410GB/s', '546GB/s' and '819GB/s' rows and no width row at all. Not back-computed: the published figures are per-SoC aggregates across a multi-package design and LPDDR5X runs at several pin rates depending on SKU, so no single width reconciles them all. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH. That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the text above names the specific document read and found not to carry it, so a future pass does not have to re-establish that from scratch.