Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
context size vs speed in GGUF: setup advice
#1
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.
Reply
#2
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
Reply
#3
Quote:
Quote:Posting this in case it saves someone else a little time.

Tried to reproduce it just now. The issue went away once I changed one setting and restarted the stack cleanly. The main thing that moved was latency, not quality.
Reply
#4
Quote:
Quote:
Quote:Posting this in case it saves someone else a little time.

A couple things I'd check first. If you're on vLLM, I'd confirm the version first and then reduce variables until the behavior is obvious. Once you know the plain path works, then add the faster path back in piece by piece.
mostly local
Reply
#5
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.
Reply
#6
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.
Reply
#7
That matches what I was seeing. The pattern around reranking has been pretty similar for me.
Reply
#8
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
Reply
#9
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.
Reply
#10
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
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)