Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
prefill/decode separation in practice
#1
Posting this in case it saves someone else a little time.

I'm not trying to build a perfect architecture diagram. I just want a sane starting point around vLLM and dual 3090.

Would rather learn from your scars than collect my own all at once.
Reply
#2
I'd approach it in a boring order. Before rebuilding anything, I'd test one clean baseline with DeepSeek and compare from there. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.
Reply
#3
Can you fill in a bit more context? Are you testing this on dual 3090 or something else?
throughput matters, but tail latency matters too
Reply
#4
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. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.

If you post your exact settings, people here can probably narrow it down pretty fast.
Reply
#5
Quote: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. A lot of

A couple things I'd check first. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at batch size. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.
learning in public
Reply
#6
What worked for me was pretty simple. On A6000, 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
#7
Tried to reproduce it just now. The issue went away once I changed one setting and restarted the stack cleanly. I expected the model choice to matter more than it did.
queue depth watcher
Reply
#8
I think the bottleneck is somewhere else. 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
#9
Quote:I think the bottleneck is somewhere else. I wouldn't optimize around that first. On my side the bigger swing came from the runtime and not the model.

What worked for me was pretty simple. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at quant drift. Once you know the plain path works, then add the faster path back in piece by piece.
Reply
#10
Appreciate the detail. That matches what I saw on M3 Max. I got better results once I stopped chasing one metric and just looked at whether the workflow felt usable.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)