New drivers and libraries are landing in the official cuda-compute-repo repo pre-installed on our devices and should be live soon.
Along with CUDA 13.2
Odd – the “Supported Products” section of the driver information page makes no mention of DGX Spark.
If you want to know whether the biggest bug of the 590 series driver on DGX Spark has been fixed, the simplest way is to wait until vLLM has completely finished starting up, then press Ctrl-C to terminate vLLM, and check whether the memory is released. If it is released, then this driver is worth trying.
Release notes for CUDA 13.2 are now live, so I’ve updated the OP.
New feature in cuBLAS Release 13.2
Fixed issue
Don’t think these are official on the spark yet?
Are you seeing these being installed through the updater?
Im going to update 4 nodes to see if I can get some progress with Qwen3.5-397B. So far it’s not going smoothy..
It’s coming:
Unpacking cuda-toolkit-13-config-common (13.2.51-1) over (13.1.80-1) …
Preparing to unpack …/2-cuda-toolkit-config-common_13.2.51-1_all.deb …
Unpacking cuda-toolkit-config-common (13.2.51-1) over (13.1.80-1) …
Preparing to unpack …/3-libxnvctrl0_595.45.04-1ubuntu1_arm64.deb …
Unpacking libxnvctrl0:arm64 (595.45.04-1ubuntu1) over (590.48.01-0ubuntu1) …
Preparing to unpack …/4-nvidia-modprobe_595.45.04-1ubuntu1_arm64.deb …
Unpacking nvidia-modprobe (595.45.04-1ubuntu1) over (590.48.01-0ubuntu1) …
Preparing to unpack …/5-nvidia-settings_595.45.04-1ubuntu1_arm64.deb …
Unpacking nvidia-settings (595.45.04-1ubuntu1) over (590.48.01-0ubuntu1) …
that 595 isn’t coming through the official dgx os update path from what I can tell. the spark receives drivers via ubuntu’s restricted pocket (noble-updates/noble-security), packaged by canonical. there’s no nvidia-graphics-drivers-595 source package on launchpad yet, so it hasn’t even entered the noble-proposed pipeline.
if you’re seeing 595 install, you’re pulling from the nvidia cuda repo directly ( Index of /compute/cuda/repos/ubuntu2404/sbsa ), not the validated dgx os stack. those of us on the standard update path are still on 580 unless we opt into one of the 590 additional driver channels (experimental).
edit: also worth mentioning - the cuda 13.2 install page explicitly states that grace systems must use the open kernel module flavor (openrm). the proprietary driver is not supported on grace. make sure you’re installing nvidia-open, not cuda-drivers.
Just as a reminder (in case it was lost in the discussion here), the 595.45.04 release is a beta, so you might want to wait unless you really want to experiment.
For stable systems, I would highly recommend just waiting for driver updates through the DGX OS update channel.
agreed.
Good point, I didn’t look closely at the source since I did not add any myself, but it does indeed come from Index of /compute/cuda/repos/ubuntu2404/sbsa .
I’ve updated the OP to not give false hopes too early :)
Looks like we’re getting 580.142 today.
Got a new kernel and nvidia module versions (stable/release train updated today), first thing I’m doing is running my nvfp4 torture test to see if I get cuda exceptions.
Edit:
surprise, still throwing exceptions with flashinfer, still on marlin :(
Any update on the stable release?
Based on the links below, I thought a stable version of the GPU driver for SLES 16 had already been released. Is that correct?
Looking at the link below, it appears the latest driver version is 595.71.05. Is it safe to assume that versions 595.58.03 and later are stable?
Is there any update? Also, I have seen driver 610 released
I wonder, do you know if and when DGX Spark will receive the NVIDIA driver 595 or later and also CUDA 13.2 or maybe even CUDA 13.3 CUDA Toolkit 13.3 - Release Notes — Release Notes 13.3 documentation ?
Any plan if and when the DGX Spark will get Ubuntu 26.04LTS anytime soon?
Many thanks for all the good work, you are doing in this community!
Kind regards,
CM
I am not an expert, so blast me if Im wrong. If you use the community docker then you use cuda 13.2 libraries. To my knowledge driver 595 does not bring major (or minor) performance upgrades. As for Ubuntu 26.04, we need to give the guys a break, it may happen, but it wont directly give us more performance.
Thanks giles8, you’re right that docker handles the CUDA libraries, but driver 595+ unlocks things that container image can’t fix.
Two examples: CUDA graph capture is currently broken on SM121a with driver 580, which means vLLM has to fall back to eager mode. That’s a real throughput hit. And NVFP4 training, which is kind of the whole point of GB10’s FP4 compute, is gated at the drive level. There’s no workaround until the driver is on the host.
So for people doing inference or training workloads, this upgrade is the unlock.
Curious if @eugr_nv / @eugr has any visibility on timeline.