MLX

Apple's array framework for machine learning on Apple Silicon, and the runtime layer under the Mac end of the local stack. mlx-lm is the language-model library on top of it; mlx-vlm the vision-language one. The framework targets unified memory — CPU and GPU address the same pool — which is why the memory arithmetic in an MLX server is about total system RAM rather than a separate VRAM budget (omlx defaults its ceiling to system RAM minus 8 GB).

The corpus reaches it twice and from opposite directions. llms-local-list files MLX in the engine row beside Ollama, llama.cpp, vLLM and SGLang — a runtime that executes weights, named but not examined. omlx is the first source here built on it, and shows the layer boundary: mlx-lm supplies the BatchGenerator that makes continuous-batching possible, and the eight tool-call parser families oMLX advertises are mlx-lm's, not oMLX's. What sits above is scheduling, caching and an API.

Two things about MLX matter for the inference story specifically. It is single-vendor by construction — Apple Silicon only, M1 through M5 — so it is the one engine in this spoke whose hardware question is settled before any other question is asked. And its performance can depend on custom Metal kernels that are compiled separately from the Python package: oMLX measures a ~30× prefill gap on GLM-5.2 between a build with them and one without, with no runtime warning on the slow path. A framework whose fast path is a build-time option is a different kind of dependency from one whose fast path is the only path.

Gaps

Nothing here comes from Apple. No release history, no version, no benchmark, no account of the framework's own design — both sources are downstream users. A first-party MLX source, or an independent Apple-Silicon-vs-CUDA serving comparison, would be the thing to hunt.

Related

omlx · local-llm-stack · llms-local-list · continuous-batching · llama-cpp · quantization · apple