Joshua Warren runs local AI on an AMD eGPU plugged into an M2 Max MacBook Pro under Omarchy
Apple all but locked eGPUs out of Apple Silicon. On Omarchy, a Radeon RX 7600 in a USB4 enclosure now loads its driver, shows up in Vulkan and runs a 7B model with llama.cpp, thanks to patches that are still up for review.
Image: joshuaswarren/omarchy-egpu (GitHub)
“Apple extremely restricted eGPUs on Apple Silicon. Until now.” That’s how Joshua Warren, of the Omarchy M team, opened his post on X on October 23, 2026. He plugged an AMD Radeon RX 7600 into a MacBook Pro and, on Omarchy, got the driver loaded, Vulkan up, and llama.cpp running Qwen2.5-7B on the card.
The details are in his new omarchy-egpu repository. The machine is a 14-inch M2 Max MacBook Pro, and the tested chain is an ASRock RX 7600 Challenger OC, an OwlTree dock and a Rosewill USB4 enclosure. According to the repo, amdgpu loads with no ring errors, RADV reports the card as AMD Radeon RX 7600 (RADV NAVI33), and llama.cpp runs on it through Vulkan.
The numbers are Joshua’s, measured on that one machine. With Qwen2.5-7B Q4_K_M, he gets 945.8 to 967.6 tokens per second on prompt processing (pp512) and 28.9 to 31.9 t/s on generation (tg128), with results varying from one boot to the next. The README says decode is limited on the GPU or driver side, not by the CPU: a test held it flat from 1 to 12 CPU threads. Why generation isn’t faster is still being investigated.
Getting there wasn’t a matter of installing a package. It took a one-line device-tree change to the PCIe tunnel’s memory window, plus kernel patches, including one that fixes a SIGBUS in the Vulkan driver. None of it is upstream. Joshua has proposed the work in linux-aurora PR #184, which is still open, and he writes there that it is “not needed for the release candidate, and there is no rush to review or merge it.”
The PR explains what was broken. On these Macs, the device trees mapped the 64-bit BAR window of USB4 tunnels 1, 2 and 3 to the wrong CPU address, so every read of the card’s VRAM came back as all-ones while the card otherwise looked healthy. The other patches teach amdgpu to cope with tunnel BARs that are mapped as non-posted device memory, where ordinary memset() and memcpy() calls hit alignment faults.
There are limits, and Joshua lists them plainly. The card was attached at boot: live cable hot-plug is untested. No display was attached to the card either, so using it as a display GPU is untested too. And since the changes aren’t published in a stock kernel, the host page notes that no stock system reproduces this yet.
His post ends with “Intel and NVIDIA GPUs next”, but the repo is already a step further on one of them. Its status matrix marks an Intel Arc Pro B60 as MEASURED on a 16-inch M1 Max MacBook Pro, with llama.cpp running on Vulkan using local xe patches. An NVIDIA RTX 5060 Ti build is compiled but has no runtime test yet, and an RX 9070 is listed as blocked.
If you want to try your own setup, the repo ships a read-only diagnostic, scripts/egpu_doctor.py, that checks the chain layer by layer: assigned memory BARs, a bound driver and a matching hardware Vulkan device. It never installs packages or changes boot entries.
The announcement came just hours after Joshua’s day 6 update on Linux for the M6 Mac mini, where Omarchy now uses the M6’s own GPU instead of software rendering.
