I tested three model families on the same hardware, same quantization, and same coding tasks. The results surprised me – the “best” model depends entirely on what you’re asking it to do.
Gemma 4 is the fastest. Qwen2.5-Coder is the most focused. Ornith is the smartest. None of them is universally “the best” – they’re different tools for different jobs, and understanding the tradeoffs is what makes a local AI setup actually useful instead of just impressive.
Here’s how they compare on my RTX 3060 Ti with 8GB VRAM.
The Contenders
I tested three specific models – not the “best version” of each family, but the specific quantizations that fit in 8GB VRAM and run at usable speeds:
| Model | Architecture | Active Parameters | Total Parameters | Quantization |
| Gemma 4 E4B | MoE | 4B | ~12B | Q4_K_M |
| Qwen2.5-Coder 7B | Dense | 7B | 7B | Q4_K_M |
| Ornith 35B-A3B | MoE + MTP | 3B | 35B | UD-IQ4_NL |
Gemma 4 E4B is Google’s small MoE model – 4 billion active parameters out of roughly 12 billion total. It’s designed for speed on consumer hardware.
Qwen2.5-Coder 7B is Alibaba’s dedicated coding model. Dense architecture – all 7B parameters fire on every token. No MoE efficiency, but the entire model was fine-tuned on code.
Ornith is the Qwen3.5 MoE variant with MTP support. 35B total, 3B active per token, 256 experts. The largest model that fits in 8GB VRAM with TurboQuant+ KV compression.
Speed Comparison
All measurements from the same GPU with the same KV cache config (q8_0 K, turbo2 V where supported):
| Model | Generation Speed | Context Window | Prompt Ingestion |
| Gemma 4 E4B | 68.17 t/s | 64k | 1664-2346 t/s |
| Qwen2.5-Coder 7B | 37.27 t/s | 128k | 162.77 t/s |
| Ornith 35B-A3B | 30-36 t/s | 128k | 670-720 t/s |
Gemma 4 E4B is nearly twice as fast as the other two. At 83 t/s, the output arrives faster than you can read it. For quick tasks – generating boilerplate, writing a simple function, answering a question – Gemma is the clear winner.
Ornith and Qwen2.5-Coder are in the same speed range, but Ornith achieves this at 128k context with TurboQuant+ compression, while Qwen2.5-Coder achieves it natively as a smaller dense model.
Quality Comparison: Coding Tasks
I tested each model on three coding scenarios. The results were consistent across multiple runs.
Scenario 1: Generate a Laravel Migration
“Write a Laravel migration for a bookings table with user_id, service_id, date, time, status, and notes fields.”
| Model | Result |
| Gemma 4 E4B | Good – correct schema, proper foreign keys, used timestamps. Missing `default` value for status. |
| Qwen2.5-Coder 7B | Excellent – correct schema, proper foreign keys, added `default(‘pending’)` for status, added index on `date` column. |
| Ornith 35B | Excellent – same as Qwen but also added a composite index on `(user_id, date)` and a comment explaining the index choice. |
Qwen2.5-Coder and Ornith both produced production-ready migrations. Gemma was close but missed the default value. The difference is that Qwen and Ornith were specifically trained/fine-tuned on code, while Gemma is a general-purpose model.
Scenario 2: Debug a Race Condition
“Here’s a Go goroutine pattern with a channel. It’s producing duplicate results. Find the bug.”
| Model | Result |
| Gemma 4 E4B | Identified the general area but couldn’t pinpoint the exact issue. Suggested adding mutex locks – incorrect solution. |
| Qwen2.5-Coder 7B | Found the race condition correctly. Explained why the channel wasn’t synchronized. Suggested a proper fix with WaitGroup. |
| Ornith 35B | Found the race condition, explained the root cause, suggested the WaitGroup fix, AND pointed out a secondary issue with the error handling that I hadn’t noticed. |
This is where model size matters. The reasoning gap between 4B active parameters (Gemma) and 3B active but 35B total (Ornith) is significant. Ornith’s larger parameter space gives it more “world knowledge” to draw from, even though only 3B parameters are active per token.
Scenario 3: Large Context Code Review
“Review this entire WooCommerce plugin (800 lines) for security issues and performance bottlenecks.”
| Model | Result |
| Gemma 4 E4B | Found 2 obvious issues (missing nonce, direct DB query). Missed subtler problems. |
| Qwen2.5-Coder 7B | Found 4 issues including the nonce, the DB query, an missing capability check, and an inefficient loop. |
| Ornith 35B | Found all 4 issues Qwen found, plus 2 more: a potential SQL injection in a search query and a missing rate limiter on the AJAX handler. The 128k context meant the entire plugin fit in memory without truncation. |
At 800 lines of code, all three models had the full context. But the quality of analysis varied significantly. Ornith’s 35B parameter space caught issues that the smaller models missed – not because it’s “smarter” in an abstract sense, but because it has more patterns in its training data to match against.
Quality Comparison: Non-Coding Tasks
Architecture Discussion
“I’m building a multi-tenant Laravel app. Should I use separate databases, separate schemas, or shared tables with tenant_id?”
| Model | Result |
| Gemma 4 E4B | Gave a reasonable overview of the three approaches. Recommended shared tables with tenant_id without much reasoning. |
| Qwen2.5-Coder 7B | Better – explained tradeoffs for each approach. Recommended shared tables for SaaS, separate databases for compliance-heavy clients. |
| Ornith 35B | Best – covered all three approaches with specific pros/cons, recommended shared tables with tenant_id AND row-level security, mentioned database partitioning as a middle ground, and noted that Laravel’s scoping already supports this pattern. |
The architecture discussion is where Ornith’s size advantage is most visible. It connects more dots across a wider knowledge base. For pure coding tasks, Qwen2.5-Coder is competitive. For broader technical decisions, Ornith’s 35B parameters give it an edge.
The Tradeoff Matrix
| Factor | Gemma 4 E4B | Qwen2.5-Coder 7B | Ornith 35B |
| Speed | Best (83 t/s) | Good (37 t/s) | Good (30-36 t/s) |
| Code quality | Good | Excellent | Excellent |
| Reasoning depth | Basic | Good | Best |
| Large context | 64k | 128k | 128k |
| VRAM usage | Lowest | Medium | Highest |
| Best for | Quick tasks | Daily coding | Hard problems |
What I Actually Use
I don’t pick one model and use it for everything. Each model has a role:
Gemma 4 E4B is my fast worker. When I need a quick function generated, a variable renamed across files, or a simple explanation of a concept, Gemma does it at 83 t/s. No waiting. The quality is good enough for 80% of daily tasks.
Ornith 35B is my daily coder. It understands code structure better than Gemma, produces cleaner output, and handles 128k context. For multi-file refactors, writing tests, and code generation where quality matters, Ornith is the default.
When I need deep reasoning or large context analysis, Ornith’s 35B parameter space catches issues that smaller models miss. It’s both my coder and my architect.
The workflow is simple: start with Gemma for quick tasks. If the output isn’t good enough, step up to Ornith. It’s a two-tier system that covers every scenario without compromising on speed or quality at any level.
When to Switch Mid-Project
I don’t always know which model I need before I start a task. The workflow is more fluid than “pick one and stick with it.” Here’s how switching actually works during a coding session.
I’ll start with Gemma for a quick question about a Laravel helper function. Gemma answers in 2 seconds. Then I realize the answer requires changes across three files. Gemma can handle single-file edits, but multi-file refactors need more context – so I switch to Ornith. The server restarts in about 10 seconds with the new model. Ornith handles the refactor cleanly.
Then I realize the refactor introduces a potential performance issue with database queries. I need someone to review the change and think about implications. Ornith handles this too – it reviews the full context and catches a N+1 query problem that Gemma missed.
Two models, two tiers, all within the same coding session. The switching cost is about 10 seconds. The quality improvement is worth hours of debugging.
The Honest Answer
There is no “best local LLM for coding” on 8GB VRAM. There are three good options that excel at different things. The question isn’t which one to pick – it’s how to use all three effectively.
If I had to choose only one: Ornith 35B. It’s the best balance of speed, quality, and context size for a developer who needs one model for everything. But the three-model stack is strictly better than any single model, and on 8GB VRAM, running them one at a time is free.
The local AI space loves ranking models. The reality is more nuanced – different architectures, different sizes, and different training approaches produce models that are good at different things. The best setup isn’t the fastest model or the biggest model. It’s the right model for the task at hand.
For the full benchmark results across 9 models and 32 configurations, see 9 Models Tested, 3 Rejected: What I Learned From 32 Benchmarks.
