RAG recall vs speed tradeoff on Threadripper box

[mintquill]

I figured I'd ask here before changing everything.

I'm trying to decide whether to keep the current stack or change course. Main question is how people here are handling router policy.

If you've tested something similar, what did you keep and what did you stop bothering with?

I care more about stability than squeezing the last possible tokens/sec out of it.

[quietsupply11]

Thanks, that helps. I don't think your conclusion is far off. The biggest change for me was simplifying the stack instead of adding one more optimization layer.

There are a few different conversations hiding inside this thread, so being explicit about the goal helps.

[cacheworks]

I'd approach it in a boring order. Before rebuilding anything, I'd test one clean baseline with Gemma and compare from there. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.

[bytestack]

I think the bottleneck is somewhere else. I get why that seems right, but on 4090 the bottleneck felt elsewhere.

[macrolab]

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. Not glamorous advice, but repeatable baselines save a lot of time.

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

[cobaltworks25]

I'd approach it in a boring order. Before rebuilding anything, I'd test one clean baseline with FLUX and compare from there. Once you know the plain path works, then add the faster path back in piece by piece.

[bytesupply76]

I'd approach it in a boring order. Before rebuilding anything, I'd test one clean baseline with FLUX and compare from there. Once you know the plain p

subscribed, curious where this lands.

[torchtrack24]

[quote]I'd approach it in a boring order. Before rebuilding anything, I'd test one clean baseline with FLUX and compare from there. Once you know the

that fixed it for me too.

[mangotinker73]

[quote][quote]I'd approach it in a boring order. Before rebuilding anything, I'd test one clean baseline with FLUX and compare from there. Once you kn

I'd approach it in a boring order. If you're on LM Studio, I'd confirm the version first and then reduce variables until the behavior is obvious. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.

[localpatch78]

Can you fill in a bit more context? Do you see the same thing with a smaller batch or shorter prompt?

There are a few different conversations hiding inside this thread, so being explicit about the goal helps.