MLX — your M4's native tongue
MLX is Apple's own ML framework, built by Apple researchers specifically for Apple Silicon — and it exists because of the architecture you learned in Topic 30: unified memory. On a Mac there is no CPU↔GPU divide to shuttle data across; MLX is designed around that, with arrays living in shared memory and operations running wherever's best, zero copies. It's not a port of a CUDA-world tool; it's native.
For LLM work, the package is mlx-lm:
pip install mlx-lm
mlx_lm.generate --model mlx-community/Qwen2.5-7B-Instruct-4bit \
--prompt "explain KV cache in one line"The mlx-community org on Hugging Face hosts thousands of pre-converted, pre-quantized models (its own format, not GGUF — the one fork in the diagram's arrow).
But here's the headline for you specifically: mlx_lm.lora fine-tunes on the Mac itself. LoRA and QLoRA training, natively on M-series — meaning your Topic 25 exercise ("what can my M4 train?") has a concrete runtime: your machine isn't just an inference box, it's a small training rig. And at the high end, unified memory changes what's possible: a 128 GB Mac Studio runs 70B+ models that no consumer GPU can fit — Topic 30's "fits vs fast" trade in its most extreme form, since the Topic 34 bandwidth law still sets the speed within each M-chip tier.
Performance position: on Apple hardware, MLX is competitive with or ahead of llama.cpp's Metal backend for many workloads, and tools like LM Studio now let you pick either engine per model.
Summary
Apple's native framework exploiting unified memory; mlx-lm for inference, mlx_lm.lora for on-Mac fine-tuning; the performance ceiling for M-series machines.
Mental model
llama.cpp made the Mac a supported platform; MLX makes it a first-class one.
Mistakes to avoid
Expecting GGUF files to load (MLX has its own converted models — check mlx-community first), and expecting GPU-class training speed — your M4 trains adapters conveniently, not quickly; it's for small runs and iteration, with rented GPUs for the serious jobs.
Exercise