+- Inference (https://www.datasculpting.ai/inference)
+-- Forum: Optimization & Performance (https://www.datasculpting.ai/inference/forumdisplay.php?fid=10)
+--- Forum: Performance Tuning (https://www.datasculpting.ai/inference/forumdisplay.php?fid=42)
+--- Thread: consumer GPU serving economics (/showthread.php?tid=1109)
consumer GPU serving economics - cudapeak - 10-13-2026
Did a bit of testing and thought I'd post the result here.
After a few runs on 5090, I ended up with decent performance, but the setup only really made sense once I adjusted around router policy.
Curious if anyone else landed in the same place.
Re: consumer GPU serving economics - kernelmike - 10-13-2026
Not sure I agree there. The reported numbers can look compelling, but in ordinary usage I didn't see the same benefit. Not saying you're wrong, just that I wouldn't lock that in as the lesson yet.
Re: consumer GPU serving economics - batchsize - 10-13-2026
Quote:Not sure I agree there. The reported numbers can look compelling, but in ordinary usage I didn't see the same benefit. Not saying you're wrong, just t
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. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.
Re: consumer GPU serving economics - ggufwire22 - 10-14-2026
Quote:[quote]Not sure I agree there. The reported numbers can look compelling, but in ordinary usage I didn't see the same benefit. Not saying you're wrong,
What worked for me was pretty simple. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at prefix caching. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.
Re: consumer GPU serving economics - localpatch78 - 10-14-2026
Quote:[quote][quote]Not sure I agree there. The reported numbers can look compelling, but in ordinary usage I didn't see the same benefit. Not saying you're
My first guess would be this: Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at tail latency. Once you know the plain path works, then add the faster path back in piece by piece.
There are a few different conversations hiding inside this thread, so being explicit about the goal helps.
Re: consumer GPU serving economics - localpatch - 10-17-2026
Ran a quick check on my box. On A6000 with Ollama, I saw basically the same behavior. The main thing that moved was latency, not quality.
Re: consumer GPU serving economics - rocmpath - 10-18-2026
Quote:Ran a quick check on my box. On A6000 with Ollama, I saw basically the same behavior. The main thing that moved was latency, not quality.
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. Could be a workload difference, but I wouldn't generalize too fast from one setup.
Re: consumer GPU serving economics - localpatch78 - 10-18-2026
Interesting, I hadn't tried that. I don't think your conclusion is far off. The biggest change for me was simplifying the stack instead of adding one more optimization layer.
Re: consumer GPU serving economics - sparrowshed - 10-19-2026
My first guess would be this: Before rebuilding anything, I'd test one clean baseline with Phi and compare from there.