Posts: 42
Threads: 10
Joined: Aug 2026
Reputation:
0
Posting this in case it saves someone else a little time.
If you were starting from scratch today for this use case, what would you choose first and what would you ignore?
Simple and boring is a valid answer.
Posts: 168
Threads: 14
Joined: Sep 2026
Reputation:
0
Quote:Posting this in case it saves someone else a little time.
subscribed, curious where this lands.
2x3090 • llama.cpp • too much VRAM is still not enough
Posts: 68
Threads: 3
Joined: Sep 2026
Reputation:
0
Maybe, but I had the opposite result. I wouldn't optimize around that first. On my side the bigger swing came from the runtime and not the model. Not saying you're wrong, just that I wouldn't lock that in as the lesson yet.
Posts: 55
Threads: 6
Joined: Sep 2026
Reputation:
0
What worked for me was pretty simple. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at speculative decoding. Not glamorous advice, but repeatable baselines save a lot of time.
Posts: 41
Threads: 0
Joined: Oct 2026
Reputation:
0
That matches what I was seeing. The pattern around reranking has been pretty similar for me.
Posts: 43
Threads: 3
Joined: Sep 2026
Reputation:
0
Maybe, but I had the opposite result. I wouldn't optimize around that first. On my side the bigger swing came from the runtime and not the model. Could be a workload difference, but I wouldn't generalize too fast from one setup.
mostly local
Posts: 48
Threads: 4
Joined: Aug 2026
Reputation:
0
I'd approach it in a boring order. If you're on llama.cpp, I'd confirm the version first and then reduce variables until the behavior is obvious. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.
Posts: 168
Threads: 14
Joined: Sep 2026
Reputation:
0
Quote:I'd approach it in a boring order. If you're on llama.cpp, I'd confirm the version first and then reduce variables until the behavior is obvious. A lo
I'd start with the simpler stack.
2x3090 • llama.cpp • too much VRAM is still not enough