Posts: 40
Threads: 8
Joined: Sep 2026
Reputation:
0
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 router policy decides everything downstream.
Maybe obvious to some of you, but it clicked for me this week.
My use case is pretty ordinary: local chat, some document work, and occasional batch jobs.
If I had to summarize the lesson so far, it would be that clean setup and observability beat clever guesses.
Posts: 128
Threads: 12
Joined: Sep 2026
Reputation:
0
A couple things I'd check first. Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at tokens/sec. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.
rack in the garage • local models everywhere
Posts: 28
Threads: 3
Joined: Sep 2026
Reputation:
0
Need a little more detail here. Do you see the same thing with a smaller batch or shorter prompt?
Posts: 18
Threads: 4
Joined: Aug 2026
Reputation:
0
What worked for me was pretty simple. Before rebuilding anything, I'd test one clean baseline with Mistral and compare from there.
learning in public
Posts: 43
Threads: 5
Joined: Sep 2026
Reputation:
0
I'd approach it in a boring order. Before rebuilding anything, I'd test one clean baseline with Llama and compare from there. A lot of these threads end up being one bad config plus a pile of conclusions drawn from it.
Posts: 45
Threads: 3
Joined: Sep 2026
Reputation:
0
My first guess would be this: Start by verifying the driver/runtime combo, then test with a smaller prompt, then look at prefill/decode split. Not glamorous advice, but repeatable baselines save a lot of time.
Posts: 137
Threads: 16
Joined: Sep 2026
Reputation:
0
Appreciate the detail. I ended up in about the same place using vLLM. I got better results once I stopped chasing one metric and just looked at whether the workflow felt usable.
throughput matters, but tail latency matters too