Apple M3 Max (MacBook Pro 16-inch, Nov 2023)

Apple tech specs: '400GB/s memory bandwidth' for the M3 Max with 16-core CPU / 40-core GPU; the 14-core CPU / 30-core GPU configuration is listed at 300GB/s. Unified-memory bandwidth, package-level, shared with the CPU.

AUDIT 2026-10-03 (unified pool verified against Apple primary source, no value changed): Apple's 16-inch MacBook Pro (Nov 2023) tech specs, support.apple.com/en-us/117737, state under Memory 'Apple M3 Max chip - 36GB unified memory - Configurable to: 96GB (M3 Max with 14-core CPU) or 48GB, 64GB, or 128GB (M3 Max with 16-core CPU)' and under Chip 'Apple M3 Max chip - ... 30-core GPU, 40-core GPU ... 300GB/s memory bandwidth' configurable to 'M3 Max with 16-core CPU, 40-core GPU (400GB/s memory bandwidth)'. So vram_gb 128 and bw 400 both belong to the SAME 16-core-CPU / 40-core-GPU configuration - the pairing is internally consistent - and unified_memory true is correct. Note the configuration trap: the 96 GB option is tied to the 14-core CPU / 30-core GPU at 300 GB/s, so a 96 GB M3 Max is SLOWER than a 128 GB one; capacity and bandwidth do not move together on this part. M3 Max: 40-core GPU (or 30-core), 16-core Neural Engine, up to 128 GB unified memory. Included as the high-end PORTABLE tier. tdp_w is null: Apple publishes no per-SoC or per-GPU power figure for the laptop, and a laptop SoC's power envelope is not a discrete TDP. Nothing is estimated here. 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. Inference read: 400 GB/s of SHARED unified bandwidth against an RTX 4090's 1008 GB/s of DEDICATED VRAM bandwidth - 0.4x the bandwidth in a package that cannot sustain a 450 W desktop card. The advantage is portability, not tokens/second. Also note the 300 GB/s 30-core GPU config is a 25% bandwidth cut for the same marketing part name: the configuration matters more than the name. 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.