Apple M5 Max (MacBook Pro 14-inch, 2026)

Apple tech specs: '460GB/s memory bandwidth' for the M5 Max with 18-core CPU / 32-core GPU; '614GB/s memory bandwidth' for the M5 Max with 18-core CPU / 40-core GPU. The 614GB/s is the highest configuration. Unified-memory bandwidth, package-level, shared with the CPU.

M5 Max: 32-core or 40-core GPU, 16-core Neural Engine, up to 128GB unified memory. The 614GB/s bandwidth (40-core GPU configuration) is the highest for any Apple Silicon laptop chip. For local LLM inference, 128GB unified memory can hold a 70B model at 4-bit (~35GB weights) with massive room for KV cache, or even a 70B model at 8-bit (~70GB weights). The 614GB/s bandwidth yields roughly 15-25 tokens/sec for a 70B model at 4-bit. The M5 Max is the highest-performance Apple Silicon laptop chip for local inference. 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.