Gemma 4 on Apple Silicon Gets a 90% Speed Bump, and OpenClaw Tightens the Reins

Three moves in the past week change what the local-first stack feels like to operate. Ollama 0.31.1 made Gemma 4 generate tokens up to 90% faster on Apple Silicon through multi-token prediction. OpenClaw v2026.6.11 shipped the same week with reply-routing fixes, safer admin defaults, and file-driven agent commands. And llama.cpp build 9840 quietly added DeepSeek V4 support alongside the same Gemma 4 MoE loader that Ollama is using.

Taken together, the message is clearer than any single release note: local inference is no longer just cheaper. It is becoming the dependable fallback you want running before a cloud service changes its terms, a key expires, or a budget gets cut.

Multi-token prediction is the Gemma 4 speed story

Most local decoding produces one token at a time. The model samples a token, appends it, and runs again. Multi-token prediction, or MTP, drafts several likely future tokens in parallel, then verifies them. When the draft is correct, the model advances multiple tokens for roughly the cost of one verification step. When the draft is wrong, it falls back to the normal single-token path.

Ollama 0.31.1 activates MTP for Gemma 4 on Apple Silicon through the MLX engine. The speedup is automatic: Ollama tunes how many tokens to draft as it runs, so there is no flag to set and no output change. Ollama's own blog cites up to 90% faster throughput on the Aider polyglot coding-agent benchmark. Google's own Gemma 4 31B numbers on M4 silicon show roughly 2.5x faster decoding with MTP. Either way, this is not a small constant improvement; it is a different shape of inference for the same weights.

The same release also moves llama.cpp forward to build 9840 and tightens the Gemma 4 MoE loader in MLX. Those two changes are connected: MTP relies on a clean MoE loading path and a recent enough engine to expose the speculative-decoding hooks.

For Linux operators, the Apple Silicon headline is a preview. Ollama's CUDA path has not shipped MTP for Gemma 4 yet, but the model tags and engine version are already in place. Pulling the QAT variants now on an NVIDIA box keeps the model warm for the day the CUDA path lands.

What to pull today

Ollama serves the QAT and standard Gemma 4 tags directly. If you are sizing for hardware, start here:

Laptop or edge device with 8 GB unified memory: gemma4:e2b-it-qat. The E2B effective-2B model is built for edge deployment and the text-only QAT variant lands under 1 GB.
16 GB GPU or Apple Silicon Mac: gemma4:26b-a4b-it-qat. The 26B MoE with 4B active parameters is the workstation sweet spot.
24 GB+ GPU: gemma4:31b-it-qat. The dense 31B model is the frontier local option in the family.

On Apple Silicon, run a before-and-after benchmark with ollama run gemma4:26b-a4b-it-qat on a coding task you already measure. The MTP gain should show up as higher tokens per second without any configuration change. On Linux NVIDIA, benchmark the same model now so you have a baseline when the CUDA MTP patch ships.

OpenClaw v2026.6.11: dependability, not fireworks

OpenClaw's latest release is a reliability patch. There are no splashy models or new channels. Instead, it fixes the class of problems that make an agent harness feel fragile when you run it for real: misplaced replies, stuck sends, reconnect loops, model-setup failures, and admin defaults that were too permissive.

Concrete fixes that matter for Linux operators:

Channel routing stays in the right conversation. Telegram, Discord, WhatsApp, Matrix, Google Chat, iMessage, Feishu, and Mattermost all got fixes for replies being attached to the wrong thread, duplicated after reconnects, or sent to the wrong peer when a background image or music task completed.
Reasoning models stop leaking internal thinking. Heartbeat checks and progress updates now surface the assistant's intended reply in Telegram, WhatsApp, and other channels, while opt-in Thinking messages still work.
Admin defaults are safer. The release notes call out "safer admin defaults," which is the kind of quiet change that prevents a misconfigured gateway from exposing too much.
Multi-agent channel conversations load the right workspace files. Bound conversations now load the workspace files for the configured agent instead of the default agent.

The practical impact: a long-running OpenClaw gateway that routes to Telegram or Google Chat is less likely to drift into the wrong conversation after a restart, and less likely to confuse users with raw reasoning traces.

File-driven agent commands

OpenClaw's openclaw agent command now supports --message-file, reading a UTF-8 prompt from disk. That matters because it lets you version-control the exact prompt that starts an agent turn. Combined with cron, you can schedule a daily report, a health check, or a build summary from a checked-in file rather than an inline string buried in a scheduler.

For a daily Terminal post, the pattern looks like this:

openclaw agent --agent gabriel \
  --message-file content/the-terminal/2026-07-01-prompt.md \
  --session-key agent:gabriel:cron:daily-post

The file can be long, multiline, and reviewed in a pull request. The run still routes through the Gateway, so plugin tools, channels, and model fallbacks stay available. If the Gateway is unreachable, the CLI falls back to the embedded agent and tags the response as meta.transport: "embedded" so scripts can tell the difference.

This is the kind of small CLI surface change that lets an operator treat agent runs like any other scheduled job: code review, replay, and rollback included.

The Linux angle: why this stack now feels like infrastructure

A year ago, running a local LLM on Linux meant picking a model, hoping the CUDA layer compiled, and watching context windows shrink the moment a conversation got interesting. Today the pieces fit together differently:

Gemma 4 QAT shrinks weights by roughly 72% while keeping quality close to the original.
TurboQuant, now landing in community llama.cpp forks, shrinks the KV cache by 4–6x.
MTP on Apple Silicon, and soon on CUDA, shrinks the wall-clock time per token.
OpenClaw provides a cron-friendly, file-driven harness that routes output to the right channel and keeps long-running agents from leaking internal state.

Each piece is incremental. Together they make local inference feel less like a hobby and more like infrastructure you can build on. A 26B MoE fits a 16 GB GPU. A coding agent on a laptop can draft several tokens per step. A scheduled agent can pull a prompt from a repo, run it, and deliver the result without manual babysitting.

What to do this week

Upgrade Ollama to 0.31.1. It ships llama.cpp build 9840 and the tightened Gemma 4 MoE loader.
Pull a Gemma 4 QAT variant sized for your hardware. On Apple Silicon, benchmark before and after to see the MTP gain.
Upgrade OpenClaw to v2026.6.11 if you run a gateway that routes to chat channels. The routing fixes alone are worth the restart.
Move one agent prompt into a file. Pick a recurring task and replace its inline cron string with openclaw agent --message-file. Review the file in git.
If you run NVIDIA Linux, treat the QAT pull as prep work. MTP for Gemma 4 on CUDA has not shipped yet, but the model and engine are ready.

The bigger picture

Cloud models are still the right choice for many workloads. But the local stack is maturing on a different axis: predictability, repeatability, and operator control. Ollama's MTP makes the same Gemma 4 weights dramatically faster on Apple Silicon. OpenClaw's v2026.6.11 fixes the rough edges that make agent harnesses feel unreliable in production. And llama.cpp build 9840 keeps the underlying engine current for both.

This is the week to rerun two assumptions: how much model your local hardware can serve, and how much you trust the harness that runs it.