Il mondo dell’inference LLM si è a lungo retto su un patto non scritto: ogni motore di serving accumula percorsi ottimizzati per silicio, quantization e architettura di modello, fino a trasformare il runtime in un labirinto di casi speciali. TokenSpeed-kernel ribalta questa logica. Invece di nascondere la complessità, la confina in un sottosistema con un’API pubblica stabile e un meccanismo di selezione che sceglie il kernel giusto al volo.

Lo strato mancante tra runtime e silicio

La scommessa progettuale è chiara: il runtime non deve sapere nulla del backend. Quando il modello richiede un’operazione di attention o Mixture-of-Experts, chiama funzioni come mha_prefill, mha_decode_with_kvcache o moe_apply. A quel punto il selettore esamina le capacità della piattaforma e i tratti dichiarati da ogni kernel registrato, scartando quelli incompatibili e ordinando i candidati per priorità. Il risultato è un callable stabile per la combinazione modello-formato-hardware. Dietro le quinte, implementazioni specializzate (Gluon per AMD, CuteDSL o TensorRT-LLM per NVIDIA) restano perfettamente isolate, ciascuna con i propri vincoli di architettura e formato tensoriale.

La differenza rispetto ad approcci “a monolite” è profonda. Aggiungere supporto per un nuovo silicio non richiede di infilare controlli condizionali nel codice del modello; scrivere un kernel più veloce per una specifica forma di attention non costringe a toccare il serving stack. TokenSpeed-kernel offre persino strumenti di benchmarking e verifica numerica standalone, così lo sviluppo dei kernel può procedere al di fuori del server completo, con cicli di iterazione stretti.

AMD MI355X: la prova sul campo

Il banco di prova è GPT-OSS 120B, un modello moderno che combina attention con sliding window, attention sinks e MoE in formato MXFP4 con attivazioni FP8. Su una singola GPU AMD MI355X (architettura CDNA4), i kernel Gluon per attention fanno segnare un throughput in prefill da 1,4 a 2,3 volte superiore al riferimento Triton portabile e un vantaggio del 10-30% rispetto alla soluzione AITER con backend CK. Sul fronte MoE, dove il collo di bottiglia in decode è spesso il routing e il lancio dei kernel, i moduli Gluon adottano percorsi differenziati: per batch minuscole un warp-decode che fonde routing e GEMM, per batch medie un grouped GEMM con pipeline ridotta. Sui batch più piccoli il distacco è netto (1,7-2,1× su Triton, 1,1-1,6× su AITER); su quelli medi AITER recupera terreno, ma Gluon resta tra lo 0,9× e l’1,4× più veloce del Triton di base. Il throughput end-to-end misurato migliora da 1,6 a 3,6 volte rispetto al path Triton originale.

Cosa cambia per chi sceglie l’on-premise

L’architettura a plugin aperta di TokenSpeed-kernel ha implicazioni che vanno oltre l’ingegneria del software. Per le organizzazioni che valutano deployment on-premise – dove la scelta dell’hardware è dettata da TCO, disponibilità e vincoli di sovranità dei dati – disporre di un unico strato API che astrae sia AMD sia NVIDIA riduce la dipendenza da un singolo fornitore. I kernel ottimizzati per CDNA4 sono già rilasciati come pacchetto separato (tokenspeed-kernel-amd), utilizzabile da motori come vLLM senza adottare l’intero TokenSpeed. Questo significa che la comunità può portare accelerazioni hardware-specifiche su stack di serving diversi, abbassando la barriera per chi vuole costruire o gestire un parco GPU misto on-premise, in linea con valutazioni di TCO che spesso vedono AMD competitiva sul rapporto prezzo/prestazioni per l’inference.

Non si tratta solo di flessibilità. La separazione netta tra runtime e kernel, insieme agli strumenti di profiling e numerics, dà ai team la possibilità di validare le performance su forme di carico reali prima di impegnarsi in un fornitore o in una generazione di GPU. In un panorama in cui nuovi modelli e formati di quantization emergono ogni pochi mesi, la capacità di specializzare i kernel senza riscrivere il serving stack è un moltiplicatore di agilità.

Kernel come prodotto, non come scorciatoia

TokenSpeed-kernel normalizza un cambio di prospettiva: i kernel non sono più artefatti interni da proteggere, ma componenti pubblici, installabili e profilabili. Il registro centrale, le API operative e i meccanismi di selezione trasformano il lavoro di ottimizzazione hardware in un processo disciplinato, verificabile e riutilizzabile. In un ecosistema che si muove verso un’inference sempre più eterogenea – per silicio, formato e architettura di modello – avere un confine duro tra ciò che il runtime chiede e come il silicio risponde non è più un lusso: è la premessa per scalare il serving LLM senza accumulare debito tecnico.