Posts: 47
Threads: 6
Joined: Sep 2026
Reputation:
0
Maybe I'm missing something obvious.
I'm trying to decide whether to keep the current stack or change course. Main question is how people here are handling batch size.
If you've tested something similar, what did you keep and what did you stop bothering with?
Posts: 29
Threads: 2
Joined: Sep 2026
Reputation:
0
Maybe, but I had the opposite result. 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. Turns out 'just one more test' was a lie.
Posts: 52
Threads: 5
Joined: Aug 2026
Reputation:
0
I don't think that's the whole story. The reported numbers can look compelling, but in ordinary usage I didn't see the same benefit. Could be a workload difference, but I wouldn't generalize too fast from one setup.
trying not to rebuild again
Posts: 41
Threads: 5
Joined: Aug 2026
Reputation:
0
What worked for me was pretty simple. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at router policy. Once you know the plain path works, then add the faster path back in piece by piece.
Posts: 42
Threads: 1
Joined: Oct 2026
Reputation:
0
I'd approach it in a boring order. On A6000, the easiest win is often to back off the aggressive settings and see whether the problem survives.
Posts: 28
Threads: 1
Joined: Sep 2026
Reputation:
0
Can you fill in a bit more context? Do you see the same thing with a smaller batch or shorter prompt?
mostly local
Posts: 51
Threads: 8
Joined: Sep 2026
Reputation:
0
What worked for me was pretty simple. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at prefill/decode split.
learning in public
Posts: 26
Threads: 5
Joined: Sep 2026
Reputation:
0
Interesting, I hadn't tried that. I don't think your conclusion is far off.