PyTorch Hardware Enablement: Updates from the Acceleration Integration Working Group

PyTorch 硬件支持：加速器集成工作组的最新进展 – PyTorch

精选项目

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通过全自动流水线解决这一问题。当在pytorch/pytorch仓库中打开PR或推送提交时，webhook会并行触发事件到所有已注册的下游仓库。

图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维护着超过60万个测试用例，涵盖运算符、autograd、性能分析、分布式训练等多个领域——这是一个巨大的验证表面，原则上任何后端都应该能够利用。但实际上，许多测试是为特定加速器集编写。设备字符串、性能分析活动、内存API和跳过装饰器在代码中硬编码，将测试逻辑紧密耦合到特定后端，而非用设备无关的表述方式。在此次重构之前，唯一的选择是通过补丁维护自定义测试用例。每次PyTorch升级都需要大量人工操作，而PyTorch更快的发布节奏进一步加剧了这种重复工作。

2026年第一季度，工作组启动了系统性工作，将PyTorch测试套件与特定硬件解耦。这项工作通过中央跟踪问题、测试用例重构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、性能分析、nn模块、linalg、优化器、卷积、序列化、多进程和dataloader等多个领域。

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

CI 安全机制：HW_CLASSIFICATION 代码规范工具强制要求每个新测试类必须声明其分类。现有未分类文件（启动时为 1,191 个）已加入白名单并逐步减少至零——这一过程遵循与 PyTorch 维护者达成的分阶段部署协议，未来计划引入更精细的 AI 代码规范层进行强化管理。

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

对 PyTorch 项目本身而言，hw_classification 系统提供了基础设施基础，通过提出类级别的硬件和频率元数据，可减少重复测试、提升 CI 可观测性并优化测试调度。H1 季度完成的测试重构工作（将测试迁移至正确分类的类中）是实现这一愿景的必要前提。对更广泛的生态系统而言，多级测试跳过机制（按功能、类、测试和操作符分级）结合硬件分类，使后端供应商可根据实现成熟度精细控制测试运行和跳过策略，而无需修改上游测试代码。

下一步计划

H2 季度的重点包括：将未分类白名单缩减至零、将设备无关性覆盖范围扩展到分布式、JIT 和 autograd 模块、以及将 hw_classification 集成到 CI 调度中以实现按运行器自动选择测试。团队还在探索一种声明式操作符能力注册表方案，使加速器能够声明支持的 dtypes 和精度覆盖，而无需修改上游 OpInfo 条目。

性能分析

作者：Vishal Goyal, Anisha Kushwaha

将新硬件加速器集成到 PyTorch 性能分析中，需要的不仅是操作符级别的计时。供应商需要明确的合约来定义内核级时间线、内存和运行时事件，以及 Chrome/Perfetto 轨迹中的 CPU-设备关联性。在缺乏可用的树外参考实现情况下，后端开发者目前只有两个不完整的选项：遗留的 ProfilerStubs/KINETO_PRIVATEUSE1_FALLBACK 路径（仅记录每个操作符的粗粒度设备时间），或逆向工程内核 Kineto 插件（如 CUPTI 和 XPUPTI），但这些插件会将厂商特定工具与集成模式本身混杂在一起。

在2026年第一季度，性能分析功能遵循了OpenReg一贯的最小化、存根式方法：这不是一个生产级的性能分析工具，但足以展示集成机制。基于PyTorch核心注册API（REGISTER_PRIVATEUSE1_PROFILER），该API允许树外后端无需对PyTorch或Kineto进行进一步修改即可将IActivityProfiler插入Kineto，我们实现了OpenReg参考存根堆栈（追踪器加IActivityProfiler/会话，RFC #177978），覆盖会话生命周期、活动类型和关联ID，并通过端到端的会话生命周期和回退测试（使用torch.profiler）进行验证，同时为传统存根路径和Kineto插件路径都提供了文档说明。

对于加速器开发者而言，OpenReg性能分析路径为内核级启动提供了一个具体的起点。无需在Kineto内部逆向工程CUPTI风格的插件或只能使用粗粒度的ProfilerStubs计时，新加速器团队可以遵循一个单一的最小化存根实现，该实现展示了树外后端如何注册IActivityProfiler、管理会话生命周期以及连接关联ID调用路径——然后只需将存根主体替换为自己的设备性能分析SDK（PTI）调用，而无需修改PyTorch或Kineto。当仅需操作符级计时时，传统存根回退方案仍然可用。

对更广泛的PyTorch生态系统而言，这将PrivateUse1性能分析转变为一个经过验证的集成接口，而非Kineto源码树中每个供应商的附加功能。端到端的torch.profiler测试能够早期捕获注册、会话生命周期和回退的回归问题，存根参考实现始终与文档保持一致，使该工作流程可被任何后端信任。

OpenReg

作者：Mansi Agarwal, Jiahao Chen, Jiahao Tan

将新硬件加速器与PyTorch集成需要实现广泛的接口功能——设备注册、操作符调度、流和事件管理、autograd集成等。没有现成的参考实现时，后端开发者往往不得不逆向工程生产级后端，这会将设备特定的优化与集成模式本身混为一谈。

OpenReg是PyTorch内置的用于PrivateUse1加速器集成的参考后端。它不是一个生产级后端——而是一个最小化的、基于CPU的实现，将集成机制与硬件复杂性隔离。在2026年第一季度，我们重点推进了三个方向：扩展核心集成模式（设备注册、操作符调度、流、事件）的覆盖范围；强化OpenReg实现与加速器集成文档之间的对应关系；并通过测试和CI加强OpenReg作为PrivateUse1集成路径验证框架的作用。

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

对于更广泛的 PyTorch 生态系统，OpenReg 作为回归保护机制发挥作用。通过 CI 验证，它确保随着 PyTorch 的演进，PrivateUse1 集成机制保持稳定，在问题影响下游硬件厂商之前就捕获到潜在的破坏性变更。OpenReg 与加速器集成文档之间更紧密的对齐也意味着文档中的工作流程可以被信任——如果在 OpenReg 中能正常工作，那么在您的后端也一定能正常工作。它还为后续章节中提到的更高级集成路径（如分布式训练、编译后端支持和性能分析）提供了共同基础，这些路径都建立在 OpenReg 设立并验证的基础模式之上。

在 2023 年下半年，OpenReg 将继续扩展到更多 PyTorch 子系统，同时验证 PrivateUse1 集成路径在不同版本间的稳定性。

图 4：OpenReg 集成架构

分布式支持

作者：Mansi Agarwal, Atharva Kshirsagar

分布式训练是大规模模型开发的核心需求，但将新加速器与 PyTorch 的分布式堆栈集成需要处理广泛的接口，包括自定义传输、ProcessGroup 注册、集体调度和多进程协调。没有明确的参考实现，后端作者要遵循这条路径会非常困难。

2026 年上半年，工作组通过构建 OCCL（OpenReg 集体通信库）开始解决这一缺口，这是一个为 OpenReg 设计的最小化自定义 c10d 后端参考实现（RFC #176877）。OCCL 并不追求生产性能，而是旨在明确主要集成点。它展示了后端如何注册 ProcessGroup、调度集体操作，并以与 PyTorch 分布式抽象一致的方式管理 Work 完成语义（#171250, #183257）。

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

图 5：分布式 OCCL 架构

对于加速器开发者来说，OCCL 为向新后端添加分布式支持提供了更清晰的起点。在此之前，厂商通常需要研究生产级后端（如 NCCL）来推断 c10d 集成契约。虽然这些后端在实践中至关重要，但它们与特定硬件的通信库紧密耦合，不适合作为学习参考。

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

编译后端支持

作者：Parshant Sharma

编译器集成是任何希望在PyTorch中良好运行的加速器的重要组成部分。将新加速器与torch.compile集成需要处理广泛的接口区域，包括Dynamo中的图捕获和设备管理，以及对于希望利用其优化流程的供应商，可能还需要处理Inductor中的调度、融合和代码生成。在没有明确参考的情况下，后端作者通常需要研究生产级集成（如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用户已访问的主安装页面。为保持页面的实用性而非沦为自我申报的自由论坛，加速器集成工作组通过正式的准入流程对其进行管理。

申请流程刻意设计得简单明了：打开一个附加计算平台申请问题，为每个要求提供证据（链接、文档、CI仪表板、安全策略等），并提交。

在H2季度，我们积极鼓励更多加速器供应商申请，特别是那些已在本文其他部分描述中完成集成工作的供应商，以让其平台面向整个PyTorch用户群体。关于要求和审核流程的完整细节请参阅准入流程文档，或在工作组Slack频道提问。

结论

加速器集成工作组在2026年上半年取得的进展，彰显了开源AI领域中厂商中立协作的力量。通过建立标准化的测试、性能分析、编译器支持和分布式执行路径，社区构建了一个基础，使硬件创新得以蓬勃发展而不破坏框架。随着硅架构的持续演进，这些标准化的集成机制确保了新型计算平台能够无缝实现生产就绪。

要了解正在进行的工作方向或参与定义PyTorch下一代硬件启用方案，欢迎访问加速器集成工作组的仓库：https://github.com/pytorch-fdn/accelerator-integration-wg，或前往PyTorch技术顾问委员会工作组页面参与社区讨论：https://pytorch.org/working-groups/ 。

致谢

我们衷心感谢PyTorch维护者和社区成员在2026年上半年给予的慷慨支持和指导。特别感谢@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/

/post-content

/inner-wrap