PyTorch 加速器集成工作组公布 2026 H1 进展：CRCR 跨仓库 CI 中继与测试重构

TL;DR

加速器集成工作组在标准化新硬件架构与开源 AI 生态系统的连接方式方面发挥着至关重要的作用。随着计算平台在云端、边缘和专用芯片领域的多样化，加速器集成工作组建立了清晰、供应商中立的集成机制，消除了自定义代码补丁并减少了生态系统的碎片化。在这篇博客中，我们介绍了该工作组在 2026 年上半年取得的成果，包括关键基础设施改进、统一测试工作流以及覆盖整个 PyTorch 平台的参考后端。

引言

PyTorch 硬件生态系统持续多样化，越来越多的 AI 计算平台采用原生框架集成。这种日益增长的采用带来了一个共同的社区挑战：简化集成路径、降低复杂性、标准化集成机制，并为异构计算平台建立可靠、统一的验证基础设施。

这正是加速器集成工作组的核心使命。以构建可扩展、包容的 PyTorch 硬件生态系统的长期愿景为目标，跨社区贡献者致力于上游框架改进、共享工具和标准化参考实现。

在 2026 年上半年，我们在多个核心工作流中取得了切实进展：重构测试套件以实现更广泛的跨后端复用、跨仓库 CI 中继（CRCR）机制、对基于 PrivateUse1 的后端的性能分析支持、OpenReg 作为参考后端的持续成熟、分布式能力支持、编译器后端集成，以及增强的 CI 基础设施和可视化仪表板。本文概述了这些主要成就及其对更广泛生态系统中计算平台 PyTorch 集成的影响。

跨仓库 CI 中继

作者：Subin George、Jiahao Chen、Jiahao Tan、Jiawei Li、Jewel K. M.

目标

PyTorch 社区推出了跨仓库 CI 中继（CRCR），这是一个旨在弥合其 CI 生态系统中长期存在的可见性差距的新系统。PyTorch 处于一个庞大的依赖项目网络的中心——包括 Intel XPU、AMD ROCm、Apple MPS、Qualcomm AI Engine 等加速器，以及通过 PrivateUse1 机制集成的各种加速器，还有 vLLM、SGLang 和 Hugging Face Transformers 等生态系统库。虽然 PyTorch 自身的上游 CI 成熟且广泛，但它在 pytorch/pytorch 仓库内运行，使下游仓库缺乏标准方式来了解何时针对上游变更进行测试、回传结果或关联跨项目的故障。这带来了一个重大的协调挑战：PyTorch 贡献者无法在合并前判断其 PR 是否会影响其他后端，而硬件维护者只能在变更提交后提供反馈。

优势

CRCR 通过全自动流水线解决了这一问题。当 PR 被打开或提交被推送到 pytorch/pytorch 时，webhook 会触发向所有已注册下游仓库并行发送 dispatch 事件。

图 1：CRCR 架构

每个仓库运行自己的 CI 工作流，并通过经过身份验证的回调报告状态，使用 GitHub OIDC 令牌以加密方式验证调用仓库的身份。结果随后在几秒内流入 PyTorch CI HUD（hud.pytorch.org/crcr），为维护者提供一个统一的仪表板，用于查看树内和跨仓库的 CI 健康状况。

图 2：CRCR Hud 仪表板

该系统使用分层允许列表，包含四个参与级别（L1–L4），让下游仓库从简单的调度通知，逐步发展到完整的 HUD 报告，再到对上游 PR 的非阻塞检查运行，最终发展为阻塞检查运行。安全性通过五层验证来保障——OIDC 身份验证、允许列表授权、速率限制、状态机检查，以及可信数据与自报数据的严格分离——确保即使下游仓库被攻破，也只能影响其自身显示的 CI 状态，而不会影响 PyTorch 的实际构建基础设施或合并决策。下游维护者的接入工作量极小：只需一个允许列表条目和一个轻量级工作流文件，无需自定义身份验证代码。

测试重构

作者：Riya Punia、Tanmay Kumar、Jiahao Chen、Jiahao Tan、Jiawei Li

目标

针对 PyTorch 现有测试套件验证新的加速器后端，是确保实现正确性并尽早发现上游变更的最有效方法之一。PyTorch 维护着超过 600,000 个测试用例，涵盖算子、自动微分、性能分析、分布式训练等——这是一个庞大的验证面，原则上任何后端都应该能够利用。然而在实践中，其中许多测试是为特定的一组加速器编写的。设备字符串、性能分析器活动、内存 API 和跳过装饰器被硬编码在各处，将测试逻辑与特定后端紧密耦合，而不是以设备无关的方式表达。在这次重构之前，唯一的选择是通过补丁维护自定义测试用例。每次 PyTorch 升级都需要大量手动工作，而 PyTorch 更快的发布节奏进一步加剧了这种重复工作。

在 2026 年上半年，工作组启动了一项系统性工作，将 PyTorch 的测试套件与特定硬件解耦。这项工作通过一个中央跟踪 issue、一份关于测试用例重构的 RFC以及一份关于测试类分类的 RFC进行跟踪，并在 PyTorch 测试重构项目中跟踪了 259 个项目。

图 3：测试重构架构

这项工作有三个维度：

设备无关的测试迁移：将硬编码的设备引用（device=”cuda”、torch.cuda.synchronize()、@onlyCUDA）替换为参数化等价形式（device=device、getattr(torch, device.type)、instantiate_device_type_tests()）。每个测试类被分类为与加速器无关（仅 CPU，针对 Dispatcher 等通用功能）、加速器无关（设备参数化，可在所有后端上运行）或加速器特定（绑定到特定后端的内部 API）。在上半年，贡献者迁移了超过 276 个测试文件，涵盖 dynamo、profiler、nn 模块、linalg、优化器、卷积、序列化、多进程和 dataloader。

硬件分类元数据：基于 Alban 提出的测试类分类，该小组在所有执行路径中实现了 hw_classification 类属性（GENERIC、DEVICE_GENERIC、CUDA、XPU、MPS）以及 –hw-classification 标志——包括 unittest、pytest、subprocess、parallel、XML 输出和 run_test.py 转发——使 CI 运行器能够自动为其硬件选择正确的测试子集。

CI 防护栏：一个 HW_CLASSIFICATION linter 强制要求每个新测试类声明其分类。现有的未分类文件（启动时为 1,191 个）被加入允许列表，并正在逐步清零——这与与 PyTorch 维护者商定的分阶段推出方案一致，未来还计划增加一个 AI linter 层以实现更精细的强制执行。

优势

对于加速器开发者而言，这些变化从根本上改变了入门体验。供应商无需再修补大量测试文件以适配其硬件，而是可以依靠 instantiate_device_type_tests() 自动为其后端生成测试变体。此前对非 CUDA 后端不可见的测试——因为它们被 @onlyCUDA 或硬编码的 device=”cuda” 所限制——现在可以在任何已注册的加速器上运行。一个设备无关的测试可以同时在 CUDA、MPS、XPU、ROCm 和 PrivateUse1 后端上生成经过验证的配置。

对于 PyTorch 项目本身，hw_classification 系统提供了基础设施基础，它提出类级别的硬件和频率元数据，以减少重复测试、改善 CI 可观测性并合理化测试调度。H1 中完成的重构工作——将测试迁移到正确分类的类中——是实现该愿景的严格前提。
对于更广泛的生态系统，多级测试跳过机制（按功能、类、测试和算子）与硬件分类相结合，使后端供应商能够根据其实现成熟度精细控制哪些测试运行、哪些跳过——而无需修改上游测试代码。

后续步骤

在 H2 中，优先事项是将未分类允许列表清零，将设备无关覆盖范围扩展到分布式、JIT 和 autograd 模块，并将 hw_classification 接入 CI 调度，以便为每个运行器自动选择测试。该小组还在探索一种声明式的按算子能力注册表，让加速器能够声明支持的 dtype 和精度覆盖，而无需修改上游 OpInfo 条目。

性能分析

作者：Vishal Goyal、Anisha Kushwaha

目标

将新的硬件加速器与 PyTorch 性能分析集成，需要的不仅仅是算子级计时。供应商需要一个清晰的契约，用于在 Chrome/Perfetto 跟踪中实现内核级时间线、内存和运行时事件以及 CPU–设备关联。如果没有可用的树外参考，后端开发者只能面对两个不完整的选择：遗留的 ProfilerStubs / KINETO_PRIVATEUSE1_FALLBACK 路径，它只记录粗略的按算子设备时间；或者逆向工程树内的 Kineto 插件，如 CUPTI 和 XPUPTI，这些插件将供应商特定的工具与集成模式本身混为一谈。

在2026年上半年，性能分析遵循了OpenReg一贯的极简、类似桩（stub）的方式：它不是生产级性能分析器，而只是足以演示集成机制。基于PyTorch核心注册API（REGISTER_PRIVATEUSE1_PROFILER），该API允许树外后端将IActivityProfiler接入Kineto，而无需进一步修改PyTorch或Kineto，我们落地了一个OpenReg参考桩栈（tracer加上IActivityProfiler / session，RFC #177978），涵盖会话生命周期、活动类型和关联ID，并用torch.profiler的端到端会话生命周期和回退测试以及针对旧版stubs路径和Kineto插件路径的文档为其提供支持。

优势

对于加速器开发者而言，OpenReg性能分析路径为内核级启动提供了具体的起点。新的加速器团队无需逆向工程Kineto内部的CUPTI风格插件，也无需满足于粗略的ProfilerStubs计时，而是可以遵循一个单一、极简的桩实现，该实现展示了树外后端如何注册IActivityProfiler、管理会话生命周期并连接关联ID调用路径——然后用自己的设备性能分析SDK（PTI）调用替换桩主体，而无需修改PyTorch或Kineto。当只需要算子级计时时，旧版stubs回退仍然可用。

对于更广泛的PyTorch生态系统而言，这将PrivateUse1性能分析转变为一个经过验证的集成接口，而不是每个供应商对Kineto源码树的单独添加。端到端torch.profiler测试能及早捕获注册、会话生命周期和回退方面的回归，并且桩参考与文档保持一致，因此该工作流对于任何后端都值得信赖。

OpenReg

作者：Mansi Agarwal、Jiahao Chen、Jiahao Tan

目标

将新的硬件加速器与PyTorch集成需要实现广泛的功能——设备注册、算子分发、流和事件管理、自动求导集成等等。如果没有可用的参考，后端开发者常常诉诸于逆向工程生产后端，这会将设备特定的优化与集成模式本身混为一谈。

OpenReg是PyTorch的树内参考后端，用于基于PrivateUse1的加速器集成。它不是生产后端——而是一个极简的、由CPU支持的实现，将集成机制与硬件复杂性隔离开来。在2026年上半年，我们专注于三个领域：扩展核心集成模式的覆盖范围（设备注册、算子分发、流、事件），加强OpenReg实现与加速器集成文档之间的对应关系，并通过测试和CI强化OpenReg作为PrivateUse1集成路径验证支柱的作用。

优势

对于加速器开发者而言，OpenReg为启动工作提供了具体的起点。新的加速器团队无需从零散的示例和生产后端中拼凑集成模式，而是可以遵循一个单一、极简的实现，该实现展示了树外后端预期如何与PyTorch交互，从设备模块注册到算子分发和运行时行为。

对于更广泛的 PyTorch 生态系统而言，OpenReg 充当了回归防护。通过 CI 运行，它验证了 PrivateUse1 集成机制在 PyTorch 演进过程中保持稳定，在下游硬件厂商受到影响之前捕获破坏性变更。OpenReg 与加速器集成文档之间更紧密的对齐也意味着，文档中描述的工作流是可信的——如果它在 OpenReg 中能运行，那么对你的后端也能运行。它还为本文后续介绍的更高级集成路径提供了共同基础，例如 分布式训练、编译后端支持以及 性能分析，这些都构建在 OpenReg 所建立并验证的基础模式之上。

后续步骤

在 H2 中，OpenReg 将继续扩展到更多 PyTorch 子系统，同时验证 PrivateUse1 集成路径在各版本间保持稳定。

图 4：OpenReg 集成架构

分布式支持

作者：Mansi Agarwal、Atharva Kshirsagar

目标

分布式训练是大规模模型开发的核心需求，但将新加速器与 PyTorch 的分布式栈集成需要应对广泛的技术面，包括自定义传输、ProcessGroup 注册、集合通信分发以及多进程协调。如果没有清晰的参考，后端作者很难遵循这条路径。

在 2026 年上半年，工作组开始着手填补这一空白，构建了 OCCL（OpenReg 集合通信库），这是 OpenReg 自定义 c10d 后端的最小参考实现（RFC #176877）。OCCL 的目标不是生产级性能，而是让主要集成点变得明确。它展示了后端如何注册 ProcessGroup、分发集合通信操作，并以符合 PyTorch 分布式抽象的方式管理工作完成语义（#171250、#183257）。

这项工作也帮助改善了周边的集成体验。除 OCCL 之外，工作组的贡献者还在加速器集成指南中补充了文档（#182308），并支持了 PyTorch 分布式基础设施的上游改进，包括对基于 Python 的后端实现更好的支持，以及设备通用的分布式测试选择。

优势

图 5：分布式 OCCL 架构

对于加速器开发者而言，OCCL 为添加分布式支持到新后端提供了更清晰的起点。在此之前，厂商往往不得不研究 NCCL 等生产级后端来推断 c10d 集成契约。虽然这些后端在实践中不可或缺，但它们与硬件特定的通信库紧密耦合，并不适合作为学习导向的参考。

OCCL 通过呈现一条独立的、与硬件无关的路径，贯穿分布式集成的核心部分，使该契约更易于理解。后端作者可以遵循更简单的模型，了解 ProcessGroup 注册、集合通信执行和完成语义如何在 PyTorch 内部协同工作。结合相关的上游改进，这为新加速器在 PyTorch 现有基础设施内启动分布式训练支持提供了更可靠的基础。

编译后端支持

作者：Parshant Sharma

编译器集成是任何希望在 PyTorch 中良好运行的加速器的重要环节之一。将新的加速器与 torch.compile 集成需要处理广泛的内容，包括 Dynamo 中的图捕获和设备管理，以及对于希望利用 Inductor 优化 pass 的厂商而言，可选的调度、融合和代码生成。如果没有清晰的参考，后端作者往往只能研究 CUDA 和 Triton 等生产级集成来拼凑注册契约。这条路径可能难以遵循，因为它将硬件特定的优化与底层集成机制混在一起。这项工作在 RFC #181093 中概述，填补了这一空白。

这项工作并非以生产性能为目标，而是旨在明确 Dynamo 和 Inductor 的集成点。使用 OpenReg，它展示了设备后端如何向编译器栈的两层注册、验证图捕获并生成融合内核，而无需修改上游 PyTorch 代码。

除了代码本身，这项工作还帮助揭示了现有文档和开发者体验中的不足。工作组向 PyTorch 的加速器文档贡献了一份编译器集成指南，涵盖 Dynamo 和 Inductor 两条路径，并提供了以 OpenReg 实现为具体示例的分步说明。

优势

这项工作为向新后端添加编译器支持提供了更清晰的起点。在此之前，厂商往往不得不研究 CUDA 和 Triton 代码路径来推断注册契约。虽然这些后端在生产中至关重要，但它们与硬件特定的调度和代码生成策略紧密耦合。

通过 Dynamo 后端和 Inductor 集成，后端作者可以看到 Dynamo 图捕获、Inductor 调度、包装代码生成和设备操作覆盖如何在 PyTorch 内部协同工作。这为树外后端在 PyTorch 现有基础设施内引入 torch.compile 支持提供了更可靠的基础，从基本的图捕获一直到融合内核生成。

PyTorch 附加平台页面

作者：Jiahao Chen、Jiawei Li

目标

长期以来，PyTorch 社区的用户缺少一个官方渠道来获取关于 PyTorch 对新后端支持的明确信息。PyTorch 附加平台页面现在是 pytorch.org 上由基金会管理的官方计算平台主页，直接从每个 PyTorch 用户都会访问的主安装页面链接过去。为了让该页面保持有意义，而不是一个自报名的自由市场，加速器集成工作组按照正式的准入流程来运营它。

申请过程刻意保持简单：提交一个 Additional Compute Platform Application issue，为每项要求提供证据（链接、文档、CI 仪表板、安全策略等），然后提交。

在下半年，我们积极鼓励更多加速器厂商，尤其是那些已经完成了本回顾其他部分所述集成工作的厂商，申请并让他们的平台展示在全体 PyTorch 用户面前。关于要求和审查流程的完整细节见准入流程文档，或在工作组 Slack 频道中提问。

结论

加速器集成工作组在 2026 年上半年取得的进展，展示了开源 AI 中供应商中立协作的力量。通过建立标准化测试、性能分析、编译器支持和分布式执行路径，社区构建了一个基础，使硬件创新得以蓬勃发展，而不会分裂框架。随着芯片架构不断演进，这些标准化集成机制确保新的计算平台能够无缝达到生产就绪状态。

如需了解正在进行的工作流，或参与定义 PyTorch 下一代硬件支持，请访问加速器集成工作组仓库： https://github.com/pytorch-fdn/accelerator-integration-wg，或在 PyTorch 技术咨询委员会工作组页面加入社区讨论： https://pytorch.org/working-groups/。

致谢

我们衷心感谢 PyTorch 维护者和社区成员在整个 2026H1 期间给予的慷慨支持和指导。特别感谢 @alband、@afrittoli、@atalman、@jbschlosser、@marco-s、@matthew-d-white、@mikaylagawarecki、@ZainRizvi、@zxiiro…… 的宝贵反馈和持续帮助。我们也感谢所有社区贡献者在整个工作中的参与和协助。

了解有关加速器集成工作组的更多信息：https://github.com/pytorch-fdn/accelerator-integration-wg

PyTorch TAC 工作组：https://pytorch.org/working-groups/

文章 PyTorch 硬件支持：加速器集成工作组的最新进展 首次发表于 PyTorch。