ROCm version that finally behaves: anyone testing this?

[rocmmixer]

Good point. I ended up in about the same place using PyTorch. Worth rechecking your defaults though, because one bad assumption can make the rest of the thread look confusing.

[quantshed]

That matches what I was seeing. I ended up in about the same place using TensorRT-LLM.

[batchyard]

Good point. That matches what I saw on 5090. I got better results once I stopped chasing one metric and just looked at whether the workflow felt usable.

[batchyard]

Did a small comparison this afternoon. My result was mixed: first run looked bad, second run looked normal. The surprise was that memory pressure showed up before throughput collapsed.

[fastquill74]

A couple things I'd check first. On GB200, 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.

[macropoint]

What worked for me was pretty simple. If you're on TensorRT-LLM, I'd confirm the version first and then reduce variables until the behavior is obvious.

[phasetrack]

worth checking the driver first.

That matches what I was seeing. The pattern around HBM constraints has been pretty similar for me. The biggest change for me was simplifying the stack instead of adding one more optimization layer. Turns out 'just one more test' was a lie.

[batchyard]

Can you fill in a bit more context? Is this local-only or are you routing anything externally? Turns out 'just one more test' was a lie.

[marbleyard32]

Tried to reproduce it just now. The issue went away once I changed one setting and restarted the stack cleanly. I expected the model choice to matter more than it did.

[thetapath]

worth checking the driver first.