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.

ModelSizeOn the 9060 XT (16GB)
qwen3:14b8.6GBfits
qwen3.6:27b16.2GBjust over
qwen3-coder:30b17.2GBover
gemma4:31b18.5GBover
qwen3.6:35b-a3b22.2GBover
llama3.3:70b39.6GBwell over

Smallest first, so that if something stops working, the record shows how far it got.

What I measured

What happened past 16GB

ModelSize9060 XT
(Thunderbolt)
5060 Ti
(OCuLink)
Integrated
qwen3:14b8.6GB9811,698748
qwen3-coder:30b17.2GBfailedfailed1,226
llama3.3:70b39.6GBfailedfailed116

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.

Why image generation tolerates it and text does not
Image generation recomputes the same picture dozens of times, which apparently leaves room to swap parts of the model in and out between steps.

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)ReadingWriting
9060 XT (over Thunderbolt)failedfailed
9060 XT (after moving to OCuLink)13430.2
Integrated1,20792.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.

The 5060 Ti failed on the same OCuLink
This is the interesting part: the 5060 Ti sat on OCuLink the whole time, and it still refused the 17.3GB model.

So “OCuLink lets you exceed 16GB" is not the rule.

The error itself is explicit.

ggml_vulkan: Device memory allocation of size 920438784 failed.
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.

ReadingWriting
llama3.3:70b (39.6GB)1165.3
qwen3-coder:30b (17.2GB)1,22691.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.

llama_bench: error: failed to load model

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.

Two different conclusions, kept apart
qwen3.6:27b / gemma4:31b / 35b-a3bUnsupported format. Unrelated to capacity
qwen3-coder:30bExternal failed, integrated succeeded — a real capacity wall
llama3.3:70bSame
The evidence for a capacity wall is these two. The other three failed for a different reason, and counting them together produces the wrong answer.

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 sizeFasterGap
1.2GBExternal1.47x integrated (1/25 over Thunderbolt only — previous article)
2.3–8.6GBExternal1.6–1.7x the integrated
17.3GBIntegratedexternal runs at one ninth
39.6GBIntegrated onlyexternal 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.