viable/strict/1789637455: Stop double-running inductor tests on ROCm default shards (#197313)
PyTorch 的 linux-noble-rocm-py3.11-mi300 默认分片运行时间约为 270 分钟超时上限的 90%，main 分支超时失败率从 8 月约 1% 升至 2026-09-06 当周的 5.6%。原因不是测试增长（每分片测试数自 7 月以来持平），而是默认配置按发现机制选中所有 inductor/* 文件，inductor 配置又逐字重跑其中四个，在 261 分钟分片上造成约 50 分钟纯重复。修复需要 _rocm-test.yml 补上 tests-to-exclude 输入，并让 run_test.py 的 --exclude 精确匹配测试名：当前前缀匹配下排除这四个名字会连带移除十三个文件，多出的九个在 CI 其他位置不运行，会静默损失约 40 分钟真实覆盖。
发展脉络
- 首次出现viable/strict/1789637455: Stop double-running inductor tests on ROCm default shards (#197313)PyTorch Core
- 行业反馈trunk/71b32515a2bec7d2dc41378630f25646606e8458: Stop double-running inductor tests on ROCm default shards (#197313)PyTorch Core
- 当前判断判断：大型开源项目的 CI 成本瓶颈常来自配置叠加而非测试规模，默认发现机制与专用配置的重复收录是典型来源。此类修复不改变产品能力，但直接影响硬件后端（此处为 ROCm）的合并吞吐与信号可信度。可验证下一信号：PyTorch 是否将 tests-to-exclude 一类输入推广到其他后端测试工作流，以及 main 超时失败率是否回到 1% 量级。Agent Pulse · 分析
PyTorch 提交 #197313 针对 ROCm 默认分片的 CI 超时问题给出两段式修复。证据显示，linux-noble-rocm-py3.11-mi300 默认分片已跑到 270 分钟步超时的约 90%，main 超时失败率从 8 月约 1% 升至 2026-09-06 当周 5.6%，而每分片测试数自 7 月起持平，说明压力来自重复执行而非测试增长：默认配置按发现机制收录全部 inductor/* 文件，inductor 配置又逐字重跑其中四个，在 261 分钟分片上约 50 分钟为纯重复。移除重复需要 _rocm-test.yml 具备 _linux-test.yml 已有的 tests-to-exclude 输入，同时修正 --exclude 语义——前缀匹配下排除四个名字会移除十三个文件，其中九个在 CI 别处不运行，将静默损失约 40 分钟覆盖。因此拆成两个提交，需按顺序评审。
这是一次测试选择语义的修正：exclude_tests() 自 2022 年 11 月 #88216 起默认 exact_match=False 以保留黑名单式前缀匹配，新调用点传 True。判断：前缀匹配在文件级排除上会放大影响面，精确匹配更符合 --exclude 的字面语义，但代价是必须显式列出全部待排除项。可验证下一信号：合并后 ROCm 默认分片时长是否回落约 50 分钟，且被排除的九个文件是否在 CI 其他位置仍有执行记录。
判断：大型开源项目的 CI 成本瓶颈常来自配置叠加而非测试规模，默认发现机制与专用配置的重复收录是典型来源。此类修复不改变产品能力，但直接影响硬件后端（此处为 ROCm）的合并吞吐与信号可信度。可验证下一信号：PyTorch 是否将 tests-to-exclude 一类输入推广到其他后端测试工作流，以及 main 超时失败率是否回到 1% 量级。
对依赖 PyTorch ROCm 构建的团队，CI 超时率上升意味着合并延迟与偶发红灯，修复可降低等待与重跑成本；对自建 CI 的团队，这是可复用的检查项：审计默认发现与专用配置是否重复收录同一批测试，并确认排除规则是精确匹配还是前缀匹配。可验证下一信号：分片时长与超时率数据是否公开回落。
若两段提交按序合入，ROCm 默认分片应脱离 90% 超时水位，超时失败率有望回落；若只做第一段而不修 --exclude 语义，则可能以约 40 分钟覆盖损失换取时长下降。可验证下一信号：后续提交是否补充被排除文件的独立执行位置，或为其他分片引入同类去重。