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

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

IBM将Spyre描述为其数据流AI加速器，针对推理进行了优化，专为在IBM Z、LinuxONE和Power系统上随应用和数据一同运行AI的企业团队而设计。其降低精度的计算面向语言生成和嵌入模型中矩阵密集型的工作负载；与按计划线程组以指令流方式执行内核的传统GPU不同，Spyre在数据到达其计算引擎时触发计算。

文章称，在2026年下半年，IBM、Red Hat以及PyTorch基金会中的合作方（包括Meta和Hugging Face）推动了多项更新，涵盖模型首日支持、vLLM中的硬件无关模型、持续回归与发布测试以及原生设备集成。在PyTorch Conference 2025上，IBM在2025年10月21日的一篇IBM Research文章中表示，计划在2026年深化Spyre支持，让Spyre作为一等后端参与开源推理工作流，并聚焦统一编译器路径、优化内核生成和透明的多加速器调度。彼时IBM已采用vLLM作为其推理运行时、采用torch.compile作为集成Spyre等加速器的前端编译器，并贡献了一个vLLM的Spyre插件，可为大语言模型推理启用分页注意力。

基于Inductor重建的编译器

这一集成的核心是torch-spyre，这是一个PyTorch后端，可将普通PyTorch代码编译为Spyre的可执行计划。模型的大部分逻辑原样通过PyTorch编译器；当某个操作尚无法有效下沉时，适配器可将其替换为编译器能够处理的数学等价形式。

在2026年10月13日发布的一篇PyTorch基金会文章中，Dave Grove、Olivier Tardieu和IBM Spyre团队描述了将torch-spyre的torch.compile后端从sendnn（一个完全从零构建的编译栈）迁移到backend=inductor（一个通过扩展PyTorch自带Inductor构建的开源后端）。使用lizard代码分析器测量，sendnn在6,170个函数中总计约273,000行C++和Python代码，而Inductor扩展在1,878个函数中约为38,600行Python代码——作者报告称，代码行数约减少7倍，且单函数复杂度更低。

Spyre是一款75瓦、PCIe连接的加速器，由32个通过环形网络互连的小核心构成，每个核心拥有自己的2 MB暂存器而非共享缓存，并以称为stick的固定128字节块移动数据。文章称，编译器工作集中在stick粒度的数据移动、暂存器规划和编译期核心分配上。

报告的测量结果包括：通过分块和布局选择，matmul内核时间减少29–69%；通过暂存器感知调度，softmax内核时间中位数从32.51微秒降至23.67微秒——减少27%；一个融合的MLP式内核将核心利用率从约三分之二提升至约80%，同时将内核时间缩短约17%。在用于压测这些决策的合成图上，新的片上重布局以核心间1.1微秒的shuffle取代了80微秒的设备内存往返。文章还指出，torch-spyre需要注册设备特定的分解，这推动了树外Inductor后端支持的改进，并已作为两个合并的拉取请求在上游PyTorch 2.12中落地。

原生设备集成

Spyre通过PrivateUse1注册成为原生PyTorch设备，这使tensor.to(“spyre”)具有真实的设备身份：PyTorch分配器存储使张量常驻设备，流提供顺序语义，运行时事件连接跨流的依赖工作。该卡带有32个通过高带宽环形网络连接的核心，每个核心拥有2 MB本地暂存器，以及最高128 GB的LPDDR5用于张量和程序；当前运行时在启动时对程序进行补丁，按三个有序步骤将符号张量地址替换为真实地址。

团队报告称，在Granite 3.3 8B、batch size为1、序列长度为1024的演示中，将图构建移出数据传输路径使prefill提升9.9%、decode提升13.6%。再将这项工作从计算调度中移除后，总计达到prefill快1.7倍、decode快2.4倍，其中约四分之三的增益来自计算路径。

“胜利之处在于，Spyre和PyTorch都不必再假装成别的东西，”作者们在2026年10月8日发表的《将Spyre打造为原生PyTorch设备》一文中写道，并补充说，Spyre保留了其数据流执行模型，同时用户获得了一个原生PyTorch设备，具备熟悉的张量放置、流和编译功能。

vLLM可移植性与llm-d的关联

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

在2026年9月22日由IBM、Meta和Hugging Face的作者发表的《vLLM中的硬件无关模型》一文中，团队描述了vLLM向硬件特定的“扁平”模型定义的转变，并介绍了基于四项设计原则构建的硬件无关层：可编译、可扩展、与硬件特定路径隔离以及可移植。早期支持已进入vLLM的主分支，并可在transformers后端上通过USE_HW_AGNOSTIC=1启用。作者们报告称，该路径已在包括Gemma 4、Qwen3和Granite 4.2在内的模型上通过Spyre树外插件得到验证，而在NVIDIA H100 GPU上，硬件无关层提供的总token吞吐量与原生实现相差在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个不同的适配器覆盖了下载量最高的10,000个Hugging Face嵌入模型中的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与PyTorch跨仓库CI中继的L2集成，该中继会在上游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上服务模型的默认方式。