My External GPU Would Not Run Over Thunderbolt — Three GPU Generations Tested | Intel Arc B580 Local LLM Part 5
I tried running an external GPU — an eGPU, where the graphics card lives in a box outside the PC — on the machines I own, working through three graphics cards from three different generations. None of them worked over Thunderbolt. Stranger still, each of the three failed at a different point.
This article is the record of that failure. With the same GPU, the same host, and the same dock, changing nothing but the connection — Thunderbolt to OCuLink — made it work immediately. Which suggests the deciding factor is the path itself, not whatever a GPU’s compatibility list says.
The machines here are a GMKtec EVO-X2 (referred to below as the EVO-X2) and an Apple Mac mini M4. The dock is an AOOSTAR AG03, and the GPUs are an NVIDIA GeForce RTX 5060 Ti, an RTX 3060, and an Intel Arc B580. As of July 2026.
The previous article is here
- 1. The equipment
- 2. Why try an external GPU at all?
- 3. The test: three GPU generations down the same path
- 4. Result: all three stopped, but in three different places
- 5. Is there something wrong with Thunderbolt?
- 6. What decides it is the path, not the compatibility list
- 7. Wrap-up
- 8. Sources
- 9. Hardware used in this test
The equipment
The EVO-X2 mini PC acted as the host, with three GPUs of different generations attached through an AOOSTAR AG03 eGPU dock. For comparison I also checked an Apple Mac mini M4, and the same Arc B580 seated directly in a desktop PCIe slot.
The GPUs I tried
- Intel Arc B580 (12GB, Battlemage generation, 2024)
- NVIDIA GeForce RTX 5060 Ti (16GB, Blackwell generation, 2025)
- NVIDIA GeForce RTX 3060 (12GB, Ampere generation, 2021)
- For comparison: NVIDIA GeForce RTX 3090 (24GB, seated directly in a desktop)
[kimono_product id="16559″]
The PCs
| Mini PC (host) | GMKtec EVO-X2 (Ryzen AI Max+ 395 / Radeon 8060S / 128GB unified memory / Ubuntu) |
| Comparison | Apple Mac mini M4 |
| Comparison desktop | Ryzen 9 3950X / RTX 3090 (used for the Arc B580 direct-slot check) |
[kimono_product id="16082″]
The Thunderbolt box: AOOSTAR AG03
It ships with a GPU power cable, a Thunderbolt 5 cable, and a mains cable. An OCuLink cable is not included, which is worth knowing before you order.
It is a sibling of the AG01 I covered in an earlier article. Here they are side by side.
The design is almost unchanged; a USB Type-C port has been added.
Including the third sibling, the AG02, the differences look like this.
| AG01 | AG02 | AG03 | |
| Built-in PSU | 800W | 800W | 800W |
| Supported GPU power | 600W | 600W | 500W |
| OCuLink | Yes | Yes | Yes |
| Thunderbolt | No | TB4 (40Gbps) | TB5 (80Gbps) |
| Thunderbolt power delivery | — | 100W | 140W |
| USB host function | No | No | Yes |
The AG03 supplies slightly less power to the GPU, which is worth noting, but it combines power delivery with a USB host function. For a PC that runs off USB power, the AG03 works as a docking station as well.
Here are all three. I use the AG01 and the AG03; the AG02 is in the table on specifications only — I have not had one in hand (checked 1 August 2026).
[kimono_product id="16361″]
[kimono_product id="16776″]
[kimono_product id="16563″]
Why try an external GPU at all?
The EVO-X2 is a mini PC with 128GB of memory, and it has been an excellent everyday machine for local LLMs (large language models — the AI that generates text). Its integrated GPU is a Radeon, though, so anything that needs CUDA — NVIDIA’s compute platform — is off the table.
Hence the question of whether an NVIDIA or Intel GPU can be bolted on externally. The appeal is keeping the convenience of a mini PC while attaching serious GPU power only when it is needed.
The test: three GPU generations down the same path
I connected them through an AOOSTAR AG03 dock, which has both Thunderbolt 5 (referred to below as TB) and OCuLink ports. I started on the TB side, attaching the three cards in turn.
Note that the host port on the EVO-X2 is USB4 (equivalent to Thunderbolt 4, up to 40Gbps). The AG03 supports Thunderbolt 5 (up to 80Gbps), but because the EVO-X2 tops out at Thunderbolt 4 speeds, this test ran at Thunderbolt 4 bandwidth.
- NVIDIA GeForce RTX 5060 Ti — Blackwell generation (2025)
- NVIDIA GeForce RTX 3060 — Ampere generation (2021)
- Intel Arc B580 — Battlemage generation (2024)
For each card I checked, step by step: does PCI see it, can the driver take hold of it, and does computation actually run.
Result: all three stopped, but in three different places
Over TB, none of the three reached the point of computing anything. But each stopped at a different stage.
Same dock, same host: change the generation and the stopping point moves cleanly from “when computing" to “just before initialization" to “at recognition". That lined up with what I found digging afterwards.
Is there something wrong with Thunderbolt?
On a hunch I took the RTX 3060 that had failed over TB and moved it to the OCuLink port on the same AG03 dock. It worked without complaint.
| Item | Over Thunderbolt | Over OCuLink |
|---|---|---|
| PCI recognition | Yes | Yes |
| Driver initialization | Failed | Succeeded |
| nvidia-smi | Not recognized | 12GB recognized |
| VRAM window (BAR) | 256MB | 16GB |
| Actual computation | Never reached | Stable |
The decisive row is the VRAM window — the BAR, the aperture through which the CPU looks into the GPU’s memory. Over TB only 256MB opens. Over OCuLink the full 16GB does.
The feature that opens that window wide is called ReBAR (Resizable BAR). With 12GB of VRAM behind a 256MB window, the driver has no sensible way to work with the memory. Changing nothing but the connection widened the window from 256MB to 16GB — a factor of 64.
I measured the speed of the RTX 3060 once it was running over OCuLink. Here is decode speed — how fast text is generated — for the same model (nemotron-3-nano:4b) on each GPU.
[kimono_bar title="nemotron-3-nano:4b decode speed (tok/s, higher is faster)" unit="tok/s" highlight="2″ note="RTX 3090 seated directly in a desktop (CUDA), RTX 3060 over OCuLink from the EVO-X2 (CUDA), Arc B580 seated directly in a desktop (Vulkan/Mesa 26.1.5). Measured with Ollama, July 2026."]
RTX 3090 (direct slot, CUDA) | 181.41
RTX 3060 (OCuLink, CUDA) | 99.20
Arc B580 (direct slot, Vulkan) | 94.69
[/kimono_bar]
What stands out is that the RTX 3060 over OCuLink (99.20 tok/s) does not come in below the same 3060 measured earlier in a direct slot (90.6 tok/s). The gap is within what driver versions and host differences explain, so on speed, OCuLink is essentially equivalent to a PCIe slot. Across 20 minutes of monitoring there were zero Xid errors and zero bus disconnects, even under load.
What decides it is the path, not the compatibility list
I compared the three failures against what has been published elsewhere. From here on, this is research rather than my own measurement.
Each stopping point matched a known problem
The RTX 5060 Ti’s behaviour — recognized at idle, instant hang the moment CUDA runs — matches NVIDIA’s open-source driver Issue #979 (an RTX 5080 hard-locking on CUDA operations over a Thunderbolt 5 eGPU) exactly. That report is still open. So this was not me misconfiguring something; it is a known wall on the driver side.
The Arc B580’s GuC initialization failure is an unresolved problem at the kernel frontier, where Thunderbolt’s particular latency causes the exchange with the GPU’s internal microcontroller to time out. The RTX 3060’s recognition failure appears to involve the Linux mechanism that treats externally attached devices as untrusted for security reasons and forces them through the IOMMU — the layer that mediates and protects memory access.
The common thread: ReBAR was not in effect
What all three shared is that over TB the VRAM window stayed pinned at 256MB. The EVO-X2’s BIOS has no ReBAR or Above-4G setting at all. By contrast, when I put the Arc B580 into a PCIe slot on a different machine (the Ryzen 9 3950X desktop), the window opened to the full 16GB and the GPU worked completely.
ReBAR took effect or did not depending on how the card was connected, and that is what separated working from not working. “This GPU is a supported generation, so it should work" does not explain this result. How you connect it mattered more than which GPU you chose.
The OS can change the outcome too
Digging further, I found a third-party report of the same EVO-X2 with a different dock (a MINISFORUM DEG2) and an RTX 5070 Ti working under Windows. The steps involved were disabling fast startup and installing the official driver — no kernel parameters anywhere.
There are also Linux eGPU guides for the EVO-X2 (for Strix Halo platforms generally), and records from people running this configuration successfully. It is not that eGPUs cannot work on this host in principle. What failed here failed under a specific combination of hardware, OS, and dock.
Wrap-up
Three GPU generations over Thunderbolt, none of them working in this configuration. Honestly, a disappointing result.
There was something to take away, though. Moving the same RTX 3060 to the OCuLink side of the same dock widened the VRAM window from 256MB to 16GB and gave stable performance equal to a direct slot. If you want an external GPU that actually works on an EVO-X2 today, OCuLink is the reliable path.
As for Thunderbolt, there are roads I have not walked yet.
- Isolating it under Windows (comparing Linux and Windows on the same machine)
- Trying again with a different dock (a Razer Core X V2, for instance)
- Another attempt on the Apple Mac mini (the Ampere generation is said to be officially supported)
People are running eGPUs on this same EVO-X2, under both Linux and Windows. What happened here is “it did not work in this configuration", not “it cannot work". I will keep looking into external GPUs on both the EVO-X2 and the Mac mini. Ending on a note that leaves room for a follow-up sits better with me anyway.
Sources
Hardware used in this test
[kimono_product id="16082″]
[kimono_product id="16563″]