Ornith-1.5-35B-A3B vs Ornith-1.5-9B on a 16GB RTX 5060 Ti
Choosing between a small dense model and a larger mixture of experts from the same family is the most common decision a 16GB card forces on you, and it's usually made on the wrong intuition. The intuition says that the small model is the fast one and the big one is the smart one. On my RTX 5060 Ti the Ornith family breaks that intuition in an instructive way: the 35B mixture of experts, with roughly three billion parameters active per token, decodes at about 112 tokens per second, while the dense 9B decodes at about 44. The MoE is bigger in memory and smaller in work per token. This comparison puts the two side by side across everything I measured in a 45-hour campaign and its follow-ups: single-answer coding with and without reasoning, real bug fixes in an agent loop, waiting time, memory, context and energy. Same family, same card, same flags, every comparison paired on the same items. What comes out is less a ranking than a map of when each model is the right tool.
Note
The bench: RTX 5060 Ti 16GB (Blackwell, 180 W limit) on PCIe Gen3 x8, Ryzen 5 4500 with 6 cores, 32GB of DDR4 at 3,600 MT/s for the October campaign and 2,133 MT/s for the September residency and context tests, Debian 13, NVIDIA driver 615.71.09 with CUDA 13.4, llama.cpp at commit 391fac1 with --fit off, a q4_0 KV cache and one slot. All the numbers you see here come from the benchmark procedure described in detail in how my harness measures local models.
The two models as they run on the card
Ornith-1.5-9B runs at Q8_0, an 8-bit quantization close to the original weights. At a 32,768-token context it occupies 8,716 MiB, loads in about 10 seconds and draws 21 W at idle in my older residency measurement; it loads 262,144 tokens of context with almost 4 GB of VRAM to spare. Ornith-1.5-35B-A3B runs at IQ3_XXS, a 3-bit quantization, because at higher precision it wouldn't fit. At its production context of 131,072 tokens it occupies 15,246 MiB, loads cold in 17.1 seconds and draws 16 W at idle.
Both families have earlier coverage on this blog: the 9B lineage is the subject of the Ornith vs Qwable comparison, and the 35B mixture of experts builds on the architecture I took apart in the engineering teardown of the Qwen3.6 35B MoE.
The comparison at a glance
| Test | Ornith-1.5-35B-A3B | Ornith-1.5-9B | Paired verdict |
|---|---|---|---|
| Coding, reasoning off, 50 problems | 19 | 8 | 14 to 3, p = 0.013, not significant after correction |
| Coding, reasoning on, within 5 min | 26 | 10 | 16 to 0, significant after correction |
| False-premise questions, 14 | 11 | 10 | too few items |
| Agentic bug fixes, 15 episodes | 10 correct, 3 illusory | 5 correct, 7 illusory | descriptive, five task families |
| Median wait, reasoning off | 2.7 s | 3.8 s | 24 paired probes each |
| Median wait, reasoning on | 8.7 s | 17.9 s | 24 paired probes each |
| Decode speed | about 112 t/s | about 44 t/s | engine counter |
| VRAM in use | 15,246 MiB at 131K | 8,716 MiB at 32K | measured |
The MoE wins every capability test in direction and the reasoning-on coding test with statistical confidence. The 9B wins on memory, and that isn't a small thing on a 16GB card.
To have a family-level comparison like this done on your own tasks, my hub on AI infrastructure for companies describes how I approach self-hosted model selection.
Coding: the gap opens when the models think
Fifty Python problems with 560 executable assertions: encoding traps, daylight saving arithmetic, Easter-based holidays, checksum validation, SQL window functions, bug fixes with misleading comments. Solved means every assertion passes.
Without reasoning, the MoE solved 19 and the 9B 8. The MoE solved 14 problems the 9B missed, the 9B 3 the MoE missed. On its own that would be convincing (p = 0.013), but it was one of sixty exploratory comparisons in the campaign, and after correcting for that many tests it doesn't hold. I report it as a direction, not as a result.
With reasoning on and five minutes per problem, the MoE solved 26 and the 9B 10. The MoE won 16 problems, the 9B none, and this one survives the correction. Reasoning helped both models, but it helped the MoE much more, because it thinks at more than twice the speed and fits its thinking into the time limit. The 9B left 26 answers unfinished at the ten-minute cap; the MoE left 5.
There is a quieter result in the failures. Without reasoning, both models fail almost always silently: they return complete, plausible code that only the tests reveal as wrong. That was true for 31 of 31 failures of the MoE and 41 of 42 of the 9B. Neither model, without thinking, tells you when it doesn't know.
Agentic bug fixes: the 9B convinces itself too easily
Five small broken projects, a bug report and a visible test suite each, file and shell tools, reasoning on, three runs per project. A hidden oracle the agent never sees compares the fix with a reference on random inputs.
The MoE delivered 10 correct fixes, 3 illusory and 2 failures. The 9B delivered 5 correct fixes, 7 illusory and 3 failures. An illusory fix passes the visible tests and is wrong. When the 9B declared success, it was wrong 7 times out of 12. When the MoE declared success, it was wrong 3 times out of 13.
The illusory fixes share signatures predicted before the run. On one project, the obvious fix ignores a legal-hold rule written in the README: the 9B shipped that exact fix in all three runs, the MoE in two of three. On another, the obvious fix counts characters instead of bytes. Five task families are too few for a statistical winner, so I report these numbers as the shape of the behaviour, not as a test, and the shape is consistent with everything else: the bigger model more often changed everything the specification required, not only what the visible tests pointed at.
A small model in an agent loop is fast at reaching green. Whether green means correct is a separate question, and on these tasks the 9B usually got the first part right and the second part wrong.
Waiting time: the bigger model answers sooner
On eight everyday probes, with three repetitions each and the prompt cache off, the MoE answered sooner than the 9B in both modes.
| Probe | Ornith 35B, off then on | Ornith 9B, off then on |
|---|---|---|
| Chat question | 1.2 s, then 5.3 s | 3.5 s, then 14.2 s |
| One shell command | 1.7 s, then 12.4 s | 3.8 s, then 59.5 s |
| Code review | 6.1 s, then 41.3 s | 20.8 s, then 110.5 s |
| Long prompt | 5.4 s, then 8.7 s | 4.5 s, then 12.8 s |
The only probe where the 9B is faster is the long prompt without reasoning, where its dense prefill on a smaller network edges ahead. Everywhere else the MoE's higher decode speed wins, and with reasoning on the gap grows because the 9B thinks for more tokens at a lower speed: on the shell command it wrote a median of 2,604 tokens against 1,387 for the MoE.
Memory and context: the 9B's advantage
On a 16GB card memory is the constraint that decides what else you can do. The 9B at 8-bit leaves about seven gigabytes free at a 32K context, enough to keep an embedding model or a second small service on the same card. The MoE leaves about one gigabyte.
Context works the same way. The 9B loads contexts beyond 262,144 tokens with memory to spare; the MoE tops out at 131,072. On a long-context retrieval test at 8K, 32K and 128K both held up: the MoE passed 11 of 12 probes, the 9B 11 of 12 in its own measurement, with a single miss each. Above 131K tokens in one prompt, only the 9B of the two can load the request, though my reading test stops at 128K, so how well it reads past that point is unmeasured.
Energy per solved task
Because it does less work per token and writes fewer tokens when it thinks, the MoE is consistently cheaper per solved task.
| Kind of task | Ornith 35B, Wh per solved | Ornith 9B, Wh per solved |
|---|---|---|
| Coding, reasoning off | 0.5 | 4.6 |
| Coding, reasoning on | 17.9 | 86.5 |
| Agentic bug fix | 19.4 | 133.2 |
| False-premise question | 7.6 | 11.9 |
At my marginal electricity price these are fractions of a cent per task, so energy won't decide your choice, but the ratio corrects an impression: a 9B that fails more often and thinks longer ends up spending more per solved task.
Italian
On mirrored question sets, where the same item exists in Italian and English, both models lose ground in Italian. The 9B lost between 14 and 21 points across three measurement conditions, the MoE between 7 and 14 across two. The samples are small, fourteen pairs per condition, but the direction is the same as for most local models I have measured: Italian is harder, and the bigger model loses less.
False premises and refusals
On fourteen questions that each carry a false premise, both models behaved well: the MoE corrected 11 premises and the 9B 10, and neither went along with a false premise once. Their failures were answers that didn't finish within ten minutes, three for the 9B and two for the MoE, and one off-topic reply each. With fourteen items the comparison is underpowered, and what the data show is that both models in this family push back on a wrong assumption when they finish their answer.
This is worth stating because it isn't true of every 9B model. A different 9B I measured in the same campaign went along with the false premise six times out of fourteen. In this family the small model inherits the habit of challenging the question, which is a good sign for its use as an assistant even where its raw capability is lower.
Reproducing the comparison on your own card
The configuration is the same for both models except for the file and the quantization, and that's the whole idea of a family comparison. With the flags pinned, a fair test on your own prompts looks like this:
# Dense 9B: leaves memory free for other services.
llama-server -m Ornith-1.5-9B-Q8_0.gguf -ngl 99 -c 32768 -fa on \
--cache-type-k q4_0 --cache-type-v q4_0 -b 512 -ub 256 -np 1 --fit off
# 35B mixture of experts: takes almost the whole card.
llama-server -m Ornith-1.5-35B-A3B-IQ3_XXS.gguf -ngl 99 -c 131072 -fa on \
--cache-type-k q4_0 --cache-type-v q4_0 -b 512 -ub 256 -np 1 --fit offRun the same set of prompts against each, one slot, prompt cache off when you time them, and compare the answers prompt by prompt; averages hide the differences. If you test with reasoning on, give both the same token budget and the same time limit, because the 9B will need more of both. If you test agentic workflows, add a check the agent can't see; on these tasks it's the difference between counting the 9B's fixes and counting its correct ones.
Problem by problem
Without reasoning the MoE solved fourteen problems the 9B missed: text decoding with mixed encodings, resource allocation, best-path search, a token bucket, a sliding median over 200,000 elements, bracket validation, JSON pointers, HTTP range parsing, flattening nested structures, bill splitting, Roman numerals, bit counting on 64-bit integers, an exact determinant and session grouping. The 9B solved three the MoE missed: JavaScript-style slicing, a SQL report with window functions and the nth unique permutation.
With reasoning on, within the ten-minute cap, the MoE solved nineteen problems the 9B didn't and the 9B none that the MoE missed. The 9B's reasoning helps it, from 8 to 12 solved, but every problem it gains the MoE also solves.
| Mode | Ornith-1.5-35B-A3B (problems) | Ornith-1.5-9B (problems) |
|---|---|---|
| Reasoning on, 2 min | 18 | 5 |
| Reasoning on, 5 min | 26 | 10 |
| Reasoning on, 10 min | 31 | 12 |
The curve shows speed turning into capability. At every time limit the MoE is ahead, and the gap widens as the limit grows, because the MoE keeps finishing problems while the 9B runs out of time on long thoughts.
Agentic results, task by task
- Hardware
- RTX 5060 Ti 16GB, 180 W, PCIe Gen3 x8; Ryzen 5 4500; 32GB DDR4-3600
- OS
- Debian 13, NVIDIA driver 615.71.09, CUDA 13.4
- Software
- llama.cpp 391fac1, harness 0.4.0, --fit off, 65,536-token context, one slot, q4_0 KV cache, reasoning on, temperature 0.4, min-p 0.05, agent loop, seven file and shell tools, 6,000 tokens/turn, hidden differential oracle, 40 to 80 trials per task
Method: Each task run three times with reasoning on, one seed per task and repetition; correct fixes counted when the visible suite passes and the hidden oracle reports zero disagreements.
Results (fixes, higher is better)
On shiftpay the 9B produced two illusory fixes that grouped shifts by date before merging them, disagreeing with the reference on 57 of 60 trials, and spent over 3,000 seconds on one of them. On snapkeep all three of its fixes carried the predicted lazy signature, 47 of 80. The agent loop also shows a difference in stamina: the 9B needed 49 automatic recoveries from empty turns across fifteen episodes and hit the per-turn token cap on 10% of its turns, the MoE needed 35 and hit it on 13%.
Yes-or-no answers
| Check | Ornith-1.5-35B-A3B | Ornith-1.5-9B |
|---|---|---|
| Leaves room on the card for another service | No, about 1 GB free | Yes, about 7 GB free |
| Loads more than 131K tokens of context | No | Yes |
| Decodes above 100 tokens per second | Yes | No, 44 |
| Solves 20 or more of 50 problems with reasoning in 5 min | Yes, 26 | No, 10 |
| Most green agentic fixes are correct | Yes, 10 of 13 | No, 5 of 12 |
| Never accepts a false premise | Yes | Yes |
| Italian as good as English on mirrored items | No | No |
Tip
If you want both models available on one 16GB card, keep the 9B resident for everyday requests and long contexts, and load the 35B only for sessions that need reasoning: a cold load of the 35B took 17 seconds on my card, and the memory headroom of the 9B costs nothing.
Which one should you run?
For most work on a 16GB card, the 35B mixture of experts is the better choice in this family: it solves more, answers sooner, ships fewer illusory fixes and costs less energy per solved task. The paired test confirms the gap on coding with reasoning, the other tests agree in direction.
The 9B is the right choice in three specific cases. When you need the card for something else at the same time, because it leaves seven gigabytes free. When you need more than 131K tokens of context in a single prompt. And when you need a model to run on a smaller card altogether, because at 8,716 MiB it fits where the MoE doesn't.
On a mixture of experts, parameter count says little about speed. The MoE carries 35 billion parameters in memory and moves about three billion per token, which is why it's faster than a dense model a quarter of its size. The configuration I used for every number here is in the recommended strategies for local LLMs on a 16GB card, and the cost of reasoning on both models is analysed in the reasoning tax article. The weights are on the official Ornith-1.5-35B-A3B GGUF page on Hugging Face.
Within the same family, on the same card, the bigger model is the faster one and the more careful one, and the smaller one keeps the card free for everything else. That choice is cleaner than the usual "speed versus quality", and it's the one I would put in front of anyone deciding between them. If you are choosing between model sizes for a team and want the decision based on your own tasks, you can describe the case in the free quote form: two minutes, and I tell you upfront whether it fits what I do.