prefill bottlenecks on longer prompts

[mellowsupply]

I figured I'd ask here before changing everything.

My current setup is PyTorch with M3 Max, and I keep running into router policy.

Not looking for the perfect answer, mostly what worked in real use.

[quietarch]

Maybe, but I had the opposite result. I get why that seems right, but on GB200 the bottleneck felt elsewhere.

[deltapoint17]

Thanks, that helps. That matches what I saw on 4090.

[tinycontext]

What worked for me was pretty simple. Before rebuilding anything, I'd test one clean baseline with Gemma and compare from there. Not glamorous advice, but repeatable baselines save a lot of time.

[oxidemixer]

My first guess would be this: If you're on vLLM, I'd confirm the version first and then reduce variables until the behavior is obvious. Once you know the plain path works, then add the faster path back in piece by piece.

[amberpatch25]

Did a small comparison this afternoon. My result was mixed: first run looked bad, second run looked normal. The main thing that moved was latency, not quality.

[sanepeak48]

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

[kernelghost]

Did a small comparison this afternoon. My result was mixed: first run looked bad, second run looked normal. I expected the model choice to matter more than it did.

[pixelspark]

My first guess would be this: Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at INT4. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.

[audiopoint18]

Good point. The pattern around batch size has been pretty similar for me. The biggest change for me was simplifying the stack instead of adding one more optimization layer.