Bonsai 27B vs Gemma 4 31B on a Mac: which local model to run

Bonsai 27B vs Gemma 4 31B on a Mac: which local model to run

Two models sat loaded in the same copy of LM Studio this week, and one of them was a fifth the size of the other. The small one answered faster, held more context in reserve, and still got the hard questions right. On paper that should settle the argument. It does not, and the reason is the thing benchmarks rarely show: what each model does when you ask it to simply write. We ran Bonsai 27B, PrismML’s 1-bit build, head to head against Gemma 4 31B QAT, the model that already drives our daily work, on a single 48 GB M4 Pro studio test machine. Same prompts, same test setup, one loaded after the other where memory demanded it.

Both are dense models. Bonsai is a 3.80 GB file at 1.128 bits per weight, published under Apache 2.0 in the Bonsai-27B-gguf repository on Hugging Face. Gemma 4 31B QAT is an 18.85 GB quantization-aware-trained build that we run at a 64K context. We covered the Bonsai internals in our 1-bit teardown, and Gemma against its nearest rival in Gemma 4 31B vs Qwen 3.5 27B. This piece is about which one to reach for.

How much faster is Bonsai 27B than Gemma 4 31B?

Speed is the cleanest result in the whole test. Across five prompts covering arithmetic, logic, instruction following, coding, and a short explanation, Bonsai generated at a mean of 27.2 tokens per second on the Metal path. Gemma managed 11.8. That is a 2.3x gap, and it held on every prompt rather than swinging around.

Bar chart comparing generation speed, Bonsai 27B at 27.2 tokens per second against Gemma 4 31B at 11.8 tokens per second
Mean generation speed across five prompts, Bonsai 27B 1-bit against Gemma 4 31B QAT, same 48 GB M4 Pro, July 2026.

The memory story runs the same direction. Bonsai loads in 8.25 seconds and holds a 100K-token context inside about 11.6 GB. Gemma occupies 18.85 GB before you send it anything. On a 48 GB machine that difference decides how much room is left for everything else you have open. If raw throughput and a light footprint were the only axes, this article would end here with a one-word answer.

MeasurementBonsai 27B 1-bitGemma 4 31B QAT
Mean generation speed27.2 tok/s11.8 tok/s
File size on disk3.80 GB18.85 GB
Tool call accuracy (3 cases)3 of 3, valid JSON3 of 3, valid JSON
Time to emit a tool call4 to 7 s6 to 8 s
Timed 250-word draft251 words in 100 s245 words in 227 s
Reasoning share of output79 to 99%79 to 89%

Source: StrideNote hands-on testing on a 48 GB M4 Pro, July 2026.

Which model is better for tool calling and agents?

We gave each model a single weather function and three requests: two that clearly needed the tool, and one that clearly did not. Both models went three for three. Each called the function with correct arguments when the question demanded it, produced valid JSON every time, and correctly declined to call anything on the question that asked for a direct answer. On tool-calling correctness there is nothing to separate them.

Latency gives Bonsai a small edge. It emitted a tool call in 4 to 7 seconds against Gemma’s 6 to 8. In an agent loop, where each step waits on the last, that difference compounds. Against that, Bonsai carries a real hazard for agent work. On one of our short prompts we capped the response at 1,600 tokens, and Bonsai spent the entire budget thinking and returned an empty answer, with a finish reason of “length”. The model had not failed in the usual sense. It simply had not stopped reasoning before the ceiling arrived. A step that silently returns nothing is worse for an agent than a slow step, because the loop has nothing to act on and no error to catch.

There is also the matter of context and fit. Our coding agents run against system prompts measured in tens of thousands of tokens, and Gemma already sits in that slot at 64K, wired into the stack we described in LM Studio vs Ollama on Mac. Bonsai can hold a far larger window in principle, but we tested it at 4K, and moving it up to agent-scale context erases part of the memory advantage that makes it attractive. For sustained agent work, Gemma is the safer default. Bonsai suits a narrow agent role: self-contained reasoning steps where you control the token budget and set it high.

Can a 1-bit model write as well as Gemma 4 31B?

This is where we expected Bonsai to fall apart, and where the test corrected us. We gave both models the same brief: a 220 to 260 word article opening for startup founders, with a concrete hook, varied sentence length, and no bullet points or em dashes.

Our first run capped output at 4,000 tokens, and both models returned empty. Each spent the whole budget on hidden reasoning before writing a word. That is the single most important operating fact about this class of model. Raising the ceiling to 12,000 tokens fixed it for both. Bonsai then produced 251 words in 100 seconds. It spent 2,249 tokens thinking before the first word landed. Gemma produced 245 words in 227 seconds after 2,281 reasoning tokens. Neither used a bullet or an em dash, so both followed the format.

On the prose itself the gap is narrow. Gemma opened on a live investor demo hitting a rate limit, with a clean narrative arc and a vivid beat when the room goes quiet. Bonsai opened on a two in the morning billing alert and wrote in punchier, more direct sentences. Gemma reads slightly more polished. Bonsai reads slightly more urgent. What separates them for our purposes is not craft but hygiene: Bonsai’s draft included a construction our own style rules ban, the “it is not about X, it is about Y” pivot, and leaned on a three-item list where one specific claim would do. Gemma’s draft carried fewer of those tells and needed less scrubbing. Both would still get an edit before publishing.

The headline correction is worth stating plainly. Given enough token budget, Bonsai writes at a quality close to Gemma and does it in under half the wall-clock time. Its earlier empty answer was a budget artifact, not a ceiling on what it can produce.

When should you run Bonsai instead of Gemma 4 31B?

The two models sort into clear roles. Gemma 4 31B is the reliable generalist. It writes visible prose on the first try, never returned an empty answer in our runs, and already anchors the daily stack, so nothing new has to be wired up. It is the model to keep loaded when you do not know what the next task will be.

Bonsai 27B is the fast specialist. It answers hard, self-contained questions at more than double Gemma’s speed from a fifth of the memory, which is exactly the profile you want when you are running a model on a laptop with other work open, or reaching for a quick reasoning pass rather than a long session. The condition attached to it is firm: give it a generous token budget, or it returns nothing. Cap it low and you get silence. Give it room and you get a strong answer, fast. Which model earns the RAM depends less on the leaderboard than on the job, a point we made in our guide to picking a local model for your RAM.

The wider signal is that a 3.80 GB file now trades blows with an 18.85 GB one across speed, tool calling, and even writing. It loses clearly only on the predictability that comes from an unbounded output channel. PrismML’s stealth-exit claim, reported when the lab first showed its 1-bit family, was that binarised weights could hold their own against conventional builds. On a single Mac, across a working week of tests, that claim mostly held.

Share this