IBM ha annunciato il completamento di una serie di aggiornamenti software che consentono all’acceleratore per intelligenza artificiale Spyre di operare come backend di prima classe nell’ecosistema PyTorch, attraverso un’integrazione sviluppata nella seconda metà dell’anno insieme a Red Hat e ad altri partecipanti alla PyTorch Foundation, tra cui Meta e Hugging Face. Il risultato concretizza il programma tecnico delineato nell’ottobre 2025, quando IBM aveva comunicato l’intenzione di rendere Spyre utilizzabile nei flussi di inferenza open source attraverso percorsi di compilazione unificati, generazione ottimizzata dei kernel e gestione di differenti architetture di accelerazione. Spyre è un processore AI basato su un’architettura dataflow, progettato per eseguire operazioni di inferenza sui sistemi IBM Z, LinuxONE e Power, consentendo alle organizzazioni di utilizzare modelli di intelligenza artificiale in prossimità delle applicazioni e dei dati aziendali. Il dispositivo impiega elaborazione numerica a precisione ridotta per accelerare le operazioni matriciali tipiche dei modelli linguistici e dei sistemi di embedding. A differenza delle GPU tradizionali, che eseguono sequenze di istruzioni organizzate in kernel e gruppi di thread pianificati, l’architettura Spyre attiva i processi di calcolo in funzione dell’arrivo dei dati alle unità di elaborazione, utilizzando una struttura hardware e un modello di esecuzione differenti rispetto a quelli generalmente adottati dagli acceleratori grafici.
L’integrazione si basa su torch-spyre, un backend che consente di compilare il codice PyTorch in un piano eseguibile sull’architettura Spyre senza richiedere una riscrittura completa delle implementazioni dei modelli. Il sistema utilizza TorchDynamo per acquisire e rappresentare il grafo computazionale e TorchInductor per trasformarlo in operazioni compatibili con l’hardware. La maggior parte delle istruzioni del modello attraversa il percorso di compilazione PyTorch senza modifiche sostanziali, mentre le operazioni non ancora supportate in modo efficiente possono essere sostituite da trasformazioni matematicamente equivalenti attraverso adattatori specifici. Uno degli interventi più importanti ha riguardato la sostituzione del precedente sistema di compilazione sendnn, sviluppato interamente da IBM, con un backend costruito estendendo direttamente Inductor. Il passaggio è stato documentato il 13 ottobre 2026 dal team IBM Spyre e ha comportato una riduzione rilevante della quantità di codice necessaria per gestire la compilazione. Secondo le misurazioni effettuate con lo strumento di analisi lizard, sendnn comprendeva circa 273.000 righe di codice C++ e Python distribuite in 6.170 funzioni, mentre la nuova estensione di Inductor utilizza circa 38.600 righe di Python e 1.878 funzioni. La nuova implementazione presenta quindi una dimensione complessiva inferiore di circa sette volte, accompagnata da una riduzione della complessità media delle funzioni.
Dal punto di vista hardware, Spyre è un acceleratore collegato attraverso interfaccia PCIe, con consumo nominale di 75 watt e 32 core di elaborazione di dimensioni contenute, connessi mediante una rete interna ad anello ad alta larghezza di banda. Ogni core dispone di 2 MB di memoria scratchpad locale, utilizzata per conservare temporaneamente dati e risultati intermedi senza dipendere da una cache condivisa. La scheda può integrare fino a 128 GB di memoria LPDDR5 destinata a tensori e programmi, mentre il trasferimento dei dati avviene attraverso unità fisse da 128 byte denominate stick. Questa organizzazione ha richiesto un lavoro specifico sul compilatore per gestire lo spostamento dei dati alla granularità prevista dall’hardware, pianificare l’utilizzo delle memorie locali e assegnare le operazioni ai diversi core durante la fase di compilazione. Le ottimizzazioni comprendono la scelta delle dimensioni dei blocchi di elaborazione, l’organizzazione dei layout dei tensori, la disposizione dei dati nelle memorie scratchpad e la riduzione dei trasferimenti tra memoria esterna e unità di calcolo. L’obiettivo è sfruttare le caratteristiche del modello dataflow senza obbligare i framework applicativi a riprodurre direttamente la struttura fisica del processore.
I risultati prestazionali pubblicati dal team di sviluppo mostrano miglioramenti misurati su kernel e grafi computazionali specifici. Le modifiche alle strategie di tiling e alla disposizione dei dati hanno ridotto i tempi di esecuzione dei kernel di moltiplicazione matriciale tra il 29% e il 69%, a seconda della configurazione considerata. Le ottimizzazioni della pianificazione basate sulla disponibilità della memoria scratchpad hanno diminuito il tempo mediano di un kernel softmax da 32,51 a 23,67 microsecondi, corrispondenti a una riduzione del 27%. In un kernel fuso assimilabile a un multilayer perceptron, l’utilizzo dei core è aumentato da circa due terzi della capacità disponibile a circa l’80%, mentre il tempo di elaborazione si è ridotto approssimativamente del 17%. Un ulteriore intervento ha riguardato la riorganizzazione dei tensori direttamente all’interno della rete di comunicazione del processore: in un grafo sintetico costruito per verificare il comportamento del sistema, un trasferimento che avrebbe richiesto un passaggio attraverso la memoria del dispositivo con una latenza di 80 microsecondi è stato sostituito da uno scambio tra core completato in 1,1 microsecondi. Questi valori riguardano le specifiche operazioni sottoposte a misurazione e non rappresentano un incremento uniforme delle prestazioni per qualsiasi modello o carico applicativo.
Il riconoscimento di Spyre come dispositivo nativo di PyTorch costituisce un secondo elemento fondamentale dell’integrazione. Attraverso il meccanismo PrivateUse1, previsto dal framework per registrare dispositivi di accelerazione esterni, Spyre acquisisce un’identità utilizzabile direttamente nelle operazioni sui tensori. Gli sviluppatori possono quindi trasferire i dati sul dispositivo mediante istruzioni come tensor.to("spyre"), affidando al sistema di allocazione di PyTorch la gestione della memoria residente sull’acceleratore. L’implementazione comprende inoltre il supporto ai flussi di esecuzione, o stream, che definiscono l’ordinamento delle operazioni, e agli eventi utilizzati per sincronizzare attività dipendenti distribuite su flussi differenti. Il runtime di Spyre gestisce gli indirizzi di memoria dei tensori attraverso una procedura di aggiornamento dei programmi al momento del lancio, sostituendo gli indirizzi simbolici con quelli effettivi mediante tre passaggi ordinati. L’integrazione permette di utilizzare le normali astrazioni di PyTorch relative alla collocazione dei dati, alla compilazione e alla gestione dell’esecuzione, mantenendo contemporaneamente il funzionamento interno dell’architettura dataflow.
Le modifiche introdotte nel runtime sono state valutate anche mediante il modello Granite 3.3 8B, utilizzando una dimensione di batch pari a uno e una sequenza di 1.024 token. In questa configurazione, lo spostamento della costruzione del grafo computazionale al di fuori del percorso dedicato al trasferimento dei dati ha prodotto un miglioramento del 9,9% nella fase di prefill e del 13,6% nella fase di decode. Un’ulteriore riorganizzazione ha eliminato parte del lavoro di costruzione del grafo anche dalla fase di dispatch computazionale, consentendo di ottenere una velocità di prefill pari a 1,7 volte quella iniziale e una velocità di decode pari a 2,4 volte quella di riferimento. Secondo le misurazioni del team, circa tre quarti del miglioramento complessivo sono riconducibili alle ottimizzazioni del percorso di calcolo. I risultati mostrano l’incidenza delle operazioni di preparazione e gestione dei grafi sulle prestazioni dell’inferenza, soprattutto quando l’esecuzione coinvolge sequenze di operazioni frequenti e trasferimenti che devono essere coordinati con i core dell’acceleratore.
Un’altra componente del programma riguarda l’integrazione di Spyre con vLLM, il runtime open source utilizzato per l’inferenza dei modelli linguistici. IBM aveva già adottato vLLM come ambiente di esecuzione e torch.compile come interfaccia di compilazione, sviluppando un plugin Spyre che introduce il supporto alla paged attention, tecnica impiegata per gestire in modo efficiente la memoria necessaria durante la generazione dei token. L’evoluzione più recente comprende il lavoro sulle definizioni hardware-agnostic dei modelli, descritto il 22 settembre 2026 da sviluppatori di IBM, Meta e Hugging Face. In questo approccio, i componenti del modello vengono progettati per essere compilabili, estensibili e indipendenti dai percorsi specifici dei singoli acceleratori, limitando la necessità di mantenere implementazioni differenti per ogni architettura. Le funzionalità di estensione CustomOp e PluggableLayer consentono ai plugin hardware di personalizzare alcune operazioni senza sostituire intere parti dello stack software. Il supporto iniziale alle componenti hardware-agnostic è già stato integrato nel ramo principale di vLLM e può essere attivato attraverso la variabile USE_HW_AGNOSTIC=1 quando si utilizza il backend Transformers.
Il nuovo percorso è stato verificato utilizzando il plugin Spyre distribuito separatamente dal progetto principale, con modelli comprendenti Gemma 4, Qwen3 e Granite 4.2. La compatibilità è stata esaminata anche su acceleratori NVIDIA H100, dove le implementazioni hardware-agnostic hanno raggiunto un throughput complessivo di token con una differenza entro il 3,4% rispetto alle versioni native, calcolata come media geometrica dei risultati ottenuti su tre modelli recenti. Le modifiche permettono inoltre di collegare Spyre all’architettura llm-d, destinata alla gestione distribuita dell’inferenza su differenti acceleratori. In questo sistema, llm-d coordina l’esecuzione distribuita attraverso vLLM, mentre vLLM utilizza PyTorch come livello di accesso ai dispositivi. La disponibilità di un backend PyTorch funzionante consente quindi a un plugin hardware di esporre Spyre all’infrastruttura di inferenza distribuita, rendendo possibile l’assegnazione dei carichi all’acceleratore senza sviluppare un percorso applicativo completamente separato.
IBM ha affiancato all’integrazione del compilatore un progetto dedicato alla disponibilità tempestiva dei modelli pubblicati nell’ecosistema Hugging Face. Il sistema HF-adapters utilizza agenti di programmazione per proporre modifiche ai componenti di runtime che impediscono l’esecuzione diretta di alcuni modelli Transformers su Spyre. Tra la metà di aprile e la fine di giugno 2026 sono stati sviluppati tredici adattatori distinti, in grado di coprire 7.960 dei 10.000 modelli di embedding maggiormente scaricati da Hugging Face. Di questi, 6.804 hanno superato i test end-to-end eseguiti sull’acceleratore. Un esempio riguarda l’attivazione gelu_new, nella quale l’operazione torch.pow(x, 3.0) può essere sostituita con il prodotto matematicamente equivalente x * x * x, rappresentazione che il compilatore torch-spyre è in grado di elaborare. Gli agenti vengono utilizzati per preparare le modifiche, mentre gli sviluppatori mantengono il controllo sulle diagnosi, sull’individuazione degli errori che si manifestano esclusivamente durante l’esecuzione sul dispositivo e sulla verifica dei risultati finali. La necessità di intervenire su operazioni matematicamente equivalenti ma rappresentate in modo differente evidenzia il ruolo dei meccanismi di decomposizione e trasformazione degli operatori nella compatibilità tra framework e acceleratori.
Il mantenimento della compatibilità nel tempo è stato affrontato anche attraverso l’integrazione di torch-spyre con il sistema Cross-Repository CI Relay di PyTorch, descritta il 30 settembre 2026 dagli ingegneri IBM e Red Hat. Il collegamento di livello L2 permette di avviare test sui progetti dipendenti quando vengono introdotte modifiche nel repository principale di PyTorch e di riportarne gli esiti nella dashboard di integrazione continua del framework. La soluzione combina una pipeline agentica di selezione dei test articolata in quattro fasi con un sistema dichiarativo di riutilizzo delle verifiche, configurato mediante file YAML. Durante l’aggiornamento da PyTorch 2.13 a PyTorch 2.14 è stato così possibile concentrare l’analisi su circa 4.000 test modificati, evitando di rieseguire indiscriminatamente decine di migliaia di verifiche. IBM e Red Hat intendono collaborare con il team PyTorch per trasferire nel progetto principale le componenti riutilizzabili del sistema, utilizzando PyTorch OpenReg come riferimento. Parallelamente, le esigenze di torch-spyre relative alla registrazione di decomposizioni specifiche per il dispositivo hanno contribuito a migliorare il supporto di Inductor ai backend mantenuti esternamente al repository principale, attraverso due modifiche integrate in PyTorch 2.12.
L’insieme degli interventi consente agli utenti dei sistemi IBM Z, LinuxONE e Power11 di avvicinarsi a un modello operativo nel quale i framework e i modelli disponibili nell’ecosistema PyTorch e Hugging Face possono essere utilizzati attraverso procedure sostanzialmente comuni a quelle impiegate con gli acceleratori NVIDIA, pur mantenendo percorsi di compilazione ed esecuzione specifici per Spyre. I prossimi sviluppi previsti comprendono l’inserimento progressivo delle definizioni hardware-agnostic nei processi di integrazione continua di vLLM e la loro successiva adozione come percorso predefinito per l’esecuzione dei modelli sull’acceleratore IBM. La nuova integrazione riguarda quindi non soltanto il supporto di Spyre come destinazione di compilazione, ma anche la gestione nativa dei dispositivi, la portabilità dei modelli, l’esecuzione distribuita e l’automazione dei test di compatibilità. Le prestazioni pubblicate rimangono riferite alle specifiche configurazioni sottoposte a verifica, mentre il percorso software permette di utilizzare l’architettura dataflow di Spyre all’interno degli strumenti open source adottati per lo sviluppo e la distribuzione dei sistemi di inferenza AI.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI).