IBM rende l’acceleratore Spyre un backend PyTorch di prima classe

In un articolo sul blog di IBM Research pubblicato il 26 ottobre 2026, IBM ha dichiarato che gli aggiornamenti software introdotti nell’ecosistema PyTorch nella seconda metà del 2026 hanno reso il suo acceleratore dataflow Spyre un backend PyTorch di prima classe, dando seguito a un piano delineato da IBM e dalla PyTorch Foundation nell’ottobre 2025.

IBM descrive Spyre come il proprio acceleratore IA dataflow, ottimizzato per l’inferenza e progettato per le aziende che eseguono applicazioni e modelli di IA insieme ai propri dati su sistemi IBM Z, LinuxONE e Power. La sua capacità di calcolo a precisione ridotta è destinata alle operazioni intensive sulle matrici tipiche della generazione linguistica e dei modelli di embedding. A differenza di una GPU tradizionale, che esegue i kernel sotto forma di flussi di istruzioni distribuiti tra gruppi di thread programmati, Spyre avvia i calcoli man mano che i dati raggiungono i suoi motori di calcolo.

Nella seconda metà del 2026, IBM, Red Hat e i collaboratori della PyTorch Foundation, tra cui Meta e Hugging Face, hanno introdotto aggiornamenti per abilitare i modelli fin dal primo giorno, supportare in vLLM modelli indipendenti dall’hardware, svolgere test continui di regressione e rilascio e integrare i dispositivi nativi, si legge nell’articolo. Alla PyTorch Conference 2025, in un articolo di IBM Research datato 21 ottobre 2025, IBM aveva dichiarato di voler potenziare ulteriormente il supporto a Spyre nel 2026, integrandolo come backend di prima classe nei flussi di lavoro di inferenza open source e concentrandosi su percorsi di compilazione unificati, generazione ottimizzata dei kernel e pianificazione trasparente su più acceleratori. IBM aveva già adottato vLLM come ambiente di esecuzione per l’inferenza e torch.compile come compilatore front-end per integrare acceleratori come Spyre; aveva inoltre contribuito un plug-in Spyre per vLLM che abilita l’attenzione paginata per l’inferenza dei modelli linguistici di grandi dimensioni.

Un compilatore ricostruito su Inductor

Al centro dell’integrazione c’è torch-spyre, un backend PyTorch che compila il normale codice PyTorch in un piano eseguibile per Spyre. La maggior parte della logica di un modello passa invariata attraverso il compilatore PyTorch; quando un’operazione non può ancora essere abbassata in modo efficace, un adattatore può sostituirla con una forma matematicamente equivalente e gestibile dal compilatore.

In un articolo della PyTorch Foundation pubblicato il 13 ottobre 2026, Dave Grove, Olivier Tardieu e il team IBM Spyre hanno descritto il passaggio del backend torch.compile di torch-spyre da sendnn, uno stack di compilazione costruito interamente da zero, a backend=inductor, un backend open source realizzato estendendo Inductor, il compilatore di PyTorch. Secondo gli autori, le misurazioni eseguite con l’analizzatore di codice lizard indicano che sendnn comprende circa 273.000 righe di codice C++ e Python distribuite in 6.170 funzioni, mentre l’estensione di Inductor conta circa 38.600 righe di Python in 1.878 funzioni: circa 7 volte meno righe e una complessità inferiore per funzione.

Spyre è un acceleratore da 75 watt collegato tramite PCIe, composto da 32 piccoli core connessi ad anello. Ciascun core dispone di una memoria scratchpad da 2 MB anziché di una cache condivisa e trasferisce i dati in blocchi fissi da 128 byte chiamati stick. Secondo l’articolo, il lavoro sul compilatore si è concentrato sul trasferimento dei dati a granularità di stick, sulla pianificazione della memoria scratchpad e sull’assegnazione dei core in fase di compilazione.

Tra i risultati riportati figurano una riduzione del 29–69% del tempo di esecuzione dei kernel matmul grazie alle scelte di suddivisione in blocchi e di layout; una riduzione del tempo mediano di esecuzione dei kernel softmax da 32,51 a 23,67 microsecondi — pari al 27% — grazie a una pianificazione che tiene conto della memoria scratchpad; e un kernel fuso in stile MLP che ha portato l’utilizzo dei core da circa due terzi a circa l’80%, riducendo al contempo il tempo di esecuzione dei kernel di circa il 17%. In un grafo sintetico progettato per mettere alla prova queste scelte, una nuova riorganizzazione del layout sul chip ha sostituito un trasferimento di andata e ritorno di 80 microsecondi verso la memoria del dispositivo con uno scambio di dati tra core di 1,1 microsecondi. L’articolo osserva inoltre che la necessità di torch-spyre di registrare decomposizioni specifiche per il dispositivo ha contribuito a migliorare il supporto di Inductor ai backend esterni all’albero dei sorgenti; questi miglioramenti sono stati integrati a monte in PyTorch 2.12 attraverso due richieste pull.

Integrazione nativa del dispositivo

Spyre diventa un dispositivo PyTorch nativo tramite la registrazione PrivateUse1, che assegna a tensor.to(“spyre”) una vera identità di dispositivo: la memoria allocata da PyTorch mantiene i tensori sul dispositivo, gli stream definiscono l’ordine delle operazioni e gli eventi di runtime collegano le attività dipendenti tra gli stream. La scheda ospita 32 core collegati da un anello ad ampia larghezza di banda, ciascuno con 2 MB di memoria scratchpad locale, e fino a 128 GB di LPDDR5 per tensori e programmi. L’attuale ambiente di esecuzione applica patch ai programmi al momento del lancio, sostituendo gli indirizzi simbolici dei tensori con quelli reali in tre passaggi ordinati.

In una dimostrazione con Granite 3.3 8B, con dimensione del batch pari a 1 e lunghezza della sequenza pari a 1024, lo spostamento della costruzione del grafo fuori dal percorso di trasferimento dei dati ha migliorato il prefill del 9,9% e la decodifica del 13,6%, ha riferito il team. Escludendo questa operazione anche dall’invio dei calcoli, i miglioramenti complessivi sono arrivati a un prefill 1,7 volte più veloce e a una decodifica 2,4 volte più veloce; circa tre quarti del guadagno sono derivati dal percorso di calcolo.

«Il vantaggio è che né Spyre né PyTorch devono fingere di essere qualcos’altro», hanno scritto gli autori in Realizzare Spyre come dispositivo PyTorch nativo, pubblicato l’8 ottobre 2026. Hanno aggiunto che Spyre mantiene il proprio modello di esecuzione dataflow, mentre gli utenti ottengono un dispositivo PyTorch nativo con modalità familiari di assegnazione dei tensori, stream e compilazione.

Portabilità di vLLM e il collegamento con Llm-D

Spyre è un acceleratore esterno all’albero del progetto, anziché una delle piattaforme GPU più comunemente supportate dai software di IA, e si affida a TorchDynamo per tracciare il grafo di un modello e a TorchInductor per adattarlo all’hardware di destinazione. In vLLM, meccanismi di estensione come CustomOp e PluggableLayer consentono a un plug-in hardware di personalizzare il comportamento senza dover reimplementare ampie parti dello stack software.

In Modelli indipendenti dall’hardware in vLLM, pubblicato il 22 settembre 2026 da autori di IBM, Meta e Hugging Face, il team ha descritto il passaggio di vLLM verso definizioni di modelli «piatte» e specifiche per l’hardware e ha presentato livelli indipendenti dall’hardware basati su quattro principi di progettazione: compilabilità, estensibilità, isolamento dai percorsi specifici dell’hardware e portabilità. Il supporto iniziale è già disponibile nel ramo principale di vLLM e può essere attivato con USE_HW_AGNOSTIC=1 nel backend Transformers. Il percorso è stato convalidato con il plug-in Spyre esterno all’albero del progetto su modelli come Gemma 4, Qwen3 e Granite 4.2; secondo quanto riferito dagli autori, sulle GPU NVIDIA H100 i livelli indipendenti dall’hardware hanno raggiunto un throughput complessivo di token entro il 3,4% da quello dell’implementazione nativa, misurato come media geometrica su tre modelli recenti.

L’integrazione di Spyre con PyTorch è anche il modo in cui si collega a llm-d, spiega l’articolo di IBM: llm-d esegue inferenze distribuite su più tipi di acceleratori basandosi su vLLM, vLLM raggiunge ciascun acceleratore tramite PyTorch e, una volta che un dispositivo dispone di un backend PyTorch funzionante, un plug-in hardware per vLLM può renderlo accessibile, così che llm-d possa assegnargli i carichi di lavoro.

Abilitazione fin dal primo giorno e test continui

Un articolo del 20 agosto 2026 del team IBM Spyre descrive HF-adapters, un progetto che usa agenti di programmazione per preparare patch di runtime che consentono ai modelli standard di Hugging Face Transformers di funzionare su Spyre. Da metà aprile a fine giugno 2026, 13 adattatori distinti sono arrivati a coprire 7.960 dei 10.000 modelli di embedding di Hugging Face più scaricati; secondo l’articolo, 6.804 di questi superano il test end-to-end su Spyre. Un esempio sostituisce torch.pow(x, 3.0), usato dall’attivazione gelu_new, con l’espressione matematicamente equivalente x x x, che lo stack torch-spyre è in grado di convertire; agli esseri umani resta il compito di diagnosticare i problemi, individuando gli errori che si verificano solo sul dispositivo e derivano da operazioni fuse e verificando le conclusioni di ciascun agente con i risultati end-to-end.

In un articolo del 30 settembre 2026, ingegneri di IBM e Red Hat hanno descritto l’integrazione L2 di torch-spyre con Cross-Repository CI Relay di PyTorch, che avvia test a valle in risposta alle modifiche apportate a PyTorch e ne invia i risultati alla dashboard CI di PyTorch. L’integrazione combina una pipeline agentica di selezione dei test in quattro fasi con un framework dichiarativo in YAML per riutilizzare i test; secondo quanto scritto dagli autori, il passaggio da PyTorch 2.13 a 2.14 ha richiesto di valutare circa 4.000 test modificati invece che decine di migliaia. Gli autori hanno aggiunto che intendono collaborare con il team PyTorch per integrare nel progetto le parti riutilizzabili, usando PyTorch OpenReg come riferimento.

Per gli utenti di IBM Z, LinuxONE e Power11, l’esperienza prevista consiste nell’ottenere modelli da ecosistemi come Hugging Face e nell’usare flussi di lavoro basati su PyTorch sostanzialmente identici a quelli impiegati con le GPU Nvidia; i punti di estensione condivisi di PyTorch nascondono gran parte delle differenze architetturali, afferma l’articolo di IBM. Gli autori dell’articolo su vLLM hanno dichiarato di voler iniziare a includere modelli indipendenti dall’hardware nei test CI e di passare gradualmente a questo percorso come impostazione predefinita per servire modelli su Spyre.