Are you using open drivers or the binary proprietary ones? As I understand it with open drivers most of the work is in the Mesa user space and trying hand built versions of that is a lot easier.
LocalLLaMA
Welcome to LocalLLaMA! Here we discuss running and developing machine learning models at home. Lets explore cutting edge open source neural network technology together.
Get support from the community! Ask questions, share prompts, discuss benchmarks, get hyped at the latest and greatest model releases! Enjoy talking about our awesome hobby.
As ambassadors of the self-hosting machine learning community, we strive to support each other and share our enthusiasm in a positive constructive way.
Rules:
Rule 1 - No harassment or personal character attacks of community members. I.E no namecalling, no generalizing entire groups of people that make up our community, no baseless personal insults.
Rule 2 - No comparing artificial intelligence/machine learning models to cryptocurrency. I.E no comparing the usefulness of models to that of NFTs, no comparing the resource usage required to train a model is anything close to maintaining a blockchain/ mining for crypto, no implying its just a fad/bubble that will leave people with nothing of value when it burst.
Rule 3 - No comparing artificial intelligence/machine learning to simple text prediction algorithms. I.E statements such as "llms are basically just simple text predictions like what your phone keyboard autocorrect uses, and they're still using the same algorithms since <over 10 years ago>.
Rule 4 - No implying that models are devoid of purpose or potential for enriching peoples lives.
If I were to guess the biggest peformance impact is if your driver doesn't support newer types like FP4 and FP8 while your hardware does, but I am not sure.
TLDR: Yes, it matters. Especially when it comes to inference and "new" features and hacks it relies on.
What GPU and what inference engine are you using?
On Debian I would use the stable version (not old stable) and I would enable nonfree firmware and also the backports version of the kernel and nonfree firmware. Then you're probably set for a year or two.
An old kernel with only free firmware likely performs much worse. Look at the release logs of the Linux kernel and any GPU driver.
If your hardware is very old, it probably doesn't matter super much. But sometimes it does (like when a manufacturer decides to unlock some sleeping feature in an old forgotten device).
I use the the proprietary ones from Nvidia, they're at 535 on oldstable IIRC but there are a lot newer ones.
I use 3xRTX2000e Ada. It's a rather new, quite power efficient GPU manufactured by PNY.
As inference engine I use exllamav3 with tabbyAPI. I like it very much because it supports 3-way tensor paralellism, making it a lot faster for me than llamacpp.
Oh, that's quite fancy hardware.
Hmm.. Unless exllama is explicitly recommended by NVIDIA for that particular GPU and setup, it seems "risky". vLLM seems to be the popular choice for most "production" systems. I'm switching from llama.cpp to vLLM because of better performance and its the engine recommended by most model providers. I don't really have the time to benchmark, so I'll just do what the documentation says. And it's really hard to do good benchmarks. Especially when "qualitative language performance" can vary for the same weights on different hardware/software.
With that kind of hardware, I would do exactly what NVIDIA and your model provider(s) say. Otherwise you might waste a lot of GPU power.
Thank you for taking the time to respond.
I've used vLLM for hosting a smaller model which could fit in two of GPUs, it was very performant especially for multiple requests at the same time. The major drawback for my setup was that it only supports tensor parallelism for 2, 4, 8, etc. GPUs and data paralellism slowed inference down considerably, at least for my cards. exllamav3 is the only engine I'm aware of which support 3-way TP.
But I'm fully with you in that vLLM seems to be the most recommended and battle-tested solution.
I might take a look at how I can safely upgrade the driver until I can afford a fourth card and switch back to vLLM.
On AMD hardware, I moved from rocm 6 to 7 and the associated amdgpu driver release and saw pretty noticeable performance improvements with llama.cpp (as of rocm 7.0.2, AMD has a Debian Trixie build, BTW).
But I imagine that AMD/Nvidia, specific hardware, application, and settings are probably all major inputs into that. YMMV.
The CUDA version is what matters the most (assuming you are on NVidia). Later CUDA versions have optimizations that earlier don't, this may in turn dictate the actual driver version you can use.
I guess some models will simply deactivate some optimizations if you don't have an appropriate version, though I mostly am aware of them failing in that case :-/
If you compare a model running on CUDA 11 vs a model running on CUDA 12, people may point out that it could be unfair, though this is generally nitpicky.
If you are worried about your perfs not being optimal, look in the log for messages like " was deactivated because was not available"
I see. When I run the inference engine containerized, will the container be able to run its own version of CUDA or use the host's version?
I am not sure, I have tried to avoid this whole situation in the last few years :-) IIRC it can have its own CUDA version, but double check that.