Ornith 1.5 9B and 35B-A3B Benchmark on RTX 5090

We benchmarked Ornith 1.5 9B and 35B-A3B against Gemma 4-26B-A4B and Qwen 3.8 27B on one RTX 5090, and found the two mixtures are nearly identical on hardware and separated entirely by training.

Aug 25, 2026Updated Aug 28, 202619 min readFollow

Topics You Will Master

Reading an Ornith GGUF header to find its hybrid block layout
Why decode speed tracks active parameters, and why that is not an Ornith invention
Comparing KV cache cost per token across Ornith, Gemma and Qwen architectures
Why "max context that loads" is a meaningless number on Windows, and what to measure instead

ornith-ai released two models on Hugging Face: Ornith-1.5-9B-GGUF and Ornith-1.5-35B-A3B-GGUF. Both cards quote a 262,144 token context.

In this blog, we will compare both against Gemma 4-26B-A4B and Qwen 3.8 27B on one RTX 5090, on speed, memory, context, quality and tool use. We read the GGUF files first.

Gemma is a mixture of experts like Ornith 35B-A3B. In simple words, a mixture keeps many small expert networks inside one model and wakes only a few per token. Qwen 3.8 is dense, so it reads all of its weights every time, which makes it our control.

Bestseller

Fine Tuning LLM with Hugging Face Transformers for NLP

Learn transformer architecture fundamentals and fine-tune LLMs with custom datasets.

95% off$199.99
$9.99Enroll now 30 day refund, lifetime access

Setup: Four Models, One RTX 5090

Everything ran on one machine in one session.

  • GPU: RTX 5090, 32 GB VRAM, full GPU offload
  • Runtime: llama-server build 10448 on Windows 11
  • Quantization: Q4_K_M for all four models
  • KV cache: f16 with flash attention on
  • Grading: pure Python functions, no judge model, meaning no AI grading another AI
Model Total Active per token Role
Ornith 1.5 35B-A3B 35B about 3B The mixture under test
Ornith 1.5 9B 9B 9B The small model under test
Gemma 4-26B-A4B 26B about 4B A mixture of similar shape
Qwen 3.8 27B 27B 27B Ornith's architecture, no mixture

Every model started the same way.

BASH
llama-server.exe -m Ornith-1.5-35B-Q4_K_M.gguf --host 127.0.0.1 --port 8099 -c 8192 -ngl 999 -fa on -np 1 --jinja --no-warmup --metrics

Important

The --jinja flag matters here. Without it the <think> block lands in content instead of reasoning_content. A script counting reasoning tokens then reports zero for a model that is thinking normally.

Decode tests used the raw /completion endpoint with ignore_eos, so the model cannot stop early. Every model produced exactly 512 tokens.

Warning

The gemma4:26b blob in the Ollama library will not load in llama.cpp. It packs the image part of the model, the vision tower, into the same file. llama.cpp loads the text half, then fails with expected 1014, got 658. We used a text-only Q4_K_M build instead. The model works fine inside Ollama.

Advertisement

What Is Inside the Ornith GGUF Files?

A GGUF file stores the model on disk, and its header lists every tensor inside. So we can count the blocks ourselves instead of trusting the card.

Ornith 9B reports the architecture qwen35 and Ornith 35B-A3B reports qwen35moe. Both sit on the Qwen 3.5 stack, so any gain comes from training rather than structure.

The header also names 256 experts, 8 of them active per token.

Grouping the tensors by block index shows the layout. Most Ornith blocks carry no attention weights at all. In the 35B, attention sits at block 3, 7, 11 and every fourth position after that.

The three blocks in between are Gated DeltaNet. They carry ssm_alpha, ssm_beta and ssm_out instead of key and value projections.

In simple words, Gated DeltaNet is a memory that stands in for attention. Attention keeps every past token and reads back over all of them for each new token. Gated DeltaNet keeps one running summary instead, and the gate decides how much of that summary to hold on to and how much the new token writes over. The summary is a fixed size whatever the context, so only the attention blocks hold a KV cache.

Gemma solves the same problem differently. All 30 of its blocks are attention blocks, but 25 use a 1,024 token sliding window.

Let me tabulate all four models for your better understanding.

Model Architecture Blocks Attention blocks Experts Residual Head dim
Ornith 1.5 35B-A3B qwen35moe 40 + 1 10 256, 8 active 2048 256
Gemma 4-26B-A4B gemma4 30 30, 25 windowed 128, 8 active 2816 512
Ornith 1.5 9B qwen35 32 + 1 8 dense 4096 256
Qwen 3.8 27B qwen35 64 + 1 16 dense 5120 256

The plus one is a draft head, a small helper block that guesses the next few tokens. It is not a layer the token passes through, so we count it apart. Gemma carries none.

Residual is the width of the model's running hidden state, the workspace every block writes into. Ornith is the finer mixture, with 256 experts against Gemma's 128. Both activate 8 per token.

Advertisement

Which Model Writes Tokens Fastest?

Decode speed is how fast a model writes its answer, in tokens per second. If it follows active parameters, both mixtures should beat Qwen by a wide margin.

Horizontal bar chart of decode speed showing Ornith 35B-A3B at 273 tokens a second, Gemma 4-26B-A4B at 232, Ornith 9B at 193 and Qwen 3.8 at 77

Model Decode Active per token
Ornith 1.5 35B-A3B 273.2 tok/s about 3B
Gemma 4-26B-A4B 232.4 tok/s about 4B
Ornith 1.5 9B 192.7 tok/s 9B
Qwen 3.8 27B 77.2 tok/s 27B

The prediction holds across both vendors. Ornith leads Gemma by 18%. Against the dense Qwen the gap is 3.5 times.

Scatter plot of decode speed against active parameters per token, with Ornith 35B-A3B and Gemma 4-26B-A4B together in the top left and Qwen 3.8 alone on the right

So speed here belongs to sparsity, not to Ornith.

Content made almost no difference. Across counting, code, JSON, essay and fiction the spread stayed under 1.5% for every model.

How Fast Does Each Model Read a Long Prompt?

Prefill is how fast a model reads the prompt before answering. We measured it from 512 tokens to 32k.

Line chart of prefill speed against prompt length, with Ornith 9B highest, Gemma 4-26B-A4B above Ornith 35B-A3B from 2k onward, and Qwen 3.8 lowest

Model 512 2k 8k 32k
Ornith 1.5 9B 6,362 9,874 10,699 9,952
Gemma 4-26B-A4B 1,114 7,168 9,719 9,533
Ornith 1.5 35B-A3B 2,305 6,809 7,547 7,217
Qwen 3.8 27B 2,270 3,289 3,480 3,184

All numbers in the table are tokens per second.

Both mixtures are slow on very short prompts, because picking which experts to use costs a fixed amount on every step. A 512 token prompt is too short to absorb it.

From 2k upward Gemma overtakes Ornith 35B and stays ahead, so on long prompts and short answers Gemma is the faster mixture.

Advertisement

How Much Memory Does the KV Cache Cost?

The KV cache holds one entry per token already in context. It decides how much context a card can hold.

Horizontal bar chart of KV cache cost per token, with Ornith 35B-A3B and Gemma 4-26B-A4B both at 20 KB, Ornith 9B at 32 and Qwen 3.8 at 64

Model Attention blocks KV per token At 262k
Ornith 1.5 35B-A3B 10 of 40 20.0 KB 5.0 GB
Gemma 4-26B-A4B 30, mostly windowed 20.0 KB 5.0 GB
Ornith 1.5 9B 8 of 32 32.0 KB 8.0 GB
Qwen 3.8 27B 16 of 64 64.0 KB 16.0 GB

Ornith and Gemma land on the same number by different routes. Ornith skips the cache on three blocks in four, and Gemma keeps 25 of its 30 blocks inside a 1,024 token window.

Ornith 9B looks odd here. It has the fewest attention blocks of the four, 8 against the 35B's 10, and it still costs more per token. Block count is only half the sum.

The other half is KV heads. Every attention block stores one key and one value for each KV head it keeps, and a key and a value take 256 numbers each at 2 bytes apiece. So a block with 4 KV heads costs 4 × 512 × 2 bytes, which is 4 KB.

Model Query heads KV heads Per block Attention blocks KV per token
Ornith 1.5 9B 16 4 4 KB 8 32 KB
Ornith 1.5 35B-A3B 16 2 2 KB 10 20 KB
Qwen 3.8 27B 24 4 4 KB 16 64 KB

Here, we can see that the 9B pays double per block, so its 8 blocks come to more than the 35B's 10.

Keeping fewer KV heads than query heads is grouped query attention, where several query heads share one KV entry. The 35B shares each KV head across 8 query heads and the 9B across 4. That single choice is what separates them.

So the Gated DeltaNet schedule is a real win over Qwen 3.8, which shares Ornith's family and still costs 64 KB. It is not a win over Gemma.

We can also store the cache in smaller numbers to save memory. That is KV quantization, and it behaved the same way for all four models.

KV cache type Size against f16 Saving
q8_0 53% 47%
q4_0 28% 72%
Advertisement

How Much Context Can Each Model Really Use?

All four models advertise 262,144 tokens, and all four start at that size and report it back. So the number a server reports proves nothing.

Caution

On Windows, asking CUDA for more memory than the card has does not fail. The driver quietly backs the extra with system RAM over PCIe. The server still starts, still reports the full context, and logs no warning. It just runs at a fraction of its speed.

So we measured the point where decode speed drops instead. The ceiling below is the largest context where a model still runs within 90% of its own short context rate.

Line chart of decode speed against allocated context, with Ornith 35B-A3B, Gemma 4-26B-A4B and Ornith 9B flat to 262k while Qwen 3.8 falls off at 262k

Model Usable context Normal rate Past the cliff Peak VRAM
Ornith 1.5 35B-A3B 262,144 271.2 tok/s no cliff 27,524 MB
Gemma 4-26B-A4B 262,144 235.6 tok/s no cliff 23,191 MB
Ornith 1.5 9B 262,144 193.4 tok/s no cliff 15,444 MB
Qwen 3.8 27B 245,760 78.4 tok/s 7.3 tok/s 32,132 MB

Qwen 3.8 holds 78 tok/s at 245,760 and drops to 7.3 at 262,144. A 7% larger window costs it 91% of its speed. Its 64 KB per token puts it at the edge of the card.

The other three stay flat to the full window, and Gemma does it with the most room to spare.

How Fast Can Each Model Answer From a 128k Document?

We hid a fact inside documents of 16k, 64k and 128k tokens, then asked for it back.

Horizontal bar chart of seconds to answer a question about a 128k token document, with Ornith 9B at 23.1, Ornith 35B-A3B at 25.2, Gemma 4-26B-A4B at 25.7 and Qwen 3.8 at 75.0

Model Seconds to answer
Ornith 1.5 9B 23.1
Ornith 1.5 35B-A3B 25.2
Gemma 4-26B-A4B 25.7
Qwen 3.8 27B 75.0

Ornith 35B and Gemma finish about half a second apart. Qwen takes three times longer.

Every model found the hidden fact every time. Retrieval accuracy separated nothing.

Advertisement

Does the MTP Draft Head Make These Models Faster?

Both Ornith files carry a nextn block, a multi-token prediction head, or MTP. In simple words, a small helper inside the file guesses the next few tokens and the full model checks all the guesses in one go. Qwen 3.8 ships one too, and Gemma does not. We tuned the same mechanism flag by flag in the Qwen 3.8 27B speed settings post.

llama-server ignores those tensors unless we ask for them.

BASH
llama-server.exe -m Ornith-1.5-35B-Q4_K_M.gguf -c 8192 -ngl 999 -fa on --jinja --spec-type draft-mtp --spec-draft-n-max 4

MTP helps on structured text and hurts on prose.

Grouped bar chart of MTP speedup by content type for Qwen 3.8, Ornith 9B and Ornith 35B-A3B, with all three above 1.0 on counting, code and JSON and both Ornith models below 1.0 on essay

Content Qwen 3.8 27B Ornith 9B Ornith 35B-A3B
Counting 2.33x 1.67x 1.28x
Code 1.99x 1.35x 1.11x
JSON 2.34x 1.11x 1.10x
Essay 1.22x 0.84x 0.74x
Fiction 1.39x 1.03x 0.72x

Acceptance rate explains it. That is the share of guesses the full model agrees with, and a rejected guess is wasted work. The draft head guesses right 43% to 86% of the time on structured output. On prose that falls to 26% to 39%, and drafting stops paying for itself.

This one goes to Qwen 3.8. Its head reaches 2.34x on JSON where Ornith 35B manages 1.10x, and it stays above 1.0 on prose where both Ornith models turn slower.

Warning

MTP is not a free speedup for anyone. Two greedy runs with MTP off are bit identical. With MTP on the output diverges on almost every model and content pair we tested. Treat it as a different configuration that needs its own quality check.

Which Model Serves Many Users at Once?

We fired 1, 4 and 8 requests in parallel and measured total throughput. That is the tokens per second across all requests added together.

Line chart of aggregate throughput at 1, 4 and 8 parallel requests, with Gemma 4-26B-A4B and Ornith 35B-A3B close together at the top and Qwen 3.8 far below

Model 1 slot 4 slots 8 slots
Gemma 4-26B-A4B 222.8 546.5 702.6
Ornith 1.5 35B-A3B 248.9 528.7 673.0
Ornith 1.5 9B 187.4 420.4 508.2
Qwen 3.8 27B 76.5 211.5 264.5

Ornith leads on a single stream. Gemma overtakes it at four slots and finishes 4% ahead at eight, because its lighter weights leave more VRAM for the extra caches that parallel requests need.

Advertisement

Which Model Answers Hard Problems Fastest?

Speed means nothing if the fast models answer worse. We ran 12 problems with checkable answers: eight in a base tier run once, and four harder ones run at two seeds each. A Python function grades every run by reading the final ANSWER: line.

Accuracy separated almost nothing. Three models scored perfectly on both tiers, and Qwen 3.8 missed one of its two runs on a single hard math problem, answering it correctly at the other seed. The table below is the hard tier, eight scored runs per model, because it is the only place the models had to work.

Horizontal bar chart of median seconds to a correct hard answer, with Ornith 35B-A3B at 8.0 seconds and Gemma 4-26B-A4B at 43.6

Model Hard tier Median tokens Thinking share Median seconds
Ornith 1.5 35B-A3B 8/8 2,110 70% 8.0
Ornith 1.5 9B 8/8 3,481 83% 18.8
Qwen 3.8 27B 7/8 1,420 89% 19.2
Gemma 4-26B-A4B 8/8 9,759 89% 43.6

Gemma spends 9,759 tokens where Ornith spends 2,110, which is 4.6 times more thinking for the same score. That turns Gemma's prefill and concurrency wins into a 43.6 second answer. This gap comes from training, not from architecture.

Ornith also thinks proportionally less, at 70% of output against 89% for both rivals, so it commits to an answer sooner.

Qwen 3.8 spends the fewest tokens of anyone at 1,420, and still takes 19.2 seconds, because it decodes at 77 tok/s. Token count and wall clock point in opposite directions.

How Well Does Each Model Use Tools?

We built a tool-calling test with a virtual database and a small source tree. Ten tasks ran at two seeds each. The tools return fixed data, and nothing runs model-written code.

One of our own tasks was badly worded. It ended with "report the timezone of that region", so every model answered UTC+1 while our grader wanted the datacenter too. We excluded it and fixed the wording, which leaves 18 scored runs per model.

Model Solved Malformed calls Mean seconds Mean thinking characters
Ornith 1.5 35B-A3B 18/18 0 5.1 2,230
Ornith 1.5 9B 18/18 0 5.9 2,252
Qwen 3.8 27B 18/18 0 10.6 1,281
Gemma 4-26B-A4B 17/18 0 10.2 5,573

Both Ornith models solved everything and Gemma missed one. Nobody produced a malformed tool call in 72 runs.

The thinking pattern repeats: Gemma spends 5,573 characters per task against Ornith's 2,230.

Note

One task at this sample size is not a wide margin. Our tasks are also far easier than the benchmarks Ornith's card cites. We cannot confirm or refute its agentic coding claim.

Advertisement

What Does Ornith's Model Card Claim?

Every claim on the card, checked against what we measured.

Claim Verdict What we found
About 3B activated parameters per token Held Decode at 3.5 times a dense 27B matches the claim
Context window of 262,144 tokens Held Delivered in full at full speed, though Gemma does the same with more room
Wide margins on agentic coding Not confirmed 18/18 against 17/18 is one task, and our test is too easy to settle it
MTP head Present Both files ship a working nextn block, though Qwen's is better
9B card recommends presence_penalty 1.5 Suspect This setting caused runaway thinking on Qwen 3.5 in our earlier tests

Which Model Should We Run?

Model Decode Weights Time to hard answer
Ornith 1.5 35B-A3B 273.2 19.7 GB 8.0 s
Gemma 4-26B-A4B 232.4 16.4 GB 43.6 s
Ornith 1.5 9B 192.7 5.2 GB 18.8 s
Qwen 3.8 27B 77.2 15.4 GB 19.2 s

Ornith 35B-A3B and Gemma 4-26B-A4B are near twins on hardware: same KV cost, same full window, about half a second apart on a 128k question. Gemma is lighter on VRAM, faster on prompts above 2k, and faster under eight-way load.

Training separates them, not silicon. Ornith reaches the same answers in a fifth of the time because it does not keep re-checking itself. So take Ornith for question answering and agent loops, and Gemma for long prompts or many users, which also saves 3.3 GB.

Ornith 9B holds a full 262k window in 15.4 GB and reads short prompts faster than either mixture. Qwen 3.8 27B is the slowest here and the only model that cannot hold its own advertised context, but it keeps the best MTP head and the lowest token count per answer.

Advertisement

What We Did Not Test

  • Vision. Both Ornith repositories ship an mmproj file. We tested text only.
  • Quality cost of KV quantization. We measured the sizes, not the output.
  • Quality cost of MTP. We proved the output changes, not that it gets worse.
  • Agentic coding at SWE-bench scale, where Ornith's main claim lives.

Conclusion

This is how the Ornith 1.5 release measures up. We read the hybrid block layout out of the GGUF headers. Then we ran both models against Gemma 4-26B-A4B and Qwen 3.8 27B on one RTX 5090. The two mixtures came out near twins on hardware, at the same 20 KB per token and the same full 262k context, and training is what separates them.

Key takeaways:

  • Decode speed follows active parameters, not total size. Both mixtures beat the dense Qwen 3.8 by a wide margin, so the speed belongs to sparsity, not to Ornith.
  • Ornith 35B-A3B and Gemma 4-26B-A4B land on the same KV cache cost by different routes: skipped cache blocks against sliding windows.
  • On Windows, "the context loads" proves nothing. Measure where decode speed falls off a cliff instead.
  • Ornith's real edge is training. It answers hard problems in 8 seconds where Gemma needs 43.6, at the same accuracy.
  • MTP speeds up structured output and can slow down prose. Qwen 3.8 carries the best head of the three.

Next steps:

Found this useful? Keep building with me.

New tutorials every week on YouTube: or go deeper with a full structured course.

Find this tutorial useful?

Subscribe to our YouTube channels for more practical production walk-throughs.

Discussion & Comments