Ollama v0.34.2 vs v0.34.1: a targeted MLX fix, not the same regression

#english #ollama #llmlocal #applesilicon

Ollama published two releases back to back: v0.34.1 on September 14 and v0.34.2 on September 15. Both changelogs touch MLX and both mention memory. That invites reading them as an emergency fix for the same issue. The official text doesn't say that.

What changed in each version

v0.34.1 (September 14), per its official changelog:

ollama create with MLX safetensors is no longer experimental. Creating GGUF models now requires llama.cpp tools for conversion and quantization.
General improvement to MLX memory handling on Apple Silicon ("Improved MLX memory handling on Apple Silicon").
Token repetition detection now requires 100 repeated tokens before triggering, to reduce false positives in cases like OCR.
/api/tags reports a measured improvement on large model libraries: from 3.1 seconds down to 294 ms cold, according to the tests included in the changelog itself.
Deprecation of typical_p: it can't be set on new models, but existing GGUF models keep it.

v0.34.2 (September 15), one day later:

First-run setup when running ollama, with the option to sign in or continue locally. That state is shared with the desktop app on macOS and Windows.
ollama://apps link to open the Apps page of the desktop app directly on macOS and Windows.
Specific fix: "Fixed excessive memory growth during long generations with MLX speculative decoding".
llama.cpp update (no version detail given in the changelog).

Why these aren't the same fix

The friction point is the shared wording: "memory" and "MLX" show up in both entries. But the text of each changelog describes different mechanisms.

v0.34.1 talks about "Improved MLX memory handling" in general terms, without specifying under what condition the problem occurred or which part of the pipeline it touched.

v0.34.2 points to a precise case: memory growth during long generations when using MLX speculative decoding. That's a specific inference mechanism, not the general memory handling the previous version mentioned.

Neither changelog says one fixes what the other broke. There's no text linking the two entries as the same regression, and there's no confirmation either that they're fully independent. The documents simply don't clarify it.

flowchart TD
  A[v0.34.1 - Sep 14] --> B[Improved MLX memory handling, general]
  A --> C[MLX safetensors no longer experimental]
  D[v0.34.2 - Sep 15] --> E[Fix: memory in MLX speculative decoding, long generations]
  D --> F[First-run setup + ollama apps]
  B -.- G{No explicit textual link}
  E -.- G

Who the v0.34.2 fix matters to

The memory fix in v0.34.2 is scoped to one scenario: MLX speculative decoding on long generations. That runs on Apple Silicon with the MLX backend.

If the use case is GGUF models on llama.cpp, that fix doesn't apply according to what the changelog says: the described problem is specific to MLX speculative decoding, not the GGUF backend.

What can't be concluded from this evidence

There's no confirmation of whether the memory growth fixed in v0.34.2 was introduced by the v0.34.1 changes or already existed before that.
The internal mechanism isn't explained: the changelog says it was "fixed," not why memory grew during speculative decoding.
There's no detail on which llama.cpp version was bumped in v0.34.2 or what that bump brings.
The /api/tags numbers (3.1 s → 294 ms) come from the project's own changelog, with no described test methodology.

Who needs to update today

Based on the available information: those running MLX models on Apple Silicon with long generations and using speculative decoding have a concrete, documented fix in v0.34.2. For the rest of the changes — stable safetensors, the repetition threshold, typical_p deprecation, the /api/tags improvement — those were already in v0.34.1, and updating to v0.34.2 includes them by inheritance, not because v0.34.2 repeats or fixes them.

Original source:

This article was originally published on juanchi.dev

DEV Community