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.
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-serverbuild 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.
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.
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.
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.

| 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.

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.

| 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.
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.

| 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% |
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.

| 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.

| 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.
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.
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.

| 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.

| 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.
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.

| 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.
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.
What We Did Not Test
- Vision. Both Ornith repositories ship an
mmprojfile. 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:
- See these same models face IBM's latest release in the Granite 4.2 vs Gemma 4 vs Qwen 3.8 benchmark.
- Tune draft depth, KV cache type, and context size on your own card with the Qwen 3.8 27B speed settings on llama.cpp.
- Match a quantization and a context size to your GPU with the local LLMs technical reference guide.