MLX 0.32.2 centers Apple silicon and includes Linux backends
MLX is an array framework from Apple machine-learning research, designed first around the shared memory architecture in Apple silicon. Its arrays can be used by CPU and GPU operations without explicit device transfers on that hardware. The current README also documents CPU-only and CUDA extras for Linux, so the project now reaches beyond Macs even though unified memory remains its defining idea.
The repository is compact beside older ML stacks, though it is substantial native software. Our commit 2d27ab0 checkout held 946 files, about 201,744 source lines, and 10.8 MB before dependencies. Python is the easiest front door. C++ is built from source, while C and Swift APIs live in linked projects. Example language models, image generation, and speech recognition are kept in a separate examples repository rather than bundled as finished applications.
NumPy-shaped APIs execute through lazy graphs
MLX exposes array operations that follow NumPy closely, along with neural-network and optimizer interfaces patterned after PyTorch. Automatic differentiation, vectorization, and graph compilation can be combined. Shapes may change without forcing the sort of ahead-of-time compilation pause some graph systems impose, because MLX constructs graphs dynamically. This feels familiar at the call site, yet its execution model deserves attention before existing code is moved over.
Operations record a graph until mx.eval or another materializing action runs it. Printing an array, converting it to NumPy, saving it, taking a scalar with item, or using a scalar array in control flow can cause evaluation. The design can avoid unused computation and reduce peak initialization memory, but evaluation placed too often adds overhead. Our 8-second successful build says the extension compiled in the sandbox; it says nothing about whether an application's evaluation points are efficient.
What happened when we ran it
Our fresh Debian sandbox used Python 3.12, 3 CPUs, and 8 GB of RAM. Installation succeeded in 55 seconds with 35 packages and 37 MB on disk. The build succeeded in another 8 seconds. Pip-audit found 0 known vulnerabilities. The checkout also contained 4 CI workflow files, no Dockerfile, and a tests directory, so test code and upstream automation were both visible.
Pytest exited with code 1 after 9 seconds. It reported 0 passed, 0 failed, and 33 collection/setup errors out of 33; its last summary line said 33 errors in 1.80s. The tail named optimizer, quantization, random, reduction, threads, tree, upsample, vmap, and zero-copy modules among the errors. It did not show a cause, so claiming a missing library, unsupported processor, or broken backend would be guesswork. No test body ran successfully in our environment.
Published packages have exact platform floors
The Apple wheel requires native Python 3.10 or newer on Apple silicon with macOS 14.0 or newer. Linux CPU wheels require glibc 2.35 or newer. CUDA packages add minimum NVIDIA architecture, driver, and toolkit requirements, with separate documented choices for CUDA 12 and CUDA 13. These floors rule out older enterprise Linux images and Macs running Python through Rosetta without changing the environment first.
Source builds add a C++20 compiler, CMake 3.25 or newer, and platform libraries. Linux needs BLAS and LAPACK development headers; Apple builds need Xcode 15.0 and the macOS 14.0 SDK. The Python route has a development extra and an in-place extension command, while C++ uses CMake and make. Our install occupied only 37 MB, but production disk and memory use will also include whichever models, datasets, and compiled kernels the application loads.
Two open reports justify focused numerical tests
Open issue 4444 describes a specific MLX 0.32.2 case where a strided slice selecting one element can return a wrong gradient, and vmap can return the wrong value and shape without raising. The report includes CPU and GPU reproductions plus several workarounds. Anyone using sliced tensors inside autodiff should add a small comparison test for the shapes and strides their model uses rather than assuming a correct forward value proves a correct gradient.
Issue 4464 reports a separate failure in variable-length training: mx.compile retained traces for distinct input shapes until a Metal buffer limit stopped the process. The report concerns MLX 0.32.2 and a particular training pattern, so it is not a verdict on all compiled work. It is still material for teams feeding many sequence lengths. Our own 33 collection/setup errors prevented the upstream suite from giving any counterevidence in the Debian CPU environment.
September 2026 activity is fast and still pre-1.0
GitHub recorded a push on September 6, 2026, one day after the measured commit, and listed 28,313 stars. Its 132 open items combined issues and pull requests; a separate search counted 87 open issues. Release v0.32.2 arrived on August 25 with fixes across casting, division, transforms, sorting, quantization, CPU operations, and Metal kernels, plus changes for CUDA and Windows-related build work.
That pace makes MLX a credible research framework, while the 0.x version and current numerical reports argue for pinning and application-level checks. The MIT license is straightforward, the guides explain lazy execution well, and 4 CI workflows are present. Adoption makes the most sense when Apple silicon is central enough to justify MLX-specific testing. A team that cannot reproduce its core model against known outputs should treat the failed 9-second test run as a stop sign, not a cosmetic CI detail.