Ollama 0.34.4 on Mac: Qwen 3.8 Prefill +19%, Gemma 4 Fix

Ollama is the runtime that puts llama.cpp and MLX behind one command line, and v0.34.4 shipped as a stable release on September 23, 2026. It landed one day after its release candidate. Most of the changelog is maintenance: a structured output rewrite, two bug fixes, and version bumps to the three libraries sitting under the hood. However, two items are Apple Silicon specific, and they are the reason this release matters if you run local models on a Mac. One makes Qwen 3.8 prefill measurably faster. The other changes how Gemma 4 handles images, and how much memory that costs you. That split matters, because the release notes carry no numbers at all. The figures below come from the pull requests that shipped the changes, and from our analysis of how those changes land on the memory budgets the ModelFit engine computes for each Apple Silicon tier. In our experience, that second step is what decides whether an update earns its place on your machine.

TL;DR: Ollama 0.34.4 (stable, 2026-09-23) makes Qwen 3.8 prompt processing faster on Apple Silicon. The upstream PR measured +18.7% at 2k prompt tokens and +19.1% at 8k on an M5 Max, both on the MLX path only. Gemma 4 now picks one of five image token budgets per image instead of a fixed default, which helps vision on 16GB Macs but adds up to 826 MB at the largest budget. The macOS desktop app fix does not touch the CLI or the server.

What Ollama 0.34.4 actually changed

Notably, the release tag is commit b2da9e4, published 2026-09-23T02:24:43Z. The diff against v0.34.3 is 14 commits, 70 files changed, and 5 contributors. The published notes list six user-facing items:

• Specifically, structured outputs on thinking models now apply in a single pass instead of two generations.
• Intermittent "model not found" errors with a large local model library no longer appear.
• In addition, the macOS app no longer becomes unresponsive when checking whether ChatGPT or Codex is running.
• In particular, Qwen 3.8 prompt processing is faster on Apple Silicon, on the MLX path only.
• Similarly, Gemma 4 on Apple Silicon picks the best image resolution per image.
• The release also bumps llama.cpp, MLX, and XGrammar, the three libraries under the hood.

Only items four and five are Mac specific. Meanwhile, the rest matter on Linux, Windows, and macOS alike, or do not touch inference at all.

The Qwen 3.8 speedup: what the numbers actually are

Prefill is the prompt-processing phase that runs before a model produces its first token, and the release notes call it faster without saying by how much. In fact, no tokens per second figure appears in the published changelog. The number lives one level down, in the pull request that shipped the change (ollama/ollama#18550), where the author posted a prefill benchmark on an M5 Max.

Three caveats matter before you expect the same numbers on your desk.

• The measurement is an M5 Max only. No M1, M2, M3, or M4 figure exists in the record, official or community. On older chips the direction should hold, because the kernel change is architectural, but nobody has measured the magnitude elsewhere.
• These are prompt processing (prefill) numbers, not generation. Consequently, decode speed, the metric people usually quote, stays untouched by this change.
• The change lives in mlxrunner, so it applies to models served through Ollama's MLX path on Apple Silicon. By contrast, a model on the llama.cpp path gets nothing from it, even on the same Mac.

Specifically, the mechanism is two edits: using MLX's gated-delta kernel for long scans, and folding the dense MLP global scales into SwiGLU. Neither adds an option you have to enable. Thus, pull the update and the MLX Qwen 3.8 path is faster on its own. For example, a long RAG prompt assembled from a document loader reaches its first token sooner, because the whole prompt now runs through the new kernel path.

What did not change

That said, two things people will assume changed, and did not.

First, server throughput outside Qwen 3.8 prefill stays unchanged. This is a targeted kernel fix, not a broad runtime win. If you mostly run Qwen 3.5, Llama, or Gemma for text generation, 0.34.4 will feel identical.

Second, MLX is Apple's array framework for Apple Silicon, and it is still not the default runner here. As of 0.34.4 you remain on llama.cpp unless a model already runs on an MLX-supported path. The next release candidate, v0.40.0-rc0, is the one that switches supported architectures to MLX by default on Apple Silicon, with its changelog pointing back at v0.34.4. Consequently, 0.34.4 is the last stable line before that default flips. That is the part we track closest. We built the ModelFit engine to answer one question per device: does a given model fit, and which runner does it land on? That answer decides whether a model feels fast, marginal, or unusable on the Mac in front of you.

Gemma 4 vision now selects resolution per image

Image token budget is the number of vision tokens a model spends to encode one image, and that number drives both detail and memory. On Apple Silicon, Gemma 4 stops using one fixed budget and picks per image instead. It chooses between five budgets, 70, 140, 280, 560, and 1120, by matching the publisher resize grid closest to the actual input resolution while accounting for aspect ratio (ollama/ollama#18603).

In other words, a screenshot gets fewer tokens, while a high-resolution scanned document keeps more detail. In practice, there is no new API parameter to set. The trade is memory, though, and the PR published the spread for the two vision builds.

Notably, the PR reports that on a 16GB M1 Mac, Gemma 4 E4B shows memory pressure and compression with reduced performance, but does not hit out of memory. In contrast, the old fixed default sat at the 280 budget, so smaller images now use less memory than before, and large ones use more. Whether that is a win depends on what you feed it. For instance, a page of chat screenshots now takes less room than it did on 0.34.3, while a single high-resolution scan can take more. We ran the same five budgets through the memory model that powers our device pages, and the 16GB tier is the only row whose shape changes. On every larger tier, the swing fits inside the headroom those machines already have.

Structured outputs on thinking models, in one pass

Structured output means constraining a model to a schema you supply, and on thinking models that constraint used to cost a second pass. Importantly, this is the biggest code change in the release and the one least visible on a Mac. Before 0.34.4, applying a format to a thinking model ran two generations: an unconstrained pass, cancelled once the parser saw the content, then a re-rendered prompt with the parsed thinking under the grammar. The commit message for the change lists the cost of that: a second prefill, a dropped chunk that crossed the boundary, a prompt hack for harmony, and, on MLX, a stray first token that could leak into the JSON. For a Mac user, the practical cost was simple: a structured call on a thinking model prefilled the prompt twice before any JSON came back.

Now both handlers send one request that names the strings ending the thinking, and the runner constrains only the content after them in a single generation. The runner evaluates the prompt once, and the metrics pass straight through.

Does this change the output contract? In other words, the response shape and the JSON schema you pass stay the same, so existing callers keep working. One behavioral edge changes: a format now applies to whatever follows the thinking, so a tool call can no longer take the place of formatted content. In fact, that was already the case with thinking off, and harmony is the exception because its tool calls come before the final message. If you rely on a model emitting a tool call where you expected a schema-conformant object, test that path.

The macOS app fix is desktop only

The fix for the app becoming unresponsive refers to the macOS menu bar application, the one that checks whether ChatGPT or Codex is running. The underlying commit (ollama/ollama#18601) removes a System Events call used for that detection. It lives in the app/ tree.

Consequently, the fix does not touch the CLI (ollama run) or the server (ollama serve, and the /api endpoints). Therefore, if your Mac has no desktop app installed, or you never open it, this item does nothing for you. That said, it is worth installing the update anyway if you do use the app, because unsticking the detection loop also unblocks the update checks that hang behind it.

Under the hood: llama.cpp, MLX, XGrammar

llama.cpp is the C/C++ inference engine that most Mac users run GGUF models on, and XGrammar is the grammar engine that enforces structured output on the MLX runner. The release notes mention updates to all three libraries without naming versions. The commits themselves name them.

The llama.cpp bump also removes a Laguna Metal patch that upstream fixed, and refines memory allocation failure logging. In addition, the MLX bump carries a temporary MLX-C patch to plumb the fast::gated_delta_update path, which is the same kernel the Qwen 3.8 speedup uses. XGrammar 0.2.7 is the structured output engine on the MLX runner.

Is updating worth it on your Mac?

Here is the honest split by machine class.

If you run nothing on the MLX path and no Gemma 4 vision, 0.34.4 is a maintenance update: take it for the bug fixes and stay on it. If you do, the update is free performance, and the Qwen 3.8 prefill numbers are measured rather than advertised. To get it: brew upgrade ollama or pull the latest build from the official installer. If you are setting up from scratch, start with the Ollama on Mac install guide.

FAQ

Is Ollama 0.34.4 stable?

Yes. It shipped as a stable release on 2026-09-23, not as a pre-release, and it is the current stable line before the v0.40.0 candidate that switches MLX on by default.

How much faster is Qwen 3.8 prompt processing after updating?

The shipping pull request measured +18.7% at a 2k prompt, +19.1% at 8k, and +13.9% at 16k on an M5 Max. No other chip has a published figure. Therefore, treat those as the magnitude on an M5 Max and a direction elsewhere.

Does the speedup apply to llama.cpp models too?

No. The change is in the MLX runner, so it applies to Qwen 3.8 on Ollama's MLX path on Apple Silicon. The same model on the llama.cpp path does not benefit.

Does the Gemma 4 change add a new option I have to configure?

No. In fact, Ollama picks the image token budget per image automatically from five levels: 70, 140, 280, 560, and 1120. There is no API parameter for it.

Does the single-pass structured output change break my existing JSON schema calls?

In other words, the response shape and your schema stay unchanged, so existing callers keep working. The one edge case is a prompt where you expected a tool call in place of formatted content. A format now applies to whatever follows the thinking, so that no longer happens, except for harmony.

Do I need the update if I only use the CLI?

For the macOS app fix, no, that applies to the desktop app only. For the Qwen 3.8 prefill and Gemma 4 vision changes, yes, those reach the CLI and the server on Apple Silicon.

Bottom line

Ollama 0.34.4 is a small release with two Mac-specific changes that have real numbers behind one of them and a memory trade behind the other. Update if you run Qwen 3.8 on the MLX path or Gemma 4 vision on Apple Silicon. If you run neither, take it for the structured output rewrite and the bug fixes, and know that the bigger Apple Silicon story, MLX as the default runner, is the next release. Either way, there is no reason to skip it, because the same build carries both the speedup and the correctness fixes. For where the runtimes stand today, see MLX vs Ollama on Mac, and to size Qwen 3.8 for your machine, see the Qwen3.8-27B local guide and the Qwen3.8-Flash-Next hardware breakdown.

Every number here comes from the Ollama release notes and the pull requests named above, and the per-tier fit is our own arithmetic on the memory each Apple Silicon Mac has. Found an error? Contact us, our editorial standards are on the about page.