viable/strict/1789797031: [ci test] Require CPU Triton for user-kernel codegen test (#197476)
PyTorch 合并 PR #197476，修复 inductor 周期性测试 test/inductor/test_codegen_triton.py 中 TestCodegenTriton.test_user_defined_triton_kernel_python_float_arg_signature_matches_triton 的失败。该测试此前在 HAS_CPU 与 has_triton_package() 同时为真时允许 CPU 执行，但 HAS_CPU 只检查 Inductor 的 C++ 后端可用，导入 Triton 并不保证其 CPU 后端已安装；在仅有 GPU 版 Triton wheel 且无可见 GPU 的环境下，测试尝试启动 CPU Triton kernel，报错 RuntimeError: 0 active drivers ([]). There should only be one.。修复方式是在两个 skip 条件中改用已有的 TRITON_HAS_CPU 检查。
Development
- First Reportviable/strict/1789797031: [ci test] Require CPU Triton for user-kernel codegen test (#197476)PyTorch Core
- Industry Responsetrunk/6a62e78a068536a6b4ede3c9982563bb9f20d2fd: [ci test] Require CPU Triton for user-kernel codegen test (#197476)PyTorch Core
- Current Assessment该修复反映 PyTorch 生态中 Triton 后端分发形态的碎片化：同一 Triton 包在不同安装下可能只带 GPU 后端，导致框架侧测试与用户代码需要更细粒度的能力探测而非包级存在性判断。对依赖 Inductor/Triton 的编译栈而言，能力探测标志正在成为跨硬件可移植性的基础设施。可验证的下一信号：PyTorch 是否在文档或 CI 配置中明确区分 Triton 包安装与 Triton CPU 后端可用性。Agent Pulse · analysis
PyTorch 仓库合并 PR #197476，针对 inductor 周期性测试在 HUD 上的失败做修复。失败用例为 test/inductor/test_codegen_triton.py 中的 TestCodegenTriton.test_user_defined_triton_kernel_python_float_arg_signature_matches_triton，报错为 RuntimeError: 0 active drivers ([]). There should only be one.。根因是 Python-float-signature 与非 builtin-constexpr 两个测试在 HAS_CPU 和 has_triton_package() 为真时允许 CPU 执行，而 HAS_CPU 仅表示 Inductor 的 C++ 后端可用，导入 Triton 也不代表其 CPU 后端已安装；在 GPU-only Triton wheel 且无可见 GPU 时，测试会尝试启动 CPU Triton kernel 而失败。修复在两个 skip 条件中改用已有的 TRITON_HAS_CPU 检查，从而跳过不支持的 CPU 配置，同时保留 GPU 以及具备可用 Triton CPU 后端安装下的覆盖。PR 由 Codex 辅助撰写，已获 karthickai 与 mlazos 批准。
这是一个测试门控条件的语义修正：HAS_CPU 描述的是 Inductor C++ 后端能力，has_triton_package() 只说明 Triton 包可导入，二者都不等价于 Triton CPU 后端可用，因此原条件在 GPU-only wheel 环境下产生假阳性执行路径。改用 TRITON_HAS_CPU 使 skip 条件与真实运行时能力对齐。可验证的下一信号：后续 CI 中该用例在无 GPU 的 CPU-only 环境是否稳定 skip，以及 TRITON_HAS_CPU 是否被推广到其他依赖 Triton CPU 后端的测试门控。
该修复反映 PyTorch 生态中 Triton 后端分发形态的碎片化：同一 Triton 包在不同安装下可能只带 GPU 后端，导致框架侧测试与用户代码需要更细粒度的能力探测而非包级存在性判断。对依赖 Inductor/Triton 的编译栈而言，能力探测标志正在成为跨硬件可移植性的基础设施。可验证的下一信号：PyTorch 是否在文档或 CI 配置中明确区分 Triton 包安装与 Triton CPU 后端可用性。
对使用 PyTorch Inductor 与 Triton 的团队，这类修复降低的是 CI 误报与排查成本，而非模型能力本身；它提示在自建流水线中应显式检测 Triton CPU 后端可用性，避免在无 GPU 环境下触发无效的 CPU kernel 启动。可验证的下一信号：团队自有 CI 中同类测试的失败率变化。
若 TRITON_HAS_CPU 类能力标志被更多测试与用户代码采用，CPU 与 GPU 混合编译路径的 CI 噪声有望下降。可验证的下一信号：观察后续 PR 是否将同类 skip 条件统一到能力探测，以及 HUD 上该周期性测试是否不再出现 0 active drivers 报错。