Qwen3.8-27B vs Ornith-1.5-35B-A3B on a 16GB RTX 5060 Ti

For several weeks my 16GB RTX 5060 Ti has served exactly two models, swapped on demand by a model loader: Qwen3.8-27B in the GSQ-RCO build with its multi-token prediction head, and Ornith-1.5-35B-A3B, a mixture of experts with about three billion parameters active per token. I chose them because each one won something the other didn't, and I wanted to know whether that impression survived a proper measurement. It did, with more nuance than I expected. This comparison is the summary of a 45-hour campaign of 645 measured tasks, plus a set of follow-up measurements on latency, context and memory, all run on the same card with every server flag pinned and every comparison paired on the same items. It's written as the story of that decision, because the answer isn't "model A is better" but "model A for this, model B for that", and the numbers that justify each half are different.

The two contenders, as they run on the card

Qwen3.8-27B is a dense model released by Alibaba on Hugging Face in August 2026 under Apache 2.0, with a native context of 262,144 tokens according to its model card. The build I use is the GSQ-RCO quantization at about 3.5 bits, which ships with a speculative decoding head; with that head enabled it decodes at about 57 tokens per second on this card. Ornith-1.5-35B-A3B is a mixture of experts quantized at IQ3_XXS; because only a small slice of its parameters works on each token, it decodes at about 112 tokens per second.

Both run with a 131,072-token context and a 4-bit KV cache, both fill the card: 15,450 MiB for the 27B with its MTP head and 15,246 MiB for the 35B, out of 16,311. Each loads cold in 14 to 17 seconds, and switching between them costs 9.6 seconds. At idle with the model resident, each draws 15 to 16 W at the card.

Two models that each fill the card can't be compared by memory or idle cost. The difference is entirely in how they answer.

Round one: coding without reasoning

The first test was fifty Python problems written for this campaign, with 560 executable assertions. The problems are the kind of thing a working developer meets and a model gets subtly wrong: encoding traps, date arithmetic around daylight saving changes, Italian holidays computed from Easter, checksum validation, SQL window functions, and six bug fixes with misleading comments. A problem is solved only when every assertion passes. Reasoning off, temperature zero, two minutes of usable time per problem.

The dense 27B solved 34 of 50, the MoE 19. On the same problems, the 27B solved 17 that the MoE missed, the MoE 2 that the 27B missed. The paired test gives p = 0.0007, and the comparison was declared as one of the two main questions of the campaign before any data existed, with a correction for multiple tests applied on top: it still holds at p = 0.004.

Speed didn't decide this round. Both models answered every problem in seconds: the MoE in a median of 4 seconds, the 27B in 10. All of the 27B's solved problems arrived in under thirty seconds.

If you want a comparison like this run on your own codebase, so that a team picks its model on evidence, my hub on AI infrastructure for companies explains how I approach self-hosted model selection with measured evidence.

Round two: coding with reasoning on

The same fifty problems, now with reasoning on and the sampler recommended for thinking, five minutes of usable time and a ten-minute hard cap per problem.

The order reversed. The MoE solved 26 within five minutes, the 27B 12. The MoE won 16 problems the 27B didn't, the 27B 2 the MoE didn't, p = 0.0013, again a pre-declared question that survives the correction.

The reason is time, not ability. All 28 failures of the 27B in this round were answers still being written when the ten-minute cap arrived; every answer it did finish was correct. The MoE thinks at twice the speed and finishes in time. Count everything solved within ten minutes instead of five and the score is 31 to 22, and that difference isn't confirmed by the paired test (p = 0.078). Given 20 minutes per problem in a follow-up run, the 27B reached 33 of 50, essentially what it had solved in thirty seconds without reasoning.

Round three: real bug fixes in an agent loop

The coding problems are single answers. The agentic test gives each model a small broken project, a bug report, file and shell tools and a visible test suite, and lets it work. A hidden oracle the model never sees then compares the fix with a reference on random inputs. Five projects, three runs each, reasoning on, generous time limits per task.

The 27B delivered 15 correct fixes out of 15. The MoE delivered 10 correct fixes, 3 illusory ones and 2 failures. An illusory fix is the dangerous kind: the visible tests pass, the agent declares success, and the hidden oracle finds the code wrong. Two of the MoE's illusory fixes landed on a trap I had written in advance, a legal-hold rule stated in the README that the obvious fix ignores, with exactly the disagreement count the lazy fix produces. Both models opened the README as their second action; the 27B then changed the file where the rule is applied in all three runs, the MoE in one.

Five task families are too few for a statistical winner: by arithmetic, no paired test on five families can reach significance. What the numbers do show is the shape, and the shape favours the 27B on careful work. The MoE was faster at it: on the tasks both solved, it usually finished in roughly half the time.

Round four: how long you wait

On eight everyday probes, a short chat question, a request for one shell command, a code review and a long prompt, I measured the time to a complete answer with reasoning off and on, three times each, with the prompt cache disabled so that every repetition paid its own prefill.

Without reasoning, both answer every probe in seconds. With reasoning, the MoE stays interactive and the 27B doesn't. The 27B is slower per token and also thinks longer: on the shell command it wrote almost nine thousand tokens of thought for a one-line answer. The paired median ratio between reasoning on and off is 14.4 for the 27B and 4.6 for the MoE.

Round five: long context, prompt reading and language

On a needle-in-a-haystack style test at 8K, 32K and 128K tokens (common-word extraction, multi-key and multi-value retrieval, variable tracking), with reasoning off, the 27B passed 12 of 12 and the MoE 11 of 12, its only miss at 8K. Four probes per length tell you where a model falls, not a precise rate, and neither fell up to 128K.

Reading long prompts is where the MoE is clearly faster: at 128K it processed 1,513 tokens per second against 540 for the 27B, so a 118K-token prompt took a median of 78 seconds per probe against 219.

On Italian, the 27B answered 11 of 14 mirrored questions correctly in Italian and 11 of 14 in English, with no question passing in one language only. The MoE was measured on the same mirrored set in two earlier conditions and lost between 7 and 14 points in Italian. These are small samples, but the direction is consistent.

The 27B is the better model when it answers directly. The MoE is the better model when the answer requires thinking and you are waiting for it.

Energy per solved problem

The MoE is cheaper per solved problem in every category where it solves the problem. Without reasoning, a solved coding problem cost 0.5 Wh above idle on the MoE and 1.1 Wh on the 27B; with reasoning, 17.9 Wh against 62.6 Wh. On agentic fixes, 19.4 Wh against 30.3 Wh. At my marginal electricity price these are fractions of a cent, so energy doesn't decide anything for one developer, but it's consistent with the speed difference: the MoE does less work per token and writes fewer tokens when it thinks.

Round six: questions with a false premise

A good assistant refuses to build on a wrong assumption. Fourteen questions in the campaign each contain a false premise that a careful reader should challenge: a command that doesn't do what the question claims, a protocol detail stated wrongly, a configuration that can't exist. A model passes when it corrects the premise and answers the real question, and fails when it goes along with it, answers something else, or doesn't finish within ten minutes.

The 27B corrected 13 of 14 premises, the MoE 11 of 14, and neither went along with a false premise even once. The differences come from unfinished answers and one off-topic reply, not from sycophancy. Within the five-minute usable window the counts were 12 and 11. With fourteen items, no paired test between two models can reach significance unless the gap is huge, so I report this round as UNDERPOWERED: both models handle false premises well, and the data can't rank them.

What the round does show is the cost of thinking again. The 27B needed 32 minutes in total for the fourteen questions with reasoning on, the MoE 26, and the MoE had 10 of its 11 correct answers within a minute, the 27B 6 of its 13.

Reproducibility in a model you use every day

A model you use every day should give you the same answer to the same question when you ask in the same way. Without reasoning, at temperature zero, both models did. I compared the fifty coding answers of the campaign, served by my benchmark harness, with the same fifty questions asked a few days earlier through the production model loader, with different context sizes and caps: 50 of 50 answers were identical character for character for both models. A second pass with the models measured in reverse order changed nothing either: all outcomes identical, speeds within about 1%.

Because of that stability, a comparison like this one means something. If the answers drifted between runs, a difference of two problems out of fifty would be noise. With reasoning on and a sampled decoder the answers do vary by design, which is why I compare the reasoning-on rounds with a paired test and don't read them as exact scores.

How I serve them side by side

On a single 16GB card the two models can't be resident together, so a model loader starts the one that is requested and stops the other. A configuration equivalent to mine is short, and every flag in it's pinned:

# Every model carries its own explicit flags: nothing is adjusted automatically.
models:
  qwen38-27b:
    cmd: >
      llama-server -m /opt/models/prod/Qwen3.8-27B-GSQ-RCO-IQ3_S-mtp.gguf
      -ngl 99 -c 131072 -fa on --cache-type-k q4_0 --cache-type-v q4_0
      -b 512 -ub 256 -np 1 --fit off --spec-type draft-mtp --port ${PORT}
  ornith15-35b:
    cmd: >
      llama-server -m /opt/models/prod/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 off --port ${PORT}

The swap costs 9.6 seconds. I pick the model once per working session, not per request, so there are only a handful of swaps a day.

Problem by problem: where each model wins

Aggregate scores hide which problems separate the two models, and that is the information you need to decide which one fits your code. Without reasoning, the 27B solved 17 problems the MoE didn't, and the list reads like a catalogue of careful, rule-heavy work: summing currency amounts without floating-point drift (sum_importi), an Italian-aware slug generator, euro formatting, semantic version comparison, finding free calendar slots, topological ordering, a TTL cache, a small expression calculator, IP allow-lists, URL normalization, pagination, IBAN validation, JavaScript-style slicing, a SQL report with window functions, the nth unique permutation, human duration parsing and a path join that must refuse traversal. The MoE solved only 2 that the 27B missed: a sliding median over 200,000 elements and an exact integer determinant.

With reasoning on, the picture inverts within the ten-minute cap. The MoE solved 15 problems the 27B didn't, among them the currency sum, a token bucket, MIME header decoding, ISO durations, euro formatting, semantic versions, invoice totals, glob matching, JSON pointers, HTTP range parsing, IBAN validation, text wrapping and secure path joins. The 27B solved 6 the MoE missed: text decoding with mixed encodings, elapsed time across daylight saving changes, free calendar slots, the TTL cache, deep merging of nested structures and session grouping. Most of the MoE's extra wins are problems the 27B solves without thinking and fails to finish while thinking.

The same 27B that wins seventeen problems in thirty seconds loses most of them again when it's allowed to think, because it doesn't finish. On this card its best answers are its fastest ones.

Agentic fixes, task by task

The five agentic projects differ in length and in the kind of trap they hide, and the two models diverge on exactly the ones that require reading the specification.

On shiftpay the MoE twice stopped with the visible suite still red, after two and four minutes, one of them cut by the per-turn token cap and not by the model; the 27B took eleven to fifteen minutes per run and fixed it every time. On snapkeep the MoE's two wrong fixes were the predicted lazy fix, 47 disagreements out of 80. On tailer its one wrong fix kept part of the text-mode reading the task warns against, disagreeing on 34 of 40 trials. On logsum and envmerge, the two tasks both models solved in every run, the MoE was faster: a median of 23 seconds against 50 on envmerge, 376 against 712 on logsum.

Where does the waiting time go?

The token counts explain the distances. With reasoning on, the 27B generated a median of 1,032 tokens on chat questions, 8,916 on shell commands and 10,400 on code reviews; the MoE 586, 1,387 and 4,549. By my estimate, between 79% and 98% of the 27B's tokens on those three profiles were thinking.

Energy per solved task, side by side

The energy is estimated at the wall by my power estimator, from a model of the machine, and measured at the card for the GPU share; the figures subtract the idle baseline over the exact time window of each task. In money they are fractions of a cent per task at my electricity price.

The capability checklist

When a model is chosen for a team, the questions are usually yes or no. This is how the two answer the ones I ask most often, each cell backed by a measurement in this article.

Which one I use for what

The campaign confirmed the split I had arrived at by intuition, and gave me numbers for it.

The rule underneath the table is simple: the dense 27B is the better model, the MoE is the faster thinker. On a 16GB card the 27B's reasoning is too slow to be useful interactively, so I use it without reasoning and get its best results. When a task needs reasoning and I am waiting, the MoE wins because it can afford to think.

A throughput chart shows none of this, since the MoE wins everything there, and a single pass rate hides it too: flip the reasoning switch and the winner changes. The configuration behind every number here is in the recommended strategies for 16GB cards, the cost of thinking is analysed in depth in the reasoning tax article, and the earlier teardown of the Qwen3.6 35B MoE on this card shows the architecture the Ornith 35B builds on.

A comparison between two models on a small card is three comparisons at once: of their answers, of their habits when they think, and of how fast each one runs on this hardware. The 27B wins the first, the MoE wins the third, and the second decides which of them you should open for a given task. If you are choosing local models for a team and want them compared on your own workload, with the same paired method, you can describe the case in the free quote form: it takes two minutes, and I tell you upfront whether it fits what I do.