My External GPU Ran at 1/25 the Speed of the Integrated One – Changing the Cable Made It 36x Faster
17 August 2026
Last time the Radeon RX 9060 XT finally started working over Thunderbolt. The cause turned out to be a boot setting I had left behind myself.
Now that it runs, the next thing is to measure it.
My expectation going in was simple. Thunderbolt is a narrow pipe, so it should be slower. The link even reports itself as “2.5 GT/s x1", which is the slowest state the standard allows. The card on OCuLink in the same machine reports “16.0 GT/s x4", so the gap looked obvious.
The measurements said otherwise. And I went on to blame the wrong culprit and publish that conclusion. This is the record, including that part.
This is a record of what I actually measured. Taken 16–17 August 2026.
How much does the way you connect a GPU actually change the speed? I measured the same card both ways.
The earlier article is here.
- 1. The test setup
- 2. What I measured
- 2.1. The result changes with model size
- 2.2. Above 2.3GB, Thunderbolt still beats the integrated GPU
- 2.3. Only the 1.2GB model is abnormally slow
- 2.4. The decisive comparison was within the same GPU
- 2.5. Changing the connection made it disappear
- 2.6. The longer the text, the wider the gap
- 2.7. Writing speed loses, plainly
- 2.8. Power draw: how much each connection actually used
- 3. What I could not measure during the runs
- 4. In summary: changing the connection made it 36x faster
- 5. The hardware I used for this test
The test setup
The same machine has three GPUs attached in three different ways. I compared them under identical conditions.
| GPU | Connection | Memory |
|---|---|---|
| Radeon RX 9060 XT | Thunderbolt | 16GB GDDR6 |
| GeForce RTX 5060 Ti | OCuLink | 16GB |
| Radeon 8060S | Integrated (unified memory) | 120GB usable |
Two things get measured: how fast it reads (prompt processing) and how fast it writes (generation). The first matters when you feed it a long document; the second when you are waiting for a reply.
What I measured
The result changes with model size
Reading speed first. Higher is faster.
| Model | Size | 9060 XT (Thunderbolt) | 5060 Ti (OCuLink) | Integrated |
|---|---|---|---|---|
| llama3.2:1b | 1.2GB | 299 | 21,184 | 7,270 |
| phi4-mini | 2.3GB | 4,142 | 6,063 | 2,356 |
| nemotron-3-nano | 2.6GB | 2,355 | 3,551 | 1,400 |
| qwen3:8b | 4.9GB | 2,045 | 3,316 | 1,217 |
| qwen3:14b | 8.6GB | 974 | 1,698 | 741 |
Only the top row looks wrong.
Above 2.3GB, Thunderbolt still beats the integrated GPU
Expressed as a ratio against the integrated GPU, it is clear.
| Model size | 9060 XT relative to integrated |
|---|---|
| 1.2GB | 0.04x (one twenty-fifth) |
| 2.3GB | 1.76x |
| 2.6GB | 1.68x |
| 4.9GB | 1.68x |
| 8.6GB | 1.31x |
From 2.3GB up, it is consistently 1.3 to 1.8 times faster. Even over that “narrow pipe", the external card beats the integrated GPU. That was not what I expected.
It loses to the 5060 Ti on OCuLink, but only by 1.5–1.7x. Nothing like an order of magnitude.
Only the 1.2GB model is abnormally slow
Back to that first row. One twenty-fifth of the integrated GPU, when everything else sits around 1.7x. The order is reversed.
My first thought was that a small model does so little work per call that communication latency dominates. Thunderbolt suffers more from latency than from bandwidth, so that story fit.
There is a clean way to test it: keep the model the same and change only the amount of work. If latency is the cause, the gap should shrink as the work grows.
I varied the prompt length by a factor of 64.
| Prompt length | llama3.2:1b (1.2GB) gap | qwen3:8b (4.9GB) gap |
|---|---|---|
| 64 | 31.5x | 1.3x |
| 512 | 71.5x | 1.6x |
| 4096 | 67.7x | 1.7x |
Sixty-four times the work, and the gap did not shrink. It widened, then flattened. The latency explanation is dead.
The decisive comparison was within the same GPU
Comparing connections or model sizes was less useful than lining up two numbers from the same 9060 XT.
| llama3.2:1b (1.2GB, small) | 299 |
| qwen3:8b (4.9GB, four times larger) | 2,045 |
And the same llama3.2:1b runs at 7,270 on the integrated GPU and 21,184 on the OCuLink 5060 Ti. The 9060 XT is the only card that is unusually slow with this model.
Here is the conclusion I drew. The connection is not the problem. Something goes wrong in this particular combination of GPU and model. The 9060 XT is a recent generation, so some path used by small models is probably not yet well optimised for it.
I varied the conditions too, to be sure. Batch size sixteen times larger, then halved. Flash Attention on, then off. Different CPU thread counts. Six variations, and none of them helped.
If nothing moves it, no setting is going to. That is what I thought when I wrote this up.
Changing the connection made it disappear
Afterwards I moved the 9060 XT to its permanent home. Thunderbolt came off, and OCuLink went on — a cable that carries the PCIe lanes out directly, so the card reports “32.0 GT/s x16", the same as an internal slot.
The connection had changed, so I ran the same measurements again. I expected the numbers to shift a little.
| Over Thunderbolt | 299 | 1/25 of integrated |
| After moving to OCuLink | 10,668 | 1.47x integrated |
Thirty-six times faster. Same GPU, same model, only the cable changed.
My reasoning had a hole in it. I argued “only the 9060 XT is slow with this model, so it must be the GPU" — but the two cards I compared also differed in how they were connected. The 9060 XT was on Thunderbolt, the 5060 Ti on OCuLink. GPU and connection moved together, and that comparison could not separate them.
The six conditions I varied were all inside the same setup, too. The one variable that mattered was the one I never touched.
The connection is the likeliest explanation, but this measurement cannot prove it was the only one. I got the last conclusion wrong by stating it too firmly, so this time I am leaving it open.
One thing the connection does not explain remains. The 5060 Ti was on OCuLink from start to finish, and it still failed under some conditions. Moving to OCuLink does not make everything work. That story belongs to the next article.
The longer the text, the wider the gap
Everything so far was measured from a clean start. Real use is not like that. A conversation accumulates what came before, and feeding in a document means starting with a long text already loaded.
So I measured again, varying how much text was already loaded.
| Text already loaded (qwen3:8b, 4.9GB) | 9060 XT (OCuLink) | Integrated | Ratio |
|---|---|---|---|
| 0 (clean start) | 2,087 | 1,196 | 1.75x |
| 4,096 | 1,656 | 761 | 2.18x |
| 16,384 | 1,047 | 308 | 3.40x |
The gap widens as the text grows. What was 1.75x becomes 3.40x at 16,384.
Both slow down. But the integrated GPU falls off far more steeply: the external card went from 2,087 to 1,047, while the integrated one dropped from 1,196 to 308.
The 8.6GB model behaves the same way, widening from 1.62x to 3.26x.
Feeding in long documents, holding a running conversation, batching work through. The more your use looks like that, the more an external card earns its place.
Earlier in this article I wrote that it suits reading long documents and summarising them. That was a guess at the time. Here it finally has numbers behind it.
This depth sweep was run by a separate workstream on my behalf. I handed over the benchmark wrapper and the device-selection method I had used, so the conditions match.
Writing speed loses, plainly
Reading held up well. Generation did not.
| Model | 9060 XT (Thunderbolt) | 5060 Ti (OCuLink) | Integrated |
|---|---|---|---|
| qwen3:14b (8.6GB) | 15.1 | 43.9 | 24.5 |
One third of the 5060 Ti, six tenths of the integrated GPU. Generation is governed by memory throughput, so the gap shows up honestly here.
Fast at reading, slow at writing. Which way it goes depends on what you are doing. Feeding it a long document to summarise suits it. Waiting on a conversational reply does not.
Power draw: how much each connection actually used
| GPU | Idle | Peak under load |
|---|---|---|
| RX 9060 XT (Thunderbolt) | 8W | 160W |
| RTX 5060 Ti (OCuLink) | — | 157W |
| Integrated Radeon 8060S | — | 118W |
The two external cards land in the same place; the integrated one is lower. It shares its power budget with the CPU, so its ceiling is different.
What I could not measure during the runs
Measurements use llama.cpp’s benchmark mode, three runs per condition. Nothing goes through ollama, so these figures may not match what you see when running models through ollama.
Model load time could not be measured
I wanted to measure how long loading a model takes. If Thunderbolt is the narrow part, pushing a large amount of data across it is exactly where the gap should appear.
But the attempt hangs.
So it is not “slow" — it is “does not finish". This survived the power-management fix from the previous article.
That means there is no load-time figure here. Though failing to measure it is itself a result.
The speeds in this article were measurable only because the method I happened to use does not go through that path. Loading models over a Thunderbolt-attached GPU is not currently reliable — worth knowing before you buy.
I did re-test this after moving to OCuLink. Here is what came back.
| Load time (qwen3:8b, 4.9GB) | 1st | 2nd | 3rd |
|---|---|---|---|
| 9060 XT (OCuLink) | 2.22s | 1.91s | 1.91s |
| 5060 Ti (OCuLink) | 5.22s | 2.31s | 2.32s |
| Integrated | 2.41s | 2.22s | 2.21s |
It loads fine. The 9060 XT is in fact the quickest of the three. What never finished over Thunderbolt now takes two seconds.
The flag I had chosen turns conversation mode off, but it still waits for input after writing its reply. Switching to the “run one turn and exit" flag finished the job in two seconds. What was stalling was my command, not the hardware.
Keeping one control in the set is what caught it. When everything fails identically, suspect your own hand before the tools.
This does not explain why it never finished over Thunderbolt — I may well have been using the same wrong flag then. I am recording only the fact that it loads in two seconds over OCuLink.
Power was measured as described above, after discarding and redoing the first run. Each GPU is read from its own sensor.
At this point the cause of the slowdown on the 1.2GB model had not been identified. I had confirmed that six different conditions failed to improve it.
| Condition changed | llama3.2:1b | qwen3:8b (control) |
|---|---|---|
| Default | 294 | 2,039 |
| Batch size x16 | 294 | 1,968 |
| Batch size halved | 278 | 1,950 |
| Flash attention on | 294 | 2,039 |
| Flash attention off | 175 | — |
| CPU thread count changed | 292 | — |
It sits at around 294 under every condition. My working theory was that small chunks of work were being dispatched inefficiently and batching would fix it — but a sixteen-fold batch size changed nothing. That theory is dead.
Under the same conditions qwen3:8b holds a steady 1.6–1.7x over the integrated GPU, so neither the GPU nor the environment is broken.
I only have one model in the 1–2GB range here, so whether this affects that size class generally or just this model, I did not know. I intended to leave it open rather than guess.
Changing the connection afterwards made it disappear, which at least rules out a property of the model itself. Reading the six conditions back, they were all variations inside one setup. The variable that mattered was not in the table.
Varying conditions when something will not work is a natural way to proceed. But it is worth asking now and then whether you have quietly fenced off the range you are varying.
Data normalisation for these measurements was done with help from a separate workstream.
In summary: changing the connection made it 36x faster
- Over Thunderbolt it is still 1.3–1.8x faster than the integrated GPU (models of 2.3GB and up). The “narrow pipe means slow" expectation was wrong
- The gap to OCuLink is only 1.5–1.7x — not an order of magnitude
- Only the 1.2GB model is abnormal, at one twenty-fifth of the integrated GPU
- Sixty-four times the work did not shrink the gap, so latency is not the explanation
- Six varied conditions changed nothing, so I concluded it was the GPU and model combination
- That conclusion was wrong. Moving to OCuLink took 299 to 10,668 — thirty-six times, and the anomaly was gone
- The two cards I compared differed in both GPU and connection, so the comparison could not separate them. All six varied conditions sat inside the same setup
- The OS drive moved at the same time, so I am not claiming the connection alone caused it
- Generation runs at a third of the 5060 Ti. Fast at reading, slow at writing
Before measuring, I believed Thunderbolt was slow because the pipe is narrow. The reported link speed appeared to confirm it.
Measured, the connection barely mattered and the cause was somewhere else entirely. Had I accepted the number the system reported, I would have written down the wrong conclusion.
Next: the 16GB capacity wall. Every model here fitted in GPU memory. What happens when one does not?
The hardware I used for this test
The eGPU dock the card sits in (it has both OCuLink and Thunderbolt)
AOOSTAR AG03 eGPU Dock (OCuLink + Thunderbolt 5)Has both OCuLink and Thunderbolt 5
As an Amazon Associate we earn from qualifying purchases.
The graphics card I used for these measurements
GMKtec EVO-X2 (Ryzen AI Max+ 395 / 128GB / 2TB)128GB unified memory mini PC
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 (16–17 August 2026): RX 9060 XT on Thunderbolt, RTX 5060 Ti on OCuLink. Median of three runs per condition.
• Over OCuLink (17 August 2026): after moving the RX 9060 XT to OCuLink (32.0 GT/s x16). 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.
• The depth sweep (17–18 August 2026): over OCuLink, run by a separate workstream using the same tooling and device selection.
Every table and chart states which set it comes from. Do not compare across them.







Discussion
New Comments
No comments yet. Be the first one!