Gemma 4 26B A4B Runs 2x Faster on Mac — Community MLX Optimization

A tweet said "2x faster." The chart behind it says 130.3%. Both are true, and the gap between them is a good lesson in how lab announcements round community work into headlines.

On September 1, 2026, Google's official @googlegemma account posted: "Running Gemma 4 26B A4B on a Mac just got 2x faster." The credit line pointed at a public leaderboard — mlx.fast, run by Eigen Labs under the YukonResearch banner — where community contributors have spent days shipping incremental MLX kernel optimizations for this exact model. The leaderboard's own graphic, posted two days earlier by developer @pratikg, reads: "Gemma 4 26B A4B now runs 130.3% faster on Mac."

130.3% faster than baseline is a 2.303x multiplier — meaningfully more than "2x," but not the clean number the headline implies, and by the time this leaderboard was checked on September 2, the live figure had already climbed past 131.9%. This is a case where the more precise number is more interesting than the rounded one: it shows a leaderboard that hasn't stopped moving.

Source: Google Gemma / mlx.fast leaderboard

TL;DR

What Actually Happened

The chain of events is simple, even if the numbers took a detour:

1. Eigen Labs, operating the mlx.fast leaderboard under the YukonResearch identity, opened a challenge: make Gemma 4 26B A4B run faster on Apple Silicon via MLX, Apple's own machine learning framework.
2. Community developers submitted pull requests against a public scoring engine (mlxfast-gemma4-26b-a4b-engine), each targeting kernel-level wins. Scoring combines prefill and decode gains as prefill^0.25 · decode^0.75 — decode speed carries three-quarters of the score, since that's what a user actually waits on token-by-token.
3. On August 30, 2026, developer @pratikg posted a leaderboard screenshot crediting incremental contributions — including one from a contributor identified as jacklightChen reaching roughly 99.8% of a milestone, with a further contributor adding another 0.33% on top.
4. By September 1, the cumulative gain hit 130.3% over the launch baseline. Google's own Gemma account reposted the story with the simpler "2x faster" framing.
5. The leaderboard kept moving. Checked again on September 2, the top score had reached 131.9%, with decode speeds around 573 tokens/second and prefill around 7,000+ tokens/second on the reference Mac hardware, measured after what the leaderboard calls a "thermal cool gate" — letting the machine cool between runs so results aren't inflated by a still-warm chip.

Across the roughly five-day window (Aug 27–Sept 2), the leaderboard logged 88 solvers and 99 promoted submissions — a genuinely high-velocity community effort, not a single lab announcement.

"2x" vs "130.3%" — Why Both Numbers Are in This Post

This is worth sitting with because it's a pattern that shows up constantly in AI announcements: a precise community-generated number gets rounded into a punchier headline.

• 130.3% is a relative increase — the model runs at 2.303x its baseline speed.
• "2x faster" rounds that down for readability, which is defensible but loses precision — and by the time Google posted it, the actual leaderboard number had already moved past the 130% mark it was citing.
• Neither number is wrong. They're measuring the same underlying leaderboard at slightly different moments, with different appetite for precision.

The practical lesson: when a lab account cites a community leaderboard, check the leaderboard, not just the tweet. Leaderboards move continuously; screenshots are already stale the moment they're posted.

What Does "A4B" Actually Mean?

Gemma 4 26B A4B is a Mixture-of-Experts (MoE) model. The name follows the same "AxB" convention that DeepSeek and Qwen use for their MoE releases:

• 26B = total parameters stored on disk — the full model, including every expert.
• A4B = active parameters per token — the subset of the network that actually runs during a single forward pass.

Per Google's own Gemma 4 model card, the 26B-A4B variant routes through 128 fine-grained experts with top-8 routing per token, activating roughly 3.88 billion parameters at inference time. The practical effect: a model with the storage footprint of a 26B dense model runs at close to the speed of a 4B dense model, because most of the network stays idle for any given token.

This is why Gemma 4 26B A4B is a good target for Mac inference in the first place — the active-parameter count is small enough that unified memory bandwidth, not sheer compute, becomes the main bottleneck, and unified memory bandwidth is exactly where MLX kernel tuning pays off.

What Is MLX, and Why Does It Matter Here?

MLX is Apple's open-source array and machine learning framework, purpose-built around Apple Silicon's unified memory architecture. It matters for this story specifically because Mac inference optimization is not the same problem as CUDA optimization:

• Nvidia GPUs have dedicated VRAM, physically separate from system RAM. CUDA kernels are tuned around moving data across that boundary efficiently.
• Apple Silicon has no discrete GPU — CPU and GPU share one unified memory pool. There's no PCIe transfer to hide latency behind; the bottleneck is memory bandwidth and how efficiently a kernel reads/reuses weight blocks already sitting in that shared pool.

That distinction is exactly why a leaderboard specifically for MLX kernels exists, separate from general LLM speed leaderboards. A kernel optimized for CUDA's memory model does not automatically transfer to MLX, and vice versa. The MLX framework exposes low-level primitives (fused attention, custom quantized matmuls, lazy computation graphs) that let contributors target Apple Silicon's actual bottlenecks directly — which is precisely the surface area 88 solvers spent five days working on.

For a closely related example of this same mechanism, Ollama shipped its own MLX kernel contribution back in June 2026 specifically for small-batch verification during multi-token prediction on Gemma 4 — reporting a 2x–2.5x speedup on the model's largest matmuls for that batch shape by reading and reusing each weight block once per batch rather than per token. That's the class of optimization this leaderboard's community submissions are almost certainly built from: kernel fusion and reduced redundant memory traffic, not a single architectural rewrite.

Honestly: what exactly changed this time?

The mlx.fast leaderboard, true to its "leaderboard" format, doesn't ship one unified writeup explaining the winning techniques — it's 99 promoted pull requests from 88 different contributors, each solving a narrow slice of the problem. That's the nature of open, incremental optimization: transparent in outcome (you can see the score climb), opaque in a single mechanism (there isn't one). Based on how comparable community MLX efforts have worked — including Ollama's own contribution above — the likely ingredients are kernel fusion for attention and expert-routing steps, tuned quantization/memory-layout choices for Gemma 4's MoE structure, and better small-batch verification kernels. Anyone wanting the ground truth can read the individual merged PRs against the mlxfast-gemma4-26b-a4b-engine repository directly; a leaderboard promise not fully explained in prose is still verifiable in code.

How Fast Does This Community Effort Actually Get You?

Reported figures from the leaderboard's later runs, measured after thermal-cooling gates to avoid inflated warm-chip numbers:

For context against other Mac benchmarks explainx.ai has covered: Ollama's MTP work on Gemma 4 12B on an M5 Max went from 50.2 to 95.0 tok/s on the Aider coding benchmark — a different model size and a different benchmark methodology than mlx.fast's, so the numbers aren't directly comparable, but both point the same direction: MLX-specific kernel work delivers real, repeated wins on Apple Silicon, model after model.

How Does Open-Source Performance Optimization Actually Happen? (The Practitioner Angle)

This story is a better example of "how does open-source speed work actually get done" than most lab benchmark posts, because you can watch it happen in near-real time:

• No single hero commit. 99 promoted submissions across 88 people means the gain is the sum of many small, independently reviewed wins — not one breakthrough paper.
• AI-assisted kernel writing is now normal. Contributors on comparable mlx.fast challenges (per @pratikg's public commentary on a separate Qwen 3.8 run on the same leaderboard) report using Claude, GPT, Gemini, and other frontier models to help write and iterate MLX kernels — meaning the tools explainx.ai covers for agentic coding are now also the tools people use to optimize the models those agents run on.
• Competitive leaderboards compress iteration time. A public score that updates within hours creates a feedback loop absent from closed internal benchmarking — you know within a day whether your kernel actually beat the field.
• Verification, not trust, backs each score. An "official run" on mlx.fast measures eight prompts in one batch on real Mac hardware in public CI — not a self-reported number — which is what makes 130.3% a load-bearing figure rather than marketing copy.

For a practitioner audience, the lesson isn't just "Gemma 4 got faster." It's that the class of optimization work that used to require an internal ML infra team is now something a public leaderboard and a weekend of contributor time can meaningfully move — a dynamic increasingly common across the local-inference ecosystem, from TurboFieldfare's SSD-streaming MoE engine to community GGUF quantization work.

"How Much RAM Do I Need on a Mac to Run This?"

This is the exact question visible in the original thread's replies, and it deserves a direct answer rather than a deflection to "it depends."

A few things to know before buying hardware for this specifically:

• macOS reserves memory for itself. Practitioners generally report only 70–80% of total unified memory is realistically usable for model weights once the OS, browser, and background apps take their share — see explainx.ai's MacBook vs. dedicated GPU comparison for the iogpu.wired_limit_mb tuning knob that controls this.
• A 16GB Mac is not a comfortable fit. You can technically squeeze a 4-bit quant onto 16GB, but you'll have almost no headroom for context length, and any other memory-hungry app running alongside will force swapping.
• If you're RAM-constrained, look at expert-streaming approaches instead of shrinking the model further. Projects like TurboFieldfare stream MoE experts from SSD and run this exact model in roughly 2GB of RAM on an 8GB Mac — much slower (5–6 tok/s on an M2 Air) but workable for offline or privacy-sensitive use where speed isn't the priority.
• More RAM helps even beyond the minimum. Unused RAM becomes disk and page cache, which measurably improves throughput on memory-bound MoE inference — a pattern also documented in the TurboFieldfare coverage above.

Local Mac Inference vs. a Hosted API: The Real Tradeoff

Even after a 130%+ speedup, running Gemma 4 26B A4B on a Mac and calling a hosted frontier API are solving different problems:

The honest takeaway: this speedup makes local Gemma 4 26B A4B a genuinely reasonable choice for privacy-sensitive workloads, offline development, or cost control at high request volume on a Mac you already own. It does not make a Mac Studio a faster alternative to a frontier hosted API for latency-critical or highest-capability work — those remain different tools for different jobs, and the gap is about model ceiling and concurrency, not raw tokens-per-second on one request.

Getting Started

1. Check your RAM tier against the table above before downloading weights.
2. Pull an MLX-native quant — the MLX community on Hugging Face maintains ready-to-run Gemma 4 26B-A4B builds at 4-bit and higher precisions.
3. Watch the mlx.fast leaderboard if you want the fastest possible build — kernel improvements land continuously, and a build from last week may already be measurably behind today's leader.
4. If you're RAM-constrained, evaluate TurboFieldfare's SSD-streaming approach instead of forcing a too-large quant into too little memory.
5. Benchmark on your own workload. Leaderboard decode/prefill numbers are measured on reference hardware under controlled thermal conditions — your Mac, your context length, and your prompt mix will move the real number.

Honest Limitations

• The leaderboard number keeps changing. Anything cited here is a snapshot; check mlx.fast directly for the current figure.
• No single technical writeup exists for exactly which kernel changes drove the gain — it's 99 separate merged pull requests, not one documented mechanism.
• "2x faster" is Google's rounding, not an independently audited multiplier — the leaderboard's own number is more precise and already moved past it by the next day.
• Decode/prefill numbers are measured on reference Mac hardware in the leaderboard's CI, not on arbitrary consumer configurations — expect variance on your own machine.
• Faster inference does not mean smarter output. This entire story is about tokens-per-second, not model quality — Gemma 4 26B A4B's reasoning capability is unchanged by any of this work.

Related Reading

• Ollama 0.31: Gemma 4 ~90% Faster on Apple Silicon With Multi-Token Prediction
• TurboFieldfare: Gemma 4 26B in ~2GB RAM on Apple Silicon
• Qwen 3.6 27B Local Dev Guide: llama.cpp, OpenCode, and Why Dense Beats MoE
• MacBook vs Dedicated GPU for Local LLMs
• What Is llama.cpp?
• What Is AI Model Quantization? Complete Guide
• Gemma 4 12B: Multimodal Local AI Guide
• Gemma 4 July 2026 Updates: Flash Attention, Tool Calling

Sources

• Google Gemma on X — "Running Gemma 4 26B A4B on a Mac just got 2x faster" (September 1, 2026)
• Pratik Gandhi (@pratikg) on X — mlx.fast leaderboard screenshot
• The Gemma 4 MLX Challenge — mlx.fast leaderboard
• Gemma 4 model card — Google AI for Developers
• Run Gemma with MLX — Google AI for Developers

Figures in this post — the 130.3% and 131.9% leaderboard readings, the 88 solvers and 99 promoted submissions, and the decode/prefill numbers — reflect the mlx.fast leaderboard as observed around September 1–2, 2026. The leaderboard updates continuously; check it directly for the current record.