MLX is Apple's array framework for Apple Silicon. The short version: it is closer to NumPy or PyTorch than to anything you install and open. It gives you arrays, automatic differentiation and a way to run them on the GPU, and expects you to build the thing you actually want.
We run it in production on a farm of Macs generating video, so this is what it is like to operate rather than what the announcement said.
What it is
A numerical computing library with a deliberately familiar API — if you have written NumPy, the surface will not surprise you. On top of that sit neural-network building blocks and optimisers, which is the part that makes it a machine-learning framework rather than just an array library.
It is open source, developed in the open on GitHub under a permissive licence. You can read it, fork it, and file issues against it, which matters more than it sounds: when a model's behaviour is strange, the ability to read the kernel is the difference between debugging and guessing.
The design decision that defines it
Unified memory. On Apple Silicon the CPU and GPU share one pool, and MLX is built around that rather than working despite it. There is no explicit transfer step — no moving an array to the GPU and back, because there is no separate place to move it to.
Anyone arriving from CUDA notices the absence immediately. A whole category of code, and a whole category of bug, simply is not there. It is also why a 64GB Mac can hold a model a 24GB discrete card has to offload, and offloading is where nominally faster hardware quietly becomes slower.
The other notable choice is lazy evaluation: operations build a graph and compute when a result is actually needed. Good for performance, mildly confusing the first time you time something and the clock reports almost nothing because the work had not happened yet.
MLX vs PyTorch with MPS
PyTorch has an MPS backend, so you can already run on Apple GPUs without MLX. The difference is posture. PyTorch is a cross-platform framework with Apple support added; MLX is designed for this hardware specifically and makes unified memory a first-class assumption rather than an adaptation.
In practice the deciding factor is rarely the framework and almost always the port. Whichever one the model you want has been implemented well in is the one you will use. A model nobody has ported runs at zero on the best Mac ever built.
Does it use the Neural Engine?
Largely not, for this kind of work. The Neural Engine is built for small, fixed, low-power inference — the on-device models Apple ships. Heavy generative workloads run on the GPU through Metal, which is what MLX targets. If you were hoping to unlock the Neural Engine with a configuration flag, that is not the shape of the thing.
The gotcha that cost us a sweep of renders
This is the part worth carrying away. MLX allocations are invisible to every free-memory reading macOS exposes. vm_stat, memory pressure, Activity Monitor — all of them look healthy right up until the kernel kills the process with rc=137.
So a guard that checks whether RAM is free before starting work is not a guard. It is a coin flip. Four machines discovered this simultaneously, mid-sweep, and the queue cheerfully re-issued the same jobs and killed them again.
The fix is to stop polling the machine and start pricing the job: estimate what a given shape of work costs before claiming it, and release it back to the queue if this node cannot afford it. Our sidecar from a real 1080×1920, 97-frame render reads peak_mem_gb: 44.1 against budget_gb: 57.6 — measured, not modelled. Our memory coefficient is still extrapolated from renders rather than derived from the model internals, and we say so; it is good enough to schedule against and gets retuned from every finished job.
Should you use it
If you want a chat model running locally, you do not need MLX — a packaged runner is the right answer and we wrote up that comparison. If you need something there is no package for, MLX is the layer you end up on, and the honest expectation is that you will be reading source at some point.
For what that looks like at scale: four Macs, one folder, 4× throughput.