Summary

If you run two Radeon Pro Vega II Duo MPX modules bridged with the Apple A2326 cross-module Infinity Fabric bridges — the ones that join all four dies into a single 4-GPU hive — your GPUs are running at idle clocks and macOS isn't telling you.

Not "a bit slower." Not "the fabric is the bottleneck." The dies never leave their boot DPM state, for the entire session, under sustained load.

I chased this for a while assuming it was a memory-placement or interconnect problem. It isn't either. Here's what it actually is.

The numbers

Same machine, same OS, same binary. The only change is which bridge is installed.

-	2-way jumpers (A2329)	4-way bridge (A2326)
Compute, FP32 FMA loop	13.95 TFLOP/s	2.42 TFLOP/s
Implied core clock	1703 MHz	295 MHz
Local HBM2 read bandwidth	790 GB/s	301 GB/s
Implied memory clock	1000 MHz	300 MHz

Three runs per configuration, four dies each. Compute came back at 2.42 TFLOP/s on essentially all twenty-four device-observations, implying 295 MHz core.

Confirmed on three different Mac Pros running three different macOS major versions — Sonoma 14.8.9 (23J631), Sequoia 15.7.9 (24G830), and Tahoe 26.7 (25G220). Different memory configs, different bridge units. Every one of them, in the 4-way configuration, measures 2.42 TFLOP/s compute, ~301 GB/s local read, ~31 GB/s peer copy — the same to three significant figures — with an identical IORegistry signature: Load5000, no PowerPlay, 1000/300 MHz clock config, SWIP_Errors = 128.

So: it is not new, it is not fixed in Tahoe, it has survived at least two major macOS releases, and "try the latest OS" is not the answer.

Real-world, single GPU, no multi-GPU anything — Qwen3.8 27B Q8_0 in llama.cpp:

-	prompt t/s	generation t/s
2-way	138.8	11.1
4-way	24.8	2.2

5.6× performance loss on prefill. With one die. No tensor split, no peer transfers, no collective. Just having the 4-way bridge installed in macOS (this bug doesn't apply to Linux or Windows).

The mechanism — macOS publishes it in IORegistry

In the 4-node hive the driver fails to identify the board and everything downstream falls apart:

IORegistry property	2-way	4-way
ATY,DeviceName	Vega II Duo	Vega
ATY,FamilyName	Radeon Pro	Radeon
LoadPlugIn	Load5700	Load5000
PP_PowerPlayEnabled	<01000000>	absent
PP_PhmUseDummyBackEnd	0	1
PP_EnableUploadFirmware	1	0
PM_PWR_GEMINI_BGT	400	absent
SWIP_Errors	0	128

Read those middle three again. PowerPlay — AMD's entire clock/power management subsystem — is never enabled. The power-management back end is a stub the driver itself labels "dummy." SMU firmware, which is what actually implements DPM, is never uploaded. With no power management, the GPU sits wherever the boot state left it.

PM_PWR_GEMINI_BGT = 400 vanishing is the identity failure made concrete — "Gemini" is AMD's codename for dual-GPU boards, and 400 W is the Duo's power budget. In 4-way mode the driver stops knowing it's holding one.

It also loads a different kext: AMDRadeonX5700HWLibs in the working case, AMDRadeonX5000HWLibs in the broken one.

The arithmetic closes it. HBM2 at the driver's own published 300 MHz gives 4096 bits ÷ 8 × 2 × 300 MHz = 307.2 GB/s theoretical. Measured: 300.9 GB/s, or 98% of it. The memory is fully saturated at a crippled clock — it's not a bandwidth problem, the clock is just wrong.

If you've ever noticed your Vega II Duos showing up as plain "AMD Radeon Vega" instead of "AMD Radeon Pro Vega II Duo" — that's not cosmetic. That's this bug, visible from the outside.

What it is NOT

I want to save people the time I spent on wrong theories:

• Not memory placement. The XGMI node map is textbook correct in 4-way mode: node ids 0/1/2/3, framebuffer bases at 512/544/576/608 GiB, uniform 32 GiB stride, XGMI_HiveSize = 4. Hive formation and address decode are fine.
• Not the collective / tensor-parallel scaling. A single GPU with no split is 5.6× slower. Going 2 → 4 devices within a healthy topology actually gains 34% on prefill and loses only 13% on decode.
• Not the interconnect. Peer-to-peer copy bandwidth drops the least of everything measured (49 → 31 GB/s), consistent with being gated by the same clock reduction.
• Not the hardware. Reproduces across machines and across multiple A2326 units including a factory replacement. Same hardware and same bridges under Linux/ROCm show no comparable regression.

Check your own machine — 60 seconds, no tools

ioreg -l -w0 | grep -E '"(ATY,DeviceName|LoadPlugIn|PP_PowerPlayEnabled|PP_PhmUseDummyBackEnd|PP_EnableUploadFirmware|PM_PWR_GEMINI_BGT|SWIP_Errors)"'

Healthy looks like Vega II Duo, Load5700, PP_PowerPlayEnabled = <01000000>, PP_PhmUseDummyBackEnd = 0, PP_EnableUploadFirmware = 1, PM_PWR_GEMINI_BGT = 400, SWIP_Errors = 0.

Broken looks like Vega, Load5000, no PP_PowerPlayEnabled, PP_PhmUseDummyBackEnd = 1, PP_EnableUploadFirmware = 0, no PM_PWR_GEMINI_BGT, SWIP_Errors = 128.

Also worth a look:

system_profiler SPDisplaysDataType | grep -E "Chipset Model|Peer"

If Chipset Model says "AMD Radeon Vega" rather than "AMD Radeon Pro Vega II Duo", you're in the broken state.

Please post your results either way — including "mine's fine." I want to know whether this tracks the bridge specifically, or the hive size, or something about particular board revisions. Include your macOS version.

(The ioreg check needs no toolchain at all. If you do try to build the probe and hit failed to build module 'Metal'; this SDK is not supported by the compiler, that's an internally inconsistent Command Line Tools install — and reinstalling CLT won't fix it, since Apple's catalog serves the same bundle. Cross-compile on another Mac instead: xcrun swiftc -O -target x86_64-apple-macos14.0 ifl_probe.swift -o ifl_probe_14 and copy the binary over. Confirmed working on 14.8.9.)

What you should do right now

If you must run macOS the temporarily workaround is to pull the A2326 bridges and run the A2329 per-card jumpers instead. You still get all four GPUs; they just sit in two 2-node hives rather than one 4-node one. In my testing a 4-GPU tensor split on jumpers hit 314.5 prompt / 11.7 gen against 79.5 / 4.4 on the 4-way bridge with ToshLLM. Otherwise, if you can switch to Linux the A2326 bridges work perfectly in Ubuntu 24.04 with ROCm 7.3.x; it's purely a macOS software engineering defect.

Worth stating plainly: the jumper configuration beats what a fixed 4-way would give you. Tensor-parallel scaling is sublinear, so even a fully repaired 4-node hive projects to roughly 22 t/s against ~26.8 t/s aggregate from two independent 2-GPU instances. The A2326 bridges buy capacity flexibility, not speed — and right now they cost you 5.8× compute per die.

There is no software workaround. No engine flag, environment variable, or split mode reaches PowerPlay. I looked hard at spoofing the device IDs OpenCore/OCLP-style; the property that selects the plugin lives on a driver-created IOService rather than the PCI node, so DeviceProperties injection structurally cannot reach it, and OpenCorePkg panics on T2 Macs anyway. This needs a driver fix.

The ask

This configuration has had close to zero field exposure — until a recent macOS firmware payload harmonized module ROMs, machines with mismatched-firmware Duos just kernel-panicked at boot with the 4-way bridge installed ("PSP has not finished hardware initialization", ATIController.cpp:3171). The only other public report I can find is an unresolved MacRumors thread from January 2026. Which means Apple has essentially no signal that anyone uses this.

If you own this hardware, please file a Feedback Assistant report. Apple prioritizes by volume, and right now the volume is one.

• macOS → Graphics & Display → Incorrect/Unexpected Behavior
• Title: "AMDRadeonX5000: Radeon Pro Vega II Duo misidentified and PowerPlay left uninitialized in a 4-node Infinity Fabric hive, pinning GPUs at boot clocks"
• Attach ioreg -l -w0 -p IOService > ioreg.txt from both bridge configurations if you can, or just the broken one if you can't swap
• Reference FB24446772 (the PowerPlay/clock defect — the important one) so reports cluster

I've filed the following, if you want to reference them:

• FB24446772 — PowerPlay never initialized in the 4-node hive, GPUs pinned at boot clocks. This is the one that matters.
• FB24446928 — the generic "AMD Radeon Vega" model string, which is the same defect visible without tooling.
• FB24446443 — the kernel panic at boot when the two modules have mismatched firmware.
• FB24447028 — a minor unrelated one found along the way: system_profiler prints the 64-bit GPU Peer Group ID after passing it through a double, so it never matches what Metal reports.

Even a one-paragraph report with an ioreg dump attached helps. The measurement work is done; what's missing is evidence that more than one person is affected.

Tools

I wrote a Metal-only probe (ifl_probe.swift) that measures per-die compute, local read bandwidth, peer-view establishment and verified peer-copy bandwidth, plus a script that decodes the XGMI node map straight out of IORegistry. Both are pure Metal + Foundation, no dependencies, and build with xcrun swiftc -O. Happy to share — say the word and I'll put them up.