Hey everyone! I was just skimming through some inference benchmarks of other people and noticed the driver version is usually mentioned. It made me wonder how relevant this is. My prod server runs Debian 12 so the packaged nvidia drivers are rather old, but I’d prefer not to mess with the drivers if it won’t bring a benefit. Does any of you have any experience or did do some testing?
You must log in or # to comment.
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.
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.
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.
I use the the proprietary ones from Nvidia, they’re at 535 on oldstable IIRC but there are a lot newer ones.
On AMD hardware, I moved from rocm 6 to 7 and the associated amdgpu driver release and saw pretty noticeable inference performance improvements on an RX 7900 XTX 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.
EDIT: Not to mention model being run.
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 “<fast attention scheme XYZ> was deactivated because <cudaSuperOptimizedMegaSparseMatMult> 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.
