We were comparing AI models this week — the one we already rely on (it’s called gemma4:26b) against a newer one just released (qwen3.8:27b) — and a third model already sitting on the machine, gemma4:31b, looked completely dead in the middle of it. Every request to it just hung. Not slow. Nothing came back at all, for ten minutes at a time.
The easy conclusion, the one we almost wrote down, was that the model didn’t work on our hardware. Some models just don’t run well on some machines. Fine, move on.
It wasn’t dead. It was working the entire time, at about 1/400th of its normal speed, because of a setting nobody had ever actually chosen.
We only found that out by watching it instead of just waiting for it. A monitored attempt finally came back after 94 seconds — and the whole time, the machine’s processor was working flat out, as hard as it possibly could. That’s not what a stuck, dead process looks like. A stuck process sits idle. This one was straining.
For comparison: the model we already trust, asked the exact same question on the exact same machine, answers in under a second. Same size, roughly — the slow one is only about a quarter bigger. A quarter bigger does not explain four hundred times slower. Something else was going on.
It took one guess to find it. We told the model, explicitly, to stop preparing for a huge conversation and only prepare for a short one. Its speed jumped nearly a hundred times over, instantly.
Here’s the mechanism, in plain terms: before an AI model answers anything, it has to set aside working memory for the conversation — room to “hold” everything that’s been said, up to some maximum length. Nobody had ever told our system how much room to set aside by default. So it guessed, and because our machine has a lot of memory available, it guessed enormous: room for a conversation hundreds of thousands of words long, held in reserve before a single word was typed, on every single request, no matter how short.
For most of our models, that oversized reservation is just wasteful — a bit of wasted memory, no real harm. For this one particular model, it was catastrophic. Something about how it’s built means that setting aside that much room isn’t just wasteful, it’s crushing — and it pays that cost from the very first word, on every single question, whether the question is one sentence or ten pages.
The part worth sitting with isn’t the bug. It’s that the model doing our actual daily work — the one real people use every day — never showed a single symptom of it. It handles the oversized reservation just fine. This had been quietly true the entire time that system was live, and nobody could have known, short of a different model happening to react badly enough to finally look broken.
That’s the kind of mistake that should worry you more than the ones that crash. A crash announces itself. This kind just quietly costs you, forever, until something unrelated finally makes you go looking.
The fix was one line of configuration: tell it explicitly how much room to reserve, instead of letting it guess. Nothing else changed. The model that looked dead now runs at a normal, healthy speed. The one that was already fine is exactly as fine as before. We double-checked properly rather than trusting the first lucky guess — tested it across five different settings, and the pattern held up cleanly: fine, fine, fine, fine, then a cliff, right at the point where nobody had set a limit. Not a slow decline. A wall.
With that sorted, we could finally answer the original question fairly: is gemma4:26b, the model we’ve built this whole project around, still the right one, now that qwen3.8:27b exists? Yes, on the measure that matters most day to day — it answers faster, in fewer words, than everything else we tested, including models specifically built to be the “fast” option. The newer competitor is genuinely better at one thing: it caught more real issues in a code-review task we ran it against. But it took six to seven times longer to do it. Neither model wins outright. One is quicker, one is more thorough, and now we know that by measurement instead of by guessing — which was the entire point of running the comparison in the first place.
None of this took special tools. It took refusing to accept “it must be broken” as an answer, and checking instead.
The full experiment records, including the raw numbers behind every figure above, are public: exp_023 and exp_025. A related, smaller test on how these models handle large documents is exp_026.