Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
70B still worth the pain
#1
Appreciate the detail. I ended up in about the same place using vLLM. Worth rechecking your defaults though, because one bad assumption can make the rest of the thread look confusing.
Reply
#2
I'd start with the simpler stack.
Reply
#3
What worked for me was pretty simple. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at NVFP4.
learning in public
Reply
#4
Ran a quick check on my box. I couldn't reproduce the slowdown until I pushed context much higher. I expected the model choice to matter more than it did.
Reply
#5
Quote:Ran a quick check on my box. I couldn't reproduce the slowdown until I pushed context much higher. I expected the model choice to matter more than it

I don't think that's the whole story. I've seen people blame continuous batching when the real issue was much more mundane.
Reply
#6
I'd approach it in a boring order. Before rebuilding anything, I'd test one clean baseline with Mixtral and compare from there. Once you know the plain path works, then add the faster path back in piece by piece.
Reply
#7
Not sure I agree there. I get why that seems right, but on 4090 the bottleneck felt elsewhere. Not saying you're wrong, just that I wouldn't lock that in as the lesson yet.
Reply
#8
Interesting, I hadn't tried that. That matches what I saw on GB200. The biggest change for me was simplifying the stack instead of adding one more optimization layer.
Reply
#9
This keeps coming up in conversation so I figured I'd start a thread.

One thing I keep noticing is that people underestimate quant drift 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.
Reply
#10
same here on my side. At this point the real bottleneck is my patience.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)