Ollama added Laguna to Apple GPUs. The macOS chat path still needs work.

Poolside says Laguna XS 2.1 is compact enough for a Mac with 36 GB of RAM. Ollama’s current Laguna XS 2.1 model page also warns that chat through ollama run or /api/chat may return empty output on macOS/Metal. The first claim concerns whether a model can fit on a machine; the second concerns whether a particular interface path returns usable work.

That distinction changes today’s decision for teams considering a local coding model. Ollama v0.32.4 provides a documented Apple-GPU route worth evaluating on one exact configuration, while the publisher’s warning argues against standardizing the affected chat route. After reading, you should be able to separate the model, runtime, hardware backend, quantization, chat template, API endpoint, and observed response before deciding whether to evaluate now or wait.

The 36 GB claim describes model fit

In its Laguna XS 2.1 announcement, Poolside describes a mixture-of-experts coding model with 33 billion total parameters and 3 billion activated for each token. A mixture-of-experts model routes each token through part of the network instead of using every parameter for every token. Poolside also says the model is compact enough for a Mac with 36 GB of RAM and supports a 262,144-token context window.

Those specifications identify the model and its intended hardware range. They do not report memory use, speed, output quality, or chat reliability for Ollama on a particular Mac. The 3-billion-active figure also describes computation inside the model; it is not a 3-billion-parameter memory claim.

Quantization creates another boundary. It stores model values at lower precision to reduce the resources needed to run them, with tradeoffs that depend on the format and implementation. Ollama’s model page lists several Laguna variants, including q4_K_M, q8_0, bf16, and mlx-bf16, so the model name alone does not identify the build a team will load or how much memory it will require.

Ollama v0.32.4 adds the Apple-GPU runtime layer

Ollama’s stable v0.32.4 release, published July 25, says it added Laguna support on Apple GPUs through the MLX engine. MLX is the execution layer Ollama uses here to run the model on Apple hardware. This release claim establishes a supported implementation path; it does not establish identical behavior across model variants, Macs, or interfaces.

The merged Laguna MLX implementation adds model-loading and model-creation paths for Laguna XS 2, XS 2.1, and S 2.1. It handles dense and routed expert layers, mixed quantization, routing, fused projections, and focused tests while staying on maintained MLX operations. Those details explain what Ollama added below the interface layer.

A separate MLX memory-residency commit configures Metal residency after the model weights materialize. It caps resident memory at the smaller of active model memory and the device’s recommended working set, then warns and continues with pageable memory if setup fails. That behavior concerns how loaded weights use memory; it is neither a general speed guarantee nor evidence that a chat response will contain output.

The current warning sits in the chat and template path

Ollama’s model page says reasoning and tool calling use the built-in laguna template. In a chat route, the application sends role-based messages, the template converts that history into the model’s expected input form, the runtime executes the model, and the API returns the result. Runtime support can therefore coexist with an interface failure that leaves the caller without usable content.

The same page says chat works as expected on Linux/CUDA but may return empty output on macOS/Metal. It does not identify affected macOS versions, Apple chips, quantizations, or the frequency of the failure. The page also does not establish a root cause, so the warning cannot support broader claims about every Apple-GPU run or a particular faulty component.

For Mac users, Ollama points to a Linux/CUDA host or /api/generate with "raw": true as alternatives. Raw generation is a different request path: it does not prove that role-based chat, the built-in template, multi-turn history, or tool behavior works on the warned route. It may help a team inspect model output while keeping the chat compatibility question open.

A matched test must show that the required endpoint returns usable work

A useful evaluation starts with an exact candidate rather than “Laguna on a Mac.” Keep the model tag or digest and quantization fixed. Pin the Ollama version, record the Mac model, Apple chip, memory, and macOS version, and identify whether the request uses MLX on Apple hardware. Then choose the interface being evaluated: ollama run or /api/chat with the Laguna template, or /api/generate with raw output.

For chat, require non-empty content that answers a representative coding request, then repeat the same request on fresh and already-loaded sessions. If the intended application uses multiple turns or tools, test those behaviors directly: history must remain coherent, a tool request must be parseable, and the model must use the returned tool result to continue. A single completion from a different endpoint cannot establish that path.

Capture the complete API response and Ollama logs for each run, including any error and completion fields the endpoint returns. Treat an empty result as a failed run even when the request appears to finish. This keeps endpoint behavior visible instead of reducing the outcome to whether the model loaded.

Test raw generation separately if it is useful to the workload. A usable raw result paired with an empty chat result shows only that the two paths behaved differently on that configuration. Our guide to production-shaped model comparison explains why the surrounding runtime and interface must stay fixed when comparing model results.

Evaluate now when the route can remain experimental

A bounded evaluation makes sense when the team wants to measure Laguna’s coding quality, memory use, and latency on one available Mac and can tolerate changing the interface or stopping when chat returns empty output. Keep the result attached to the exact quantization, runtime, hardware backend, and endpoint used. That work can show whether Laguna deserves another review without turning a successful sample into a shared standard.

Wait to standardize when the intended workflow depends on macOS chat, preserved multi-turn history, tool calls, or unattended automation. Revisit the decision after the public warning changes, then rerun the same workload on the required route. A changed page or runtime version is a reason to test again; repeatable non-empty output and correct task behavior provide the evidence for the local decision.

Compatibility is only the immediate issue. Once the route behaves consistently, teams still have to own updates, monitoring, recovery, security, and cost; our article on the open-model production ownership gap covers that broader deployment decision without folding it into this release.

BaristaLabs can help through AI consulting or a focused local model compatibility review. The work compares one coding workload across the exact model, quantization, runtime, hardware backend, and interface path so the team can decide whether the route should remain in evaluation.

Use Ollama v0.32.4 and Laguna XS 2.1 for a bounded Apple-GPU evaluation if that evidence is useful now. Wait to standardize the warned macOS chat route until the exact path repeatedly returns non-empty, correct results for the workload the team intends to run.

Sources

• Ollama v0.32.4 release
• Ollama Laguna XS 2.1 model page
• Poolside: Introducing Laguna XS 2.1
• Ollama Laguna MLX implementation
• Ollama MLX memory-residency commit