verifiedhigh · 0.85updated 2026-10-08

Apple M4 Max (MacBook Pro 14-inch, 2024)

apple m-series (M4 Max) 2024

Fields

accelerators/apple-m4-max

Vendor

apple

Architecture

m-series (M4 Max)

Release year

2024

Process (nm)

Form factors

VRAM (GB)

128

Memory type

lpddr5x unified

Memory bandwidth (GB/s)

546

Bandwidth basis

Apple tech specs: '546GB/s memory bandwidth' for the M4 Max with 16-core CPU / 40-core GPU - the highest published bandwidth for a single M4 Max package; the 14-core CPU / 32-core GPU configuration is listed at 410GB/s. Unified-memory bandwidth, package-level, shared with the CPU.

Unified memory

yes

Consumer part

yes

notes

AUDIT 2026-10-03 (unified pool verified against Apple primary source, no value changed): Apple's tech specs for the 14-inch MacBook Pro (M4 Pro or M4 Max, 2024), support.apple.com/en-us/121553, state under Memory 'Apple M4 Max chip - 36GB unified memory - Configurable to: 48GB, 64GB, or 128GB (M4 Max with 16-core CPU)' and under Chip '410GB/s memory bandwidth' for the 32-core GPU configuration, configurable to 'M4 Max with 16-core CPU, 40-core GPU (546GB/s memory bandwidth)'. So vram_gb 128 is the maximum configurable unified pool and 546 GB/s is the 40-core-GPU configuration's package bandwidth - both correct as stored, unified_memory true correct. The pairing matters: 128 GB is only offered on the 16-core-CPU / 40-core-GPU configuration, which is the same configuration that carries the 546 GB/s, so the two numbers are consistent with each other and a 128 GB M4 Max does deliver 546 GB/s. The 14-core/32-core config tops out at 64 GB and 410 GB/s. Also note the SAME 546 GB/s and 128 GB appear on Mac Studio (2025) - support.apple.com/en-us/122211 lists M4 Max at '36GB unified memory ... Configurable to: 48GB, 64GB, or 128GB' and 'Configurable to: M4 Max with 16-core CPU, 40-core GPU (546GB/s memory bandwidth)'. Reading the M4 MAX record as 'a MacBook' understates it; the identical silicon is sold in a Mac Studio with no battery power limit, which is the configuration actually used for local LLM serving. M4 Max: 32-core or 40-core GPU, 16-core Neural Engine, up to 128 GB unified memory, 14-inch MacBook Pro (2024). memory_type recorded as lpddr5x is a package-level characterisation, NOT an Apple-published spec for this part; Apple specifies only 'unified memory'. tdp_w is null because Apple publishes no SoC power figure for this machine. 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: 546 GB/s shared vs the 4090's 1008 GB/s dedicated and the 5090's 1792 GB/s dedicated. The 128 GB capacity is what makes this part interesting for large-model work, not the bandwidth. Against a 16 GB discrete card the capacity win is decisive (a 30B model in 4-bit fits here and not there); against a 32 GB 5090 the bandwidth deficit is decisive for tokens/second. 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.

Notes

memory_type recorded as lpddr5x is a package-level characterisation, NOT an Apple-published spec for this part; Apple specifies only 'unified memory'. tdp_w is null because Apple publishes no SoC power figure for this machine.

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: 546 GB/s shared vs the 4090's 1008 GB/s dedicated and the 5090's 1792 GB/s dedicated. The 128 GB capacity is what makes this part interesting for large-model work, not the bandwidth. Against a 16 GB discrete card the capacity win is decisive (a 30B model in 4-bit fits here and not there); against a 32 GB 5090 the bandwidth deficit is decisive for tokens/second. 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.

Cross-references

This record references no other records — it is a leaf. It is cited by 54.