Portare un nuovo acceleratore in uno stack di serving per LLM è di solito un progetto che si misura in mesi. Il team IBM che lavora su Spyre ha scelto una strada diversa: in meno di una settimana, due sviluppatori e i loro coding agent AI hanno collegato SGLang all’acceleratore enterprise con un plugin di circa 1.500 righe. Il risultato non è un esperimento da laboratorio. SGLang su Spyre ha raggiunto un throughput circa 3,6 volte superiore all’implementazione di riferimento PyTorch basata su torch-spyre e prestazioni pari a vLLM sui workload misurati con Granite 3.3 8B e Gemma 4 26B A4B.

Alla base c’è il supporto hardware già disponibile in PyTorch. Torch-spyre registra Spyre come dispositivo PyTorch e lo collega a torch.compile, esponendo le operazioni dell’acceleratore attraverso API standard. Invece di riscrivere kernel o allocatori, il gruppo ha riusato il codice esistente. Non è un dettaglio: il lavoro di integrazione è diventato soprattutto un lavoro di connessione tra due astrazioni già esistenti. Gli agenti AI hanno usato come riferimento le implementazioni PyTorch delle operazioni di Spyre già presenti nel backend vLLM e hanno adattato il codice alle interfacce di SGLang.

Il conto delle righe non è neutrale

Il plugin SGLang conta circa 1.500 righe, contro le circa 3.500 del backend vLLM già disponibile per Spyre. La differenza non va letta come una gara di sintesi. Il team spiega che circa due terzi del divario derivano dal fatto che la classe base dell’attention in SGLang fornisce gran parte della logica circostante: il backend Spyre deve solo sovrascrivere l’operazione interna di scaled dot-product attention. In vLLM quella logica andava implementata in modo più esteso. Per chi mantiene integrazioni di acceleratori, è un segnale di come la struttura interna di un framework di serving possa ridurre o aumentare il costo di manutenzione.

SGLang, peraltro, non era pronto per un dispositivo non CUDA senza modifiche. Il lavoro ha richiesto quattro piccoli interventi: due per rendere disponibili percorsi di esecuzione senza dipendenze CUDA e due per registrare Spyre come dispositivo e backend di attention senza Triton. I primi due sono riutilizzabili da altri acceleratori; gli ultimi sono specifici per Spyre. Il prefix sharing tramite RadixCache, invece, ha funzionato senza alcuna modifica specifica: la condivisione dei prefissi viene risolta nello scheduler prima che l’esecuzione arrivi all’acceleratore. È una separazione dei compiti che ha permesso di concentrare il codice nuovo sulle primitive di calcolo, non sulla pianificazione della memoria. L’esempio di utilizzo pubblicato imposta max_running_requests=1 e disable_cuda_graph=True, segno che l’integrazione iniziale punta alla correttezza più che alla saturazione dell’hardware.

Il segnale per l’inference on-premise

Questa integrazione dice qualcosa di strutturale sul mercato degli acceleratori enterprise. Per anni, portare un serving framework su un processore non NVIDIA ha significato ricostruire pezzi significativi dello stack, spesso legati a CUDA. Qui la strada è stata diversa: il fornitore dell’hardware investe nel supporto PyTorch e torch.compile, mentre i punti di estensione di SGLang definiscono dove collegare il codice. Il risultato è che un team di due persone, con l’aiuto di coding agent alimentati da IA, può raggiungere un backend funzionante in giorni. Questo riduce la barriera all’ingresso per acceleratori non mainstream e sposta l’incentivo: la differenziazione non sta più solo nella potenza di calcolo, ma nella qualità e manutenibilità del supporto software.

È anche un indicatore per chi valuta deployment self-hosted. Un framework di serving come SGLang non è un componente monolitico legato a una singola piattaforma. I punti di estensione, il KV pool device-agnostic e il dispatch degli operatori consentono di collegare hardware specializzato senza riscrivere scheduler, gestione delle richieste e ciclo di serving. Il caso Spyre non garantisce che ogni acceleratore seguirà la stessa traiettoria, ma mostra che l’integrazione rapida è possibile quando il supporto hardware è espresso in PyTorch. Per chi osserva i trade-off del deployment on-premise, AI-RADAR pubblica framework analitici su /llm-onpremise per valutare questi scenari senza scorciatoie commerciali.

Il prossimo passo dichiarato è il supporto ai dynamic shapes e, più avanti, a Triton e RadixAttention, con l’obiettivo di aprire ulteriori ottimizzazioni dei kernel. Se questi pezzi arriveranno, il confine tra hardware specializzato e serving stack open source diventerà ancora più sottile.