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、およびMetaやHugging Faceを含むPyTorch Foundationの協力企業が、初日からのモデル対応、vLLMにおけるハードウェア非依存モデル、継続的な回帰テストとリリーステスト、ネイティブデバイスとの統合を含む更新を提供した。2025年10月21日付のIBM Researchの記事で、IBMはPyTorch Conference 2025において、2026年にSpyreへの対応をさらに強化する計画を明らかにしていた。オープンソースの推論ワークフローでSpyreを正式なバックエンドとして利用できるようにし、統一されたコンパイラ経路、最適化されたカーネル生成、複数のアクセラレーターを透過的にスケジューリングする機能に重点を置くとしていた。その時点でIBMは、推論ランタイムとしてvLLMを、アクセラレーターの統合に使うフロントエンドコンパイラとしてtorch.compileを採用していた。また、大規模言語モデルの推論でPaged Attentionを利用できるSpyre用vLLMプラグインも提供していた。

Inductorを基盤に再構築したコンパイラ

この統合の中核となるtorch-spyreは、通常のPyTorchコードをSpyreで実行可能なプランにコンパイルするPyTorchバックエンドだ。モデルのロジックの大部分は、PyTorchコンパイラをそのまま通過する。ある演算をまだ効果的に低レベル化できない場合は、アダプターがその演算を、コンパイラで処理できる数学的に等価な形式に置き換える。

2026年10月13日付のPyTorch Foundationの記事で、Dave Grove、Olivier Tardieu、IBM Spyreチームは、torch-spyreのtorch.compileバックエンドを、ゼロから構築したコンパイルスタックsendnnから、PyTorch独自のInductorを拡張して作られたオープンソースのbackend=inductorへ移行したと説明した。著者らによると、コード解析ツールlizardで測定したsendnnは、6,170個の関数にわたるC++とPythonのコードが合計約273,000行に上る。一方、Inductorの拡張部分は1,878個の関数にわたるPythonコードが約38,600行で、行数は約7分の1となり、関数ごとの複雑さも低下した。

Spyreは75ワットのPCIe接続型アクセラレーターで、リング状に接続された32個の小型コアを搭載する。各コアには共有キャッシュではなく、2 MBの専用スクラッチパッドが備わっている。また、スティックと呼ばれる128バイト固定長の単位でデータを転送する。記事によると、コンパイラ開発では、スティック単位のデータ移動、スクラッチパッドの計画、コンパイル時のコア割り当てに重点が置かれた。

報告された測定結果には、タイル分割とデータ配置の選択による行列積カーネル時間の29～69％短縮、スクラッチパッドを考慮したスケジューリングによるsoftmaxのカーネル時間中央値の32.51マイクロ秒から23.67マイクロ秒への短縮（27％減）、そして融合型のMLP風カーネルによるコア使用率の約3分の2から約80％への向上とカーネル時間の約17％短縮が含まれる。こうした判断が効果を発揮するように作られた合成グラフでは、新しいオンチップのデータ再配置により、デバイスメモリーへの往復にかかる80マイクロ秒が、コア間の1.1マイクロ秒のデータ転送に置き換わった。また記事は、torch-spyreでデバイス固有の分解処理を登録する必要があったことが、アウトオブツリーのInductorバックエンドのサポート改善を促す一因となり、その改善が2件のプルリクエストのマージを経てPyTorch 2.12に取り込まれたとも述べている。

ネイティブデバイスとの統合

PrivateUse1への登録によって、SpyreはPyTorchのネイティブデバイスになる。これによりtensor.to(“spyre”)で実際のデバイスとして認識され、PyTorchのアロケーターが確保したストレージによってテンソルがデバイス上に保持されるほか、ストリームが実行順序のセマンティクスを提供し、ランタイムイベントが複数のストリームにまたがる依存関係のある処理をつなぐ。このカードには、高帯域幅のリングで接続された32個のコアが搭載され、各コアは2 MBのローカルスクラッチパッドを備える。また、テンソルとプログラム用に最大128 GBのLPDDR5を搭載する。現在のランタイムは起動時にプログラムへパッチを適用し、3段階の順序立った手順で、シンボリックなテンソルアドレスを実際のアドレスに置き換える。

チームによると、バッチサイズ1、シーケンス長1024のGranite 3.3 8Bを使ったデモでは、グラフ構築をデータ転送経路から切り離すことで、プリフィルが9.9％、デコードが13.6％高速化した。さらに、その処理を計算のディスパッチからも取り除くと、合計でプリフィルは1.7倍、デコードは2.4倍高速化し、改善幅のおよそ4分の3は計算経路によるものだった。

「SpyreもPyTorchも、別の何かを装う必要がないことが成果だ」と著者らは、2026年10月8日公開のSpyreをネイティブなPyTorchデバイスとして構築するで記している。さらに、Spyreはデータフロー型の実行モデルを維持しながら、ユーザーは使い慣れたテンソル配置、ストリーム、コンパイル機能を備えたネイティブなPyTorchデバイスを利用できると述べている。

vLLMの移植性とLlm-Dとの連携

Spyreは、AIソフトウェアで最も広くサポートされているGPUプラットフォームの一つではなく、アウトオブツリー型のアクセラレーターです。TorchDynamoでモデルの計算グラフをトレースし、TorchInductorでそのグラフを対象ハードウェア向けに変換します。vLLMでは、CustomOpやPluggableLayerなどの拡張機構により、ハードウェアプラグインがソフトウェアスタックの大部分を再実装することなく、動作をカスタマイズできます。

IBM、Meta、Hugging Faceの著者らが2026年9月22日に公開したvLLMにおけるハードウェア非依存モデルでは、vLLMがハードウェア固有の「フラットな」モデル定義へ移行していることを説明し、4つの設計原則に基づくハードウェア非依存レイヤーを紹介しています。その原則は、コンパイル可能であること、拡張可能であること、ハードウェア固有の経路から分離されていること、そして移植可能であることです。初期サポートはvLLMのメインブランチに追加されており、transformersバックエンドでUSE_HW_AGNOSTIC=1を指定すると有効にできます。この方式は、Gemma 4、Qwen3、Granite 4.2などのモデルでSpyreのアウトオブツリープラグインを用いて検証されました。また著者らによると、NVIDIA H100 GPUでは、3つの最新モデルにおける幾何平均で測定したトークンの総スループットが、ネイティブ実装の3.4%以内に収まりました。

IBMの投稿によると、Spyreがllm-dと連携するうえでも、PyTorchとの統合が重要な役割を果たします。llm-dは複数種類のアクセラレーターにわたってvLLM上で分散推論を実行し、vLLMはPyTorchを介して各アクセラレーターにアクセスします。そのため、デバイスで動作するPyTorchバックエンドが整えば、vLLMのハードウェアプラグインを通じてそのデバイスを利用可能にし、llm-dがそこに処理を割り当てられるようになります。

初日からの利用開始と継続的なテスト

IBM Spyre Teamが2026年8月20日に公開した投稿では、コーディングエージェントを使ってランタイムパッチの草案を作成し、標準のHugging Face TransformersモデルをSpyre上で実行できるようにするプロジェクト、HF-adaptersが紹介されています。投稿によると、2026年4月中旬から6月下旬にかけて、13種類のアダプターが対応するモデルは、Hugging Faceで最もダウンロードされた埋め込みモデル1万件のうち7,960件に達し、そのうち6,804件がSpyre上でエンドツーエンドテストに合格しました。たとえば、gelu_new活性化関数のtorch.pow(x, 3.0)を、数学的に等価なx x xに置き換えています。torch-spyreスタックではこちらの式をコンパイルできます。一方、人間は診断作業を担い、デバイス上でのみ発生する融合演算に起因した障害を特定するとともに、各エージェントの結論をエンドツーエンドの結果と照合します。

2026年9月30日の投稿でIBMとRed Hatのエンジニアは、PyTorchのCross-Repository CI Relayとtorch-spyreのL2統合について説明しました。この統合により、上流のPyTorchに変更が加わると下流のテストが実行され、その結果がPyTorchのCIダッシュボードに報告されます。また、エージェントを活用した4段階のテスト選定パイプラインと、宣言的なYAMLテスト再利用フレームワークを組み合わせています。著者らによると、PyTorch 2.13から2.14へのアップグレードでは、数万件ではなく約4,000件の変更されたテストを評価すれば済みました。さらに、PyTorch OpenRegを参照点として、再利用可能な部分を上流に取り込むためPyTorchチームと協力する意向も示しています。

IBM Z、LinuxONE、Power11のユーザーに想定されているのは、Hugging Faceなどのエコシステムからモデルを入手し、Nvidia GPUで使う場合とほぼ同じPyTorchベースのワークフローを利用できる環境です。IBMの投稿によると、共通のPyTorch拡張ポイントがアーキテクチャ間の違いの多くを吸収します。vLLMに関する投稿の著者らは、CIにハードウェア非依存モデルを組み込み始め、Spyreでモデルを提供する際のデフォルトとして、この方式へ段階的に切り替える計画だと述べています。