新硬件接入 PyTorch 的标准化路径

新硬件接入 PyTorch：从补丁地狱到标准化工作流

PyTorch 加速器集成工作组在 2026 年上半年交出两套基础设施：跨仓库 CI 中继让下游硬件厂商在 PR 合并前就能反馈兼容性问题，测试套件重构将 60 万条用例从只给 CUDA 写的改造成任何后端都能复用的参数化模板。这两项改动直接降低国产芯片、边缘 AI 加速器接入 PyTorch 的工程成本，也为开源生态树立了标准化集成机制的范本。

问题：硬件多样化遇上集成碎片化

PyTorch 的硬件生态正在快速分化。除了英伟达 CUDA、苹果 MPS、AMD ROCm、英特尔 XPU 这些"一线"后端，还有大量通过 PrivateUse1 机制接入的国产加速器、边缘 AI 芯片和专用硅片。每增加一款新硬件，都要解决同一批问题：

测试套件绑死特定硬件：PyTorch 维护着超过 60 万条测试用例，覆盖算子、自动微分、性能分析、分布式训练等各层。但这些测试大多为 CUDA 写死——硬编码的 device="cuda"、torch.cuda.synchronize()、@onlyCUDA 装饰器随处可见。新后端要复用这套测试，只能自己打补丁、维护分支，每次 PyTorch 升级都要重新对齐。
上游看不到下游的 CI 状态：PyTorch 主仓库的 CI 跑得再完善，也只覆盖它自己支持的几款硬件。下游硬件厂商（比如某国产 NPU 团队）维护着自己的适配仓库，但 PyTorch 贡献者在合并 PR 时根本不知道这个改动会不会把下游打挂——只能等代码合并后，硬件厂商升级依赖时才发现问题，那时再回滚已经来不及了。

这两个瓶颈让"接入 PyTorch"从技术问题变成了维护噩梦：每次上游发版，下游都要花几周时间重新验证、修补丁、回归测试。而 PyTorch 发版节奏还在加快，这套人工对齐的模式已经不可持续。

方案一：跨仓库 CI 中继（CRCR）——让上游看见下游

PyTorch 加速器集成工作组在 2026 年上半年推出了 Cross-Repository CI Relay（CRCR），用一套全自动管线打通上下游的 CI 可见性。

工作流程

当有人向 pytorch/pytorch 提交 PR 或推送新 commit 时，webhook 会并行触发所有已注册的下游仓库（比如 Intel XPU、AMD ROCm、vLLM、SGLang、Hugging Face Transformers，以及任何通过 PrivateUse1 接入的硬件后端）。每个下游仓库跑完自己的 CI 后，通过 GitHub OIDC token 认证身份，将结果回传到 PyTorch 的统一面板 hud.pytorch.org/crcr。

CRCR 架构：webhook 触发下游并行 CI，结果汇总到统一面板

图 1：CRCR 架构。图片来源：PyTorch Blog

这套机制解决了两个长期痛点：

合并前可见：PyTorch 维护者在合并 PR 之前就能看到这个改动对所有下游的影响，不用等代码入库后才发现兼容性问题。
单点汇总：所有跨仓库 CI 的结果都进同一个面板，不用逐个去下游仓库翻 CI 日志。

四级参与模型与五层安全校验

CRCR 设计了分级准入机制（L1 到 L4），让下游仓库逐步建立信任：

L1：只接收 dispatch 通知，不回传结果。适合刚开始适配的团队，先把 CI 跑起来。
L2：可以把结果报告到 HUD 面板，但不影响 PyTorch 的合并决策（non-blocking）。
L3：结果会显示在 PR 的 check 列表里，但仍然是 non-blocking。
L4：成为 blocking check——如果这个下游 CI 失败，PyTorch 的 PR 就不能合并。

这个设计的核心是渐进式信任：新接入的硬件不会一上来就拥有"一票否决权"，得先证明自己的 CI 稳定、不误报，才能逐级晋升。

安全方面，CRCR 用了五层防护：

OIDC 身份验证：回调必须带 GitHub 签发的 OIDC token，密码学级别确认调用方身份。
白名单授权：只有列入 allowlist 的仓库才能参与。
速率限制：防止某个下游仓库刷屏或 DoS。
状态机检查：每个 CI 任务都有明确的生命周期（pending → running → success/failure），不符合状态转移规则的回调会被拒绝。
信任数据与自报告数据严格分离：即使某个下游仓库被攻破，它也只能篡改自己在面板上的显示状态，无法影响 PyTorch 主仓库的构建基础设施或合并逻辑。