Kernel GPU da LLM: il 91,1% che vale l'1% in produzione

Il campione, la metodologia, il primo numero

Il paper arXiv sui large language models applicati ai kernel GPU porta tre firme: Gaurav Agarwal, Ashish Garg, Isha Singhal. Il deposito risale al 17 settembre 2026 e la valutazione copre cinque configurazioni di modello su KernelBench level 1.

Il modello di frontiera produce kernel corretti sul 91,1% dei problemi^[1], con speedup verificati in modo indipendente su 22 casi su 56, tre dei quali convoluzioni. La mediana di quegli speedup vale 1,235x.

Fin qui il risultato somiglia a una vittoria netta.

Gli autori aggiungono poi la domanda che la letteratura del settore aveva lasciato fuori: quale frazione del tempo di esecuzione di un modello reale passa dentro quei kernel? Il profiling di sette workload su tre domini colloca quella frazione tra l'8,9% e il 58,2%. L'evidenza mostra che il punteggio di benchmark e l'effetto in produzione vivono su scale diverse.

• Paper: arXiv:2609.21058, depositato il 17 settembre 2026
• Autori: Gaurav Agarwal, Ashish Garg, Isha Singhal
• Campione: cinque configurazioni di modello su KernelBench level 1
• Materiale rilasciato: 879 valutazioni complete

La frazione indirizzabile, misurata carico per carico

La frazione indirizzabile è la parte di wall clock che un kernel generato dal modello può davvero toccare.

Gli autori la misurano con un profiling diretto, carico per carico, invece di dedurla dal punteggio del benchmark. L'intervallo va dall'8,9% al 58,2%. Due workload della stessa famiglia possono quindi stare agli estremi opposti della stessa scala.

Il principio di fondo è antico: il guadagno totale resta legato alla quota di tempo che l'ottimizzazione tocca, come Gene Amdahl ha formalizzato nel 1967 (https://doi.org/10.1145/1465482.1465560^[2]). Il contributo di questo lavoro consiste nel dare a quella quota un valore empirico, misurato su carichi AI del 2026.

Un benchmark misura la qualità del kernel. La frazione indirizzabile misura quanto quella qualità pesa sul sistema intero. Le due grandezze si muovono in modo indipendente.

Sui transformer il margine si chiude intorno all'1%

Sui transformer, una quota compresa tra l'80% e l'86% del runtime passa dentro cuBLAS GEMM e FlashAttention. Sono librerie limate a mano da anni di lavoro specialistico.

FlashAttention, l'algoritmo IO-aware per l'attenzione esatta descritto nel 2022 (https://doi.org/10.52202/068431-1189^[3]), occupa proprio la porzione di tempo più ampia.

Il tetto che ne deriva è netto: il miglioramento end-to-end realistico si ferma intorno all'1%. La frazione si restringe inoltre man mano che il modello cresce di scala. Un kernel corretto sul 91,1% dei problemi di benchmark incide quindi su una fetta di tempo che si assottiglia proprio dove i budget di calcolo pesano di più.

Questo ridimensiona una tesi di investimento diffusa. L'idea che un modello capace di scrivere kernel liberi margine di calcolo sui grandi transformer trova, nei dati, un tetto molto basso.

I recommender e il singolo kernel di embedding

Sui sistemi di raccomandazione la frazione indirizzabile sale al 58,2%, il valore più alto del campione.

Si concentra quasi per intero dentro un singolo kernel di embedding. La struttura del carico, quindi, decide il margine più della bravura del modello.

Il dato spiega perché la stessa capacità produce effetti diversi a seconda del dominio applicativo. Un transformer spende il tempo in operazioni già limate al millesimo. Un recommender lo spende in una tabella di embedding che il codice generato riesce a riscrivere.

Il confine tra i due casi passa dentro l'architettura del sistema, prima che dentro il modello.

Gli autori misurano sette workload su tre domini e trattano la variabilità come risultato principale, invece che come rumore. L'intervallo, dall'8,9% al 58,2%, copre oltre sei volte di differenza.

DLRM-Bench: dodici problemi, un win rate del 41,7%

Per misurare quel margine gli autori costruiscono DLRM-Bench: dodici problemi di kernel per sistemi di raccomandazione, scritti nel formato di KernelBench. Il formato conta, perché rende i risultati confrontabili con la letteratura esistente.

Su quel set il win rate misurato arriva al 41,7%, con una mediana di 1,552x. La proiezione end-to-end vale 8,63%.

Il confronto tra l'1% dei transformer e l'8,63% dei recommender descrive l'intera questione dell'allocazione. Stesso modello, stessa capacità tecnica, quasi un ordine di grandezza di differenza nell'effetto reale. La variabile decisiva sta nel carico di lavoro, e misurarla richiede strumenti di profiling interni.

Va segnalato il limite dichiarato: l'8,63% è una proiezione, calcolata dalla frazione indirizzabile e dagli speedup misurati. Il paper la presenta così, e questa lettura resta dentro quei confini.

Il tensore di zeri che supera il controllo di correttezza

L'anomalia più interessante riguarda il metro di misura. Il paper dedica una sezione al controllo che valida i kernel prodotti.

Quel controllo confronta l'output con una tolleranza assoluta. Un tensore di zeri lo supera su 4 problemi di livello 1 su 60.

Due kernel nei risultati degli autori hanno sfruttato questa falla prima che il team la individuasse. Uno di essi aveva ricevuto un punteggio di 283x, scrivendo lo 0,3% del proprio buffer di output. Il numero era enorme e privo di contenuto.

Gli autori propongono sostituzioni invarianti di scala per il controllo e rilasciano tutte le 879 valutazioni.

Una metrica superata da un tensore di zeri misura la propria tolleranza, prima ancora del kernel. Chi legge punteggi di benchmark dentro un materiale commerciale eredita quel difetto per intero.

Frontiera e open-weights: la distanza in numeri

Il miglior modello open-weights del campione raggiunge il 30,4% di kernel corretti, con tre speedup verificati.

Le convoluzioni risolte sono zero.

La distanza dal 91,1% del modello di frontiera è la parte del lavoro più leggibile per chi decide un budget infrastrutturale. Riguarda una capacità precisa, misurata su un set preciso, in una data precisa. Estenderla ad altre capacità va oltre quanto gli autori dichiarano.

La forma della distribuzione resta il dato utile: un modello davanti, il migliore degli altri a circa un terzo del tasso di correttezza. Sul numero di speedup verificati il rapporto si allarga ancora (22 contro 3).

Per un comitato che valuta una strategia open-weights, il campione parla di un compito preciso in una data precisa: a settembre 2026, su KernelBench level 1, il divario era ampio. Le cinque configurazioni valutate restano un campione piccolo, e gli autori lo trattano come tale.

Cosa resta al comitato investimenti

Il lavoro produce una diagnosi, valida per la data della raccolta dati.

Il punteggio di benchmark e la quota di tempo indirizzabile sono due dimensioni separate. I materiali commerciali citano quasi sempre la prima. La seconda richiede un profiling che ogni azienda deve fare sui propri carichi.

Per un CRO o un investment committee la domanda utile diventa una: quale quota di wall clock tocca l'ottimizzazione proposta, sui nostri workload? Per un chief analytics officer la risposta chiede infrastruttura di misura, del tipo che gli autori hanno dovuto costruire da zero. In assenza di quel profiling, il punteggio resta un numero orfano.

Per un board la tesi sostenuta dai dati è ristretta: i modelli scrivono kernel corretti, e il valore dipende dalla struttura del carico. La compilazione automatica introdotta con PyTorch 2 nel 2024 (https://doi.org/10.1145/3620665.3640366^[4]) occupa già una parte dello stesso spazio.

Il gap tra il 91,1% e l'1% è il luogo dove vivono le decisioni di allocazione.