Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
structured output failures with vLLM
#1
Posting this in case it saves someone else a little time.

I'm helping a small team set up a local workflow. We don't need a giant stack, but we do care about tail latency.

I'm especially interested in mistakes worth avoiding.

I care more about stability than squeezing the last possible tokens/sec out of it.
Reply
#2
That matches what I was seeing. 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.
trying not to rebuild again
Reply
#3
Quote:[quote]Thanks, that helps. The pattern around quant drift has been pretty similar for me. I got better results once I stopped chasing one metric and j

Good point. I don't think your conclusion is far off.
Reply
#4
My first guess would be this: On GB200, 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.
Reply
#5
Ran a quick check on my box. On 5090 with TensorRT-LLM, I saw basically the same behavior. I expected the model choice to matter more than it did.
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 continuous batching. Not glamorous advice, but repeatable baselines save a lot of time.
Reply
#7
A couple things I'd check first. Before rebuilding anything, I'd test one clean baseline with Mixtral and compare from there. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.
Reply
#8
Thanks, that helps. The pattern around quant drift has been pretty similar for me. I got better results once I stopped chasing one metric and just looked at whether the workflow felt usable.
Reply
#9
Quote:Thanks, that helps. The pattern around quant drift has been pretty similar for me. I got better results once I stopped chasing one metric and just loo

Not sure I agree there. 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.
throughput matters, but tail latency matters too
Reply
#10
I don't think that's the whole story. I've seen people blame continuous batching when the real issue was much more mundane. Could be a workload difference, but I wouldn't generalize too fast from one setup.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)