[Oseltamivir]

Summary

First published MI300X and MI325X results: 43 files (22 MI300X, 21 MI325X), all on vllm/vllm-openai-rocm:v0.32.0.

• EP8 (MoRI, UCCL-EP; normal and low-latency; BF16 and FP8) ran in parallel across both partitions at 068e7c0. Single-node shards use only xGMI and do not interfere.
• EP16 ran one two-node shard at a time at 6cbbb96. Running them concurrently on the shared RoCE fabric skewed p50 by up to 2.9x and p99 by up to 30x. Three MI300X MoRI EP16 cases were re-timed alone after interference in their first serial pass, and each case keeps its quiet run: every top rung has p99/p50 ≤ 1.05, except MI325X MoRI low-latency BF16 at 1.20, which both runs show.
• swap-blocks smoke profiles (contiguous, random) ran at 6cbbb96.
• UCCL-EP low-latency FP8 EP16 is recorded as invalid on MI300X (oracle failure) and was not run on MI325X, where it hangs.

test_results.py passes: every file is a runnable case in cases.json and comes from a commit on main.

中文

首次发布 MI300X 与 MI325X 结果：共 43 个文件（MI300X 22 个，MI325X 21 个），均使用 vllm/vllm-openai-rocm:v0.32.0。

• EP8（MoRI、UCCL-EP；normal 与 low-latency；BF16 与 FP8）于 068e7c0 在两个分区上并行运行。单节点分片只使用 xGMI，互不干扰。
• EP16 于 6cbbb96 一次只运行一个双节点分片。并发运行时，共享 RoCE 网络使 p50 偏高最多 2.9 倍、p99 最多 30 倍。三个 MI300X MoRI EP16 用例在第一次串行运行受到干扰后单独重测，每个用例保留其无干扰的结果：所有最高档 p99/p50 ≤ 1.05，唯一例外是 MI325X MoRI low-latency BF16 为 1.20，两次运行都如此。
• swap-blocks smoke 配置（contiguous、random）于 6cbbb96 运行。
• UCCL-EP low-latency FP8 EP16 在 MI300X 上记录为 invalid（oracle 失败），在 MI325X 上会挂起，因此未运行。

test_results.py 通过：每个文件都是 cases.json 中可运行的用例，且来自 main 上的提交。

AI disclosure

Drafted and tested with an AI coding assistant; reviewed by the author.

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Apart from the inline finding, I checked that the source_sha in every one of the 43 records matches the commit message. All EP8 records show 068e7c0, and all EP16 and swap-blocks records show 6cbbb96, so nothing is wrong there.

Extended reasoning...

The change only adds 43 JSON benchmark result files under collectivex/results/mi300x and collectivex/results/mi325x. It changes no code and touches no security-sensitive surface. The source_sha check above was done by grepping each record against the commits named in the commit message.

[claude]

🟡 (optional) Dashboard readers get eight FP8 prefill results that carry slow_gpu: true, the flag the methodology says means "Do not compare a flagged case". Here throttle_fraction_max.power is 0.0941, well above the 5% cutoff. Every FP8 prefill case published on both SKUs is power-throttled 5.5-16%, while the BF16 prefill twins sit at 0.01-0.14%. Fix: re-measure these cases without throttling. Otherwise state the throttling in the PR and in methodology.md:967-968, which still says prefill spends 0.01-0.02% power-capped. Same pattern at 8 sites (this file, mi300x mori ep8 fp8 prefill, mi300x uccl-ep ep8/ep16 fp8 prefill, mi325x mori and uccl-ep ep8/ep16 fp8 prefill).

Why this was flagged

The trigger is publication. On push to main, .github/workflows/collectivex-results-ingest.yml sends every file under collectivex/results/ to InferenceX-app, the dashboard's source of truth. I could not check whether that app filters on runtime.gpu_clocks.slow_gpu. This record has slow_gpu true, with power throttling on all 16 ranks (0.078-0.094) and sm_clock_ratio_min 0.9895. collectivex/bench/gpu_clocks.py:303 sets that flag when a rank is throttled for at least 5% of timed passes. methodology-summary.md:187 says "Do not compare a flagged case". methodology.md:967-968 says the busiest prefill cases spent 0.01-0.02% power-capped. Seven sibling FP8 prefill files show the same flag at 0.0548-0.1607 power: mi300x-mori ep8, mi300x-uccl-ep ep8 and ep16, and mi325x mori and uccl-ep at ep8 and ep16. The matching BF16 prefill files read 0.0002-0.0007. On the base branch no AMD results are published, so readers would not get flagged numbers next to clean BF16 twins. tests/test_results.py does not prevent this because it never checks slow_gpu. summarize.py only prints a warning.

Verification: This record has "slow_gpu":true and "throttle_fraction_max":{"power":0.0941,...}. collectivex/bench/gpu_clocks.py:303 and :316-318 set the flag when a rank is throttled for at least THROTTLED_FRACTION (5%) of the timed passes. collectivex/docs/methodology-summary.md:187 says "Do not compare a flagged case." No publishing gate filters on it: summarize.py:140-150 only adds a callout.