I am wondering what is the best way to combine both into one setup for Hermes. Do I use qwen as main model or deepseek. There are many options to choose from.
I want to run both at the same time using three or more sparks under one Hermes harness. I don’t know if this is the best way or there are better ways.
Open to listen and learn from experts in this forum.
Thank you in advance
I am having exactly the same questions.
I thought of using Deepseek for the default profile (leveraging the big ctx window) and qwen as coding subagent. having 4 units, that would let one unit for maybe media gen usage (Minimax H3 ? ).
With that I hope to cover a very large scope of use cases, from productivity to entertainment and social accounts management…
I still did not test this yet though… You know the moto : ‘I’ll do it tomorrow’ ;)
My experience with Hermes:
low reasoning modeUnfortunatelly, new Qwen model is very talkative and it goes beyond the standard limits of Hermes. So, its usability on spark is not very good for Hermes - much better to use Qwen3.6 27b for it as additional model.
Hermes could be exposed as openAI compatible end point. I tried to test some models combinations to see if they perform better compared to original model alone. Results are good for some tests, but not correct for others. I think timeout and output format could be improved. I was using 32,a3b and it is excellent, thinking for upgrade.
I use ds4flash across 2 sparks and defer vision and delegate coding tasks (via a Hermes core hack) to 122b on a third spark. Use that for kanban profiles too for complex work. Not sure why you’d use 35b - even for speed - as in my experience it ended up taking longer than 122b on most tasks due to looping or failing the adversarial review step I built in.
Given your contributions across the forum I’m really interested to know why you ended up on 35b for this when 122b seems so much better for the aux third spark model in my testing.
The answer is simple - I have three sparks and I need both 35b (for subagents, basic vision, small model for Hermes) and 27b (for the code review, additional backup vision and some long analysis in the future), which are running on one instance. 122b unfortunately doing less quality job during code review and 27b (especially new) could find deep logic errors after the Deepseek. So I have virtual MoE (Deepseek as architector/planer and coder, and Qwen 27b as reviewer).
I am searching for 4 spark in my region, but for the last month minimal price on them increased from $4200 to $4930 without any availability on the local market. So, I am forced to conserve the resources of my current LLM fleet
122b was my best choice before minimax m3 and then dsfv4. Now I am thinking why not use 3.8 27b as secondary. Maybe also 122b could be trained using kimi k3 and 3.8 max to be better.
I ended up running Qwen 3.8 27B FP8 on a dual R9700s.
Very good performance. Obviously more power consumption. But I use that together with the DualSparks for DeepSeek. Pretty nice combo.
dual R9700s run in a VM on a proxmox and has 32GB of RAM and 12 vCPUs from ryzen 9900X
But I don’t even think that VM needs 12 vCPUs. 8 would be perfectly fine.
The whole box when it sits idle draws about 145 watts So a little bit less than a double of what DualSparks do. When it runs inference, it adds another 600 watts.
But nice thing is that running Proxmox on it, there’s quite a bit of capacity left for all sorts of other stuff, unless you’re running inference 24x7.
With a synched graphDb, I’ll run q8 27b on a 10gbe via a 5090. The result gives me a wild work horse that can stick to spec build at 10-50x tk/s, with DS4 on a single spark as the research and validation judge. They don’t talk to each other per say, outside of PRs and wrestling through the rare hallucination.
with a synched graphDb
What’s the graphdb for – memory shared between q8 and ds4?
More or less. It allows a tertiary orchestrator model to delegate different machines for appropriate loads. Small contextual instruction but need faster tk/s > use machine A || needle-depth cross-domain context for whatever specific thing or spec builds > use machine B etc. The orchestrator leases work by domains and queues if there is overrun swarm changes or something. Then treesitter chugs through keeping it together and synched.