PyTorch 向新一类加速器开放 AI 生态：IBM Spyre 支持落地

IBM Research：AI·2026-10-26 20:00· 42 分钟前AI 评分35

PyTorch 向新一类加速器开放 AI 生态

AI 导读

IBM 与 PyTorch 基金会兑现 2026 年 Spyre 深度支持计划，torch-spyre 后端、Spyre 的 vLLM 插件与编译器改进让常规 PyTorch 模型可直接跑在 Spyre 上。

正文 · 原文

2025 年 10 月，IBM 与 PyTorch 基金会制定了 2026 年深化 Spyre 支持的计划：将该加速器视为一等 PyTorch 后端，并支持多加速器调度。最新的软件生态更新兑现了这一承诺。torch-spyre、Spyre 的 vLLM 插件、编译器改进以及持续集成工作共同让熟悉的模型和工作流更容易迁移到另一类 AI 硬件上。

AI 正越来越多地嵌入到处理交易、检测欺诈、分析理赔和协助员工的系统中。随着使用量的增长，AI 硬件生态也在扩张。GPU 仍是现代 AI 的核心，但越来越多不同架构、执行模型和性能特征的加速器加入其中。为开发者提供更多选择，需要的不仅仅是制造新芯片。软件生态必须让新加速器可用，同时不迫使开发者放弃熟悉的模型、工具和工作流。

Spyre 是 IBM 的数据流 AI 加速器，针对推理进行了优化。它专为在 IBM Z、LinuxONE 和 Power 系统上让 AI 与应用程序和数据协同运行的企业团队而设计。其低精度计算非常适合语言生成和嵌入模型中大量矩阵运算的工作负载。传统 GPU 以指令流的形式在调度的线程组上执行内核，而 Spyre 则在数据到达其计算引擎时触发计算。PyTorch 提供了通用层，使这一不同架构能够融入一个主要围绕 GPU 构建的生态。

将 PyTorch 扩展到 GPU 之外

这项工作的核心是 torch-spyre，这是一个 PyTorch 后端，可将普通 PyTorch 代码编译为 Spyre 的可执行计划。模型的大部分逻辑都原样通过 PyTorch 编译器。当模型包含底层栈尚无法有效降低的操作时，适配器可以将其替换为编译器能够处理的数学等价形式。模型的计算保持不变，而其实现变得与该加速器兼容。

迁移到 PyTorch 的 Inductor 后端还减少了团队必须维护的自定义编译器代码量。由此产生的编译器比它所取代的系统小约七倍，且每个函数的复杂度明显更低。更小的表面积使上游 PyTorch 的改进更容易引入 torch-spyre，并将 Spyre 专属工作集中在关键之处。

同样的原则也适用于设备边界。在最近的演示中，将图构建移出数据传输路径，使 Granite 3.3 8B 在批大小为 1、序列长度为 1024 时的性能提升了 9.9%（prefill）和 13.6%（decode）。将这项工作也从计算调度中移除后，总提升达到 prefill 快 1.7 倍、decode 快 2.4 倍，其中约四分之三的增益来自计算路径。

保持 vLLM 的可移植性

Spyre 是一款树外加速器，而非 AI 软件最常支持的 GPU 平台之一。Spyre 依赖 TorchDynamo 追踪模型图，并依赖 TorchInductor 将该图降级为针对目标硬件优化的表示形式。在 vLLM 中，CustomOp 和 PluggableLayer 等扩展机制允许硬件插件自定义行为，而无需重新实现软件栈的大部分内容。

随着 vLLM 的演进，保留这些扩展点至关重要。一些新的模型实现正日益针对特定模型和前沿 GPU 硬件进行专门化。为了在开展这些优化工作的同时保持可移植性，vLLM 社区正在开发与硬件无关的层，这些层与硬件特定路径隔离，并被设计为可编译、可扩展且可跨加速器平台移植。早期支持已落地 vLLM，并且该路径已在 Spyre 插件上针对 Gemma 4、Qwen3 和 Granite 4.2 等模型得到验证。在 NVIDIA H100 GPU 上，这些与硬件无关的层所实现的总 token 吞吐量与原生实现相差在 3.4% 以内（以三个近期模型的几何平均值衡量）。

一种工作流，更多硬件选择

对于 IBM Z、LinuxONE 和 Power11 用户而言，预期的体验很直接：从 Hugging Face 等生态获取模型，并使用与 Nvidia GPU 上基本相同的基于 PyTorch 的工作流。共享的 PyTorch 扩展点将大部分架构差异隐藏在框架之下，从而降低采用摩擦，避免体验局限于一小部分经过特殊打包的模型权重。

设想一个保险理赔工作流，它将用于欺诈检测的 XGBoost 模型与在 Spyre 上用于取证分析的 Gemma 26B 模型相结合。该软件栈使开发者能够使用熟悉的模型生态和框架接口来组装工作流，同时根据工作负载的适配性来选择硬件。

Spyre 的 PyTorch 集成也是它连接 llm-d 的方式。llm-d 在 vLLM 之上运行分布式推理，并旨在支持多种加速器类型，而非单一硬件路径。vLLM 通过 PyTorch 访问每个加速器：一旦某个设备拥有可用的 PyTorch 后端，vLLM 硬件插件便可将其暴露出来，随后 llm-d 即可将工作调度到其上。Spyre 遵循这一路径。torch-spyre 提供 PyTorch 后端，而 Spyre vLLM 插件构建于其上。因此，使 Spyre 成为 PyTorch 设备的工作，与使其可用于 llm-d 部署的工作是同一项工作。

让兼容性可衡量

只有当用户拥有明确证据表明模型可跨平台可靠运行时，广泛的兼容性才有用。IBM Research 的工程师正在通过端到端模型测试和持续集成来构建这一证据。这项工作有助于团队检测上游框架变更何时影响下游硬件支持。

端到端模型测试至关重要，因为故障可能源于操作、形状、布局、数值范围和编译器融合行为的组合，而孤立的单元测试无法揭示这些组合。针对可信的 CPU 或 GPU 参考运行真实模型，可将每个模型转化为兼容性测试和用于加固平台的探针。它还为开发者提供了关于哪些模型和加速器配置已一同经过验证的更清晰信号。

2026 年下半年，IBM、Red Hat 及其在 PyTorch 基金会中的合作伙伴（包括 Meta 和 Hugging Face）推动了新的软件生态更新，涵盖模型首日支持、vLLM 中的硬件无关模型、持续回归与发布测试，以及原生设备集成。一项关于前端与后端编译器的新演示进一步介绍了该技术栈。这些工作共同展示了模型适配器、编译器路径、运行时集成、vLLM 扩展和 CI/CD 如何结合起来，支持 Spyre 成为 PyTorch 生态中的一等参与者。

通过结合熟悉的工作流、可移植的编译器路径、广泛的模型支持以及透明的验证，IBM 正在帮助让硬件选择成为一种切实可行的选项，而不是软件集成的负担。

来源：IBM Research：AI · research.ibm.com