Framework Desktop Gets Two R9700 GPUs via PCIe

Four lanes of PCIe Gen 4 is not a lot to work with. At 8 gigabytes per second bidirectional, it's the kind of bandwidth that makes GPU enthusiasts wince. Level1Techs built a whole system around that constraint anyway, bolting two ASUS R9700 GPUs onto a Framework Desktop via a Broadcom PLX bridge, and the result is 192 gigabytes of total addressable memory for running large AI models on consumer-adjacent hardware.

The breakdown: 128GB of unified memory on the Strix Halo platform, plus 32GB on each R9700, for 192GB total. As the video puts it: "It is 192 gigs of VRAM. That's the joke that I'm making, but it's not homogeneous anymore." That distinction matters a lot for which workloads actually benefit.

The PCIe bridge trick

The Framework Desktop's motherboard exposes a PCIe x4 Gen 4 slot. That narrow connection is the only path between the host CPU and the external GPUs. You can't widen it from the platform side, so the strategy here is to make it matter less.

The Broadcom PLX bridge (a PEX-series chipset) sits between the host and the two R9700s. The host sees one PCIe device; the GPUs see each other through the bridge at 8 lanes Gen 5, which is bandwidth-equivalent to 16 lanes of Gen 4. That GPU-to-GPU link is fast. The host-to-GPU link is still the same poky x4 Gen 4 pipe, but for workloads where the two GPUs mostly talk to each other rather than constantly ferrying data back to the CPU, that bottleneck fades.

Attempts to configure the bridge at x16/x16 didn't pan out. The current configuration runs at 8 lanes wide across multiple slots, with two slots unused. Whether four GPUs could eventually fit is an open question: BAR space limitations and BIOS constraints on the Framework side would likely need sorting first.

Connecting the bridge to the GPUs requires MCIO cables and breakout PCBs. The video is emphatic on one point: you need a full PCIe bridge, not a PCIe retimer. Retimers just clean up the signal; bridges actually multiplex and route traffic between devices. Broadcom and Astera Networks make the relevant chips. PCIe Gen 5 bridges (PEX 89 series) have become difficult to source, but the Gen 4 PLX/PEX 88 series chips can still be found on eBay. This PCIe bridge approach is the same playbook documented in AM5 multi-GPU builds, where consumer platforms get pushed well past their designed lane counts.

What runs well, what doesn't

Dense models, the kind where every parameter needs to move through the host connection repeatedly, struggle on this setup. The x4 Gen 4 link back to the platform becomes the ceiling, and you feel it.

Mixture of Experts (MoE) models are a different story. In a MoE architecture, only a subset of the model's parameters activates for any given token. That means large chunks of computation can live on the GPU pair and execute there without constantly crossing the host bottleneck. Prefill (processing the input prompt) can run on the R9700s while the Strix Halo platform handles the rest. "Because there's not really nearly as much of a bottleneck for the two GPUs communicating with one another, you can actually get some pretty good speed out of this."

The 120-billion-parameter Qwen model is the flagship test case here. It has memory structures designed to run from slower storage, including NVMe, so the working set that needs to live in fast memory is manageable. With 128GB on the platform and 64GB of VRAM across the two R9700s, there's room to offload a significant chunk into GPU memory while keeping the KV cache (the running context buffer) on the Strix Halo side. Performance on this is still being refined; the video describes it as working but not yet at its ceiling, per the Level1Techs video.

The non-MTP performance floor across tested configurations came in around 10 tokens per second. MTP (multi-token prediction, a technique for boosting throughput) can push that higher, but it also introduces accuracy tradeoffs that matter for the kinds of tasks this setup targets.

The software layer is a construction zone

Hardware headaches are tractable. Software headaches are where this project spent most of its time.

RCCL (pronounced "Rickle"), AMD's low-level GPU communication library, needs to coordinate between the Strix Halo's iGPU and the two external R9700s simultaneously. Those are different RDNA implementations, and nobody in the software stack planned for this combination. Kernel panics happened. The kworker process ate CPU. Wayland crashed.

"Why why do I love misery so much?" is a direct quote, and it sounds earned.

One unexpected finding: RCCL runs more stably behind a PCIe bridge than on native PCIe CPU connections, even on AM5 desktop platforms. The theory is that RCCL was designed assuming GPUs would be behind bridge chips (as they are in large multi-GPU server configurations), so a Broadcom PLX bridge on a mini desktop actually maps better onto RCCL's mental model than a direct CPU-to-GPU connection does. Whether that's by design or happy accident, it's a useful data point.

Peer-to-peer communication between the iGPU and discrete GPUs still has unresolved bugs as of publication. That's active development territory, not a closed issue.

What this is actually for

Level1Techs is direct about the use case: "This is an experimenters platform. This is not a path to affordable home local AI."

The target audience is researchers, lab students, people who need to debug RCCL on RDNA hardware without access to a server cluster. The video floats the idea that AMD itself could use setups like this as a dev platform for testing ROCm-plus-RDNA combinations, given that ROCm 10 just launched and RDNA software support has improved significantly over the past several months.

For RAG pipelines (retrieval-augmented generation, where a model queries a large external knowledge base), the deep memory pool is surprisingly useful. Having 64 fast VRAM gigabytes available for retrieval buffers while the Strix Halo handles inference is a configuration that doesn't obviously exist in commercial hardware at this price point.

For someone running dense models who wants fast inference and doesn't want to debug kernel panics: this is not the setup. A single high-bandwidth APU or a dedicated GPU with a large VRAM pool will serve better.

For someone who wants to run 100B+ parameter MoE models on hardware that costs less than a used car, who doesn't mind that the software stack is partially under construction, and who finds the architecture itself interesting: the Framework Desktop plus two R9700s plus a Broadcom bridge is a novel configuration that AMD's own engineers probably haven't stress-tested.

ROCm 10 just dropped. Performance numbers on this platform are still moving. The interesting question now is how much of the remaining roughness is fixable through software, and whether the next generation of AMD APU platforms will be designed with external PCIe bridge configurations in mind from the start.

By Yuki Okonkwo, AI & Machine Learning Correspondent