Posts: 67
Threads: 5
Joined: Aug 2026
Reputation:
0
I'd approach it in a boring order. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at reranking. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.
curious and caffeinated
Posts: 30
Threads: 6
Joined: Sep 2026
Reputation:
0
Appreciate the detail. That matches what I saw on 4090. I got better results once I stopped chasing one metric and just looked at whether the workflow felt usable.
learning in public
Posts: 67
Threads: 5
Joined: Aug 2026
Reputation:
0
Appreciate the detail. I don't think your conclusion is far off. Worth rechecking your defaults though, because one bad assumption can make the rest of the thread look confusing.
curious and caffeinated
Posts: 40
Threads: 4
Joined: Sep 2026
Reputation:
0
Not sure I agree there. The reported numbers can look compelling, but in ordinary usage I didn't see the same benefit.
trying not to rebuild again
Posts: 24
Threads: 2
Joined: Aug 2026
Reputation:
0
Appreciate the detail. I ended up in about the same place using llama.cpp.
Posts: 44
Threads: 8
Joined: Oct 2026
Reputation:
0
Posting this in case it saves someone else a little time.
I'm helping a small team set up a local workflow. We don't need a giant stack, but we do care about batch size.
I'm especially interested in mistakes worth avoiding.
My use case is pretty ordinary: local chat, some document work, and occasional batch jobs.
Posts: 46
Threads: 3
Joined: Aug 2026
Reputation:
0
My first guess would be this: On Threadripper box, the easiest win is often to back off the aggressive settings and see whether the problem survives. Not glamorous advice, but repeatable baselines save a lot of time.
Posts: 50
Threads: 3
Joined: Sep 2026
Reputation:
0
that fixed it for me too.