Ollama 0.30.8はMLXランナーを内蔵するがGGUFは通らない — M1 Max 64GB実測Ollama 0.30.8 ships with an integrated MLX runner for Apple Silicon, but…

Ollama's 0.30.8 release adds an integrated MLX runner for Apple Silicon, a change that has fueled expectations of faster local large language model inference on Macs. A hands-on investigation on an M1 Max machine with 64GB of unified memory suggests those expectations need to be checked carefully, because the standard models most users pull are not actually routed through the new MLX path.

The core finding comes from a practical question. Before measuring tokens per second, the author wanted to confirm whether the models they normally obtain with `ollama pull` and start with `ollama run` were being served by the MLX runner at all. Without that confirmation, any benchmark numbers would lack a meaningful basis for comparison. Through binary analysis and cross-referencing runtime logs, the answer turned out to be that they were not.

The reason lies in the distinction between a model's file format and the runner that executes it. MLX is Apple's array framework built specifically for Apple Silicon, taking advantage of the unified memory architecture shared between CPU and GPU. Models designed for MLX are typically distributed in an MLX-specific format. GGUF, by contrast, is the format associated with llama.cpp, the C/C++ inference engine that Ollama has historically relied on as its default backend. When you pull a typical model from Ollama's library, you generally receive a GGUF file, and that file appears to be executed by the llama.cpp-based runner rather than the MLX one.

That means simply upgrading to 0.30.8 does not automatically grant a speed improvement. The MLX runner being present in the binary is necessary but not sufficient; the model also has to be in a form the MLX runner will handle. Users who assume the new backend is active for their existing GGUF downloads may be measuring the same llama.cpp path they were using before, and attributing any variance to MLX incorrectly.

Some background helps explain why this distinction matters. MLX was released by Apple's machine learning research group as an open framework, and a companion project, MLX-LM, provides language model tooling on top of it. Because MLX is tuned for Apple Silicon's GPU and unified memory, it has attracted interest as a potentially faster route for on-device inference than more general-purpose backends. LM Studio, another popular desktop application for running local models, has also added MLX support alongside its GGUF and llama.cpp option, which has helped popularize the idea that MLX equals better performance on Macs. Whether MLX is faster in any given case is likely to depend on the model, quantization, and workload, so the framing of "MLX is simply faster" is an oversimplification.

For Ollama users specifically, the practical takeaway is to verify the active backend before drawing conclusions. The investigation relied on inspecting the binary and matching it against runtime logs, rather than trusting release notes or community summaries. That level of scrutiny is a reminder that in fast-moving local LLM tooling, feature availability in a release does not always mean the feature is engaged for a given configuration.

The gap between "ships with" and "is used by default" is common in this space. Ollama abstracts a lot of complexity for users, which is part of its appeal, but that abstraction can also obscure which code path is running. To actually exercise the MLX runner, a user would likely need a model packaged for MLX rather than the GGUF artifacts served by default `ollama pull`, though the exact packaging and configuration requirements are worth confirming per version.

None of this diminishes the value of adding an MLX runner. Integrating it positions Ollama to offer an Apple-native execution path over time, and future releases or model conversions could make that path more accessible. For now, however, the finding is a caution against benchmarking on assumptions. Anyone comparing tokens per second across setups should first establish which runner is handling the request, ideally through logs, so that the numbers reflect the backend they think they are measuring.