22 karma · joined September 19, 2026
Definitely worth looking at if you have only a single 5090 is ninfer, and various hardware specific forks (3090, 4090).
With llama.cpp once you have the model + the runner on the same box you have from 1 ... 40+ configurations of GPUs (depending on how many gpus you have and how many sub-classes of GPUs) for basic options that will load the model. Then you can start multiplying by different batch sizes (1024, 4096, 8192), CPU thread counts (4, 8, 16), tensor splits (this can get really hairy), P2P enabled/disabled, various caching options, speculative decoding options and so on.
The effect is that you can easily spend a day or more benchmarking. On first run of a new model the software should figure this out by itself.
llama-bench is next to useless for this purpose.
The risks are:
- creating a lot of dead code - ending up with substantial repetitions (this is getting better over time but the risk is definitely still there) - testing only on the happy path rather than all execution paths - mixing current and outdated information resulting in subtly broken code - inability to reason past a certain level of complexity, but no signal that this is the case
For each of these risks there are remedies, one of the more powerful ones for me is the ability to just roll back when things have gone too far off the rails, realize in hindsight what caused it and to retry with a much better initial prompt.
What kind of hardware and what particular quant?