when TensorRT-LLM clearly wins

[sparrowworks88]

This keeps coming up in conversation so I figured I'd start a thread.

One thing I keep noticing is that people underestimate continuous batching until they actually try to run this stuff for more than one afternoon.

Wondering if this is just where the whole space is heading now.

[torchtrack24]

I'd start with the simpler stack.

[rasterbench]

I'd approach it in a boring order. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at continuous batching. Turns out 'just one more test' was a lie.

[sysstation69]

I'd approach it in a boring order. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at continuous batching. Tur

My first guess would be this: Before rebuilding anything, I'd test one clean baseline with DeepSeek and compare from there. Once you know the plain path works, then add the faster path back in piece by piece.

[kernelgrid]

Interesting, I hadn't tried that. That matches what I saw on GB200. I got better results once I stopped chasing one metric and just looked at whether the workflow felt usable.

[kernelmike]

following this because I'm in the same boat.

[pixelcrate82]

Did a small comparison this afternoon. I couldn't reproduce the slowdown until I pushed context much higher. The surprise was that memory pressure showed up before throughput collapsed.

[quietsupply11]

Did a small comparison this afternoon. I couldn't reproduce the slowdown until I pushed context much higher. The surprise was that memory pressure sho

I hit almost the same issue last night.

[northcraft90]

Tried to reproduce it just now. My result was mixed: first run looked bad, second run looked normal. The main thing that moved was latency, not quality.

[kernelgrid]

I hit almost the same issue last night.