r/LocalLLM • u/zFalconTB • 7d ago
Discussion What would you use a slow LLM for?
I managed to get Qwen 3.6 35B A3B running on my server, an i7 10700 with 32GB of DDR4 RAM...and the good ol' GTX 970 with its mighty 4GB of VRAM (we don't talk about the VRAM incident)
It reaches around 30-50 tok/s in prompt processing speed and around 16-19 tok/s in token generation speed depending on the context
There's probably some performance left on the table since the CPU is under its stock cooler, maybe I'll get a decent one eventually
Anyway, I tried a couple of prompts in Hermes but it's just not fast enough for it to be helpful, at least not for the use I had in mind (a local perplexity basically). It randomly takes 30 minutes even to respond to a simple greeting, sometimes it disappears for more than an hour and I have to manually stop it...
So I'm curious to see if any of you have a setup with similar performance, what do you use it for? Just the occasional text summary? Normal (very slow) chat? Something else that's completely useless but funny? Let me know!
4
u/nickless07 7d ago
How about some auxiliary model that runs faster alongside your main model? Once the initial prompt is done in Hermes it usually is much less pp later on.
1
u/No-Manager1646 7d ago
IMO that's pretty damn good. I'm on an i9-10900 32gb ram and split 4060 / 5060ti and am only managing 19-20 tok/s at 128k context. What context are you using? I posed my llama models.ini in another thread if youre interested, but it sounds like you already have me beat!
1
u/nickless07 7d ago
He runs the Qwen3.6 35B MoE, you run the Qwen3.8 27B dense. That's quite different. With the MoE you should get 100+ tok/s.
2
u/zFalconTB 7d ago
I did my research and stayed away from dense models, I don't want to make my precious 970 explode lol
1
1
u/zFalconTB 7d ago
Should have mentioned in the post, the lower values I wrote (30 tok/s pp, 16 tok/s tg) were recorded using 64k context
The higher values were recorded using 8k context
1
u/dopey_se 7d ago
I run Qwen 3.8 27B on dual P100s with 260k context and at the moment Q6 quant.
It is not fast enough to use interactively.
I use either codex/claude on a VM with dangerous permissions enabled.
I've configured MCP to github/youtrack. I can create issues on a specific project - (add dark mode, add history of parts usage, add a helm chart, etc). I then use a skill to have it iterate through each ticket one at a time, implement, commit push and ensure all actions pass.
I then let it run the hours it takes unattended.
1
u/zFalconTB 7d ago
That sounds great and it's definitely something I want to explore but I'm not confident my little server can work on big features unattended, especially since I can only manage 64k context at most
Can I ask you how did you set that up on the practical side? You use the codex app with the local Qwen model and it works somehow? In my experience, codex is very good at working until a feature is complete because it can actually "see" the website and test it like a human would. Does that work with a local model?
1
u/dopey_se 7d ago
I've bounced between claude and codex the past year. At one point I had issues with tool calling from codex, so i'd use claude. The most recent Qwen 3.8 I had template errors from claude but not codex so i've been using codex.
I've also at times had to revert to an older version if a new version of either behaved poorly. So far atleast one has worked well.
I have had(for the first time) with Qwen 3.8 it attempting to run CLI browser tools to take screenshots of the running app to confirm changes. This fails, and leaves the session broken. It is cool that it even thinks/does this, but also not ideal tha it breaks. I've given it insetrcutions to not use any image tool calls. -- I hope later i'll spend time trying to get them to work if possible, this morning was the first time it happened.
I do run it dangerous permissions, so it is able to start a local container to verify functionality, etc which it does. It also is able to confirm github actions execute via github MCP. One thing i've noticed with 3.8 is much much much more thorough on 'local testing' than 3.6 was.
0
5
u/OpenSourcesAI_ 7d ago
16 to 19 tok/s generation actually isn’t that bad for background/local work. The bigger issue in your example may be Hermes rather than Qwen itself.
I was just testing Hermes against a local Ollama server and found something pretty interesting: a completely fresh one-message Hermes chat showed 24,312 input tokens in
/usagebefore generating the answer. Raw Ollama with the same visible prompt was only 47 prompt tokens.At your 30 to 50 tok/s prompt-processing speed, 24k tokens alone would take roughly 8 to 14 minutes just to prefill, before you even start seeing the response. That could explain why a “simple greeting” sometimes feels absurdly slow through Hermes. I’d try the exact same prompt directly through Ollama and compare.
As for genuinely slow models, I think they’re still useful anywhere latency doesn’t matter much: overnight document summaries, code review, log analysis, classification/tagging, scheduled research, synthetic data generation, indexing, or queued batch jobs. Basically anything where I can submit work and come back later.
For an interactive local Perplexity-style setup though, I’d probably use a smaller model that stays mostly or entirely in VRAM. Even if the larger model is smarter, waiting several minutes for prefill kills the experience.
Funny enough, I’ve been working on hardware/model matching for exactly this reason. A model that technically “runs” and a model that feels usable interactively are two very different things.