The models we tested — and the ones that stayed

Four files, ten ways of working

A model is one file on disk, but the same file can be served in several ways: with reasoning or without, with settings tuned for conversation or for code. This costs no memory — the machine holds one model at a time anyway. That is how four files (about 70 GB in total) power ten profiles.

Model	Writes	Reads in	Context	Sees images	Where it ended up
Gemma 4, 26B (sparse)	200/s	7011/s	262K	yes	the default for everything
Qwen 3.6, 35B (sparse)	132–185/s	4970/s	262K	no	coding and agent work
Gemma 4, 31B (dense)	72/s	2204/s	164K	yes	best Polish in the lineup, documents
Qwen 3.6, 27B (dense)	59–72/s	2100/s	262K	no	tasks demanding precision

The numbers are tokens per second: writing the answer and reading in the input text.

Sparse or dense — the one difference you need to understand

A dense model recomputes all of its parameters for every word. A sparse model divides itself into many specialized experts and activates only a few of them at a time — out of 35 billion parameters, three billion actually work. The effect: it is much faster at the same file size.

That looks like pure gain, but it is not. In the programming test, where the models wrote projects on their own, all the variants took almost identical time — from 3.78 to 3.80 hours for the full set of ten tasks, despite a two-and-a-half-fold difference in writing speed. They reached the goal by different roads: the dense model generates slowly but rarely errs (834 steps), the sparse model generates fast and makes up for it with attempts (1987 steps).

The practical difference lies elsewhere: the dense model uses 39% less context, which matters when working on an existing, large project. The sparse one does more — 44% more tests and 26% more code.

Model compression: what we let go, and what we do not

Models are published at full precision, but for home use you download a compressed version — otherwise nothing would fit. We checked how much that compression really costs in quality.

We ran the same model through a set of tasks (Polish, reasoning, code, logic puzzles) at three compression levels: strong, medium and light. All three passed with no difference in quality. The logic puzzles were solved correctly in every run.

Lighter compression, on the other hand, has a concrete cost: on the dense model it is speed and context at once (moving to noticeably better precision means −25% speed), on the sparse model almost exclusively context. Since quality does not improve and context shrinks — the choice was obvious. The strongly compressed version is what runs in production.

There is one exception worth noting. Gemma models are prepared for compression during training, so they tolerate it exceptionally well. That is one of the reasons they have the best command of our native Polish in the whole lineup.

What dropped out and why

The Polish model (Bielik, 11B). Natural Polish, sound reasoning and code, answers directly without long-winded deliberation. It fell on two things: context ends at 32,768 tokens (a limit of the model itself) and it does not support acceleration through the helper model. In a lineup where everything else stands at 262 thousand tokens of context, it was hard to find a place for it.

The smaller Gemma models (12B). The only ones that see images, video and hear audio, with elegant Polish and sensible results. They stayed out of production because the larger models fit without trouble — and if they fit, there is no reason to go smaller.

The specialized code model (30B). It uses a different tool-calling format from the rest and needs separate preparation. It awaits a quality assessment; its context and memory are already verified.

Reading in follows a different order than writing

Worth separating, because the choice of model depends on what you do with it.

When writing, the card’s memory bandwidth decides — here sparse models with the helper model win (140–200 tokens per second). When reading in, compute power decides and both cards genuinely share the work. The order changes: large dense models come out three times worse here than sparse ones of the same class, while small dense models climb back up because their weights are light.

The practical rule: when the query is mostly material to read (a project review, a long document) — reading in matters. When the question is short and the answer long — writing matters.

Settings can cost more than the choice of model

The most surprising result of this series. The same model, the same file, the same memory — the only difference being the generation settings recommended by the maker for the non-reasoning mode. The cost: 29% of writing speed (132 versus 185 tokens per second).

The mechanism is understandable: those settings change the probability distribution of the next words, so the helper model guesses right less often and the speed-up from speculation melts away. The lesson for anyone tuning such a machine: repetition penalties are more expensive in a configuration with the helper model than in a plain one — when judging output quality, watch the speed at the same time.

---

All numbers from our own measurements: 2 × RTX 5070 Ti 16 GB, one model at a time, measured through the same server we use every day.