I am exploring the idea of building a small DGX Spark cluster using two GB10-based systems from different vendors - one from NVIDIA and one from Lenovo.
From a hardware and software perspective, they should be quite similar, but I am not sure if there are any hidden compatibility issues when clustering mixed-vendor GB10 nodes.
Has anyone here tried running a DGX Spark cluster with heterogeneous GB10 systems like this?
Did it work out of the box?
Any issues with networking, drivers, or orchestration?
Would you recommend sticking to a single vendor instead?
I would appreciate any real-world experience or advice before I proceed.
Yes, everything works without any problems in one stack. I have a DGX Spark + Asus GX10.
Everything is stable!
One clarification, to be honest. After the first launch of the Asus GX10, there was a problem with connecting to WIFI during installation (a common issue with Asus). I downloaded the image from the NVIDIA website from the DGX Spark device and installed it on the Asus GX10, and the OS on both devices became identical.
Having both the Founder’s Edition and the Dell GB10, there appears to be two major differences:
Packaging - the case and power supply are branded in line with each of the vendor. Dell provides a little sticker on the unit with the serial number / bootstrap info. Nvidia has a sticker on the paper instruction manual on the box.
Firmware - the Dell and the FE do not use the same firmware. As a result, firmware released on the FE has come out sooner than when it has come out on the Dell. I presume this is because Dell gets the firmware updates at the same time as it’s released and needs time to integrate.
There have been no issues with networking the different models together as it seems like it is the same board. The DGX OS appears to be the same and updates at the OS level arrive at the same time for both units.
Buying the same will generally help with consistency, which can be good in perhaps having fewer things to check when you’re debugging something, or which can be bad in that it may be consistently broken on both units.
I have a two-node cluster; one is the NVidia DGX Spark and the second is an HP ZGX Nano G1n.
I also upgraded the NVMe drive on my HP ZGX from 1TB to 4TB using a Corsair MP700 Micro, and reimaged it using NVidia’s recovery image, and everything worked without issues.
Like @wcw mentioned, the hardware is virtually identical except for the case, but having both being the same hardware does help with consistency, specially when it comes to firmware updates. The firmware on my HP unit was about two months behind NVidia firmware.
I can’t answer the question of Lenovo. But my cluster setting is dgx spark (4TB) as master, and gigabyte atom (1TB) as worker, the linux system is the same, so no issue operating.
But Gigabyte atom has only 119GB compare with 121GB on dgx spark, so I can’t run Qwen3.5 397b int4-autoround with 2GB missing using vllm, however I manage to run the model with gptq-int4 using sglang. If you choose Lenovo, I would suggest you make sure you get is 121GB vram.
I think another issue is with cluster. we have 3 documents for setting the cx7 connection. One is Nvidia’s playbook, the second one is eugr’s vllm docker, the third one is sparkrun. I don’t have a good time to mess with those 3 documents. Hope in the future, we can have one simple instructions for setup up the cluster. When you got the cable, make sure you connect port0 to port0, or port1 to prot1, do not connect port left to right, or right to left.
Did Gigabyte release a new firmware that might resolve this issue and release the 2GB giving you 121GB of VRAM? Supposedly, Nvidia FE had firmware that did this?
The extra memory, I think, is a firmware. If you check out the @_piotr3k article/ video we did on the GB10 cluster:
For the OP - we had up to five different types of nodes, without issue
On the cooling - we have tested 6 of the 8 available GB10 systems. Hopefully, we can do the MSI unit soon, but the Acer I have not really seen available as easily. Cooling differences are small in normal operation. If you put stress-ng or something on, you can get more than 1-4C deltas, but like we ran Kimi-K2.6 on 8 nodes for a week and they all sat within +/-3C.
We noticed a bigger delta with different firmware versions running on boxes. Any test on temps ideally is real-world workloads, but also the same firmware revisions.
Yes. For firmware updates we are depending directly on each Manufacturer. And some are faster that others in this process… 🤷
To better understand: the Manufacturer from who you bought provides you a warranty, some level of support, RMA, etc. - thus they are responsible for said firmware, including Quality Control it doesn’t break their version of the hardware - because the warranty/support/RMA costs are for them if the unit breaks due to the firmware they shipped.
Thanks for jumping in @Patrick-ServeTheHome - always better to have the original author! Given the eclectic cluster the team and you built and documented, I thought it would have been a shame not to point to this great STH article/video - which covers several “Does X work in cluster with Y?” combinations. 😇
You use fwupdmgr and update. That November 2025 firmware probably gets you up and running. Maybe think of that like an Ubuntu 26.04 ISO, but then you use something like apt update / apt dist-upgrade to go from a base to the most recent firmware. Hopefully that makes sense.
Our entire monitoring dashboard actually started as a firmware update tool because we needed something to see driver/ firmware drift.
@_piotr3k Thank you for the kind words. I will share with the team.
Hi Patrick, can you please share the command you used on running Kimi-K2.6 on 8 nodes, I tried with eugr TF5 image and I can’t get it to start. Thank you!
@ETS Thank you for provide the link. also thanks to @Patrick-ServeTheHome for more informative data. but I am sorry for my confusing, I noticed the website contains a version 2.144.9, but my version below is 1.9.31, so my question is should I manually download this version (Nov 25 of last year) or wait a new firmware update.
fwupdmgr get-history GIGABYTE AI TOP ATOM │ ├─Embedded Controller: │ │ Device ID: de4d7b5fa8e558b2b42bc28c7a6123c738949413 │ │ Previous version: 0x00000001 │ │ Update State: Success │ │ Last modified: 2026-03-27 01:13 │ │ GUID: 0cd286ff-a1c6-4b6f-8441-b05d35ff47d2 │ │ Device Flags: • Internal device │ │ • Updatable │ │ • System requires external power source │ │ • Supported on remote server │ │ • Needs a reboot after installation │ │ • Reported to remote server │ │ • Device is usable for the duration of the update │ │ • Signed Payload │ │ │ └─AITOP ATOM fused Embedded Controller Update: │ New version: 0x02004b03 │ Remote ID: lvfs │ Release ID: 132227 │ Summary: AITOP ATOM Embedded Controller Firmware Update │ License: Proprietary │ Size: 519.1 kB │ Created: 2025-11-20 │ Urgency: High │ Tested by Gigabyte: │ Tested: 2025-11-20 │ Distribution: ubuntu 24.04 │ Old version: 0x00000001 │ Version[fwupd]: 1.9.31 │ Vendor: Gigabyte │ Duration: 30 seconds │ Release Flags: • Trusted metadata │ • Tested by trusted vendor │ Description: │ This update improves the performance and stability of the AITOP ATOM Device. │ Checksum: f730428206fc97424bea8d3559c074f093529804ecddc5b3198c62739a3f2938 │