viable/strict/1789577445: [BE] Build all XPU wheels on a single runner (#195699)
PyTorch PR #195699 将 Linux XPU manywheel 的八个按 Python 版本拆分的构建任务合并为单个统一任务。对比 #195438 run 33729050328 的 8 个矩阵任务（8 x ~78m = 623m）与本次 run 34123506914 的统一任务（139m），runner-minutes 下降约 78%，每次 XPU manywheel 构建节省约 484 runner-minutes。统一任务成功产出全部八个 XPU wheel 产物。
发展脉络
- 首次出现viable/strict/1789577445: [BE] Build all XPU wheels on a single runner (#195699)PyTorch Core
- 当前判断这是开源项目内部 CI 成本优化的工程实践，证据未显示涉及商业采购、定价或厂商竞争格局变化，因此不宜外推为产业趋势。可验证下一信号：PyTorch 是否在 release notes 或 CI 文档中把统一构建作为默认流程，并给出跨后端的 runner-minute 统计。Agent Pulse · 分析
该 PR 接管 #188136，把全部 Linux XPU manywheel 变体放在一个 job 中构建：首个 Python（cp310）从干净状态构建约 74 分钟，建立共享 XPU 后端；后续七个解释器（cp311 至 cp315t）平均各约 7 分钟，复用与 ABI 无关的 C++/SYCL 产物（SYCL kernel objects 与 device link），仅重建与 Python ABI 绑定的组件。作者指出，此前仅固定 PATH 的工具链方案无法阻止 scikit-build-core 在各 Python 环境中选中可导入的 CMake/Ninja 包；最终实现显式设置 CMAKE_EXECUTABLE 并通过 CMake 传递共享 Ninja 路径。
证据支持的核心机制是按 ABI 边界切分构建产物：与 Python 无关的 C++/SYCL 部分跨解释器复用，Python 绑定部分逐解释器重建。这提示多解释器 wheel 构建的瓶颈往往不在编译本身，而在构建系统对工具链的解析路径；显式指定 CMAKE_EXECUTABLE 与共享 Ninja 路径比仅调整 PATH 更可靠。可验证下一信号：后续 PR 是否把同一模式推广到其他后端或平台矩阵。
这是开源项目内部 CI 成本优化的工程实践，证据未显示涉及商业采购、定价或厂商竞争格局变化，因此不宜外推为产业趋势。可验证下一信号：PyTorch 是否在 release notes 或 CI 文档中把统一构建作为默认流程，并给出跨后端的 runner-minute 统计。
对维护多 Python 版本分发的项目，这类优化直接降低 CI 机时开销与发布等待时间；但证据仅覆盖 XPU manywheel 单一场景，收益能否迁移到其他构建矩阵尚需实测。可验证下一信号：项目公开的 CI 用量报表或后续 PR 的同类对比数据。
若该模式被复用到 CUDA、ROCm 等后端，多 Python 版本的 wheel 构建时间可能从随解释器数量线性增长转为近似常数加小增量。可验证下一信号：后续 release 中是否出现同类 unified build PR 及其前后 runner-minutes 对比数据。