Ollama Releases v0.40.12-rc1, Adds LFM3 and d1 Model Support

A Low-Key Release Candidate That Points in a Clear Direction

Ollama has released the v0.40.12-rc1 release candidate. Judging from the release record on GitHub, the version number itself is just a routine iteration, but one line in the commit message is worth noting: mlx: add LFM3 and d1 models (#19333). In other words, the core change in this release centers on integrating two new models into the MLX backend — LFM3 and d1.

A release candidate (rc1) usually means features are essentially frozen and the build has entered testing and validation. For developers who care about the local inference toolchain, the value of this information lies not in the version number bump, but in Ollama's continued investment in the MLX technical path.

Why Expanding Models on the MLX Backend Matters

MLX is Apple's machine learning framework designed for Apple Silicon chips, emphasizing efficient inference under a unified memory architecture. By integrating new models into the MLX backend, Ollama directly implies that these models can run on Apple Silicon devices through a path better tailored to the hardware, rather than relying on a generic inference implementation.

For Mac users, this kind of change is often where the difference is most noticeable — whether a model loads successfully, whether memory usage stays manageable, and whether interaction latency is acceptable all depend on how well the backend is adapted. This commit brings LFM3 and d1 into MLX support, indicating that Ollama is aligning its "runnable model list" with hardware backends at a finer granularity, rather than simply handling everything uniformly by model name.

It should be noted that the original release information does not disclose the specific parameter sizes, architecture details, or performance data of these two models, so it would be inadvisable to make quantitative predictions about their inference performance. What is certain is that they have entered Ollama's MLX support matrix.

MLX's unified memory architecture is the key design that distinguishes it from traditional GPU inference stacks. On Apple Silicon, the CPU and GPU share the same physical memory, and MLX leverages this to avoid explicit data copies during inference, thereby reducing latency and peak memory usage. However, this also means the model loader needs dedicated adaptation for MLX's tensor layout and quantization schemes; a generic backend (such as the CPU-based llama.cpp path) cannot be reused directly. Ollama maintains separate model integration logic for MLX precisely so that weight mapping, KV cache allocation, and similar steps fit the unified memory model, rather than applying a generic implementation designed for dedicated VRAM.

What the Release Process Itself Signals

This tag was created by GitHub account dhiltgen on 27 Oct 15:47, and the commit carries a GitHub-verified signature (GPG key ID: B5690EEEBB952194). For open-source projects, signature verification and the release candidate process are part of supply chain trustworthiness: they show that the release action came from a project maintainer and went through a traceable signing step.

From an engineering perspective, the existence of an rc version also suggests the changeset is not small. Model integration involves loading logic, tensor mapping, and possibly quantization format adaptation, all of which require a round of real-world use to surface issues. Putting LFM3 and d1 into the release candidate together, rather than splitting them into multiple smaller versions, may mean the two share part of the integration work.

In semantic versioning workflows, a release candidate usually indicates that features are frozen and only bug fixes remain, but its real purpose is to hand the changeset to early users willing to accept instability risk. For changes like model integration, unit tests can hardly cover load failures, precision deviations, or memory overflows on real hardware; only actual runs can expose them. If issues collected during the rc phase involve backend adaptation, the cost of fixing them is far lower than a hotfix after the official release — this is precisely one of the engineering motivations for putting LFM3 and d1 into rc1 together rather than splitting them into smaller versions.

Practical Impact for Developers

If you run models locally with Ollama, the practical significance of this rc version is that you can verify in advance how the new models perform on your machine, especially loading and inference stability in Apple Silicon environments. A release candidate is meant to collect feedback; if you encounter backend-related issues, reporting them now is more valuable than waiting for the official release.

For the broader ecosystem, Ollama's continued expansion of MLX model support will strengthen the usability of "Mac as a local inference platform." The more diverse the models, the more room developers have for local prototyping, validating privacy-sensitive scenarios, and offline experiments. These seemingly trivial model integration commits, accumulated over time, are what truly constitute the competitiveness of the local AI toolchain.

As for what tasks LFM3 and d1 are each suited to and where their capability boundaries lie, we will need to wait for model cards or follow-up documentation. Given the limited information, it is safer to understand this as a backend capability expansion rather than to over-interpret it.