Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
vLLM vs SGLang for small teams
#1
Posting this in case it saves someone else a little time.

If you were starting from scratch today for this use case, what would you choose first and what would you ignore?

I'm especially interested in mistakes worth avoiding.

For context, I'm not chasing leaderboard numbers. I mostly want the system to feel consistent day to day.
Reply
#2
Quote:Posting this in case it saves someone else a little time.

A couple things I'd check first. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at VRAM headroom.
learning in public
Reply
#3
A couple things I'd check first. If you're on SGLang, 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.
curious and caffeinated
Reply
#4
Quote:A couple things I'd check first. If you're on SGLang, I'd confirm the version first and then reduce variables until the behavior is obvious. A lot of

I'd approach it in a boring order. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at INT4. Once you know the plain path works, then add the faster path back in piece by piece.

I'm happy to test one more variant if you want a second data point.
mostly local
Reply
#5
Quote:[quote]A couple things I'd check first. If you're on SGLang, I'd confirm the version first and then reduce variables until the behavior is obvious. A

subscribed, curious where this lands.
throughput matters, but tail latency matters too
Reply
#6
Quote:[quote][quote]A couple things I'd check first. If you're on SGLang, I'd confirm the version first and then reduce variables until the behavior is obvi

same here on my side.
Reply
#7
A couple things I'd check first. If you're on TensorRT-LLM, 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
#8
My first guess would be this: On dual 3090, 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.
mostly local
Reply
#9
What worked for me was pretty simple. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at speculative decoding. Not glamorous advice, but repeatable baselines save a lot of time.
queue depth watcher
Reply
#10
Quote:Thanks, that helps. The pattern around MoE serving has been pretty similar for me. I got better results once I stopped chasing one metric and just loo

same here on my side.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)