Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
prefill bottlenecks on longer prompts
#1
Thought I'd post a small recipe because a lot of threads ask similar things.

This isn't revolutionary, but the combination of vLLM and B200 felt surprisingly usable once I tuned around long context.

Feel free to tear it apart if you see something dumb.

My use case is pretty ordinary: local chat, some document work, and occasional batch jobs.
Reply
#2
What worked for me was pretty simple. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at structured output.
curious and caffeinated
Reply
#3
Quote:What worked for me was pretty simple. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at structured output.

Thanks, that helps. I don't think your conclusion is far off. I got better results once I stopped chasing one metric and just looked at whether the workflow felt usable.

If you post your exact settings, people here can probably narrow it down pretty fast.
Reply
#4
Tried to reproduce it just now. On 5090 with PyTorch, I saw basically the same behavior.
Reply
#5
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
#6
I'd start with the simpler stack.
Reply
#7
Quote:I'd start with the simpler stack.

My first guess would be this: Before rebuilding anything, I'd test one clean baseline with Mistral and compare from there. Once you know the plain path works, then add the faster path back in piece by piece.
throughput matters, but tail latency matters too
Reply
#8
My first guess would be this: On B200, the easiest win is often to back off the aggressive settings and see whether the problem survives. Not glamorous advice, but repeatable baselines save a lot of time.
curious and caffeinated
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)