comparing models without fooling yourself with PyTorch

[kernelarch]

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

The more I work with local setups, the more it seems like INT4 decides everything downstream.

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

[sysstation69]

following this because I'm in the same boat.

[relaynest82]

I tested this tonight. 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.

[batchsize]

A couple things I'd check first. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at prefill/decode split. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.

I'm happy to test one more variant if you want a second data point.

[benchplease]

A couple things I'd check first. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at prefill/decode split. A lo

subscribed, curious where this lands.

[batchsize]

What worked for me was pretty simple. On Threadripper box, 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.

[benchplease]

Thanks, that helps. I ended up in about the same place using TensorRT-LLM.

[cacheline]

Thanks, that helps. I ended up in about the same place using TensorRT-LLM.

Not sure I agree there. I wouldn't optimize around that first. On my side the bigger swing came from the runtime and not the model. Worth testing the simpler explanation before adopting the more interesting one.

[batchfield55]

That matches what I was seeing. I ended up in about the same place using TensorRT-LLM. The biggest change for me was simplifying the stack instead of adding one more optimization layer.

[cacheline]

Can you fill in a bit more context? What model, what runtime, and roughly what context size?