![]() |
|
continuous batching wins and losses - Printable Version +- Inference (https://www.datasculpting.ai/inference) +-- Forum: Inference Engines (https://www.datasculpting.ai/inference/forumdisplay.php?fid=9) +--- Forum: vLLM / SGLang (https://www.datasculpting.ai/inference/forumdisplay.php?fid=36) +--- Thread: continuous batching wins and losses (/showthread.php?tid=238) Pages:
1
2
|
continuous batching wins and losses - rocmrunner40 - 09-12-2026 Did a bit of testing and thought I'd post the result here. I tried this with FLUX using vLLM on 5090. The headline result was better than I expected, but small local stacks still ended up being the limiting factor. Curious if anyone else landed in the same place. Re: continuous batching wins and losses - signalcraft14 - 09-12-2026 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. Re: continuous batching wins and losses - cacheline - 09-15-2026 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. Re: continuous batching wins and losses - routearch - 09-15-2026 Appreciate the detail. The pattern around token cost has been pretty similar for me. The biggest change for me was simplifying the stack instead of adding one more optimization layer. Re: continuous batching wins and losses - turboarch95 - 09-15-2026 Good point. I ended up in about the same place using LM Studio. The biggest change for me was simplifying the stack instead of adding one more optimization layer. Re: continuous batching wins and losses - phasestream53 - 09-16-2026 Maybe, but I had the opposite result. I've seen people blame reranking when the real issue was much more mundane. Worth testing the simpler explanation before adopting the more interesting one. Re: continuous batching wins and losses - fusedtinker - 09-16-2026 Tried to reproduce it just now. My result was mixed: first run looked bad, second run looked normal. The surprise was that memory pressure showed up before throughput collapsed. I'm happy to test one more variant if you want a second data point. Re: continuous batching wins and losses - batchcraft - 09-16-2026 I'd approach it in a boring order. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at HBM constraints. Once you know the plain path works, then add the faster path back in piece by piece. Re: continuous batching wins and losses - promptpoint - 09-16-2026 Tried to reproduce it just now. On dual 3090 with Ollama, I saw basically the same behavior. The surprise was that memory pressure showed up before throughput collapsed. Re: continuous batching wins and losses - nanogarden - 09-19-2026 I hit almost the same issue last night. |