IBM 将 Spyre 加速器打造为 PyTorch 一等后端

IBM 在 2026 年 10 月 26 日发布的IBM Research 博客文章中表示，2026 年下半年 PyTorch 生态系统推出的软件更新，已使其 Spyre 数据流加速器成为 PyTorch 一等后端，实现了 IBM 与PyTorch Foundation于 2025 年 10 月提出的计划。

IBM 将 Spyre 描述为其数据流 AI 加速器，针对推理进行了优化，旨在服务于在 IBM Z、LinuxONE 和 Power 系统上运行 AI，并将其与应用程序和数据协同使用的企业团队。它采用低精度计算，面向语言生成和嵌入模型中以矩阵运算为主的工作。传统 GPU 会将内核作为指令流，在经过调度的线程组间执行；与之不同，Spyre 会在数据到达其计算引擎时触发计算。

文章称，2026 年下半年，IBM、Red Hat 以及 PyTorch Foundation 的合作伙伴（包括 Meta 和 Hugging Face）推出了多项更新，涵盖模型开箱即用支持、vLLM 中与硬件无关的模型、持续回归测试和发布测试，以及原生设备集成。2025 年 PyTorch 大会上，IBM 在一篇发表于 2025 年 10 月 21 日的 IBM Research 文章中表示，计划在 2026 年进一步加强对 Spyre 的支持，使其作为一等后端参与开源推理工作流，并重点推进统一编译器路径、优化内核生成，以及透明的多加速器调度。此前，IBM 已采用 vLLM 作为推理运行时，并将 torch.compile 用作集成 Spyre 等加速器的前端编译器；此外，IBM 还为 vLLM 贡献了 Spyre 插件，使大语言模型推理能够使用分页注意力。

基于 Inductor 重建的编译器

此次集成的核心是 torch-spyre，这是一个 PyTorch 后端，可将常规 PyTorch 代码编译成适用于 Spyre 的可执行方案。模型的大部分逻辑都能原样通过 PyTorch 编译器；如果某项操作暂时无法有效降低到目标形式，适配器可以将其替换为数学上等价、且编译器能够处理的形式。

在PyTorch Foundation 于 2026 年 10 月 13 日发布的一篇文章中，Dave Grove、Olivier Tardieu 和 IBM Spyre 团队介绍了 torch-spyre 的 torch.compile 后端迁移过程：从完全从头构建的编译技术栈 sendnn，转向 backend=inductor。后者是通过扩展 PyTorch 自有的 Inductor 构建的开源后端。作者报告称，使用 Lizard 代码分析器测量后发现，sendnn 在 6,170 个函数中约有 273,000 行 C++ 和 Python 代码；而 Inductor 扩展约有 38,600 行 Python 代码，分布在 1,878 个函数中——代码行数约减少 7 倍，且每个函数的复杂度更低。

Spyre 是一款 75 瓦、通过 PCIe 连接的加速器，由 32 个通过环形互连连接的小型核心构成。每个核心都配有自己的 2 MB 暂存存储区，而非共享缓存；它以固定的 128 字节数据块传输数据，这些数据块称为 sticks。文章称，编译器方面的工作重点在于以 stick 为粒度的数据移动、暂存存储区规划，以及编译时的核心分配。

报告的测量结果包括：通过分块和布局选择，矩阵乘法内核耗时降低 29–69%；通过考虑暂存存储区的调度，softmax 内核的中位耗时从 32.51 微秒降至 23.67 微秒，降幅为 27%；此外，一个类似 MLP 的融合内核将核心利用率从约三分之二提升至约 80%，同时将内核耗时缩短约 17%。在一个专门用于考验这些决策的合成计算图中，新的片上重布局操作以核心间 1.1 微秒的数据交换，取代了耗时 80 微秒的设备内存往返传输。文章还指出，torch-spyre 需要注册设备专用分解规则，这推动了对树外 Inductor 后端支持的改进；相关改进后来以两项已合并的拉取请求形式进入 PyTorch 2.12。

原生设备集成

通过 PrivateUse1 注册，Spyre 成为 PyTorch 原生设备，使 tensor.to(“spyre”) 获得真正的设备身份：PyTorch 分配器的存储机制可让张量驻留在设备上，流提供顺序语义，而运行时事件则能连接不同流上的依赖任务。这张加速卡配有 32 个核心，通过高带宽环形互连连接，每个核心拥有 2 MB 本地暂存存储区；此外，它还配备最高 128 GB 的 LPDDR5，用于存放张量和程序。目前的运行时会在程序启动时对程序进行修补，分三个有序步骤将符号张量地址替换为实际地址。

团队报告称，在 Granite 3.3 8B 上进行演示时，批量大小为 1、序列长度为 1024；将计算图构建移出数据传输路径后，预填充性能提升了 9.9%，解码性能提升了 13.6%。如果再将这部分工作从计算调度中移除，预填充速度总计可提升至 1.7 倍，解码速度可提升至 2.4 倍，其中约四分之三的增益来自计算路径。

作者在《将 Spyre 构建为 PyTorch 原生设备》一文中写道：“这项成果的优势在于，Spyre 和 PyTorch 都不必假装成别的东西。”该文发表于 2026 年 10 月 8 日。作者还补充说，Spyre 保留了自己的数据流执行模型，同时用户能够获得一个原生 PyTorch 设备，并使用熟悉的张量放置、流和编译功能。

vLLM 的可移植性与 Llm-D 的连接

Spyre 是一种树外加速器，并非 AI 软件最常支持的 GPU 平台之一。它依靠 TorchDynamo 跟踪模型计算图，再由 TorchInductor 为目标硬件降低该计算图。在 vLLM 中，CustomOp 和 PluggableLayer 等扩展机制允许硬件插件定制行为，而无需重新实现软件栈的大部分内容。

在由 IBM、Meta 和 Hugging Face 的作者于 2026 年 9 月 22 日发布的文章 vLLM 中的硬件无关模型 中，团队介绍了 vLLM 转向硬件专用的“扁平化”模型定义，并提出了基于四项设计原则构建的硬件无关层：可编译、可扩展、与硬件专用路径隔离，以及可移植。相关初步支持已合入 vLLM 的主分支，可在 transformers 后端通过 USE_HW_AGNOSTIC=1 启用。作者称，该方案已通过 Spyre 树外插件在包括 Gemma 4、Qwen3 和 Granite 4.2 在内的模型上完成验证；在 NVIDIA H100 GPU 上，硬件无关层的总令牌吞吐量与原生实现相差不超过 3.4%，这一数据是对近期三款模型取几何平均值后得出的。

IBM 的文章还解释说，Spyre 通过 PyTorch 集成连接到 llm-d：llm-d 基于 vLLM 在多种加速器上运行分布式推理，vLLM 则通过 PyTorch 访问各类加速器；一旦某个设备拥有可用的 PyTorch 后端，vLLM 硬件插件就能将其接入，让 llm-d 可以把任务调度到该设备上。

从第一天起启用并持续测试

IBM Spyre 团队在 2026 年 8 月 20 日的一篇文章中介绍了 HF-adapters 项目。该项目利用编码智能体起草运行时补丁，使原版 Hugging Face Transformers 模型能够在 Spyre 上运行。文章称，从 2026 年 4 月中旬到 6 月下旬，共有 13 个不同的适配器，覆盖了 Hugging Face 下载量最高的 10,000 个嵌入模型中的 7,960 个，其中 6,804 个通过了在 Spyre 上进行的端到端测试。文章举例称，其中一个适配器将 gelu_new 激活函数中的 torch.pow(x, 3.0) 替换为数学上完全等价的 x x x，torch-spyre 软件栈能够将其降级为目标硬件支持的操作；人类仍负责诊断工作，定位由融合操作引起、仅在设备上出现的故障，并根据端到端结果核验各个智能体的结论。

在 2026 年 9 月 30 日的一篇文章中，IBM 和 Red Hat 的工程师介绍了 torch-spyre 的 L2 集成：它接入 PyTorch 的跨仓库 CI 中继（Cross-Repository CI Relay），在上游 PyTorch 发生变更时触发下游测试，并将结果反馈到 PyTorch 的 CI 控制面板。该集成将由智能体驱动的四阶段测试选择流水线与声明式 YAML 测试复用框架结合起来。作者写道，从 PyTorch 2.13 升级到 2.14 时，需要评估的变更测试约为 4,000 项，而不是数万项；他们还表示，计划与 PyTorch 团队合作，将可复用部分贡献至上游，并以 PyTorch OpenReg 为参照。

IBM 的文章指出，对于 IBM Z、LinuxONE 和 Power11 用户，目标是让他们能够从 Hugging Face 等生态系统获取模型，并使用与在 Nvidia GPU 上基本相同的 PyTorch 工作流；共享的 PyTorch 扩展接口则能隐藏大部分架构差异。vLLM 文章的作者表示，他们计划开始在 CI 中纳入硬件无关模型，并逐步将这条路径设为在 Spyre 上提供模型服务的默认方式。