I purchased the DGX Spark expecting a compact workstation suitable for AI development and professional use. Unfortunately, after spending considerable time with the device, I cannot recommend it for any production or professional environment.
The most serious issue is thermal stability.
During sustained AI workloads, the system can overheat to the point where it performs a hard power-off. This is not a graceful shutdown—the machine simply loses power. For a device marketed toward AI developers and professionals, this behavior is unacceptable. A workstation should throttle performance or otherwise protect itself before reaching the point of an unexpected shutdown.
Even more frustrating is that the system does not automatically recover after such an event. Despite enabling the BIOS option for automatic power-on after power loss, the machine remains powered off and requires manual intervention. This makes unattended execution of long-running inference or training jobs unreliable.
There are several additional issues that significantly reduce the value of the platform for professional users:
Thermal reliability – The cooling solution appears insufficient for sustained high-performance AI workloads. Long-running jobs should not risk crashing the entire machine.
Memory bandwidth bottleneck – While the GPU itself is capable, real-world inference performance is often constrained by memory bandwidth, preventing the hardware from reaching the throughput many users expect from its compute specifications.
No Wake-on-LAN support – A workstation intended for remote operation should support standard remote power management. Without Wake-on-LAN, recovering from crashes or powering on the device remotely is unnecessarily difficult.
Lack of enterprise remote management – NVIDIA ships the device with Ubuntu, yet there is no integrated, officially supported remote desktop solution configured out of the box. Users are left to install and troubleshoot their own remote access software, which is surprising for a premium AI workstation. A polished remote management experience should be considered a core feature, not an afterthought.
Overall, the hardware has significant potential, but the current product feels unfinished from a workstation perspective. Reliability and manageability are just as important as raw AI performance.
Until NVIDIA addresses the thermal stability issues, improves remote management capabilities, and provides a more robust enterprise experience, I cannot recommend the DGX Spark for professional workspaces where reliability is essential. Unexpected shutdowns during long-running AI jobs are simply not acceptable for a device in this price range.
I hope NVIDIA acknowledges these issues and prioritizes firmware, thermal management, and platform improvements. At present, however, my experience has been disappointing, and I would advise organizations to carefully evaluate alternative AI workstations if uninterrupted operation is a requirement.
It’s rough to find out your choice isn’t going to work out for you, although that’s a broad brush to paint everyone’s experience. Maybe try to RMA your box for service or replacement.
My small b2b2c has processed (maybe tens of) billions of tokens over the last ~6 months with 1 spark being guided to perform daily, through nightly unattended workloads. For 1 small, low powered AIO, it’s paid for itself and then some.
It is a developer box and designed for small to medium-sized businesses at most. In a cooled server room, the box runs 100% stable. Otherwise, even at 35°C, it works with sudonvidia-smi -lgc 0,2000 asolout stable. “Working Horse” .
Are you the author of the blog post? This sentence puzzle me:
Last night one of our nodes just vanished. SSH dropped, no ping response, telemetry gap. An hour later it came back on its own, GPU at 39°C, sitting in idle. Classic thermal shutdown.
So, the Spark recovered about an hour later without any user intervention!?
Device could be in bootloop. I encountered that. My ascent gx10 was couldn’t leave the bootloop for a few hours. Discovered that when opened boot logs.
This is actually the typical OOM pattern. People usually don’t wait it out; the responsiveness goes to zero but it typically isn’t a hard hang - after a while thrashing (can be tens of minutes or a couple hours) it generally terminates the process/container and recovers. However, if you had a Docker container doing that set up to auto-restart it can seem to permanently hang.
Note that I haven’t OOMed since the most recent update which may have changed the above.
Odd I ran 4 nodes at over 90% utilization for 7+ days with 0 issue. Though I do have mine fully racked and properly cooled like you’d treat anything with “professional” workloads on them.
If you care about stability, take a look at that… GB10 looks to be overclocked to a max in order to hit the advertised 1PFlop FP4 performance, but in real-world inference, the “downclock” barely (if at all) affects performance but can reduce power to half and consequently, temperatures.
I don’t think these statements are accurate for most users. My Spark has been running 24/7 since Nov and has never oveeheated or crashed even once. It sits in my server rack and I can RDP into it if I want, but 99.9% of the time I just ssh. It runs Ubuntu so turning on RDP is literally like one click in the settings.
As for the memory bandwidth, I mean I personally don’t understand why this is a topic. It’s not like this spec was a secret. It is a tradeoff. If you want 128GB of GDDR7 then I would suggest getting a different more expensive device.
For me the Spark is great for trying out new models, new training frameworks, and general messing around. I have other machines for production workflows but the Spark is an important part of my dev pipeline.
Underclocking should not affect decode speed at all as unless you run insane amount of concurrents GPU is just chilling at this phase as it’s being ram speed bound . It would affect preprocessing where GPU works at 100%. But in practice the difference appears to be non material.
I think it should be enough to reproduce the issue by running Ollama in a docker passing --gpu=all with two models (for example, gpt-oss:20B and Qwen3-Coder) and sending around 10–15 concurrent requests to each. That represents a realistic AI workload rather than an artificial stress test.
After reading the forum and the responses, I came to the conclusion that perhaps NVIDIA should ship the DGX Spark together with a refrigerator. 🙂
That said, I do appreciate that it fills an important gap in the market by providing a compact AI system with a GPU that can be used directly from containers. That was one of the main reasons I bought it. Unfortunately, I am still disappointed with the overall solution.
I intentionally didn’t mention in the title that this is my subjective personal opinion—just as NVIDIA doesn’t mention these critical limitations on the product page. 🙂
I genuinely believed the DGX Spark would become the real competitor and the final answer to the “crying wall” discussion here:
Unfortunately, in my opinion, it isn’t there yet.
And since we’re ending on a lighter note, I couldn’t resist sharing this imaginary conversation:
Apple engineers’ small talk:
Mark: Hey John.
John: Hey Mark.
Mark: Have you heard NVIDIA released the DGX Spark?
John: Yes. Can we buy one?
Mark: Sure. It’s expensive, so it’s worth to test it, let’s give it a try.
Later that day…
Mark: I’ve got one. Let’s have some fun.
John: Great, let’s test it.
testing…
testing…
John: Ok we’ve done, so, what’s the conclusion?
Mark: I think we can safely increase our prices. 🙂
As an active AI user of Apple’s M5 Max I can confidently say it can only dream to perform as well as one Spark. From weak GPU (60 TFLOPS vs 210-250 TFLOPS realistically on Spark) to terrible kv cache and attention management in MLX. Llamacpp works decent but unless you run MLX-optimized models (which has same kv-cache and attention balooning issues as it uses MLX-LM) its much slower and negates the whole deal.
PS realistic example - running Qwen 3.6 27B in Q8 - takes 29GB ram, system has 128GB, about 16GB is normal overhead, OS, apps, so at least 80 GB is available for attention and cache. Yet it barely can fit 500k tokens (and its terribly slow past 200k, quality use is under 100k). Because it keeps everything in BF32. Using TurboQuant degrades model quality hard even in Q8 kv, and slows down by 20-25%
Yes same model on spark takes about 36GB ram for 1M kv cache tokens in q8. So it can fit 2M. Yes generation is slower on spark on low context (21 t/s with MTP vs 36-40 t/s on M5) but past 100-150k Mac is slower than spark in in generation, and decode is laughably slower on Mac.
So Apple comparison is not in favor of Apple. Before you mention M3 Ultra - M5 Max is pretty much same performance of GPU as M3 Ultra (2x M3 Max), while Ultra has 800GB/s ram vs 612 GB/s on M5, but it only slightly affects generation, not decode where it sucks.
Fair comparison is with DGX Station of multi-RTX 6000 Pro system. But then compare the cost and you have your answer. No free cheese.
Agree it depends, but I am just saying I encountered to many issues so far, and this power off on temperature just fulfilled my bucket. I know there are some tweaks about swap or so but I think this should be resistant since the beginning cause poweroff is the worst what can be done.
And reality on TG is here while true that processing input is incredible in speed on Spark the token generation is slower just because of this memory bandwidth as far as I found.
If you accept the fact this has been positioned as a developer box, not professional inference box and priced as such with known sacrifices (RAM speed to make it cheaper) and form factor to be portable and desk-friendly (cooling) then all it takes is changing the way you approach and think about it to be at peace with it. It took me at least 2-3 weeks to get proficient with it, but only because I haven’t touched Linux in 20 years aside of small vps configurations for private vpn or similar services. And finding this forum accelerated my learning a lot. I started with official Nvidia cookbooks and spent a lot of time struggling with NIM inference (got it working but it’s a really bad fit for spark), custom builds of SGLang and CUDA kernels. Then I found this forum (lol it was always available on same nvidia website where cookbooks are - just never looked there for few weeks) and everything sped up 500%.
If you get it working - it will keep working just fine. I can only speak of running 1 box or 2-box cluster but once learning is done I consider it a very reliable platform.
About cooling - this is normal. I built a PC with water cooled CPU to avoid having my RTX 5070Ti overheating and never had a termal event since. DC-grade systems are expected to be properly cooled, not internally cooled. Spark sits in between and only asking for a little bit of love and care. A Desk Fan helps enormously if you have them on desk. Cooling in rack is even easier.
m5 max supports nvfp4, for qwen3.6 27b nvfp4 (nvidia release) it matches spark PP speed (LM Studio, MLX), 1-1.2k PP, both on 0 depth.
If you will hammer mbp 16" 8 hours continuously it will overheat, same with dgx. the only thing about macbooks, trick from intel era, placing macbook on rubber water bag filled with cold water still works.