Running GLM 5.3 and Other Big LLMs on the GMK Tech Evo X5 Pro
How to configure BIOS memory, dual-boot Linux, and fix GPU bottlenecks on the GMK Tech Evo X5 Pro to run 150GB+ models like GLM 5.3.
Why won’t a 157GB model load on a 192GB machine?
Because the GPU doesn’t get all the memory by default. The GMK Tech Evo X5 Pro ships with 192GB of unified memory shared between CPU and GPU, but out of the box the BIOS splits that pool roughly in half: 128GB goes to the GPU, the rest stays with the system. A model like GLM 5.3, which weighs in around 157GB, simply doesn’t fit in that 128GB slice. The fix isn’t more hardware. It’s reconfiguring how the box allocates memory it already has, plus clearing a few driver and software roadblocks that show up once you try to push past the default setup.
TL;DR
- The Evo X5 Pro runs AMD’s Ryzen AI Max Plus 395 (“Gorgon Halo”) chip with 192GB of unified memory, priced around $7,000 for the 4TB storage configuration ($6,800 for 2TB), making it roughly half the cost of linking two NVIDIA DGX Sparks.
- Out of the box, the BIOS caps GPU memory at 128GB, which blocks models like GLM 5.3 (157GB), Qwen 3 235B (142GB), and DeepSeek V4 Flash (155GB) from loading at all.
- Raising the UMA frame buffer size to 160GB in BIOS (GFX Configuration menu) is what opens up enough GPU memory to actually load these larger models.
- WSL doesn’t work for GPU acceleration on this chip. Vulkan falls back to a software CPU renderer and ROCm doesn’t support the chip inside WSL, cutting token generation to roughly a third of native speed.
- A proper Ubuntu dual boot is faster than Windows for prompt processing and most token generation, but ComfyUI’s video generation ran far slower on Linux until a one-line ROCm memory-layout fix (calling
.contiguous()) brought it back to 1.5x faster than Windows. - Token generation speeds after the fix landed around 14 to 16 tokens per second for GLM 5.3, DeepSeek V4 Flash, and Qwen 235B, with memory bandwidth close to NVIDIA’s DGX Spark but notably weaker prompt processing throughput.
- Extra GPU memory doesn’t slow down smaller models that already fit, but it does buy meaningfully longer context windows, which matters more for coding agents than raw chat speed.
What’s actually inside the Evo X5 Pro?
The Evo X5 Pro is GMK Tech’s follow-up to the Evo X2, which was the first mini PC to ship with AMD’s Strix Halo chip. This generation uses the Ryzen AI Max Plus 395, internally nicknamed Gorgon Halo, paired with Radeon 8060S graphics. It’s built as a unified memory system: CPU and GPU draw from the same 192GB pool instead of having separate dedicated VRAM, similar in concept to NVIDIA’s DGX Spark.
Port selection points toward serious desktop use rather than a stripped-down appliance: dual USB4 and dual USB-A on the front, more USB4 V2 and USB-A on the back, HDMI, and dual 10 Gigabit Ethernet.
On raw compute, independent testing (cited from Level1 Techs) found the Evo X5 Pro’s 16 x86 cores outperform the DGX Spark’s 20 ARM cores on compilation and Docker workloads, beating it by around 22% on a Linux kernel build and scoring about 18% higher in 7-Zip compression benchmarks. Memory bandwidth between the two machines is nearly identical on paper (273 GB/s) and in practice (around 246-248 GB/s on the GPU side).
How do you open up more GPU memory in BIOS?
The setting that matters is called UMA frame buffer size, found under GFX Configuration in the BIOS. This value determines how much of the unified memory pool is handed to the GPU at boot, rather than reserved for the operating system.
The default allocation is 128GB. Pushing it to 160GB, the maximum the BIOS allows, is what makes room for the larger models. BIOS will warn that going this high can cause Windows stability issues related to paging file management, since Windows needs enough leftover system memory to handle its own virtual memory. If you plan to stay on Windows after making this change, you need to manually adjust page file settings to avoid instability.
With the GPU memory raised to 160GB, models that were previously impossible to load start working: GLM 5.3 (157GB), Qwen 3 235B (142GB), and DeepSeek V4 Flash (155GB) all load successfully, something the 128GB-capped DGX Spark configuration cannot do with the same files.
Why doesn’t WSL work for GPU acceleration?
Windows Subsystem for Linux seems like the obvious shortcut: get a Linux environment without dual booting. It installs cleanly and runs Ubuntu inside Windows with no partitioning required. The problem is the GPU becomes invisible to it.
Inside WSL, Vulkan falls back to LLVMpipe, a software renderer that uses the CPU to simulate GPU behavior. ROCm, AMD’s CUDA equivalent, doesn’t support this chip inside WSL at all and simply fails to initialize. The performance hit is severe: a small model like Qwen 3 4B runs at about 25 tokens per second under WSL’s CPU-only path, compared to 82 tokens per second with native GPU acceleration on Windows, a drop to roughly a third of normal speed. Prompt processing suffers even more, dropping from around 1,800 tokens per second on native Windows GPU to 328 tokens per second inside WSL.
Without shadow IT.
This isn’t a fundamental flaw in WSL itself. It comes down to AMD’s current driver support for this chip inside the WSL environment. The practical takeaway: if you want real Linux performance on this hardware, dual booting is required, not optional.
Is dual-booting Linux actually worth the hassle?
Mostly yes, with one significant catch that needed a manual fix.
Running Ubuntu 26.04 alongside Windows with identical BIOS settings (128GB GPU memory) and the same llama.cpp backend, Linux beat Windows on five out of seven tested models, sometimes by as much as 1.5x, particularly in prompt processing speed. Token generation was roughly comparable between the two, with Windows occasionally edging ahead by a small, practically unnoticeable margin (up to 5%).
Video generation was the exception, and a strange one. Running the same 5-second clip through ComfyUI, Windows finished in about 194 seconds while Linux took 316 seconds, nearly 1.6 times slower on the platform that’s supposed to be better suited to this workload. The root cause turned out to be how ComfyUI hands attention data to ROCm on Linux: the data layout in memory was inefficient, causing roughly a 15x slowdown on that specific operation. The fix was a single line of code calling a .contiguous() function to reorder the data in memory before ROCm processes it. After that one-line change, Linux completed the same clip in 126 seconds, outperforming Windows by about 1.5x. This illustrates a broader point: on hardware this new, some bottlenecks aren’t hardware limits at all, they’re software defaults that haven’t been tuned for the platform yet.
How fast does GLM 5.3 actually run once it’s loaded?
Once BIOS memory is raised and the model is running on Linux with the right backend, GLM 5.3 loads at roughly 142.8GB out of the available 160GB and runs with GPU utilization near 99%. Generation speed lands around 14.2 tokens per second. Similarly sized models performed in the same range: DeepSeek V4 Flash at 15.9 tokens per second and Qwen 3 235B at 15.8 tokens per second. Qwen 235B is a mixture-of-experts model, meaning only about 22 billion of its 235 billion parameters activate per token, which is part of why it keeps pace despite its larger overall size.
Both Vulkan and ROCm backends were tested, since both are under active development for this chip. Vulkan currently has a slight edge in most cases, though not universally.
Increasing GPU memory from 128GB to 160GB did not slow down smaller models that already fit in the smaller allocation. Six out of seven tested models showed performance within about 1% either way, meaning the extra headroom is close to “free” in terms of raw speed. Where it pays off is context length: a 120GB model like Qwen 3.8 Flash Next can use a full 262,000 token context window on the Evo X5 Pro’s larger memory pool, while a memory-constrained alternative runs out of context far sooner. For coding agents that need to hold an entire project in memory rather than a handful of files, that difference matters more than small variations in tokens-per-second.
Frequently Asked Questions
Can you run GLM 5.3 on the GMK Tech Evo X5 Pro without changing BIOS settings?
No. The default BIOS allocation gives the GPU 128GB of memory, and GLM 5.3 requires approximately 157GB. The model will fail to load until the UMA frame buffer size is raised in BIOS, with 160GB being the maximum available setting.
Does WSL support GPU acceleration on the Ryzen AI Max Plus 395?
Not currently. Vulkan falls back to a CPU-based software renderer inside WSL, and ROCm doesn’t support this chip in that environment at all. Native Linux via dual boot is required for GPU-accelerated workloads.
Is Linux faster than Windows for running large language models on this hardware?
For most tested models, yes, particularly for prompt processing, where Linux showed up to 1.5x better throughput. Token generation speeds were close between the two operating systems. Video generation workloads needed a specific ROCm memory-layout fix before Linux outperformed Windows.
Does adding more GPU memory slow down smaller models?
No. Testing showed six out of seven models performed within about 1% whether the GPU memory allocation was set to 128GB or 160GB. The main benefit of the larger allocation is supporting bigger models and longer context windows, not a tradeoff against smaller model speed.
How does the Evo X5 Pro compare to NVIDIA’s DGX Spark for running large models?
The Evo X5 Pro offers more total memory (192GB versus the Spark’s 128GB) at roughly half the cost of linking two Sparks together. It also showed faster compilation and compression benchmark results. The DGX Spark maintained an advantage in prompt processing speed and certain GPU-bound tasks like image and video generation.
