Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
industry move that matters for local users
#1
Spent some time on this today and wanted to compare notes.

I've gone back and forth between vLLM and SGLang for Mixtral. The interesting difference for me has been tail latency.

Trying to avoid rebuilding the whole thing twice.
watching release notes so you don't have to
Reply
#2
Appreciate the detail. The pattern around tool calling has been pretty similar for me. The biggest change for me was simplifying the stack instead of adding one more optimization layer.
Reply
#3
worth checking the driver first.
learning in public
Reply
#4
I'd start with the simpler stack.
learning in public
Reply
#5
Maybe, but I had the opposite result. I wouldn't optimize around that first. On my side the bigger swing came from the runtime and not the model. Could be a workload difference, but I wouldn't generalize too fast from one setup.
Reply
#6
My first guess would be this: If you're on TensorRT-LLM, I'd confirm the version first and then reduce variables until the behavior is obvious. Once you know the plain path works, then add the faster path back in piece by piece.
LoRA tinkerer • dataset janitor
Reply
#7
I tested this tonight. The issue went away once I changed one setting and restarted the stack cleanly. The surprise was that memory pressure showed up before throughput collapsed.
Reply
#8
Quote:Spent some time on this today and wanted to compare notes.

Maybe, but I had the opposite result. I've seen people blame HBM constraints when the real issue was much more mundane.
learning in public
Reply
#9
What worked for me was pretty simple. Before rebuilding anything, I'd test one clean baseline with Qwen and compare from there. Not glamorous advice, but repeatable baselines save a lot of time.
Reply
#10
following this because I'm in the same boat.
learning in public
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)