Does an External GPU Make a Mini PC Stronger? Past 16GB the Roles Swapped
17 August 2026
Last time I measured the Radeon RX 9060 XT over Thunderbolt. Against expectation, it ran 1.3 to 1.8 times faster than the integrated GPU.
That measurement had a gap in it, though. Every model I used fitted inside GPU memory. The largest was 8.6GB, and the 9060 XT has 16GB. Half of it was never touched.
What happens when a model does not fit?
This machine carries 128GB of unified memory, and the integrated GPU can use 120GB of it. For large models the integrated one should have the advantage — but it is slower. Fast and narrow against slow and wide. I wanted to know which wins.
This is a record of what I actually measured. Taken 17 August 2026.
The earlier article is here.
The test setup
Six models, arranged to straddle the 16GB line.
| Model | Size | On the 9060 XT (16GB) |
|---|---|---|
| qwen3:14b | 8.6GB | fits |
| qwen3.6:27b | 16.2GB | just over |
| qwen3-coder:30b | 17.2GB | over |
| gemma4:31b | 18.5GB | over |
| qwen3.6:35b-a3b | 22.2GB | over |
| llama3.3:70b | 39.6GB | well over |
Smallest first, so that if something stops working, the record shows how far it got.
What I measured
What happened past 16GB
| Model | Size | 9060 XT (Thunderbolt) | 5060 Ti (OCuLink) | Integrated |
|---|---|---|---|---|
| qwen3:14b | 8.6GB | 981 | 1,698 | 748 |
| qwen3-coder:30b | 17.2GB | failed | failed | 1,226 |
| llama3.3:70b | 39.6GB | failed | failed | 116 |
Once past 16GB, both external cards stopped working.
This surprised me. I expected the overflow to spill into system memory and simply run slower. When I tried image generation on an Intel Arc B580 earlier, a 12GB card handled 2048×2048 images by shuffling weights in and out, at about 1.3 times the time.
Here it does not get slower. It does not start.
Text generation is different. Every single token passes through the whole model, so swapping cannot keep up. That, I thought, was why it refuses at load time instead.
Half of that explanation turns out to be wrong.
Changing the connection let 17.3GB run
As described in the previous article, I later moved the 9060 XT from Thunderbolt to OCuLink. The connection had changed, so I ran the measurements again.
The 17.3GB model ran.
| qwen3-coder:30b (17.3GB) | Reading | Writing |
|---|---|---|
| 9060 XT (over Thunderbolt) | failed | failed |
| 9060 XT (after moving to OCuLink) | 134 | 30.2 |
| Integrated | 1,207 | 92.7 |
It runs. But reading comes in at one ninth of the integrated GPU. Inside 16GB it was 1.3 to 1.7 times faster; the moment it spills over, this is what is left.
So “swapping cannot keep up in text generation" was half right and half wrong. It does get slow enough that swapping struggles — but the part where it therefore refuses to start was wrong. It starts, and it runs slowly. Whatever stopped it over Thunderbolt was a separate matter from capacity.
The largest model, 39.6GB, still did not run on the 9060 XT even over OCuLink. Spilling 39.6GB out of a 16GB card is evidently too much to ask.
So “OCuLink lets you exceed 16GB" is not the rule.
The error itself is explicit.
ggml_vulkan: vk::Device::allocateMemory: ErrorOutOfDeviceMemory
Out of GPU memory, in as many words. The 9060 XT (AMD) can spill into system memory; the 5060 Ti (NVIDIA) cannot. That looks like a difference in the software that drives the card, but two cards is not enough to say so firmly.
There was a detour here too. I noticed that the one card that failed was also the one card with a different power-management setting, and thought that might be it. Having already been caught out by exactly that pattern — a difference on the failing side that I never treated as a variable — I wanted to rule it out early this time.
Matching the settings and measuring again changed nothing. Same error. Power management had no part in it. The cause you think of is usually not the one.
Only the integrated GPU ran the 39.6GB model
The largest model, llama3.3:70b at 39.6GB, ran on the integrated GPU alone.
| Reading | Writing | |
|---|---|---|
| llama3.3:70b (39.6GB) | 116 | 5.3 |
| qwen3-coder:30b (17.2GB) | 1,226 | 91.7 |
Writing at 5.3 is slow enough to feel while you wait. But running at all is the point. On a 16GB card, no amount of waiting produces an answer.
The 17.2GB model runs at 91.7, which is perfectly usable. The external 9060 XT manages 30.2 on the same model. Barely crossing 16GB turns a 1.3–1.7x advantage into a third — that gap is what matters most in practice.
The boundary is not as clean as “runs or does not run". Crossing it swaps which card you want.
Three models failed for a different reason
Here is where I nearly jumped to the wrong conclusion.
Three of the six (qwen3.6:27b, gemma4:31b, qwen3.6:35b-a3b) also failed on the integrated GPU, which has 120GB available.
I started to read that as “everything past 16GB fails", but the integrated GPU failing does not fit that story. So I ran one of them by hand to see the error.
Not out of memory — the software does not support that model format. All three are relatively recent designs, and it has nothing to do with capacity.
| qwen3.6:27b / gemma4:31b / 35b-a3b | Unsupported format. Unrelated to capacity |
| qwen3-coder:30b | External failed, integrated succeeded — a real capacity wall |
| llama3.3:70b | Same |
Had I counted failures without checking why, I would have written “five of six failed on external GPUs" — which is false.
So does adding an external GPU help?
Three articles of measurements, condensed into one table.
| Model size | Faster | Gap |
|---|---|---|
| 1.2GB | External | 1.47x integrated (1/25 over Thunderbolt only — previous article) |
| 2.3–8.6GB | External | 1.6–1.7x the integrated |
| 17.3GB | Integrated | external runs at one ninth |
| 39.6GB | Integrated only | external does not run |
The answer is that the roles separate.
Adding an external GPU does not simply make the whole machine stronger. Within 16GB it genuinely helps; past that the positions swap. And running large models is exactly what a unified-memory machine is for.
Put differently, an external GPU does not cover the integrated GPU’s weakness. It extends its strength. Mid-sized models where you want speed benefit from it. Large models where you need capacity stay with the unified memory.
What I could not measure during the runs
The large-model runs here are a single pass per condition, for time reasons. Earlier articles used the average of three, so the conditions differ. Measuring the same qwen3:14b both ways gave writing speeds of 16.98 and 15.07 — about 10 percent apart. These figures are not directly comparable with the earlier ones.
I also did not verify the reason for every failure. I ran one by hand, identified the error type, and inferred that the others failed the same way.
One of them (the 22.8GB model) was re-tested after the change of connection. Same result — and it will not load on the integrated GPU either, with 120GB available. Failing with capacity to spare confirms the reading: not capacity, not the connection, but a format the software does not support.
In the post-OCuLink runs, the models above 16GB were also measured once each. I did not look at variance.
And the connection was not the only thing that changed. The OS and the model files moved from the internal drive to an external SSD (USB4, measured at 1.8 GB/s), with a reboot in between. I cannot attribute the 17.3GB model running to the change of connection alone. This article records only what changed across the move.
Normalising the measurement data was done with help from a separate workstream. The duplicate condition measured twice was found during that process.
In summary: it widens what you can run, but it does not make things faster
- Over Thunderbolt, both external cards stopped running the moment a model passed 16GB
- Moving to OCuLink let the 17.3GB model run. Reading came in at one ninth of the integrated GPU, so the advantage is gone
- Only the integrated GPU ran the 39.6GB model (writing at 5.3). OCuLink did not change that
- The 5060 Ti failed at 17.3GB on the same OCuLink. The connection is not the whole story
- The boundary is not “runs or does not run" — crossing it swaps which card you want
- Three of the six failed on format support, not capacity. Counting them together gives the wrong conclusion
- An external GPU does not fix the integrated GPU’s weakness. It extends what it is already good at
Three articles chasing an external GPU. A setup I had written off started working, the speed measurements overturned my expectation, and the capacity wall showed yet another face.
If you are weighing up adding an external GPU to a unified-memory mini PC, it comes down to what you want to run. For models that fit in 16GB, it is worth it. For large models, the unified memory on its own is the safer answer.
The hardware I used for this test
The eGPU dock the card sits in (it has both OCuLink and Thunderbolt)
[kimono_product id="16563″]
The graphics card I used for these measurements
[kimono_product id="17102″]
[kimono_product id="16082″]Test environment: GMKtec EVO-X2 (Ryzen AI Max+ 395, 128GB unified memory) / Ubuntu 24.04 / kernel 7.0.0-29 / integrated Radeon 8060S / llama.cpp (Vulkan, build dbadb68).
This article contains two sets of measurements taken over different connections.
• Over Thunderbolt (17 August 2026): RX 9060 XT on Thunderbolt, RTX 5060 Ti on OCuLink. Models above 16GB measured once per condition.
• Over OCuLink (17 August 2026): after moving the RX 9060 XT to OCuLink (32.0 GT/s x16). Once per condition. The OS and model files also moved from the internal M.2 to an external SSD (USB4) at the same time, so the connection was not the only change.
Every table states which set it comes from. Do not compare across them.