Megakernels tornano al centro del dibattito sull'inference

“Nessun serio fornitore di inference usa in produzione un forward pass hand‑fused da 67 mila righe.” La frase, pronunciata in una masterclass su Inference Engineering, riaccende il confronto: megakernels “morti” per la produzione, “ancora utili” per tagliare latenza e overlap tra kernel¹.

Il campo favorevole è concreto. Investire settimane per fondere più operazioni in un unico kernel può ridurre l’overhead di lancio e l’overlap imperfetto tra kernel separati. La discussione ricorda che PDL ha già limato parte del problema, ma non del tutto. Restano “marginal gains” legati agli straggler tra le CTA, ossia i gruppi di thread lanciati sulla GPU che finiscono in tempi diversi. Entra “Rubin”, citato come meccanismo di scheduling: se il secondo kernel richiede 10 CTA e il primo ne ha già sette concluse e tre in coda, il secondo può partire subito con quelle sette. Su orizzonti lunghi, sostengono, la coda si livella e il vantaggio della fusione si assottiglia¹.

Arriva il contrappunto. Ali sostiene che “un kernel fuso non può salvarti” quando la pipeline usa tensor parallelism, cioè quando si suddivide una matrice tra più GPU. Se metà matrice sta su una GPU e l’altra metà su un’altra, e la fase successiva richiede l’intera matrice per un’operazione non lineare, la fusione non aggira quel vincolo: bisogna comunque attendere i dati completi prima di procedere¹.

Da qui l’etichetta “dead”. Chi la usa sostiene che, su archi temporali ampi, code e straggler si compensano, riducendo l’impatto dei megakernels rispetto a tecniche che coordinano meglio le CTA tra kernel successivi. C’è anche una barriera pratica: quelle 67 mila righe di codice non entrano nelle pipeline dei provider; chi le scrive lo fa per ricerca, non per il deployment¹.

I difensori dei megakernels non promettono miracoli. Puntano a ottimizzazioni puntuali: tagliare l’overhead di avvio e mitigare l’overlap imperfetto là dove PDL non basta e prima che strumenti come “Rubin” gestiscano meglio gli straggler. Se lo scheduling migliora, il vantaggio della fusione si riduce di conseguenza¹.

La masterclass menziona anche un lancio di Cursor, ma il baricentro resta sull’orchestrazione del calcolo GPU: un unico kernel grande contro una catena granulare con scheduling più accorto, a seconda dei colli di bottiglia osservati¹.

Per chi progetta inference, la traccia operativa è chiara: misurare dove si perde tempo. Overhead di lancio, straggler tra CTA, limiti del tensor parallelism e capacità dello scheduler (“Rubin” incluso) orientano la scelta tra fusione e coordinamento. La registrazione integrale raccoglie i casi e gli esempi citati, utile per decidere quando fondere e quando invece affinare lo scheduling tra kernel¹.