Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
context size vs speed in GGUF: anyone testing this?
#1
This keeps coming up in conversation so I figured I'd start a thread.

One thing I keep noticing is that people underestimate prefix caching until they actually try to run this stuff for more than one afternoon.

Maybe obvious to some of you, but it clicked for me this week.

For context, I'm not chasing leaderboard numbers. I mostly want the system to feel consistent day to day.
Reply
#2
Ran a quick check on my box. On A6000 with PyTorch, I saw basically the same behavior. The surprise was that memory pressure showed up before throughput collapsed.
Reply
#3
Thanks, that helps. That matches what I saw on M3 Max. Worth rechecking your defaults though, because one bad assumption can make the rest of the thread look confusing.
Reply
#4
Quote:Thanks, that helps. That matches what I saw on M3 Max. Worth rechecking your defaults though, because one bad assumption can make the rest of the thre

Good point. I ended up in about the same place using SGLang. Worth rechecking your defaults though, because one bad assumption can make the rest of the thread look confusing.
Reply
#5
A couple things I'd check first. If you're on LM Studio, 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
#6
My first guess would be this: If you're on LM Studio, I'd confirm the version first and then reduce variables until the behavior is obvious.
Reply
#7
A couple questions before I guess too hard. What model, what runtime, and roughly what context size?
2x3090 • llama.cpp • too much VRAM is still not enough
Reply
#8
Can you fill in a bit more context? Are you testing this on Threadripper box or something else?
Reply
#9
Quote:Can you fill in a bit more context? Are you testing this on Threadripper box or something else?

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.
Reply
#10
I'd approach it in a boring order. On B200, the easiest win is often to back off the aggressive settings and see whether the problem survives. Once you know the plain path works, then add the faster path back in piece by piece.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)