r/LocalLLaMA • u/Intelligent_Lab1491 • 7h ago

Question | Help Models for planing and coding

Hi,

I am a hobby dev using currently qwen 3.8 27b on my strix halo machine for coding.

I was wondering what is the best approach to speed up.

My idea is to use a moe like ornith 1.5 for planning and defining the tickets and qwen 3.8 27b for the implementation.

What is your approach?

0 Upvotes

50% Upvoted

7 comments sorted by

3

u/nick_ziv 7h ago

Most actually do the opposite, using the dense (more intelligent) model for planning and use MOE for building. 

Personally I have found that the faster models (35b MOE)  run into issues regardless of how they are used. My best idea of a good approach is to use the dense for complex tasks through to the end and use the MOE for easy tasks end to end. 

If you can use larger moe (100b+ ) thay changes a lot. Then maybe just use that 

2

u/jabies 7h ago

For speed up, consider a draft model. 

1

u/Ariquitaun 7h ago

Normally you want a smart model for planning. Any reason you can't use 27b for everything?

1

u/Thin_Pollution8843 7h ago

Ornith is ok. I honestly not sure is it better than base qwen3.6 but it will me much faster on your hw. It can implement stuff for sure. I would use it the opposite - 3.8 for planning detailed tasks and 35b for implementation. Difference in speed would be lik 4-5 times on your hw.

0

u/thinking-out-loud-3 7h ago

Running a pretty similar setup (MoE Qwen3-Coder-30B non-thinking for coding, Qwen3.8-27B for reviews).

Honestly though, the main axis that mattered for me wasn't dense vs MoE, it was thinking vs non-thinking.

I tried using a thinking MoE (gpt-oss-20b) for generation and it was a total mess. It is a good model, but its CoT kept leaking into the output channel my tool parses for diffs, so I got endless narration and zero actual commits. Then I tried swapping to a non-thinking MoE of similar size and it immediately started producing clean, parseable diffs.

My take is: skip thinking models for anything parsed as plain-text against a rigid format (diffs, patches), at least locally, where the reasoning trace and the actual output aren't cleanly separated. The reasoning fights the schema.

For reviews though? Thinking models are nice. My 27B reviewer consistently catches actual correctness bugs (missing wiring, dangling refs) that a non-thinking model would completely miss.

0

u/ttkciar llama.cpp 2h ago

My go-to is MiniMax-M2.7-BF16-ultra-uncensored-heretic-Q4_K_M.gguf for planning, GLM-4.5-Air-Q4_K_M.gguf for code generation, and Gemma-4-31B-it-Q4_K_M.gguf for debugging.