MLX-LM on 64GB Apple M4 Max: Qwen3-4B-Instruct-2507 bf16 prompt processing at 2048 tokens
Fields
benchmarks/mlx-m4-max-qwen3-4b-fp16-prefill-tok-sNotes
Recorded deliberately as the prefill-side counterpart to mlx-m4-max-qwen3-30b-a3b-4bit-decode-tok-s, because the asymmetry is the point: ~1781 tok/s prefill against ~52 tok/s generation on the same chip, a ~34x gap driven by the arithmetic intensity difference between the two phases. Anyone reasoning about MacStudio-class capacity should note that prefill is essentially free and decode is what costs. Same unmerged-PR caveat as its sibling (mlx-lm PR #552, closed Aug 2026, never merged), hence measured_by=vendor but confidence 0.6 and the notes say so explicitly. Curiosity from the same table worth knowing: prefill barely moves with quantization on this model (bf16 1780.63, q8 1606.57, q4 1622.27) while generation nearly doubles (52.47 -> 134.52). That is the signature of a bandwidth-bound decode and a compute-bound prefill, and it means on Apple silicon you lose nothing by quantizing prefill and gain a great deal on decode.
PROVENANCE RAISED 2026-10-08 (w8-bench-src): same merge verification as its sibling - mlx-lm PR #552 ('LLM Benchmarks' by awni) has merged=true, merged_at 2025-10-15T19:24:12Z per the GitHub API, and the table it added is live at mlx_lm/BENCHMARKS.md, fetched and read on 2026-10-08, where the Qwen3-4B bf16 row reads prompt 1780.63 / generation 52.47 / memory 9.02 GB - the same figures this record holds. So the unmerged-PR caveat recorded here is retired: it is a MERGED table from the project's own member, not an orphan PR. VALUE UNCHANGED (1780.63), CONFIDENCE UNCHANGED (0.6) - merged is not reproduced, and the source still omits trial count, the M4 Max GPU-core count of the SKU and thermal state.