IBM 使 Spyre 加速器成为首级的 PyTorch 后端

AI 模型和平台

IBM 使 Spyre 加速器成为首级的 PyTorch 后端

在 Google 上的首选来源中添加 Unite.AI

IBM 称 in IBM Research 2026年10月26日发布文章称，2026年下半年在PyTorch生态系统范围内交付的软件更新使其Spyre数据流加速器成为一流的PyTorch后端，交付了2025年10月概述的IBM和PyTorch基金会计划。

IBM将Spyre描述为它的数据流AI加速器，优化用于推论，并为企业团队在IBM Z,LinuxONE，和Power系统同时运行AI的应用程序和数据设计。 它的减精计算在语言生成和嵌入模型中瞄准矩阵重的工作，与常规的GPU不同，它执行内核作为指令流，跨越计划线组，随着数据到达其计算引擎，Spyre触发计算。

2026年下半年，IBM,Red Hat，以及PyTorch Foundation的合作者，包括Meta和Hugging Face，将更新推向覆盖首日模式的启用，vLLM中的硬件不可知模型，连续回归和释放测试，以及原生设备集成，邮政状态。 在2025年的PyTorch会议上，在2025年10月21日的IBM研究站，IBM 称计划2026年更深的Spyre启用，Spyre作为一等后端参与开源推论工作流程，并专注于统一的编译器路径，优化内核生成，透明的多加速器调度。 IBM当时已经采用了vLLM作为其推论运行时间和火炬。 编译为集成Spyre等加速器的前端编译器，它为vLLM提供了Spyre插件，使得大型语言模型推论的调频注意力得以实现。

在导入器上重建的编译器

集成的中心是火炬-spyre,PyTorch后端将普通的PyTorch代码编译成Spyre的可执行计划。 模型的逻辑大多通过PyTorch编译器，没有改变；当一个操作尚不能有效降低时，适配器可以用编译器可以处理的数学等效形式来代替。

在2026年10月13日发表的PyTorch基金会文章中，戴夫·格罗夫(Dave Grove)，奥利维尔·塔尔迪厄(Olivier Tardieu),IBM Spyre Team描述了移动火炬-spyre的火炬。 从 sendnn 编译后端，一个完全从零开始构建的编译堆栈，到后端=插件，一个通过扩展 PyTorch 自己的插件而构建的开源后端。 用蜥蜴代码分析器测量，Sentnn总共大约273,000行C++和Python跨越了6,170个功能，而Inductor扩展则大约在Python的38,600行进入了1,878个功能——大约减少了7x线，每个功能复杂度较低，作者们报告说。

spyre是一个75瓦，PCIe附着的加速器，由32个小核心wired一起建在一个环上，每个环都有自己的2MB刮板而不是共享缓存，它以固定的128字节块移动数据，称为棒。 编译器的工作集中在棒角数据运动，抓盘规划，以及编译时间核心任务，即邮局。

所报告的测量包括：Matmul内核时间从平板和布局选择减少29-69%；软马克斯中位内核时间从32.51微秒降至23.67微秒——从刮毛板-知觉排程减少27%；一个熔化的MLP型内核将核心利用率从大约三分之二提高到大约80%，同时削减内核时间在17%左右。 在为强调这些决定而绘制的合成图上，一个新的芯片上继电器取代了80微秒设备-模具的往返，在芯片间进行了1.1微秒的洗涤。 火炬-spyre需要登记设备特定分解的指出也帮助推动改善树外传导器后端支持

本地- DEVIS 整合

Spyre通过PrivateUse1注册成为原生的PyTorch设备，它赋予了lamor.to("spyre")一个真实的设备身份：PyTorch分配器存储使该设备上保留了lators居住，流提供订购语义，运行时事件将依赖性的工作连接跨流。 该卡搭载32个由高带宽环连接的芯片，每个芯片上装有2MB的局部刮板，以及最多128GB的LPDDR5用于伸缩器和程序，目前的运行时间补丁程序位于发布，在三个顺序步骤中用符号式的伸缩器地址代替真实的伸缩器地址。

在一次以批量尺寸1和序列长度1024对Granite 3.3 8B的演示中，将图构件移离数据传输路径，预填率提高了9.9%，解码率为13.6%，团队报告。 将这项工作从计算调度中去掉，也使总数达到1.7x更快的预填和2.4x更快的解码，大约四分之三的收益来自计算路径。

“赢家是Spyre和PyTorch都不必装作别的东西，”作者在Building Spyre上写道

vLLM 可移植性和 Llm- D 连接

Spyre是一个树外加速器，而不是AI软件最常用支持的GPU平台之一，依靠火炬Dynamo追踪一个模型图和火炬引入器来降低目标硬件的图。 在 vLLM 中，CustomOp 和 PluggableLayer 等扩展机制允许一个硬件插件自定义行为而无需重新执行软件堆栈的大部份。

在由来自IBM,Meta和Hugging Face的作者于2026年9月22日发布的vLLLM中的硬件-不可知性模型中，团队描述了vLLM向硬件特定"平面"模型定义的转变以及基于四个设计原理的推出硬件不可知性层：可编译，可扩展，与硬件特定路径隔离，以及可移植。 早期的支援已经降落在vLLM的主分支，并且可以在变压器后端使用USE HW AGNOSTIC=1启用。 Gemma 4、Qwen3和Granite 4.2等型号的Spyre树外插件对路径进行了验证，在NVIDIA H100 GPU上，硬件不可识别层在3.4%的本土实施范围内交付了总的代号吞吐量，据作者们报告，最近三种型号的几何平均值衡量。

Spyre的PyTorch集成也是它如何连接到llm-d,IBM的帖子解释：llm-d在vLLM顶部分布的推论，跨越多个加速器类型，vLLM通过PyTorch到达每个加速器，一旦一个设备有一个工作好的PyTorch后端，一个vLLM硬件插件就可以曝光它，这样llm-d就可以将工作排在它上。

一日启用和连续测试

2026年8月20日来自IBM Spyre Team的一篇文章描述了HF适应器，这个项目使用编码agents来起草运行时间补丁让股票Hugging Face变形器模型运行在Spyre上。 2026年4月中旬至6月下旬，13台独特的适配器陆续登场，覆盖了1万个最下載的Hugging Face嵌入型号中的7,960台，其中6,804台在Spyre上通过了端到端的测试，邮报。 一个例子是将gelu 新激活的火炬.pow(x,3.0)替换为数学上完全相同的xxx，火炬-spyre堆可以降低；人类保留诊断工作，将引信操作产生的仅设备的故障本地化，并对照端到端的结果检查每个agent的结论。

在2026年9月30日的一篇文章中，IBM和红帽工程师描述了火炬-spyre与PyTorch的交叉存储器CI Relay的L2集成，这引发了上游PyTorch变化的下游测试，并将结果报告回PyTorch的CI仪表板。 集成配对了具有声明式YAML测试-再使用框架的代理四级测试-选择管道，从PyTorch 2.13升级到2.14意味着评价大约4000个变更的测试而不是数万个，作者们写道，他们打算与PyTorch团队合作到上游以PyTorch OpenReg为参考点的可重复使用部件。

对于IBM Z,LinuxONE，以及Power11的用户来说，预期的经验是从Hugging Face等生态系统获得模型，并基本上使用与Nvidia GPU相同的基于PyTorch的工作流程，共享的PyTorch扩展点隐藏了大部分建筑差异，IBM的邮政状态。 VLLM post 称的作者们计划开始在CI中包括硬件不可知模型，并逐渐切换到该路径作为在Spyre上服务模型的默认。

本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。

AI Models & Platforms

IBM Makes Spyre Accelerator a First-Class PyTorch Backend

Add Unite.AI to your preferred sources on Google

IBM said in an IBM Research blog post published October 26, 2026 that software updates delivered across the PyTorch ecosystem in the second half of 2026 have made its Spyre dataflow accelerator a first-class PyTorch backend, delivering on a plan IBM and the PyTorch Foundation outlined in October 2025.

IBM describes Spyre as its dataflow AI accelerator, optimized for inference and designed for enterprise teams running AI alongside their applications and data on IBM Z, LinuxONE, and Power systems. Its reduced-precision compute targets the matrix-heavy work in language generation and embedding models, and unlike a conventional GPU, which executes kernels as instruction streams across scheduled groups of threads, Spyre triggers computation as data arrives at its compute engines.

In the second half of 2026, IBM, Red Hat, and collaborators in the PyTorch Foundation including Meta and Hugging Face pushed updates covering day-one model enablement, hardware-agnostic models in vLLM, continuous regression and release testing, and native-device integration, the post states. At PyTorch Conference 2025, in an IBM Research post dated October 21, 2025, IBM said it planned deeper Spyre enablement for 2026, with Spyre participating as a first-class backend in open-source inference workflows and a focus on unified compiler pathways, optimized kernel generation, and transparent multi-accelerator scheduling. IBM had by then adopted vLLM as its inference runtime and torch.compile as the frontend compiler for integrating accelerators such as Spyre, and it had contributed a Spyre plugin for vLLM that enables paged attention for large language model inference.

A Compiler Rebuilt on Inductor

At the center of the integration is torch-spyre, a PyTorch backend that compiles ordinary PyTorch code into an executable plan for Spyre. Most of a model’s logic passes through the PyTorch compiler unchanged; when an operation cannot yet be lowered effectively, an adapter can replace it with a mathematically equivalent form that the compiler can handle.

In a PyTorch Foundation post published October 13, 2026, Dave Grove, Olivier Tardieu, and the IBM Spyre Team described moving torch-spyre’s torch.compile backend from sendnn, a compilation stack built entirely from scratch, to backend=inductor, an open-source backend built by extending PyTorch’s own Inductor. Measured with the lizard code analyzer, sendnn totals roughly 273,000 lines of C++ and Python across 6,170 functions, while the Inductor extension comes in at roughly 38,600 lines of Python across 1,878 functions — about 7x fewer lines with lower per-function complexity, the authors reported.

Spyre is a 75-watt, PCIe-attached accelerator built from 32 small cores wired together over a ring, each with its own 2 MB scratchpad rather than a shared cache, and it moves data in fixed 128-byte chunks called sticks. The compiler work concentrated on stick-granularity data movement, scratchpad planning, and compile-time core assignment, the post states.

Reported measurements include a 29–69% reduction in matmul kernel time from tiling and layout choices, a drop in softmax median kernel time from 32.51 microseconds to 23.67 microseconds — a 27% reduction — from scratchpad-aware scheduling, and a fused MLP-style kernel that lifted core utilization from roughly two-thirds to about 80% while cutting kernel time around 17%. On a synthetic graph built to stress those decisions, a new on-chip relayout replaced an 80-microsecond device-memory round trip with a 1.1-microsecond shuffle between cores. The post also notes that torch-spyre’s need to register device-specific decompositions helped drive improvements to out-of-tree Inductor backend support that landed upstream in PyTorch 2.12 as two merged pull requests.

Native-Device Integration

Spyre becomes a native PyTorch device through PrivateUse1 registration, which gives tensor.to(“spyre”) a real device identity: PyTorch allocator storage keeps tensors resident on the device, streams provide ordering semantics, and runtime events connect dependent work across streams. The card carries 32 cores connected by a high-bandwidth ring, each with 2 MB of local scratchpad, and up to 128 GB of LPDDR5 for tensors and programs, and the current runtime patches programs at launch, substituting symbolic tensor addresses with real ones in three ordered steps.

In a demonstration on Granite 3.3 8B at batch size 1 and sequence length 1024, moving graph construction off the data-transfer path improved prefill by 9.9% and decode by 13.6%, the team reported. Removing that work from compute dispatch as well brought totals to 1.7x faster prefill and 2.4x faster decode, with roughly three quarters of the gain coming from the compute path.

“The win is that neither Spyre nor PyTorch has to pretend to be something else,” the authors wrote in Building Spyre as a Native PyTorch Device, published October 8, 2026, adding that Spyre keeps its dataflow execution model while users get a native PyTorch device with familiar tensor placement, streams, and compilation.

vLLM Portability and the Llm-D Connection

Spyre is an out-of-tree accelerator rather than one of the GPU platforms most commonly supported by AI software, relying on TorchDynamo to trace a model graph and TorchInductor to lower that graph for the target hardware. Within vLLM, extension mechanisms such as CustomOp and PluggableLayer allow a hardware plugin to customize behavior without reimplementing large portions of the software stack.

In Hardware-Agnostic Models in vLLM, published September 22, 2026 by authors from IBM, Meta, and Hugging Face, the team described vLLM’s shift toward hardware-specific “flat” model definitions and introduced hardware-agnostic layers built on four design principles: compilable, extensible, isolated from hardware-specific paths, and portable. Early support has landed in vLLM’s main branch and can be enabled with USE_HW_AGNOSTIC=1 on the transformers backend. The pathway has been validated with the Spyre out-of-tree plugin on models including Gemma 4, Qwen3, and Granite 4.2, and on NVIDIA H100 GPUs the hardware-agnostic layers delivered total token throughput within 3.4% of the native implementation, measured as the geometric mean across three recent models, the authors reported.

Spyre’s PyTorch integration is also how it connects to llm-d, the IBM post explains: llm-d runs distributed inference on top of vLLM across multiple accelerator types, vLLM reaches each accelerator through PyTorch, and once a device has a working PyTorch backend, a vLLM hardware plugin can expose it so llm-d can schedule work onto it.

Day-One Enablement and Continuous Testing

An August 20, 2026 post from the IBM Spyre Team describes HF-adapters, a project that uses coding agents to draft runtime patches letting stock Hugging Face Transformers models run on Spyre. From mid-April to late June 2026, 13 distinct adapters came to cover 7,960 of the 10,000 most-downloaded Hugging Face embedding models, of which 6,804 pass their end-to-end test on Spyre, the post reports. One example replaces the gelu_new activation’s torch.pow(x, 3.0) with the mathematically identical x x x, which the torch-spyre stack can lower; humans retain the diagnosis work, localizing device-only failures that arise from fused operations and checking each agent’s conclusions against end-to-end results.

In a September 30, 2026 post, IBM and Red Hat engineers described torch-spyre’s L2 integration with PyTorch’s Cross-Repository CI Relay, which triggers downstream testing on upstream PyTorch changes and reports results back to PyTorch’s CI dashboard. The integration pairs an agentic four-stage test-selection pipeline with a declarative YAML test-reuse framework, and upgrading from PyTorch 2.13 to 2.14 meant evaluating roughly 4,000 changed tests instead of tens of thousands, the authors wrote, adding that they intend to work with the PyTorch team to upstream the reusable parts with PyTorch OpenReg as the reference point.

For IBM Z, LinuxONE, and Power11 users, the intended experience is to obtain models from ecosystems like Hugging Face and use substantially the same PyTorch-based workflows they would use with Nvidia GPUs, with shared PyTorch extension points hiding much of the architectural difference, the IBM post states. The authors of the vLLM post said they plan to begin including hardware-agnostic models in CI and gradually switch to that pathway as the default for serving models on Spyre.

Auto-fetched and translated by AI Atlas. All rights belong to the original author.