Posts: 28
Threads: 3
Joined: Sep 2026
Reputation:
0
Has anyone else run into this?
I'm trying to decide whether to keep the current stack or change course. Main question is how people here are handling VRAM headroom.
If you've tested something similar, what did you keep and what did you stop bothering with?
Posts: 168
Threads: 14
Joined: Sep 2026
Reputation:
0
Good point. The pattern around speculative decoding has been pretty similar for me. The biggest change for me was simplifying the stack instead of adding one more optimization layer.
2x3090 • llama.cpp • too much VRAM is still not enough
Posts: 51
Threads: 11
Joined: Sep 2026
Reputation:
0
Not sure I agree there. I wouldn't optimize around that first. On my side the bigger swing came from the runtime and not the model. Worth testing the simpler explanation before adopting the more interesting one.
Posts: 168
Threads: 14
Joined: Sep 2026
Reputation:
0
Tried to reproduce it just now. I couldn't reproduce the slowdown until I pushed context much higher. I expected the model choice to matter more than it did.
2x3090 • llama.cpp • too much VRAM is still not enough
Posts: 142
Threads: 20
Joined: Sep 2026
Reputation:
0
My first guess would be this: Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at NVFP4. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.
small models can still be useful