Posts: 36
Threads: 3
Joined: Oct 2026
Reputation:
0
Spent some time on this today and wanted to compare notes.
I've gone back and forth between llama.cpp and vLLM for Gemma. The interesting difference for me has been speculative decoding.
Trying to avoid rebuilding the whole thing twice.
I care more about stability than squeezing the last possible tokens/sec out of it.
still benchmarking everything
Posts: 40
Threads: 4
Joined: Aug 2026
Reputation:
0
Need a little more detail here. Is this local-only or are you routing anything externally?
Posts: 67
Threads: 5
Joined: Aug 2026
Reputation:
0
subscribed, curious where this lands.
curious and caffeinated
Posts: 49
Threads: 7
Joined: Oct 2026
Reputation:
0
A couple things I'd check first. On 5090, the easiest win is often to back off the aggressive settings and see whether the problem survives.
trying not to rebuild again
Posts: 33
Threads: 4
Joined: Aug 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. Not saying you're wrong, just that I wouldn't lock that in as the lesson yet.
Posts: 44
Threads: 3
Joined: Oct 2026
Reputation:
0
Ran a quick check on my box. I couldn't reproduce the slowdown until I pushed context much higher.
small models can still be good
Posts: 55
Threads: 8
Joined: Oct 2026
Reputation:
0
That matches what I was seeing. The pattern around tokens/sec has been pretty similar for me. I got better results once I stopped chasing one metric and just looked at whether the workflow felt usable.
Posts: 38
Threads: 8
Joined: Sep 2026
Reputation:
0
I think the bottleneck is somewhere else. I've seen people blame long context when the real issue was much more mundane.
Posts: 49
Threads: 7
Joined: Oct 2026
Reputation:
0
A couple questions before I guess too hard. Do you see the same thing with a smaller batch or shorter prompt?
trying not to rebuild again