DGX Spark vs GMK Evo X5 Pro: Which Mini PC Wins for Local LLMs?
NVIDIA DGX Spark vs GMK Tech Evo X5 Pro tested on GLM 5.3, DeepSeek V4, and long-context coding agents. Here's what the numbers show.
Which is better for local LLMs, the DGX Spark or the GMK Evo X5 Pro?
For raw memory capacity and running the biggest models, the GMK Tech Evo X5 Pro wins because it ships with 192GB of unified memory in one box, versus 128GB on a single DGX Spark. For prompt processing speed, image generation, and video generation, the DGX Spark wins by a wide margin, often 1.5x to 3x faster, because it has more raw GPU compute. Neither answer is complete on its own: the right choice depends on whether your bottleneck is fitting a model in memory or waiting for it to chew through a long prompt.
TL;DR
- The GMK Tech Evo X5 Pro costs around $7,000 with 192GB of unified memory, while two linked DGX Sparks run close to $14,000, making the Evo X5 Pro roughly half the price per box and about 30% cheaper per gigabyte of memory.
- Both machines share nearly identical memory bandwidth (around 246-248 GB/s on the GPU side), so token generation speed for models that already fit in memory is close, often within about 9%.
- The DGX Spark dominates prompt processing, reading a 10,000-token file in about 12 seconds versus roughly 30 seconds on the Evo X5 Pro, a gap driven by raw GPU compute rather than bandwidth.
- Out of the box, the Evo X5 Pro’s BIOS only allocates 128GB to the GPU by default, meaning large models like GLM 5.3 (157GB) won’t load until you manually raise the UMA frame buffer setting.
- Windows Subsystem for Linux (WSL) cannot see the GPU on this AMD Strix Halo chip, dropping performance to roughly a third of native speed, so getting real GPU acceleration on Linux requires a dual boot.
- After raising the GPU memory allocation to 160GB, the Evo X5 Pro successfully runs models the Spark cannot load at all, including GLM 5.3, DeepSeek V4 Flash, and Qwen3 235B.
- For long-context coding agent work, the Evo X5 Pro held a full 262,000-token context on a 120GB model while the Spark ran out of room near 61,000 tokens, and still generated tokens 44% faster at matched context length.
Without shadow IT.
What hardware is actually inside each machine?
The DGX Spark is NVIDIA’s compact AI desktop box built around its own platform and ARM-based CPU cores, paired with 128GB of unified memory shared between CPU and GPU.
The GMK Tech Evo X5 Pro is built on AMD’s Ryzen AI Max Plus Pro 495 chip, part of the “Strix Halo” family (also nicknamed Gorgon Halo), paired with Radeon 8060S integrated graphics. GMK Tech previously shipped the Evo X2, one of the first mini PCs to use the original Strix Halo chip. The Evo X5 Pro is the next generation, with 16 x86 CPU cores versus the Spark’s 20 ARM cores, and configurations up to 192GB of unified memory (a 128GB option exists too). Port selection on the Evo X5 Pro is aimed at workstation use: USB4 on front and back, multiple USB-A ports, dual 10 Gigabit Ethernet, and HDMI output.
Both machines use a unified memory architecture, meaning CPU and GPU draw from the same physical memory pool rather than having dedicated video RAM. That single design choice is what makes the rest of this comparison interesting, because how that pool gets divided between the operating system and the GPU determines what models you can actually run.
How does memory bandwidth compare between the two?
On paper, both machines report similar memory bandwidth figures, close to 273 GB/s. Real-world GPU-side measurements land around 246 GB/s on the Evo X5 Pro and 248 GB/s on the DGX Spark, essentially a tie. Since token generation speed for models that already fit in memory is governed largely by how fast the GPU can read weights out of memory, this explains why chat-style generation speeds between the two machines are close, typically within about 9% of each other across several mid-sized models tested, including Qwen3 Coder 30B, GPT-OSS 20B, and Qwen3.6 35B.
Bandwidth parity does not mean performance parity everywhere, though. It only applies to generation, the part of inference where the model produces one token at a time. Prompt processing, the GPU-heavy work of ingesting everything you feed the model before it starts responding, is a completely different computational load and that’s where the two machines diverge sharply.
Why does prompt processing speed matter so much?
Prompt processing is the step where the model reads your input, whether that’s a pasted code file, a long chat history, or a stack of documents, before generating its first output token. Unlike generation, this work happens largely in parallel across thousands of tokens at once, so it’s limited by raw GPU compute rather than memory bandwidth.
This is where the DGX Spark pulls ahead substantially. In testing, the Evo X5 Pro was 1.5 to 3 times slower than the Spark on prompt processing across several models. A practical example: feeding a 10,000-token code file into a 27-billion-parameter dense model took around 30 seconds on the Evo X5 Pro to produce a first token, compared to about 12 seconds on the Spark. The same gap shows up in image generation (a 1024x1024 Stable Diffusion XL image took 25 seconds on the Evo X5 Pro versus 13 on the Spark) and video generation (a 5-second clip took 196 seconds on the Evo X5 Pro versus 40 on the Spark, before software fixes).
For anyone running coding agents that paste large files or maintain long conversation histories, this difference compounds every single turn.
Does the extra memory on the Evo X5 Pro actually get used?
Out of the box, no, not fully. Despite having 192GB installed, the Evo X5 Pro’s BIOS draws a line at boot time, assigning a fixed share to the GPU and the rest to the operating system. As shipped, that split gives the GPU only 128GB, identical to the DGX Spark’s entire memory pool, with the remaining 64GB reserved for Windows.
That default setting means large models like GLM 5.3 (157GB), DeepSeek V4 Flash (155GB), and Qwen3 235B (142GB) all fail to load, exactly as they would on a single DGX Spark, which simply doesn’t have enough memory for them regardless of settings.
The fix is in the GFX Configuration menu under UMA frame buffer size, where the BIOS allows raising the GPU’s share up to 160GB. With that change, all three large models load and run, pulling around 14 to 16 tokens per second depending on the model. Testing also showed that models which already fit in the default 128GB allocation saw no meaningful slowdown when given access to 160GB instead, with six out of seven models landing within about 1% either way, meaning there’s little downside to raising the limit if you plan to run bigger models.
Is Linux necessary, and does WSL work?
Most local LLM tooling and guides assume a Linux environment, so the natural instinct is to reach for Windows Subsystem for Linux rather than dual booting. On this hardware, that doesn’t work well. WSL cannot access the AMD GPU at all; Vulkan falls back to a software-only CPU implementation, and AMD’s ROCm compute layer doesn’t support the chip inside WSL.
The performance cost is severe. A small model that ran at 82 tokens per second on native Windows with GPU acceleration dropped to about 25 tokens per second under WSL running on CPU alone, roughly a third of the speed. Prompt processing suffered even more, with the GPU path hitting around 1,800 tokens per second versus about 328 tokens per second emulated on CPU inside WSL.
The practical takeaway is that getting real GPU-accelerated Linux on this box currently requires a dual boot setup, not WSL. Once dual booted, Linux turned out faster than Windows on five of seven tested models for generation speed, though Windows held a slight edge (up to 5%) in a couple of cases, a difference small enough to not matter in everyday use. Linux’s prompt processing advantage over Windows mirrored the gap seen on the DGX Spark, making it the better choice for serious workloads on this machine, once a driver-level quirk in video generation software was patched with a one-line code fix.
How do the two machines compare for coding agents and long context?
Long context windows are where the Evo X5 Pro’s extra memory pays off directly. Using a 120GB model, the Evo X5 Pro supported a full 262,000-token context window, while the DGX Spark ran out of memory around 61,000 tokens. For a coding agent, that’s the difference between holding an entire small project in context versus only a couple of files at a time.
At a matched context length of 58,000 tokens, where both machines could operate, the Evo X5 Pro generated tokens at about 25 per second compared to roughly 17.3 per second on the Spark, a 44% speed advantage once context size was equalized. Long context windows consume memory because the model retains data on every token it has processed, so machines with more usable GPU memory can sustain both longer contexts and, in this case, faster generation once that context is loaded.
Frequently Asked Questions
Can one GMK Evo X5 Pro replace two linked DGX Sparks?
For models that fit within the Evo X5 Pro’s expanded memory allocation (up to 160GB after a BIOS change), yes, a single unit can load models that don’t fit on one Spark, such as GLM 5.3 at 157GB. Whether it fully replaces a two-Spark cluster depends on whether your workload needs the Spark’s superior prompt processing speed or is more memory-bound.
Does the Evo X5 Pro need Linux to run large LLMs well?
Linux isn’t required to load large models, that’s controlled by the BIOS memory split, but Linux delivers faster prompt processing and, after a software fix, faster video generation than Windows on the same hardware. WSL does not provide GPU acceleration on this chip, so a true dual boot is needed to get Linux’s benefits.
Why is a 27-billion-parameter dense model so much slower than a 30-billion mixture-of-experts model?
Dense models activate all of their parameters for every single token, while mixture-of-experts models only activate a small subset, roughly 3 billion parameters in one tested case. Less computation per token means significantly higher generation speed on otherwise similar hardware.
What’s the actual price difference between the two setups?
A single Evo X5 Pro with 192GB of memory costs around $7,000, while two linked DGX Sparks (needed to approach similar combined memory for the largest models) cost close to $14,000. On a per-gigabyte basis, that works out to roughly $37 per gigabyte on the Evo X5 Pro versus about $54 per gigabyte on the Spark.
Does more GPU memory slow down smaller models that already fit?
No. Testing found that raising the Evo X5 Pro’s GPU memory allocation from 128GB to 160GB had almost no effect on models that already fit in the smaller allocation, with most results landing within about 1% of each other.
