Adding MI50s over PCIe makes decode WORSE, not better: gpt-oss-120B MXFP4 tg8192 falls 71.2 -> 33.9 -> 21.3 -> 14.3 tok/s from 2 to 4 to 6 to 8 cards under -sm tensor

Same command and session as comm-mi50-2x-gpt-oss-120b-mxfp4-tensor-split-decode (-p 16384 -n 8192 -b 2048 -ub 1024 -ngl 99 -mmp 0 -dio 1 -fa 1 -o md -r 3 -sm tensor), scaled by HIP_VISIBLE_DEVICES. Series: 2 GPU tg8192 71.22 +/- 2.78 (pp16384 882.18), 4 GPU tg8192 33.89 +/- 1.53 (pp16384 1079.23), 6 GPU tg8192 21.32 +/- 0.29 (pp16384 1140.89), 8 GPU tg8192 14.32 +/- 0.36 (pp16384 1006.68). MI50 has no GPU-to-GPU interconnect; these are PCIe-attached. Clock/power state not stated by the reporter.

COMMUNITY-REPORTED. This is the most decision-relevant number in this slice for anyone planning an MI50 cluster, and it runs against the intuition that more cards means more throughput. Prefill rises 882 -> 1079 -> 1141 then FALLS to 1007 at 8 cards while decode falls monotonically and roughly by half per doubling - the signature of a PCIe all-reduce sitting in the critical path of a memory-bound decode step. Because all four points come from one session on one machine, the shape of the curve is much more trustworthy than any single point. Pair with the fork maintainer's counter-measure in comm-gfx906-tensor-split-garbage-and-pcie-degradation (-tps N, PLE shard), which recovers most of the loss at 8 GPUs (TG 26.9 at -tps 4 vs 20.9 for -sm layer). INTERCONNECT IDS FILLED 2026-10-04: interconnect_ids was empty; it now carries the interconnect list of the accelerator record(s) this run names (amd-radeon-instinct-mi50x). BASIS AND ITS LIMITS, stated because this field is easy to over-read: it records the FABRIC PRESENT IN THE HARDWARE CONFIGURATION, which is how every previously-filled record in this repo reads it, not traffic measured over that fabric. The clearest evidence for that convention is that single-GPU records already carry a scale-up fabric here - trtllm-llama31-8b-fp8-h100-1k1k-tps is 1x H100 at TP=1 and carries ['nvlink-4','nvswitch-4'] - and that host-link-only records carry a PCIe value (arc-pro-b70-mlperf-v6-1-llama2-70b-offline-tokens carries ['pcie-gen5'] on 4x Arc Pro B70, which has no GPU-to-GPU fabric at all). So a value here does NOT mean the interconnect was exercised by this particular workload, and must not be cited as evidence that it was. Whether the run actually crossed that fabric is a question about TP/EP/PP size, which this repo records in methodology, not here. NOT INVENTED: nothing was filled where the accelerator record itself carries no interconnect, so this field stays empty for any part whose own record has none - which is the honest state for a single-socket Apple sOC and for parts whose vendor publishes no host interface. FORMAT_ID BACKFILL 2026-10-08 (w10-bench-formatid): format_id was null and is now 'mxfp4'. EVIDENCE, quoted from this record's own text: model: "gpt-oss-120b MXFP4 MoE (59.02 GiB)". NO NUMBER CHANGED - value, metric and unit are untouched; this adds metadata, it does not re-measure. The value was NOT taken from a model name, from a sibling record, or from outside knowledge. Left null everywhere the record's own unit/methodology does not name a format for this run: 63 of the 150 records in data/benchmarks/ are still null and each one has its reason, because a null with a reason is correct and a guessed value is not.