Apple M1 Ultra (Mac Studio, 2022)

Apple tech specs: '800GB/s memory bandwidth' for the M1 Ultra configuration with a 64-core GPU. IMPORTANT: the 48-core GPU configuration of the SAME chip is listed at 400GB/s, so the figure scales with the SoC configuration, not just the part name. Unified-memory bandwidth, package-level, shared with the CPU - there is no separate VRAM bus.

AUDIT 2026-10-03 (unified pool verified against Apple primary source, no value changed): Apple's Mac Studio (2022) tech specs (support.apple.com/en-us/111900) state 'Apple M1 Ultra chip - 64GB unified memory - Configurable to: 128GB' and '800GB/s memory bandwidth' for the 48-core GPU configuration, configurable up to the 64-core GPU. So vram_gb 128 is the maximum of the configurable unified pool, unified_memory true is correct, and 800 GB/s is package-level and shared with the CPU. IMPORTANT CONFIGURATION CAVEAT that a Mac-serves-LLM reader must not miss: Apple lists 400GB/s for the M1 MAX and 800GB/s for the M1 ULTRA, and within M1 Ultra the 800 GB/s figure is printed for the 48-core GPU base configuration - the 64-core configuration is reached via 'Configurable to' rather than carrying its own bandwidth line. The bandwidth number therefore tracks the SoC, not the memory capacity: 64 GB and 128 GB of unified memory are the SAME package with the SAME 800 GB/s. Compared with apple-m3-ultra (512 GB at 819 GB/s) the M1 Ultra is the capacity-constrained generation by a wide margin. Two M1 Max dies joined by Apple's UltraFusion silicon interposer; 64-core GPU option (48-core option listed); 16-core/32-core Neural Engine; up to 128 GB unified memory. tdp_w caveat: 370 W is the Mac Studio's 'Maximum continuous power' - a SYSTEM figure covering CPU, GPU, memory and PSU losses. It is NOT a GPU TDP and must not be lined up against a discrete card's TGP (a 575 W RTX 5090 is a GPU-only figure). 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. Concretely vs a 24 GB RTX 4090: 128 GB advertised at 800 GB/s vs 24 GB dedicated at 1008 GB/s. Capacity ratio 5.3x, bandwidth ratio 0.79x. A 70B-class model at 4-bit fits only on the Mac; once it does fit, the 4090 decodes it faster per stream. Separate the feasibility question from the throughput question. 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.