I strongly considered it, but the one thing that scares me away from wanting to do the spark is you basically have to use nvidia's linux (from what I've read) and it doesn't appear the nvidia is interested in upstreaming their kernel changes. I'm avoiding where possible buying electronics where support is controlled by the manufacturer and not me.
A good instinct. There are a lot of things a $500 AMD GPU can do in linux that a $5000 DGX cannot.
Nvidia DGX Spark as a daily driver
71–80 of 85 posts
Re: Nvidia DGX Spark as a daily driver
#72Earlier quoted context omitted.
It's simple, the 395+ Max Strix Halo you bought for $1800 is now a ~$4000 build (at least the AMD AI dev unit). If only we had time travel right? Either way, the Nvidia unit comes with Connect-X 7. That may or may not matter to you, but the hardware for that isn't cheap. In general the Nvidia cards also have better support for models. I know AMD is trying to catch up but anything except their datacenter cards do not…
AMD is barely trying. The 395+ Max Strix Halo was launched January 2025. gfx1151 was not listed in the ROCm compatibility matrix for ROCm 7.2.4 [0]. This is the previous version of ROCm. It's only finally received support in ROCm 7.14.0 [1]! It literally just started receiving support last week. [0] https://rocm.docs.amd.com/en/docs-7.2.4/compatibility/compat... [1] https://rocm.docs.amd.com/en/docs-7.14.0/compatibil…
Re: Nvidia DGX Spark as a daily driver
#73Earlier quoted context omitted.
But strix halo boxes themselves are available, just not that one. And despite my concerns about what's said about Cuda and ROCm I have never had a problem running any model, for image or text or voice, the community has done great work in making things work. So the point of the question stands. It's also interesting that the most high end Chinese equipment, both prosumer things like these boxes but also the Huawei pr…
> I have never had a problem running any model, for image or text or voice, the community has done great work in making things work There is a whole world of other tooling and stuff that isn't just for hobbyists to run inference with ML models, but also how to do profiling, debugging and gathering data when you run distributed workloads, and so on. The nsight toolkit seems miles ahead of the competition on other plat…
Re: Nvidia DGX Spark as a daily driver
#74Earlier quoted context omitted.
NVIDIA also cares about Hollywood and CAD/CAM shops. I learnt three times that AMD isn't necessarily better in Linux as advertised, now I don't care any longer.
A lot of Hollywood studios use renderers that jump straight to CUDA as their backend. Cycles is a popular one, as well as Renderman and Octane.
Re: Nvidia DGX Spark as a daily driver
#75Earlier quoted context omitted.
NVIDIA also cares about Hollywood and CAD/CAM shops. I learnt three times that AMD isn't necessarily better in Linux as advertised, now I don't care any longer.
I'm not aware of any commercial CAD/CAM software running Linux that Nvidia would have a money interest in supporting. Which current CAD/CAM is running on Linux with graphics? The closest I'm aware of it FEA packages allowing remote calculation on Linux machines while the GUI runs on Windows. Is that what you're referring to?
Re: Nvidia DGX Spark as a daily driver
#76I do appreciate how Nvidia tries to say close to vanilla with Linux and Android (nvidia shield). Instead of trying to build a shitty moat like Samsung with all their garbage software. If nvidia ever releases Android smartphone, I'd probably stand in line to get one.
After leaving a few of great-on-paper SoCs as paperweights I've learnt that I just don't want to deal with anyone's custom platform as I'll eventually be left with an outdated system that's annoying and time-consuming to maintain.
Re: Nvidia DGX Spark as a daily driver
#77I have a DGX and a Ryzen AI Max 395 - while I love both of them, there are a few critical things that leave the DGX in use, while the Ryzen "just" is my primary homelab server. The biggest thing is prefil numbers, and the performance impact of higher context sizes. Qwen 27b is a great model, nemotron is decent, gemma is workable. But all of them need reasonable context for reasonable outputs. Unfortunitly, as others…
Re: Nvidia DGX Spark as a daily driver
#78Earlier quoted context omitted.
AMD Strix Halo was half the price at launch, same 128GB unified memory and nearly identical memory bandwidth. It is x86, so run whichever OS your heart desires. You give up 200GB networking, but anyone 'daily driving' one of these things are probably not needing to cluster multiples of them at high speed..
I'm seeing it for 4k and up for similar specs as the spark?
For those who are interested mainly in GPU performance, the NVIDIA system may be preferable. Otherwise, the Ryzen CPU is significantly stronger in multi-threaded performance, much stronger when running applications that are aware of AVX-512, so Strix Halo is preferable when the CPU performance matters.
Also for things like video decoding or transcoding, the DGX Spark GPU is likely to be weak.
Re: Nvidia DGX Spark as a daily driver
#79Earlier quoted context omitted.
Actually, its ~119GB usable (I have one). You can shutdown a lot of unneeded services if you only use it remote which will trim a lot more fat. You can enable the RDP service if you don't want to sit in front of it but get a desktop interface. The "shitty" network is 10Gb/s and wifi7! You get a twin QSFP28DDlol+++ (I jest) that each run at 200Gb/s - not for the casual home user but handy at work, although I "only" ha…
That ~119 GB optimization is great. Hadn't seen that yet. That pops a 4x-Spark setup to 476 GB, which gives a lot more headroom for running something like GLM 5.2 at 4-bit, which isn't completely terrible. I should have prefaced my post - I almost bought four Sparks a couple months ago, but ultimately opted to buy two more RTX 6000 Pro Max-Q's. It was a painful choice because the two 6000's were more expensive than f…
That is not really true. Once you have 2 fast Ethernet ports, like DGX Spark has, you can interconnect any number of systems without using a switch.
In the simplest case, you just daisy chain the systems and you configure in Linux the Ethernet interfaces as bridges.
For better performance, you can close the chain into a ring, with an extra cable. In this case the Linux configuration is more complex, because you must do IP-level routing, preferably with a routing protocol like OSPF, to be able to double the throughput between 2 systems, by using both paths through the ring.
The only advantage of a switch is a greater throughput when there are 4 or more systems, which happens only when all the interconnected systems are attempting to communicate simultaneously, in which case having only 2 paths through a ring will serialize some of the transmissions.
When only 2 systems attempt to communicate with each other, a ring has double throughput in comparison with a switch. You need 2 switches to match the throughput that a ring has, as long as it does not become congested. Or you could use one double-sized switch, with the ports partitioned between 2 VLANs, with each DGX Spark connected to 2 ports, in different VLANs. Both 2 switches or a double-sized switch would greatly increase the price.
For only 3 systems, a switch is useless, as it is worse than connecting the systems in a triangle and configuring the IP addresses for point-to-point links (the configuration as bridges is needed only for 4 or more daisy-chained systems). The configuration with 3 DGX Sparks seems optimal from the PoV of the performance per dollar ratio.
Re: Nvidia DGX Spark as a daily driver
#80I strongly considered it, but the one thing that scares me away from wanting to do the spark is you basically have to use nvidia's linux (from what I've read) and it doesn't appear the nvidia is interested in upstreaming their kernel changes. I'm avoiding where possible buying electronics where support is controlled by the manufacturer and not me.
Many other distros almost work out of the box (as in they boot and run without any modifications). The custom kernel patches you mentioned address mainly non-critical bugs such as a bug where the Realtek r8127 stops working after a reboot (but it works if you turn it off and on again) [1] [2]. I'd consider it in a way better state than trying to run other Linux distros on certain device tree-based devices like, say,…