llama.cpp decode on 2x MI50 with -sm tensor: 71.2 tok/s for gpt-oss-120B MXFP4 (and layer split is FASTER at 81.7)

llama-bench, -p 16384 -n 8192 -b 2048 -ub 1024 -ngl 99 -mmp 0 -dio 1 -fa 1 -o md -r 3 -sm tensor, 2 GPUs via HIP_VISIBLE_DEVICES=0,1 (2x32752 MiB, gfx906:sramecc+:xnack-, wave size 64). Decode figure is tg8192 = 8192 generated tokens, so it is steady-state decode at a long context, not TTFT or a short-context number. Same run with default (layer) split: pp16384 914.81 +/- 0.52, tg8192 81.72 +/- 0.44 - i.e. tensor split is WORSE for decode on this 2-card PCIe node. Not stated by the reporter and therefore NOT recorded: ROCm version, clock/power state, PCIe generation and lane width, host CPU. build hash ff5ef82.

COMMUNITY-REPORTED MEASUREMENT, not a verified benchmark. Pasted in full by the mx-llama.cpp maintainer (mxxm3679) in the gfx906 Discord #llama-cpp channel on 2026-04-22, including the exact command line, device enumeration, and stddev over 3 repeats. Treat as a self-reported practitioner run. Reproducible is null rather than false because essential methodology is missing: without the ROCm version, the SCLK state and the PCIe topology, a re-run is not a like-for-like comparison - and this community's own reporting shows clock and topology move these numbers by tens of percent. The headline finding worth keeping is the layer-vs-tensor comparison, which was run back-to-back on the same machine in the same session and is therefore a fair A/B despite the missing metadata. 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.