加速器集成工作组更新 – PyTorch

来源：https://pytorch.org/blog/pytorch-hardware-enablement-updates-from-the-acceleration-integration-working-group/

精选项目

• PyTorch logo (https://pytorch.org/projects/pytorch/)

TL;DR（太长不看）

加速器集成工作组在标准化新硬件架构接入开源 AI 生态系统方面发挥着关键作用。随着计算平台在云端、边缘端和专用芯片上日益多元化，加速器集成工作组确立了清晰、厂商中立的集成机制，消除对自定义代码补丁的依赖，并降低生态碎片化程度。本篇博文将介绍该小组在 2026 年上半年取得的成果，包括关键的基础设施改进、统一的测试工作流，以及覆盖整个 PyTorch 平台的参考后端。

引言

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

这正是加速器集成工作组（https://github.com/pytorch-fdn/accelerator-integration-wg）的核心使命。怀着打造一个可扩展、包容的 PyTorch 硬件生态系统的长期愿景，来自不同社区的贡献者共同推进上游框架改进、共享工具开发以及标准化的参考实现。

在 2026 年上半年（https://docs.google.com/document/d/1O5YBzMqH0kJ5Xe7bkxs38utXF2ksBietPC5sPffykc4/edit?usp=sharing），我们在多个核心工作流上取得了切实进展：重构测试套件以实现更广泛的跨后端复用、跨仓库 CI Relay（CRCR）机制、基于 PrivateUse1 的后端 profiling 支持、OpenReg 作为参考后端的持续成熟、分布式能力支持、编译器后端集成，以及增强的 CI 基础设施和可观测性仪表盘。本文将概述这些主要成就及其对更广泛生态系统中各计算平台接入 PyTorch 的影响。

跨仓库 CI Relay（CRCR）

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

目标

PyTorch 社区推出了跨仓库 CI Relay（CRCR）（https://github.com/pytorch/pytorch/issues/175022），这是一套全新系统，旨在填补其 CI 生态中长期存在的可观测性缺口。PyTorch 处于一个庞大依赖项目网络的核心位置——包括 Intel XPU、AMD ROCm、Apple MPS、Qualcomm AI Engine 以及通过 PrivateUse1 机制（https://docs.pytorch.org/docs/2.14/accelerator/index.html）集成的各种加速器，还有 vLLM、SGLang 和 Hugging Face Transformers 等生态库。尽管 PyTorch 自身的上游 CI 已经相当成熟且覆盖广泛，但它仅在 pytorch/pytorch（https://github.com/pytorch/pytorch）仓库内运行，下游仓库缺乏一个标准途径来了解何时应针对上游变更进行测试、如何回传结果，或如何跨项目关联失败信息。这带来了一个显著的协同挑战：PyTorch 贡献者在合并前无法得知自己的 PR 是否会影响其他后端，而硬件维护者也只能在变更已经提交之后才能反馈意见。

收益

CRCR 通过一条完全自动化的流水线解决了这一问题。当 PR 被创建或有提交推送到 pytorch/pytorch 时，webhook 会并行触发分发事件，推送给所有已注册的下游仓库。

**

图 1：CRCR 架构

每个仓库运行各自的 CI 工作流，并通过带鉴权的回调回传状态，使用 GitHub OIDC token 对调用方仓库的身份进行密码学验证。结果随后在数秒内流入 PyTorch CI HUD（hud.pytorch.org/crcr）(http://hud.pytorch.org/crcr)，让维护者能够通过单一仪表盘同时掌握 in-tree 与跨仓库的 CI 健康状况。

**

图 2：CRCR HUD 仪表盘

该系统采用分级的 allowlist（https://github.com/pytorch/pytorch/blob/main/.github/allowlist.yml），设置四个参与级别（L1–L4）(https://github.com/pytorch/pytorch/issues/175022)，让下游仓库可以从简单的分发通知，逐步进阶到完整的 HUD 报告，再到非阻塞、最终阻塞式的上游 PR check 运行。安全性通过五层校验加以保障——OIDC 身份验证、allowlist 授权、限流、状态机检查，以及可信数据与自报数据的严格分离——确保即使某个下游仓库被攻破，也只能影响其自身显示的 CI 状态，而无法触及 PyTorch 真正的构建基础设施或合并决策。下游维护者的接入成本极低：只需一条 allowlist 记录和一个轻量的工作流文件，无需编写任何自定义鉴权代码。

测试重构

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

目标

针对 PyTorch 现有测试套件验证新的加速器后端，是确保实现正确性并尽早发现上游变更的最有效方式之一。PyTorch 维护着超过 60 万条测试用例，覆盖算子、autograd、profiling、分布式训练等多个领域——这是一片庞大的验证面，原则上任何后端都应该能够加以利用。但在实践中，这些测试中有许多是为特定一组加速器编写的。设备字符串、profiler 活动、内存 API 以及 skip 装饰器在代码中被大量硬编码，将测试逻辑与特定后端紧密耦合，而非用设备无关的方式来表达。在这次重构之前，唯一的办法是通过补丁维护自定义测试用例。每次 PyTorch 升级都需要投入大量人工，而 PyTorch 更快的发布节奏进一步加剧了这种重复劳动。

在 2026 年上半年，工作组启动了一项系统性工作，将 PyTorch 的测试套件与特定硬件解耦。这项工作通过一个中央跟踪 issue（https://github.com/pytorch/pytorch/issues/185590）、一份关于测试用例重构的 RFC（https://github.com/pytorch/pytorch/issues/174469）和一份关于测试类分类的 RFC（https://github.com/pytorch/pytorch/issues/185142）进行追踪，并在 PyTorch Test Refactoring 项目（https://github.com/orgs/pytorch/projects/154）中跟踪了 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（https://github.com/alband）提出的测试类分类（https://github.com/pytorch/pytorch/issues/185142）基础上，小组实现了 hw_classification 类属性（GENERIC、DEVICE_GENERIC、CUDA、XPU、MPS）以及一个 –hw-classification 参数，并覆盖所有执行路径——unittest、pytest、subprocess、并行运行、XML 输出以及 run_test.py 转发——使 CI 运行器能够自动为自身的硬件选取正确的测试子集。

CI 护栏： 一个 HW_CLASSIFICATION linter（https://github.com/pytorch/pytorch/pull/190173）强制要求每个新增测试类都必须声明其分类。现有的未分类文件（发布时为 1,191 个）被列入 allowlist，并正在逐步清零——这与 PyTorch 维护者协商确定的分阶段推进方案一致，后续还计划引入一层 AI linter 以实现更细粒度的管控。

收益

对加速器开发者而言，这些改动从根本上改变了接入体验。厂商不再需要通过补丁修改大量测试文件以适配自家硬件，而是可以依赖 instantiate_device_type_tests() 为自己的后端自动生成测试变体。那些此前对非 CUDA 后端“不可见”的测试——因为它们被 @onlyCUDA 或硬编码的 device=“cuda” 所拦住——如今可以在任何已注册的加速器上运行。单条设备无关的测试就能同时产出经验证的 CUDA、MPS、XPU、ROCm 和 PrivateUse1 后端配置。

对 PyTorch 项目本身而言，hw_classification 系统提供了基础设施基础，它提出以类级别的硬件与执行频率元数据来减少重复测试、提升 CI 可观测性并优化测试调度。上半年完成的重构工作——将测试迁移至正确归类的测试类中——是实现这一愿景的严格前提。对更广泛的生态系统而言，多层级的测试跳过机制（按特性、测试类、测试用例和算子跳过）结合硬件分类，让后端厂商能够依据自身实现的成熟度，精细控制运行哪些测试、跳过哪些测试——而无需修改上游测试代码。

后续计划

在下半年，首要任务是推动未分类 allowlist 归零，将设备无关的覆盖范围扩展到分布式、JIT 和 autograd 模块，并将 hw_classification 接入 CI 调度，实现按运行器自动选择测试。小组还在探索一种声明式的逐算子能力注册表，让加速器无需修改上游 OpInfo 条目即可声明其支持的数据类型和精度覆盖策略。

Profiling

作者：Vishal Goyal、Anisha Kushwaha

目标

将新的硬件加速器与 PyTorch profiling 集成，所需的远不止算子级别的计时。厂商需要一份清晰的契约，涵盖内核级时间线、内存与运行时事件，以及在 Chrome/Perfetto trace（https://perfetto.dev/docs/）中的 CPU 与设备关联。由于缺少一个可用的树外参考实现，后端开发者只能在两种不完善的方案中选择：要么走传统的 ProfilerStubs（https://github.com/pytorch/pytorch/blob/main/torch/csrc/profiler/stubs/base.cpp）/KINETO_PRIVATEUSE1_FALLBACK（https://github.com/pytorch/pytorch/pull/101554）路径，该路径只能记录粗粒度的算子级设备耗时；要么对树内的 Kineto（https://github.com/pytorch/kineto）插件进行逆向工程，例如 CUPTI（https://github.com/pytorch/kineto/blob/main/libkineto/src/CuptiActivityProfiler.cpp）和 XPUPTI（https://github.com/pytorch/kineto/tree/main/libkineto/src/plugin/xpupti）——这会把厂商专属的工具实现与集成模式本身混为一谈。

在 2026 年上半年，profiling 遵循了 OpenReg 一贯的最小化、stub 式思路：并非生产级 profiler，而是刚好足以展示集成机制。在 PyTorch 核心注册 API REGISTER_PRIVATEUSE1_PROFILER（https://github.com/pytorch/pytorch/pull/172154）的基础上——该 API 让树外后端可以将一个 IActivityProfiler（https://github.com/pytorch/kineto/blob/main/libkineto/include/IActivityProfiler.h）接入 Kineto，而无需对 PyTorch 或 Kineto 做任何进一步修改——我们落地了一个 OpenReg 参考 stub 栈（tracer 加上 IActivityProfiler / session，RFC #177978（https://github.com/pytorch/pytorch/issues/177978）），覆盖了会话生命周期、活动类型和关联 ID，并辅以基于 torch.profiler（https://docs.pytorch.org/docs/2.13/profiler.html）的端到端会话生命周期与回退测试，以及针对传统 stub 路径和 Kineto 插件路径的文档。

收益

对加速器开发者而言，OpenReg 的 profiling 路径为内核级 bring-up 提供了一个具体的起点。新的加速器团队不必在 Kineto 内部逆向工程 CUPTI 式插件，也不必迁就于粗粒度的 ProfilerStubs 计时，而是可以遵循一套单一的、最小化的 stub 实现，直观了解树外后端如何注册 IActivityProfiler、管理会话生命周期并打通关联 ID 调用路径——随后用自身设备 profiling SDK（PTI）的调用替换 stub 的实现体，而无需修改 PyTorch 或 Kineto。当仅需算子级计时时，传统的 stub 回退方案依然可用。

对更广泛的 PyTorch 生态系统而言，这将 PrivateUse1 profiling 转化为一个经过验证的集成面，而非向 Kineto 源码树中添加的各厂商专属代码。端到端的 torch.profiler 测试能够尽早捕捉注册、会话生命周期和回退方面的回归问题，而 stub 参考实现与文档保持同步，使该工作流对任何后端都值得信赖。

OpenReg

作者：Mansi Agarwal、Jiahao Chen、Jiahao Tan

目标

将新的硬件加速器与 PyTorch 集成，需要实现一整套功能面——设备注册、算子分发、流与事件管理、autograd 集成等等。在缺少可用参考实现的情况下，后端开发者往往只能逆向工程生产级后端，这会将设备专属的优化与集成模式本身混为一谈。

OpenReg（https://github.com/pytorch/pytorch/tree/main/test/cpp_extensions/open_registration_extension/torch_openreg）是 PyTorch 树内针对基于 PrivateUse1（https://docs.pytorch.org/tutorials/advanced/privateuseone.html）的加速器集成的参考后端。它并非生产后端——而是一个最小化的、由 CPU 支撑的实现，旨在将集成机制与硬件复杂性隔离开来。在 2026 年上半年，我们聚焦于三个方面：扩大核心集成模式的覆盖范围（设备注册（https://github.com/pytorch/pytorch/blob/main/test/cpp_extensions/open_registration_extension/torch_openreg/torch_openreg/init.py）、算子分发（https://github.com/pytorch/pytorch/tree/main/test/cpp_extensions/open_registration_extension/torch_openreg/csrc/aten）、流与事件（https://github.com/pytorch/pytorch/tree/main/test/cpp_extensions/open_registration_extension/torch_openreg/csrc/runtime）），收紧 OpenReg 实现与加速器集成文档（https://docs.pytorch.org/docs/2.13/accelerator/index.html）之间的对应关系，并通过测试与 CI 强化 OpenReg 作为 PrivateUse1 集成路径验证主干的角色。

收益

对加速器开发者而言，OpenReg 为 bring-up 工作提供了一个具体的起点。新的加速器团队不必从零散的示例和生产后端中拼凑集成模式，而是可以遵循一套单一的、最小化的实现，直观了解一个树外后端应当如何与 PyTorch 交互——从设备模块注册，到算子分发，再到运行时行为。

对更广泛的 PyTorch 生态系统而言，OpenReg 充当回归防护网。通过 CI 加以持续验证，它